Opened 12 years ago

Closed 5 years ago

#2423 closed defect (wontfix)

GDAL bug in data/cubewerx_extra.wkt (Google projection)

Reported by: Markus Neteler Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: svn-trunk
Severity: normal Keywords:
Cc: pkelly, msieczka

Description

Frank,

trying to create a "Google" location in GRASS from EPSG 900913, I discovered:

data/cubewerx_extra.wkt:

900913,PROJCS["Google Maps Global
Mercator",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Mercator_2SP"],
PARAMETER["standard_parallel_1",0],PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",0],PARAMETER["false_easting",0],PARAMETER["false_northing",0],
UNIT["Meter",1],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"]]

while PROJ4 says:

grep '^<9' /usr/local/share/proj/esri.extra
<900913> +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 <>

GRASS apparently takes the definition from cubewerx_extra.wkt first part so it's coming out incorrectly:

g.proj -c epsg=900913 loc=google

GRASS 6.4.svn (google):~ > g.proj -w
PROJCS["Mercator",
    GEOGCS["wgs84",
        DATUM["WGS_1984",
            SPHEROID["WGS_1984",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Mercator_2SP"],
    PARAMETER["standard_parallel_1",0],
    PARAMETER["central_meridian",0],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

GRASS 6.4.svn (google):~ > g.proj -p
-PROJ_INFO-------------------------------------------------
name       : Mercator
proj       : merc
datum      : wgs84
ellps      : wgs84
lat_ts     : 0.0
lon_0      : 0.0
x_0        : 0.0
y_0        : 0
k          : 1.0
nadgrids   : @null
wktext     : defined
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : Meter
units      : Meters
meters     : 1

Could cubewerx_extra.wkt be fixed? Or is GRASS broken (it works for others well) to pick up definitions?

thanks, Markus

Change History (6)

comment:1 Changed 12 years ago by Markus Neteler

Summary: GDAL bug in data/cubewerx_extra.wkt?GDAL bug in data/cubewerx_extra.wkt (Google projection)

Renaming /usr/local/share/gdal/cubewerx_extra.wkt to something else leads to:

g.proj -c epsg=900913 loc=google2
ERROR 6: EPSG PCS/GCS code 900913 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
ERROR: Unable to translate EPSG code

This suggests that the second part of the definition is ignored.

markus

comment:2 Changed 12 years ago by pkelly

My only concern here (although it could be considered a separate issue) is that I feel this cubewerx_extra.wkt file should not be being picked up at all: GRASS installs a local copy of the GDAL *.csv files, and g.proj calls SetCSVFilenameHook() to specify that this location should be searched for support files.

My installation doesn't recognise EPSG code 900913 at all, but it is clear that Markus' does, and now we can see it is from the cubewerx_extra.wkt file. So it seems that when OGR is failing to find 900913 in the GRASS copy of the files, it is looking elsewhere on the system rather than just failing. This seems a bit unpredictable to me, as there is perhaps a chance of picking up out-of-date data. My understanding was that SetCSVFilenameHook() was a complete override to the default search path, not just a "suggestion" of where else to search.

The thinking behind this was to have more control over which support files were used and not having to rely on perhaps a pre-installed version of GDAL that might not have also had the support files included with it. But perhaps it's not a big issue.

Paul

comment:3 Changed 12 years ago by msieczka

Cc: msieczka added

comment:4 Changed 5 years ago by Jukka Rahkonen

Is this a GDAL bug or GRASS bug or something else? I hope that neteler is reading.

comment:5 in reply to:  4 Changed 5 years ago by Markus Neteler

Replying to jratike80:

Is this a GDAL bug or GRASS bug or something else? I hope that neteler is reading.

Of course.

A fresh test:

GRASS 7.0.0svn (nc_spm_08_grass7):~ > g.proj -c epsg=900913 loc=google
ERROR 6: EPSG PCS/GCS code 900913 not found in EPSG support files.  Is this a valid
EPSG coordinate system?
ERROR: Unable to translate EPSG code

GRASS 7.0.0svn (nc_spm_08_grass7):~ > g.proj -c epsg=3857 loc=google
Location <google> created
You can switch to the new location by
`g.mapset mapset=PERMANENT location=google`

I suggest to close this as wontfix because epsg=900913 is not an official code.

comment:6 Changed 5 years ago by Jukka Rahkonen

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.