[gdal-dev] ogr2ogr reprojection, features are not transformed
even.rouault at mines-paris.org
Wed Nov 16 14:09:19 EST 2011
> 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).
Feel free to add a warning. Logically, this should be more in the shapefile
driver page. But this assumes that people actually read docs, which is dubious
> 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...
Yes shapefiles suffers from a lot of deficiencies (limitations of dbf format, no
native - documented - spatial indexing, prj files, ...) You might experiment
with spatialite which is far more capable, but still less 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
> 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
> whereas an example file (brazil.prj) has:
> however, GDAL can deal with these variations:
> $ gdalsrsinfo -o wkt_esri ESRI::brazil.prj
The conversion between GDAL WKT and ESRI WKT belongs to the field of
experimental science certainly. There are some known rules, but a lot of
particular cases, some still remaining to be unearthed. The version of
ogr_srs_esri.cpp in 1.8-esri branch is far more complicated than the one in
As far as your above algorithm is concerned, I'm wondering how it could work,
with the variations you gave above. Perhaps a statistical approach with fuzzy
string matching would give better results than something based on hashing ;-)
More seriously, I think that a campaign of collecting a lot of .PRJ files
(ideally coming from ESRI software, and not produced by GDAL) would be needed
first to see which rules can work in practice.
Another point to keep in mind is that the TOWGS84 parameters proposed by GDAL
do not always make concensus. The GRASS developers are not particularly happy
with that : they would prefer that a list of possible transformations would be
proposed when EPSG lists several of them, instead of just one picked up. See
More information about the gdal-dev