[gdal-dev] ogr2ogr reprojection, features are not transformed

[Etienne Tourigny]

Even,

Yes you are right! sorry about that.
I removed the .prj file from the and there is a small shift between the results.

It seems that setting source srs is needed when using shapefiles, as
you said.  This should be documented somewhere (probably on the
ogr2ogr page and/or shapefile driver page).

The more I use shapefiles the more I see the limitation in this file
format, and am quite puzzled as to why it is still so widespread...


Any other ideas on how we can fix this?
Here is how I think it could be done:

1- for all EPSG projections, generate its ESRI WKT (and perhaps a few
variations)
2- make a mapping from ESRI WKT (or its hash) to EPSG codes
3- use the hash mapping to find the EPSG code from a given WKT.

Does this make sense?

An obvious hurdle is that WKTs can have small variations.

For example,

EPSG:4618 as output by GDAL:
$ gdalsrsinfo -o wkt_esri EPSG:4618
GEOGCS["SAD69",DATUM["D_South_American_1969",SPHEROID["GRS_1967_Truncated",6378160,298.25]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]

whereas an example file (brazil.prj) has:
GEOGCS["SAD69",DATUM["D_South_American_1969",SPHEROID["GRS_1967_Modified",6378160,298.25]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]

however, GDAL can deal with these variations:
$ gdalsrsinfo -o wkt_esri ESRI::brazil.prj
GEOGCS["SAD69",DATUM["D_South_American_1969",SPHEROID["GRS_1967_Truncated",6378160,298.25]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]

cheers,
Etienne

On Tue, Nov 15, 2011 at 9:16 PM, Even Rouault
<even.rouault at mines-paris.org> wrote:
> Le mercredi 16 novembre 2011 00:02:24, Etienne Tourigny a écrit :
>> Even,
>>
>> I had tried that as I thought it could be the cause, however:
>>
>> I get the same result, although the +towgs84 parameters are set in the
>> source OGRCT.
>>
>> You can see the shapes are identical in size:
>> -rw------- 1 tourigny tourigny 371684 2011-11-15 20:52 LC_CIDADE_32722.shp
>> -rw------- 1 tourigny tourigny 371684 2011-11-15 19:35 LC_CIDADE_sad69.shp
>> -rw------- 1 tourigny tourigny 371684 2011-11-15 19:33 LC_CIDADE.shp
>> -rw------- 1 tourigny tourigny 371684 2011-11-15 20:46
>> LC_CIDADE_wgs84-2.shp
>
> Ah, and you didn't check the result with ogrinfo ? I can a difference when
> looking at the geometries.
>
> There's no reason that the .shp would have different sizes. Reprojection only
> affects the value of coordinate values, which in .shp are binary double. So
> whatever its value, a double value uses 8 bytes ;-)
>