Bug report #1537

Units unknown in GRASS mapset creation for EPSG 26745

Added by John Tull almost 11 years ago. Updated about 10 years ago.

Status:Closed
Priority:Low
Assignee:nobody -
Category:GRASS
Affected QGIS version: Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:11597

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.

wkt_with_units_undetected.prj - WKT with units partially not recognised (180 Bytes) Markus Neteler, 2009-03-21 08:39 AM

History

#1 Updated by cgsbob - over 10 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.

#2 Updated by Markus Neteler over 10 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]],
        PRIMEM[[Greenwich]],
        UNIT[[degree]],
    PROJECTION[[Lambert_Conformal_Conic_2SP]],
    PARAMETER[[standard_parallel_1]],
    PARAMETER[[standard_parallel_2]],
    PARAMETER[[latitude_of_origin]],
    PARAMETER[[central_meridian]],
    PARAMETER[[false_easting]],
    PARAMETER[[false_northing]],
    UNIT[[US survey foot]]

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
).

#3 Updated by Markus Neteler over 10 years ago

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]],
        PRIMEM[[Greenwich]],
        UNIT[[degree]],
    PROJECTION[[Lambert_Conformal_Conic_2SP]],
    PARAMETER[[standard_parallel_1]],
    PARAMETER[[standard_parallel_2]],
    PARAMETER[[latitude_of_origin]],
    PARAMETER[[central_meridian]],
    PARAMETER[[false_easting]],
    PARAMETER[[false_northing]],
    UNIT[[unknown]]    <<-- !

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.

#4 Updated by Markus Neteler over 10 years ago

Replying to jctull:

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

Just to avoid confusion in this #

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

#5 Updated by cgsbob - over 10 years ago

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

#6 Updated by Markus Neteler over 10 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).

#7 Updated by John Tull over 10 years ago

Replying to [comment:5 neteler]:

Replying to jctull:

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

Just to avoid confusion in this #

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.

#8 Updated by arkygeek - over 10 years ago

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

#9 Updated by Martin Dobias over 10 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"63782064294978698213898AUTHORITY["EPSG""7008]],
      TOWGS84[-3,142,183,0,0,0,0],
      AUTHORITY[[EPSG""6267]],
    PRIMEM[[Greenwich"0AUTHORITY["EPSG""8901]],
    UNIT[[degree"00174532925199433AUTHORITY["EPSG""9108]],
    AUTHORITY[[EPSG""4267]],
    PROJECTION[[Lambert_Conformal_Conic_2SP]],
    PARAMETER[[standard_parallel_1]],
    PARAMETER[[standard_parallel_2]],
    PARAMETER[[latitude_of_origin]],
    PARAMETER[[central_meridian]],
    PARAMETER[[false_easting]],
    PARAMETER[[false_northing]],
    UNIT[[unknown]]

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

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

#10 Updated by Markus Neteler over 10 years ago

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]],       
    PARAMETER[[standard_parallel_2]],       
    PARAMETER[[latitude_of_origin]],                     
    PARAMETER[[central_meridian]],                       
    PARAMETER[[false_easting]],                       
    PARAMETER[[false_northing]],                            
    UNIT[[unknown]]                       

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

Old Style WKT[wkt_with_units_undetected.prj] = PROJCS[[unnamed"GEOGCS["NAD27"DATUM["North_American_Datum_1927"SPHEROID["Clarke 1866"63782064294978698213898]]PRIMEM["Greenwich"0]UNIT["degree"00174532925199433]]PROJECTION["Lambert_Conformal_Conic_2SP"]PARAMETER["standard_parallel_1"3546666666666667]PARAMETER["standard_parallel_2"3403333333333333]PARAMETER["latitude_of_origin"335]PARAMETER["central_meridian"-118]PARAMETER["false_easting"2000000]PARAMETER["false_northing"0]UNIT["unknown]]
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]],
        PRIMEM[[Greenwich]],
        UNIT[[Degree]],
    PROJECTION[[Lambert_Conformal_Conic]],
    PARAMETER[[standard_parallel_1]],
    PARAMETER[[standard_parallel_2]],
    PARAMETER[[latitude_of_origin]],
    PARAMETER[[central_meridian]],
    PARAMETER[[false_easting]],
    PARAMETER[[false_northing]],
    UNIT[[Foot_US]],
    PARAMETER[[scale_factor]]
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

#11 Updated by Frank Warmerdam - over 10 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 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 helps.

#12 Updated by cgsbob - over 10 years ago

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

#13 Updated by John Tull over 10 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

#14 Updated by Anonymous about 10 years ago

Milestone Version 1.0.2 deleted

Also available in: Atom PDF