Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5649 closed defect (invalid)

Getting projection name broken

Reported by: pberkes Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: 1.11.0
Severity: normal Keywords:
Cc:

Description

Requesting the projection name is broken in some cases, as shown in this example (Python):

>>> from osgeo import osr
>>> srs = osr.SpatialReference()
>>> srs.ImportFromProj4('+units=m +init=epsg:32155')
0
>>> srs.GetAttrValue('projcs')
'unnamed'

The GDAL_DATA environment variable is set to ".../share/gdal" in my Python distribution, which contains, among other files, "pcs.csv", which has a line

32155,"NAD83 / Wyoming East",9001,4269,14931,9807,1,0,4499,8801,40.3,9110,8802,-105.1,9110,8805,0.9999375,9201,8806,200000,9001,8807,0,9001,,,,,,

Change History (2)

comment:1 Changed 7 years ago by Even Rouault

Resolution: invalid
Status: newclosed

Using ImportFromProj4() goes through PROJ.4 library, which doesn't use GDAL CSV files and has no way of communicating a projection name to applications.

For what you want, use ImportFromEPSG(32155). That will set "NAD83 / Wyoming East" as PROJCS name

comment:2 Changed 7 years ago by pberkes

Hi rouault, thank you for the reply.

On a colleague's machine with pretty much the same set up (OSX, as well), the commands above return

'NAD83 / Whyoming East'

Also, if he edits the "pcs.csv" he can change the output and get, for instance,

'NAD83 / Whyowhyowhyoming East'

Judging from that, I suppose "osgeo" does look into the CSV file, maybe after going through the PROJ.4 library.

That said, the solution you gave works for me, but I'll need to parse the PROJ.4 string by hand...

All the best, Pietro

Note: See TracTickets for help on using tickets.