Context Navigation

← Previous Ticket
Next Ticket →

#1537 closed bug (fixed)

Units unknown in GRASS mapset creation for EPSG 26745

Reported by:	jctull	Owned by:	nobody
Priority:	major: does not work as expected	Milestone:
Component:	GRASS	Version:	1.0.0
Keywords:	ogr grass mapset creation epsg:26745 units unknown	Cc:	neteler, warmerdam
Must Fix for Release:	No	Platform:	All
Platform Version:		Awaiting user input:	no

Description

A user reported that units are being reported as "unknown" for a new GRASS mapset created with the GRASS plugin. It was occurring, specifically, with epsg 26745 (California Zone V, NAD27). I verified the same on my build from trunk.

Creating the mapset within grass using the location wizard and epsg code 26745 produces the correct PROJ_UNITS (unit = US Survey Foot, and units = US Survey Feet). It is unclear why the PROJ_UNITS are unknown and unknowns for unit and units, respectively, when the mapset is created from qgis.

Attachments (1)

wkt_with_units_undetected.prj (180 bytes ) - added by neteler 15 years ago.: WKT with units partially not recognised

Download all attachments as: .zip

Change History (18)

comment:1 by cgsbob, 15 years ago

I can confirm this bug under Ubuntu Hardy Heron. I don't know what effect this bug will have. I would imagine it would affect area calculations at least.

comment:2 by neteler, 15 years ago

Using GRASS directly, it works:

GRASS 6.5.svn (nc_spm_07):~ > g.proj -c epsg=26745 loc=dd
Location dd created!

exit
grass65 ~/grassdata/dd/PERMANENT/

