[GRASS-user] Unusual [Open|ESRI]FileGDB: how to import

Even Rouault even.rouault at spatialys.com
Mon Oct 30 15:30:15 PDT 2017


On lundi 30 octobre 2017 22:28:27 CET Markus Metz wrote:
> On Mon, Oct 30, 2017 at 10:16 PM, Rich Shepard <rshepard at appl-ecosys.com>
> 
> wrote:
> > On Mon, 30 Oct 2017, Rich Shepard wrote:
> >>  The projection information I see looks acceptable to grass:
> >>  
> >>  
> >>  Why is WGS_1984 not recognized by grass7.3.svn? Have I used the
> 
> incorrect
> 
> >> EPSG code? And why doesn't grass find the correct datum when I let it
> >> create a new location?
> > 
> > Helmut,
> > 
> >   Markus M's fix for the segfault works. Because I used the same command
> > 
> > in the shell as the GUI used the non-recognition of the datum and the
> > segfault were of the same origin.
> > 
> >   My importing of FileGDB data has exposed a few bugs which is a good
> 
> thing.
> 
> > Markus' immediate fixes is an even better thing.
> > 
> > My thanks to both of you,
> 
> Thanks for testing GRASS 7.3!
> 
> The projection information is problematic because it is contradicting
> itself. WKT says datum and ellipsoid are WGS84, but the embedded proj.4
> string says there is no datum and the ellipsoid is a sphere because of
> "+a=6378137 +b=6378137".

Yes, this is because WebMercator is fundamentally a hack from a cartography point of view. It 
uses the spherical formulation of Mercator projection for an ellipsoid. PROJ.4 has no better 
way of expressing this has +a=6378137 +b=6378137 +nadgrids=@null.

A cleaner way would to add a new projection method in proj.4, let's say 
+proj=spherical_merc, and then you'd have:
+proj=spherical_merc +datum=WGS84

The pure WKT part of the WKT string reported by GDAL for EPSG:3857 is atually a lie. It 
shouldn't use PROJECTION["Mercator_1SP"] (ESRI uses a 
PROJECTION["Mercator_Auxiliary_Sphere"] instead.)
The way GDAL solves the issue is to add the
EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 
+y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs"] node so that the SRS is 
correctly exported to something that works with proj.4


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20171030/30cdb720/attachment.html>


More information about the grass-user mailing list