Re: [gdal-dev] Strange behaviour of gdal_translate

2009-05-29 Thread Antonio Valentino
Il giorno Fri, 29 May 2009 20:17:07 +0200 Even Rouault ha scritto: > Antonio, > > The behaviour you get is more or less expected. Generally in GDAL, > either you have a geotransform with its projection, either you have > GCPs with their associated projection. But having both at the same > time i

Re: [gdal-dev] non-fully conform output of gdalwarp

2009-05-29 Thread Even Rouault
Matthieu, I can also reproduce it with GDAL 1.6.1, but no longer with GDAL 1.7.0dev. Significatn changes have been done in trunk concerning preservation of citations in the GeoTIFF driver. The most significant for your use case is probably http://trac.osgeo.org/gdal/changeset/15993 that adds Im

Re: [gdal-dev] Strange behaviour of gdal_translate

2009-05-29 Thread Even Rouault
Antonio, The behaviour you get is more or less expected. Generally in GDAL, either you have a geotransform with its projection, either you have GCPs with their associated projection. But having both at the same time isn't really supported. The fact that the VRT seems to accept that is more an a

Re: [gdal-dev] GDAL Python Development: Area Selection

2009-05-29 Thread Even Rouault
I've added a few days ago the link in the http://trac.osgeo.org/gdal/wiki/GdalOgrInPython page (section Tutorial), with Chris permission. Le Friday 29 May 2009 20:08:05 Howard Butler, vous avez écrit : > On May 29, 2009, at 12:59 PM, Even Rouault wrote: > > * Someone brought my attention to the

Re: [gdal-dev] GDAL Python Development: Area Selection

2009-05-29 Thread Howard Butler
On May 29, 2009, at 12:59 PM, Even Rouault wrote: * Someone brought my attention to the following site, http://www.gis.usu.edu/~chrisg/python/, that has very interesting slides and exercices about how to use GDAL/OGR in Python. That's awesome! We need to spread links to that everywhere :)

Re: [gdal-dev] GDAL Python Development: Area Selection

2009-05-29 Thread Even Rouault
Pooven, We clearly miss a specific documentation for the GDAL Python bindings (contributions welcome !). The OGR ones have docstring help generated from C++ doxygen. Generally, the Python API is close to the C++ one that is documented on the website, but there are a few specific methods like R

[gdal-dev] Strange behaviour of gdal_translate

2009-05-29 Thread Antonio Valentino
Hi list, I'm trying to convert the attached virtual file into a regular geo-tiff. Note that the dataset defines both a geo-transform and GCPs but they have different projections. After conversion if I call gdalinfo on the result file I get $ gdalinfo out.tif Driver: GTiff/GeoTIFF Files:out.tif

Re: [gdal-dev] non-fully conform output of gdalwarp

2009-05-29 Thread Matthieu Rigal
Hi Ivan, I should have mentioned it, but I already tested it, by changing the DATUM, the file is nicely projected, but the header still has this unknown and unnamed fields... Could it actually come from my GEOS or proj4 libraries ? Or can it only come from GDAL ? Best regards, Matthieu On F

Re: [gdal-dev] non-fully conform output of gdalwarp

2009-05-29 Thread Lucena, Ivan
If you use DATUM["GRS_1980" instead of DATUM["D_GRS_1980" it might work. See http://spatialreference.org for more info. > ---Original Message--- > From: Matthieu Rigal > Subject: [gdal-dev] non-fully conform output of gdalwarp > Sent: May 29 '09 05:11 > > Hi guys, > > Working

Re: [gdal-dev] ogr2ogr encoding

2009-05-29 Thread Nico Mandery
Hi, I had a similar problem with german umlauts not to long ago. I solved it by specifing the client encodung in the postgresql connection string example: ogr2ogr -f PostgreSQL PG:"dbname=mydb options='-c client_encoding=latin1'" . hope it helps, nico Alexandre Dube schrieb: > Hi, > > I

[gdal-dev] non-fully conform output of gdalwarp

2009-05-29 Thread Matthieu Rigal
Hi guys, Working with GDAL 1.6.1, I got some strange result. It is not very compromising, because the result is OK, but it shall be enhanced, or I shall learn how to use it. giving the following command : gdalwarp -t_srs 'PROJCS["ETRS89_GRS80_3",GEOGCS["LUA_ETRS89",DATUM["D_GRS_1980",SPHEROID[