GRASS 6.5.svn (dd):~ > g.proj -w
PROJCS["Lambert Conformal Conic",
    GEOGCS["clark66",
        DATUM["North_American_Datum_1927",
            SPHEROID["Clarke_1866",6378206.4,294.9786982]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",35.46666666666667],
    PARAMETER["standard_parallel_2",34.03333333333333],
    PARAMETER["latitude_of_origin",33.5],
    PARAMETER["central_meridian",-118],
    PARAMETER["false_easting",2000000],
    PARAMETER["false_northing",0],
    UNIT["US survey foot",0.3048006096012192]]

GRASS 6.5.svn (dd):~ > g.proj -p
-PROJ_INFO-------------------------------------------------
name       : Lambert Conformal Conic
proj       : lcc
datum      : nad27
ellps      : clark66
lat_1      : 35.46666666666667
lat_2      : 34.03333333333333
lat_0      : 33.5
lon_0      : -118
x_0        : 609601.2192024384
y_0        : 0
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : US survey foot
units      : US survey feet
meters     : 0.3048006096012192

I suspect an GDAL/OGR issue (GRASS is calling those functions, see http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/proj/convert.c ).

comment:3 by neteler, 15 years ago

Cc:	neteler added

follow-up: 6 comment:4 by neteler, 15 years ago

Version:	HEAD → 1.0.0

Using QGIS Version_1_0 branch, I can replicate the problem:

Plugins -> GRASS -> New Mapset -> Next -> Create New location -> Next -> Projection -> EPSG-ID 26745 -> Search -> Next and so on...

Opening the created Location in GRASS shows:

GRASS 6.5.svn (testloc):~ > g.proj -w
PROJCS["Lambert Conformal Conic",
    GEOGCS["clark66",
        DATUM["North_American_Datum_1927",
            SPHEROID["Clarke_1866",6378206.4,294.9786982]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",35.46666666666667],
    PARAMETER["standard_parallel_2",34.03333333333333],
    PARAMETER["latitude_of_origin",33.5],
    PARAMETER["central_meridian",-118],
    PARAMETER["false_easting",2000000],
    PARAMETER["false_northing",0],
    UNIT["unknown",0.3048006096012192]]    <<-- !

The desired Unit should be "US survey foot" which is

grep 'US survey foot' *
unit_of_measure.csv:9003,US survey foot,length,9001,12,39.37,Used in USA.,EPSG,EPSG,2000-05-07,99.99,0

Since it works in GRASS, it seems to be a lookup problem in QGIS. I don't know how the EPSG lookup mechanism in QGIS works, so I dunno how to debug this further.

in reply to: description ; follow-up: 9 comment:5 by neteler, 15 years ago

Replying to jctull:

Creating the mapset within grass using the location wizard and epsg code 26745 ...

Just to avoid confusion in this ticket:

You meant to say "Creating the mapset within QGIS using the location wizard..." (using the GRASS location wizard there is no such problem).

in reply to: 4 comment:6 by cgsbob, 15 years ago

Markus, can you tell me how this bug can effect GRASS?

comment:7 by neteler, 15 years ago

cgsbob: since the number is used, I don't think that there is any affect. To be sure, just reproject a vector point to UTM/LL/whatever, one time with the broken name, one time with the corrected name in PERMANENT/PROJ_UNITS. I expect that the results are identical (better to test of course).

comment:8 by warmerdam, 15 years ago

Cc:	warmerdam added

in reply to: 5 comment:9 by jctull, 15 years ago

Replying to neteler:

Replying to jctull:

Creating the mapset within grass using the location wizard and epsg code 26745 ...

Just to avoid confusion in this ticket:

You meant to say "Creating the mapset within QGIS using the location wizard..." (using the GRASS location wizard there is no such problem).

Markus,

You are correct. Sorry for the typo. And thank you for doing a much better followup on the initial bug report.

comment:10 by arkygeek, 15 years ago

Platform:	All → OS X
Platform Version:	→ 10.5.6

I can confirm this in OSX as well from an install of all the latest frameworks etc from http://www.kyngchaos.com as of March 16 2009. QGis version reports as 1.0.1-Kore

comment:11 by arkygeek, 15 years ago

Platform:	OS X → All
Platform Version:	10.5.6

comment:12 by wonder, 15 years ago

Indeed it looks to be OGR problem as Markus suggested. From my tests - the proj4 string for this projection (epsg 26745) is:

+proj=lcc +lat_1=35.46666666666667 +lat_2=34.03333333333333 +lat_0=33.5 +lon_0=-118 +x_0=609601.2192024384 +y_0=0 +ellps=clrk66 +datum=NAD27 +to_meter=0.3048006096012192 +no_defs

When you import it to OGR and export as WKT, you'll get:

PROJCS["unnamed",
  GEOGCS["NAD27",
    DATUM["North_American_Datum_1927",
      SPHEROID["Clarke  1866",6378206.4,294.978698213898,AUTHORITY["EPSG","7008"]],
      TOWGS84[-3,142,183,0,0,0,0],
      AUTHORITY["EPSG","6267"]],
    PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],
    AUTHORITY["EPSG","4267"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",35.46666666666667],
    PARAMETER["standard_parallel_2",34.03333333333333],
    PARAMETER["latitude_of_origin",33.5],
    PARAMETER["central_meridian",-118],
    PARAMETER["false_easting",2000000],
    PARAMETER["false_northing",0],
    UNIT["unknown",0.3048006096012192]]

You can see that the units are set to unknown and not feet.

Probably this could be fixed in OGR... Frank?

by neteler, 15 years ago

Attachment:	wkt_with_units_undetected.prj added

WKT with units partially not recognised

comment:13 by neteler, 15 years ago

Keywords:	ogr added

Running attached WKT file through "testepsg" returns the same problem ("Foot_US" only recognised in the ESRified part):

testepsg wkt_with_units_undetected.prj
Validate Succeeds.                                         
WKT[wkt_with_units_undetected.prj] =                       
PROJCS["unnamed",                                          
    GEOGCS["NAD27",                                        
        DATUM["North_American_Datum_1927",                 
            SPHEROID["Clarke 1866",6378206.4,294.978698213898,
                AUTHORITY["EPSG","7008"]],                    
            TOWGS84[-3,142,183,0,0,0,0],                      
            AUTHORITY["EPSG","6267"]],                        
        PRIMEM["Greenwich",0,                                 
            AUTHORITY["EPSG","8901"]],                        
        UNIT["degree",0.0174532925199433,                     
            AUTHORITY["EPSG","9108"]],                        
        AUTHORITY["EPSG","4267"]],                            
    PROJECTION["Lambert_Conformal_Conic_2SP"],                
    PARAMETER["standard_parallel_1",35.46666666666667],       
    PARAMETER["standard_parallel_2",34.03333333333333],       
    PARAMETER["latitude_of_origin",33.5],                     
    PARAMETER["central_meridian",-118],                       
    PARAMETER["false_easting",2000000],                       
    PARAMETER["false_northing",0],                            
    UNIT["unknown",0.3048006096012192]]                       

Simplified WKT[wkt_with_units_undetected.prj] =
PROJCS["unnamed",                              
    GEOGCS["NAD27",                            
        DATUM["North_American_Datum_1927",     
            SPHEROID["Clarke 1866",6378206.4,294.978698213898],
            TOWGS84[-3,142,183,0,0,0,0]],                      
        PRIMEM["Greenwich",0],                                 
        UNIT["degree",0.0174532925199433]],                    
    PROJECTION["Lambert_Conformal_Conic_2SP"],                 
    PARAMETER["standard_parallel_1",35.46666666666667],        
    PARAMETER["standard_parallel_2",34.03333333333333],
    PARAMETER["latitude_of_origin",33.5],
    PARAMETER["central_meridian",-118],
    PARAMETER["false_easting",2000000],
    PARAMETER["false_northing",0],
    UNIT["unknown",0.3048006096012192]]

Old Style WKT[wkt_with_units_undetected.prj] = PROJCS["unnamed",GEOGCS["NAD27",DATUM["North_American_Datum_1927",SPHEROID["Clarke 1866",6378206.4,294.978698213898]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",35.46666666666667],PARAMETER["standard_parallel_2",34.03333333333333],PARAMETER["latitude_of_origin",33.5],PARAMETER["central_meridian",-118],PARAMETER["false_easting",2000000],PARAMETER["false_northing",0],UNIT["unknown",0.3048006096012192]]
ESRI'ified WKT[wkt_with_units_undetected.prj] =
PROJCS["Lambert_Conformal_Conic",
    GEOGCS["GCS_North_American_1927",
        DATUM["D_North_American_1927",
            SPHEROID["Clarke_1866",6378206.4,294.9786982]],
        PRIMEM["Greenwich",0],
        UNIT["Degree",0.017453292519943295]],
    PROJECTION["Lambert_Conformal_Conic"],
    PARAMETER["standard_parallel_1",35.46666666666667],
    PARAMETER["standard_parallel_2",34.03333333333333],
    PARAMETER["latitude_of_origin",33.5],
    PARAMETER["central_meridian",-118],
    PARAMETER["false_easting",2000000],
    PARAMETER["false_northing",0],
    UNIT["Foot_US",0.30480060960121924],
    PARAMETER["scale_factor",1.0]]
PROJ.4 rendering of [wkt_with_units_undetected.prj] = +proj=lcc +lat_1=35.46666666666667 +lat_2=34.03333333333333 +lat_0=33.5 +lon_0=-118 +x_0=609601.2192024384 +y_0=0 +ellps=clrk66 +datum=NAD27 +to_meter=0.3048006096012192 +no_defs

comment:14 by warmerdam, 15 years ago

The text associated with the foot units is not significant, it is just a clue for the user. The proper value is associated with the units keyword.

I have established that the WKT to PROJ.4 converter does not make an effort to use +units=us-ft unless the name of the units happens to exactly match an expected value which is presumably generally not the case when coming from EPSG which has a distinct name for the us foot units.

I do not consider this a bug, but it is certainly an annoyance, so I am filing a GDAL/OGR ticket on the issue: http://trac.osgeo.org/gdal/ticket/2901

I also suspect that this whole problem is alleviated by the change in qgis r10398 which makes it possible for qgis to work with coordinate systems even if they do not exactly match something in the coordinate system database.

I would suggest closing this ticket, possibly after confirming that r10398 helps.

comment:15 by cgsbob, 15 years ago

I just updated to r10398 and can confirm that QGIS-GRASS plugin creates a new mapset with the correct units.

comment:16 by jctull, 15 years ago

Resolution:	→ fixed
Status:	new → closed

comment:17 by (none), 15 years ago

Milestone:	Version 1.0.2

Milestone Version 1.0.2 deleted

Note: See TracTickets for help on using tickets.

Download in other formats: