[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