QGIS » QGIS Application

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.

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

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.

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, can you tell me how this bug can effect GRASS?

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

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.

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

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?

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

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.

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

Milestone Version 1.0.2 deleted