Le 01/10/2015 10:42, Even Rouault a écrit :
>
> I don't think so. Looks like an issue with your GDAL and/or proj.4 install.
> The proj.4 string for EPSG:3857 reported above is wrong. It should be (as
> reported by gdalsrsinfo "EPSG:3857"):
>
> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=
Le 16/09/2015 17:57, Carl Godkin a écrit :
>
> Can you suggest a workflow to get what I want? Is there another tool
> for this I should use instead?
Hi,
You should consider using gdalwarp, which is a more powerful tool than
gdal_merge, that was written at the beginning to demonstrate how to use
Le 15/09/2015 16:06, Even Rouault a écrit :
> Hi,
>
> As announced, I have prepared a GDAL/OGR 1.11.3 release candidate. Please
> review and test.
>
It seems that another backport is missing :
# make -C swig/python generate
make : on entre dans le répertoire « /tmp/gdal-1.11.3/swig/python »
sw
Le 15/09/2015 19:07, Even Rouault a écrit :
>
> Contemplating if I should do the "official" backport of those 2 changesets to
> 1.11.3...
>
> Even
I think it is a good idea, because if you don't do it, distribution
maintainers will apply the patch without understanding the risks, since
poppler
Le 15/09/2015 16:06, Even Rouault a écrit :
> Hi,
>
> As announced, I have prepared a GDAL/OGR 1.11.3 release candidate. Please
> review and test.
>
Hi,
It seem that the patch for recent poppler versions has not been backported :
make[2] : on entre dans le répertoire « /tmp/gdal-1.11.3/frmts/
Le 2015-08-24 10:11, Jukka Rahkonen a écrit :
>
> Wouldn't it be time to bury 900913 permenently? There is also an open
> ticket
> about that https://trac.osgeo.org/gdal/ticket/5622
>
> -Jukka Rahkonen-
>
+1
Jean-Claude
___
gdal-dev mailing list
gd
Le 27/04/2015 16:55, jramm a écrit :
I'm writing a custom processing program using GDAL in C.
Have you tried gdal_translate on the same raster ?
Jean-Claude
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/g
Le 16/04/2015 00:25, Nicolas Ragg a écrit :
On 15/04/2015 07:59, Jean-Claude Repetto wrote:
Please run the command : gdalinfo -mdd ECW file.ecw
What are the metadata (ECW) :
PROJ= ?
DATUM= ?
Jean-Claude
Hello
Thank for your support, here they are :
PROJ=epsg:27592
DATUM=epsg:27592
Do
Le 15/04/2015 01:23, Nicolas Ragg a écrit :
Hello all
I have a french map in ECW format, i guess it is from IGN. Srs seems ok
but when i import
the thing in qgis or try to warp the file it is all shifted to north
(Around
Sweden).
Please run the command : gdalinfo -mdd ECW file.ecw
What are th
Le 24/10/2014 05:00, user_name a écrit :
How will I merge all the images that are for day 1, for day 2 and for day 3
and save each merged images to a new directory leaving only the
T/datayear/juliandate as the filename for each day. Merging files is easy
but doing it in batch and merging based
On 29/08/2014 04:09, precy wrote:
I have 4(sometimes 5) raster images and projected these using gdalwarp. I've
tried stitching these images using these commands gdal_merge.py -n 0
-a_nodata 0 -of GTiff -0 output.tif a.tif b.tif c.tif d.tif e.tif. The first
3 images was stitched and the last 2 ima
Le 01/07/2014 12:13, 00darki a écrit :
I've tried to use -a_ullr and -a_srs option but this doesn't make any
difference.
*gdal_translate.exe -a_ullr "-90" "90" "-180" "180" -a_srs "EPSG:4326"
Hi,
Your ullr parameters are not in the right order. Try :
gdal_translate -a_ullr -180 90 180 -90
Je
On 28/05/2014 19:48, Rémy GOURRAT wrote:
do i need to install the GDAL-1.11.0.win-amd64-py3.3.msi , i think
that’s it just for AMD Processor, right ?
Thanks for your help
Rémy Gourrat
Bonjour,
Since you are French, you may find useful to read this page :
http://geotribu.net/node/636
Jean-C
Le 27/05/2014 08:28, Chrishelring a écrit :
I´m trying to merge about 40 ecw files into one, using gdal_merge.py. it
seems to work (no error), but when I´m trying to open the file, it says,
"Unable to read header information: Cannot open file
c:\temp\ortofoto2007\ortofoto2007.ecw".
Hi,
Does th
On 27/03/2014 07:21, ridgewang wrote:
> Hi，
> I have 2 suggestions：
> 1. supply an option that can build the gdal using the static c++ runtime
> library, so we can use it not depends on the msvcr80.dll and msvcp80.dll.
>
Hi,
You can use gdalwarp to merge several files.
On 25/03/2014 00:01, Jed O. Kaplan wrote:
Dear Dmitriy,
Yes that is the correct projection code, but the problem is - and hence my
original question - that the “Times” projection referred to on the link you
sent me is not defined in proj4. I’m wondering if anyone has programmed it, or
if some
On 10/03/2014 05:47, ridgewang wrote:
> Hi,
> I want to use gdal_merge.py to merge two image files. But it reports
> cannot load _gdal library and %1 is not a valid win32 module. Here the %1
> means the _gdal, maybe. In python CUI, I run 'import osgeo.gdal' or 'import
> gdal' command,
On 28/02/2014 14:04, Jukka Rahkonen wrote:
I downloaded the failing tiff
http://trac.osgeo.org/gdal/raw-attachment/ticket/5403/1041up_1075down-938-960_spts-740-769-820-922_0.5-782-794_0.5_spts-935-1020_0.5_spts-cut2_spts.zip
Gdalinfo and gdal_translate had no troubles at all (Windows 7 64-bit,
On 08/02/2014 07:11, Stephen Woodbridge wrote:
I've run into a problem that I think is related to a change in the EPSG
definition for EPSG:32662
The symptom is that the image after gdalwarp reprojection is about 20km
south of where it should be.
Please post the gdalwarp command you have used.
Le 01/10/2013 16:21, Guillaume Sueur a écrit :
My use case is weird as I am using GDAL to reproject a WMS source which
doesn't offer web mercator (French Cadastral Parcels WMS) and needs some
computation on the URL (city code, CRS depending on location).
If I understand your solution, I can't di
Hello,
I confirm the problem.
I don't know how to fix the bug, nor if it really a bug in GDAL, but I
can provide a workaround : use EPSG:3857 instead of EPSG:3785, which is
obsolete.
gdalwarp -s_srs epsg:3857 -t_srs EPSG:4326 -of GTiff "Avenue de
Mont-de-Marsan.png" test.tif
Upper Left (
On 03/09/2013 01:32, nicholas.g.lawre...@tmr.qld.gov.au wrote:
> "ogr2ogr -f "MapInfo File" "C:\DATA\2013\08\osm2\australia_lines.tab"
> "C:\DATA\2013\08\osm2\australia-latest.osm.pbf lines"
I tried the command you suggested, but it returns this error
Unable to open datasource 'C:\DATA\2013\
Le 28/08/2013 17:03, Ismael BELAAOUAD a écrit :
Hello,
I'm trying to load GDAL Raster dataset into DIB (Device Independent Bitmap) in
C++ project.
Can someone help me with that?
Best regards,
Hi,
Have you read the tutorial at http://www.gdal.org/gdal_tutorial.html ?
Jean-Claude
_
On 26/08/2013 11:14, BigBaka wrote:
It's been a few months, but wondering if there are any instructions on how to
install this patch, or if tanasko managed to fix the error message saying
basic_string::_S_create
I also have the same problem on newly installed Ubuntu 12.04 with QGIS 1.8.
Any upd
On 24/08/2013 22:13, Murat Beyhan wrote:
Hi,
I have tried to do before but until I can't succeded please help me
how to convert utm data into geographic lat/lon data.
I have point and line data in shape file and I would like to convert it
into lat/long data
Hi,
The CRS of your file is incorr
Le 15/07/2013 15:26, William Kyngesburye a écrit :
Bummer, still no OS X support.
and no Linux support for ARM.
SDK 3.3 is still the best option.
Intergraph is killing the ECW format.
Jean-Claude
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Le 09/07/2013 08:44, Ahmet Temiz a écrit :
hello
Is there any way to fix this problem:
" tiles with different size, and irregular blocking"
regards
Please read this page carefully :
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Regards
Le 22/06/2013 20:21, Wolfgang16 a écrit :
Hi,
I am a beginner in GDAL and try to find out what works and what does not
work. I have installed the new ver. 1.10 on Windows XP SP3 and I am
especially interested in the new MAP driver. With the gcps2wld.py utility I
found a behaviour which I cannot
On 24/06/2013 23:03, Oyvind Idland wrote:
I got a tiled dataset from a client, consisting of 8 jpegs + jpw's.
These are used in a .vrt, and I get the following error: "IReadBlock
failed at X offset 0, Y offset 73".
Here is a sample dataset that fails:
https://dl.dropboxusercontent.com/u/3256172
Le 10/06/2013 17:44, Andre Joost a écrit :
What you see on the screen, is in fact projected, but with a simple one
degree = one unit on the screen projection. The extent of that map is
still +/- 180°/90°
This projection is the same as "Plate carrée" (EPSG:32663), except that
the units are deg
On 06/06/2013 18:54, Andrew Brooks wrote:
Hi
Just a couple of problems:
frmts/msg/msgcommand.cpp:434: error: 'sprintf' was not declared in
this scope
(needed a #include)
--with-rename-internal-libtiff-symbols=yes and
--with-rename-internal-libgeotiff-symbols=yes
.libs/libgdal.so: unde
On 31/05/2013 19:48, adi_khan wrote:
Thanks for your reply frank.
I understand that the GDAL I am using is ancient, but considering 'upgrading
to other version' not an option could you tell me if there's a way I can
mosaic using 1.4.5 only?
Another option is to use gdalwarp instead of gdal_merg
Le 18/04/2013 10:13, tanasko a écrit :
I did everything according to the instructions from this link:
http://wiki.openstreetmap.org/wiki/ECW#Howto_install_gdal_with_ECW_support
The libecwj2-3.3-wcharfix.patch patch is missing on this page.
___
gdal-d
Le 21/03/2013 15:12, Rainer M Krug a écrit :
Ah - now I understand it. "Well-known text" *is* a format of specifying
projections. I thought it was referring to "ascii text file" or something
along these lines. Maybe a link to a WKT format specification would be
useful or at least changing the te
On 24/01/2013 20:43, Elias Kotsifis wrote:
> Hello
>
> I want to calculate the elevation of any point on earth, giving lat,
> Long (for example like google elevation Api, or the earth tools:
> http://www.earthtools.org/webservices.htm # cheigit) based the ASTER
> GDEM MODEL V2.
> I went to downlo
On 24/01/2013 12:39, Jean-Claude Repetto wrote:
> Hello,
>
> I just tried to create a ticket, as I do usually. I logged in, filled in
> my ticked, pressed the button "Create Ticket", and I got these messages :
>
> You are currently not logged in. You may want to d
Hello,
This utility program is very useful to change georeferencing of a raster
without having to decompress and recompress it. It is a lot faster and
the quality is not changed.
I think it would deserve to be an official GDAL 1.10 command, not just a
Python sample.
Jean-Claude
__
This is the ticket I tried to file in Trac (see my previous message just
a minute ago) :
gdal2tiles.py seems to be broken in gdal-1.10 BETA 1;
$ gdal2tiles.py
File "/usr/bin/gdal2tiles.py", line 680
g.add_option("-g", "--googlekey", dest='googlekey',
Hello,
I just tried to create a ticket, as I do usually. I logged in, filled in
my ticked, pressed the button "Create Ticket", and I got these messages :
You are currently not logged in. You may want to do so now.
Error: Forbidden
TICKET_CREATE privileges are required to perform this operatio
Le 03/01/2013 17:29, Robb K. Wright a écrit :
I'm interested in trying out the -epo flag with gdal_translate, but it
doesn't seem to exist within the current Windows binaries
Which version ?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://l
On 21/12/2012 15:49, reina...@geodesign.com.br wrote:
> Ivan,
>
> Do you know the correct specification of GeoTiff's ProjectedCSTypeGeoKey
> for SIRGAS2000 EPSG: 31983?
>
> I get Unknown-31983 with gdal utility programs.
>
> Thanks,
GDAL knows this system :
$ epsg_tr.py 31983
PROJCS["SIRGAS 20
On 17/12/2012 13:13, Volkmar Herbst Agricon wrote:
> Dear all,
> I have a problem using gdal libraries (fwtools247) in .Net. I do need to
> reference the library in .net 4.0. It works in 3.5 but not with framework
> 4.0. Is there any way to use the libs in 4.0? Or could you give us some
> other sug
On 05/12/2012 22:19, Nik Sands wrote:
> Thanks for the reply. Just to clarify though, can you tell me what it is
> that is wrong about it?
>
The GCP coordinates look like UTM coordinates (UTM zone 36) :
Point01,xy,3051,328,in,deg,,0,N,,0,E, grid, 36, 673750, 3572910,N
So the projection is UTM,
On 05/12/2012 03:53, Nik Sands wrote:
> Hi GDAL devs,
>
> I have a problem with GDALSuggestedWarpOutput producing an error. It works
> for most of the files I've thrown at it, but I have one file that a user has
> sent me for which the error occurs. The file in question can be downloaded
> fo
On 29/11/2012 23:32, Nik Sands wrote:
> Thanks for the reply. Firstly, it did resolve my problem, so thanks very
> much for this information.
>
> However, I don't get that warning with gdalinfo .
You have to use the debug switch (look at the command I used in my
previous post).
___
Le 28/11/2012 22:54, Nik Sands a écrit :
After applying the suggested patch, it no longer errors out in the same way,
however, I now get another error just a little further on in my code.
-
Failed to get geo-transform (error 3) for file: Cradle Mountain_ozf.map
Le 28/11/2012 05:16, Nik Sands a écrit :
Hi GDAL-dev,
I've recently re-compiled GDAL from the trunk after the patch to fix UTM ozi files was
applied. This has worked well for most UTM files I've tried so far, but I've come across
one that produces a strange error in my code, but works OK with
Le 14/11/2012 00:44, Nik Sands a écrit :
Thanks very much for looking into this. I've filed the bug at
https://trac.osgeo.org/gdal/ticket/4894
I have submitted a patch (see ticket). I couldn't test it completely,
because you didn't provide image files matching the .map files.
So please tes
Le 13/11/2012 01:03, Nik Sands a écrit :
Thanks for the replies so far. Unfortunately, adding a 3rd calibration point
to the .map file has not helped. Of course I'm assuming that the added
calibration point is valid (eg, I tried the one suggested below, which looks
like it should be OK).
Do
Le 12/11/2012 09:10, Nik Sands a écrit :
I will try but don't have any Ozi products and am not confident I can create
one that is legitimate. The same may apply to the user who raised the issue
but I will check.
You don't need Ozi, only a text editor.
__
On 12/11/2012 08:16, Nik Sands wrote:
> Is that limitation actually built into GDAL?
> Because 2-point .map files are not uncommon, and so long as the two points
> are both different in both axes, then there should be no reason why a 3rd
> point in required (especially in UTM).
>
> Nik.
Have yo
On 12/11/2012 05:02, Nik Sands wrote:
>
> Please help me figure out why the two sets of .map files behave so
> differently. In particular, how can I get a spatial reference system for the
> failing .map files?
> (Content of two example files are below. First one is OK, second one fails.
> Le
Le 24/08/2012 07:24, Stefan Keller a écrit :
Hi,
The FWTools mentioned on the bottom of the download page of GDAL/OGR
Binaries [1] leads to releases where the latest build dates back to
2007.
I think there should be a note that FWTools are outdated and not
maintained any more - unless I'm wrong
On 27/07/2012 16:33, jkadlec wrote:
> Hi, I have a problem making GDAL work with ECW files on Fedora Linux 17.
> Here are the steps I did following the instructions on:
> http://trac.osgeo.org/gdal/wiki/ECW
> 1. I downloaded, installed and compiled libecwj 3.3 library
> 2. I downloaded the source o
Le 24/07/2012 09:44, Zoltan Szecsei a écrit :
Hi GDALers,
I need to convert ECW files to GeoTIFF (and not the other way round).
I have 20 or so files now, but will be getting >1000 of them, so batch
must be the way to go.
I would prefer a linux solution, but I see that the "free" Erdas SDK is
o
Le 17/07/2012 09:39, laurent celati a écrit :
Dear Mr. Loskot,
I would like compile gdal 1.9.1 from GDAL'S SVN then compile Qgis 1.8 from
source using Gdal SVN version because i 'm working on displaying postgis
raster data with qgis. And i noticed a bug with gdal 1.9 regarding overviews
(bug fix
On 07/13/2012 01:07 PM, laurent celati wrote:
> Hello,
>
> I would like compile gdal 1.9.1 from GDAL'S SVN then compile Qgis 1.8 from
> source using Gdal SVN version. I'm working on Windows 7 64bits.
>
> I am not in the habit of compiling software
>
> I did not used to compile software. Can you
On 07/08/2012 07:48 PM, aphunter wrote:
> Definitely, thanks for the help. I am sort of new to this stuff. Below is the
> imagery from the small images I'm testing with.
Hi,
Since you have reprojected one of the images, it has a black border. Try
to change the images order in the gdalwarp command.
Le 27/06/2012 15:52, Mac Wind a écrit :
With ASCII DXF
ogr2ogr -s_srs 27492.prj -t_srs 4326.prj myfile_WGS84.dxf myfile_ASCII12.dxf
I get this error message:
FAILED: Layer entities already exists, and -append not specified.
Consider using -append, or -overwrite.
Try to remove the
On 06/15/2012 04:46 PM, Martin Ouellet wrote:
> Hi,
>
> I manually georeferenced some images in ArcGIS and at the end, I got a
> .tfwx file and a aux.xml.
>
> I wish to convert them into geotiff with the georeferenced info in the
> header:
>
> 1) I've renamed the .tfwx into .tfw and run a gdal_t
Le 10/05/2012 10:26, Alexandre Gacon a écrit :
Where can I create a osgeo login ?
http://www.osgeo.org/osgeo_userid
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
On 05/10/12 08:27, Alexandre Gacon wrote:
Hi,
I have added an option on the Postgres driver for OGR to avoid
computation of the SRID of a spatial request when the SRID is known. Is
it possible to add it to the code repository ?
--
Alexandre Gacon
Hi,
You have to open a new ticket at :
http:
On 05/06/12 09:40, akshay gupta wrote:
Hi all,
I am writing an application to load vector maps/shape files using
gdal/ogr and display them onto a gui designed using Qt. I am new to
dealing with vector files, I am not able to decide how to render them on
GUI. Few approaches that come to my mind
On 03/22/12 21:57, Even Rouault wrote:
Oh well, if you can confirm the patch works, I'll end up commiting it. It isn't
too invasive.
Yes, your patch works. You can commit it, thanks.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osg
On 03/22/12 20:55, Even Rouault wrote:
I'm a bit hesitant to apply that for now. Hopefully Gentoo will revert their
change under user pressure. Please complain loudly in the ticket ;-)
It seems they have chosen the option to patch all the packages that are
using the OF macro.
For GDAL, see :
Le 22/03/2012 16:35, Kyle Shannon a écrit :
Jean Claude,
I have a gdal test machine running Ubuntu 11.10. I build zlib 1.2.6 and built
and linked gdal against it no problems. Probably doesn't help much.
It seems the problem is specific to Gentoo. Please read
https://bugs.gentoo.org/show_bu
Le 22/03/2012 14:53, Even Rouault a écrit :
Selon Jean-Claude Repetto:
Hello,
Since a few weeks, I have a problem to compile GDAL trunk on one of my
PCs. But it works on others, so I think there is a problem on the PC.
This PC runs Linux 32 bits (Gentoo), and gcc version is 4.5.3.
The first
Hello,
Since a few weeks, I have a problem to compile GDAL trunk on one of my
PCs. But it works on others, so I think there is a problem on the PC.
This PC runs Linux 32 bits (Gentoo), and gcc version is 4.5.3.
The first error occur in this line :
typedef voidpf (ZCALLBACK *open_file_func) OF(
Hello ,
Since this morning, "./configure" of the trunk version of GDAL returns
an error :
configure: error: FileGDBAPI not found.
Tested on Linux 32 bits and Linux 64 bits.
Regards,
Jean-Claude
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http:
Le 16/03/2012 09:55, Chrishelring a écrit :
Hi all,
very simple question (atleast I hope so ;). I need to check the version of
the ogr library included in my mapserver configuration, but cant seem to
find a way to do it. If I just enter ogr2ogr ind the shell no versionnumber
is presented.
ogr2
Le 28/02/2012 10:52, Sylvain MAFFREN a écrit :
Hi,
And thanks for your tests ! For those who want to make some tests with
the same file than me (tiff RGB - 293 Mo),I published it on a FTP server
My results on Gentoo Linux 64 bits and GDAL 1.9.0 :
Size = 16706521
Band 1
Minimum=0.000, Maxim
On 02/28/12 02:15, andreaerdna wrote:
- the 32-bit GDAL versions/builds 1.7.3 from www.gisinternals.com/sdk and
1.7.0b2 from FWTools 2.4.7 on 64-bit/32-bit Windows tested using
gdal_translate without a "TARGET" creation option behave the same way
producing an output ECW file of 164.417.131 bytes
On 02/07/12 21:41, Even Rouault wrote:
It would be extremely useful to have a Ozi driver that supports a wider
range of projections than the current iteration, and it seems slightly odd
that a developer who is ready to do the necessary work to improve the
driver is not being encouraged.
We hav
On 02/03/12 00:31, David Baker (Geoscience) wrote:
All,
Working in C#... I have need for EPSG:4418. Per
http://www.epsg-registry.org/ this is the code for “ProjectedCRS [NAD27
/ BLM 18N (ftUS)]”. This code does not seem to be in the GDAL/OGR/Prog4
database in FWTools2.4.7. Executing the line:
v
Le 30/01/2012 15:05, Jose Gomez-Dans a écrit :
I don't think they are the same. Plate Carree is an equidistance
cylindrical projection. I used a different EPSG (32662) for this same
data with success, although it shows are "deprecated"...:
http://spatialreference.org/ref/epsg/32662/
Jose
spa
Le 30/01/2012 14:28, Alfredo Alessandrini a écrit :
Hi,
I'm trying to reproject the VGT-P product with the gdal libraries.
The metafile is reported below.
It's right to assume the EPSG 4326 code as source spatial reference set?
Yes, I think so. But it is not a Plate Carrée projection, since
Le 30/01/2012 08:22, Jukka Rahkonen a écrit :
AksakTimur yahoo.com> writes:
Yes, the files that I try to open are jpgs and bmps.
I would guess that GDAL does not support .map files generally but only with the
OZF file format. http://gdal.org/frmt_ozi.html
GDAL supports only Ozi .map file
On 01/28/12 22:41, AksakTimur wrote:
Hey,
I'm new to GDAL and I have a problem when I try to open a raster file with a
.map worldfile(OziExplorer Map Data File):
Hello,
Can you post the .map file ?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Le 09/01/2012 17:06, Andreas Neumann a écrit :
Should I edit the world file? The image is a geotiff, so it doesn't have
a worldfile.
Thanks for any ideas.
Andreas
Hi,
You can use the new utility gdal_edit.py (in GDAL 1.9) to edit GeoTiff
metadata.
Frank, Even : It would be useful to add
Le 09/01/2012 14:24, Pepijn Van Eeckhoudt a écrit :
Our GIS toolkit takes a
different approach and defaults to +towgs84=0,0,0 instead.
Pepijn Van Eeckhoudt
Blindly adding "+towgs84=0,0,0" will unlikely give correct results.
You'll have to provide the correct datum transformation parameters
Le 28/11/2011 16:55, Jan Tappenbeck a écrit :
Hi !
i try to start a gdal_merge by win7 64 bit and the fwtools 2.4.7
gdal_merge.bat -ul_lr 2601660.7343 5477349.8203 2607572.5742
5475273.3574 -of GTiff -o %output%_number.tif %input%
Hi,
gdal_merge.py is only an example program to show how t
Le 16/11/2011 04:48, Chaitanya kumar CH a écrit :
Chris,
FWTools for Windows had not been maintained for quite a while. But the
Intersection() function should work with the latest. It uses gdal1.5
Hi,
Since FwTools is not maintained, I think the FwTools paragraph on the
page http://trac.osge
Le 03/11/2011 11:23, Jan Tappenbeck a écrit :
can andyone tell me how the command had to be for
"Consider using color table expansion (-expand option in
gdal_translate)" ???
This is explained in the documentation :
http://www.gdal.org/gdal_translate.html
In your case, I think you'll have to
Le 03/11/2011 10:45, Jan Tappenbeck a écrit :
i had transform some tif-files by epsg-code so the images will rotate
and at the border now some black triangles.
now i want to merge by gdalwarp
Hi,
Wouldn't it be easier to merge the maps before warping ?
Jean-Claude
___
Le 23/07/2011 16:17, Михаил a écrit :
Hello, everybody.
I have some images in TIFF format created in Photoshop. Also, I have
georeferncing for each file in txt.
If I'm working with BMP files, then i have no problems - I can use this
command line for example
gdal_translate -co COMPRESS=LZW -co JPE
On 09/24/11 14:45, dev4cx4...@snkmail.com wrote:
Success returns false, and UTMeast = -505516.60123597935 and UTMnorth =
959.7180830985
And the expected result was ...
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mai
On 09/22/11 19:03, Even Rouault wrote:
- gdal_edit reports no error when the parameters are wrong :
$ gdal_edit.py -mo KJHJKHJKHJ=GKFLLLMM France.ecw
I see nothing wrong here. It is perfectly valid to assign GKFLLLMM to
KJHJKHJKHJ metadata item. gdal_edit.py is meant as being generic, so if th
Le 01/09/2011 14:12, Even Rouault a écrit :
I've just commited a new changeset. Now the support for updating the header info
has been successfully tested on Linux 64bit with 3.3 SDK, Windows 32bit with 3.3
SDK and Windows 32bit with 4.2 Read-Only SDK.
At first, I had an issue with 4.2 Read-only
Le 22/09/2011 13:37, Jan Hartmann a écrit :
Found the answer to this one: use the "listgeo" and "geotifcp" utilities
from the Geotiff library (http://trac.osgeo.org/geotiff/). They are not
included in the gdal utilities, so you need them install them yourself.
Jan
There is a new GDAL utility p
Le 06/09/2011 14:12, Even Rouault a écrit :
I believe this should be fixed now by http://trac.osgeo.org/gdal/changeset/23067
.
The case that was dealt with before was when using ./configure
--with-ecw=/the/path/to/install/dir , but not ./configure --with-ecw[=yes]
which, I presume, is your use
Le 05/09/2011 19:24, Even Rouault a écrit :
If I add the libNCSEcwC.so library, it works:
I had updated configure.in and configure to include that new dependency. So try
./configure again.
I had run ./configure, so your changes are not sufficient, or there is
another problem.
I have noti
On 09/05/11 20:08, aperi2007 wrote:
But gdalwarp is a tool I never will think to use for this.
Is gdalwarp capable to merge raster ?
According to previous messages posted on this list, gdalwarp is THE tool
you must use to merge rasters. gdal_merge.py is only a demo script that
has been writ
Le 01/09/2011 14:12, Even Rouault a écrit :
Le jeudi 01 septembre 2011 01:56:04, Pinner, Luke a écrit :
Does this apply to the 4.x read-only version of the ERDAS ECW/JP2 SDK as
well as the old 3.3 SDK?
I've just commited a new changeset. Now the support for updating the header info
has been su
Le 01/09/2011 12:32, Marco Scheuble a écrit :
GDAL 1.4.4 doesn't support EPSG:900913, so I added the following lines to
'cubewerx_extra.wkt':
#
# EPSG:900913
#
900913,PROJCS["Google Maps Global
Mercator",GEOGCS["WGS84",DATUM["WGS_1984",SPHEROID["WGS84",6378137,298.25
Le 31/08/2011 14:13, Yves Jacolin a écrit :
Another question: I have 2 000 ECW files (40 Mo each), 49 ECW files (1 Go each)
and 2 ECW files (2 Go each). I worked first on 2 Go ECW file, it takes around 1
day to assign the projection information in the files.
Do you think this is normal? How can
On 07/24/11 10:09, Paul Lohr wrote:
If anyone has the libecwj file and they would like to share it, that would help
me out greatly. This is the ECW SDK that contains the source code (probably
version 3.3). According to the GDAL website, the file is probably named
libecwj2-3.3-2006-09-06.zip. I
Le 11/07/2011 12:12, Solimyr a écrit :
Thx, I tried to copy the file .prj but didn't work so I moved to use the
ogr2ogr method using -a_srs but I'm not able to do that...
I get the spatialRef using ogrinfo, like:
GEOGCS["GCS_WGS_1984",
DATUM["WGS_1984",
SPHEROID["WGS_1984",637813.
On 07/06/11 22:54, mett wrote:
Jean-Claude Repetto wrote:
Probably because your projection is not cylindrical. What projection are
you using ?
The projection is
`PROJCS["User-Defined WGS84/Lambert Conformal Conic (IS.)",GEOGCS["WGS
84",DATUM["WGS_1984",SPHEROID[
On 07/06/11 22:26, mett wrote:
Hello,
thank you very much for your reply. For example:
Upper Left = (*258321.25943477*, 655225.28062628)
Lower Left = (*258321.25943477*, 574605.28062628)
here the X value is the same (258321.25943477), so, I would aspect that also
the conversion is the same relate
On 07/06/11 21:43, mett wrote:
Hello everybody,
I'm using GDAL 1.8.0 with Java, and I do not why but I got different results
with TransformPoint with same inputs. Maybe I'm wrong, anyway see this:
Upper Left = (/258321.25943477/, 655225.28062628)
Abs: *-24.39163021771631*, 66.2996405709653
Lowe
1 - 100 of 196 matches
Mail list logo
