#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)
Change History (18)
comment:1 by , 14 years ago
comment:2 by , 14 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 , 14 years ago
| Cc: | added |
|---|
follow-up: 6 comment:4 by , 14 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.
follow-up: 9 comment:5 by , 14 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).
comment:7 by , 14 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 , 14 years ago
| Cc: | added |
|---|
comment:9 by , 14 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 , 14 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 , 14 years ago
| Platform: | OS X → All |
|---|---|
| Platform Version: | 10.5.6 |
comment:12 by , 14 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 , 14 years ago
| Attachment: | wkt_with_units_undetected.prj added |
|---|
WKT with units partially not recognised
comment:13 by , 14 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 , 14 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 , 14 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 , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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.