uDIG

MapServer and uDig off by some distance on french projection

Details

Description

From email (thanks Philippe de Franclieu):

Please check the PRIMEM parameters for the french projections.
The pb is the UOM :

  • PRIMEM["Paris", 2.33722917, AUTHORITY["EPSG","8903"]], (ie expressed in decimal degrees). It should read PRIMEM["Paris", 2.5969213, AUTHORITY["EPSG","8903"]], (ie expressed in grad,which is the default UOM).

BTW, note that there are some obsolete CRS (27582, 27592) in your EPSG database which parms cannot be retrieved on the OCEAN site (EPSG database version 6.11)
http://ocean.csl.co.uk/experimental/index.php

I hope this helps.
Regards

  1. PDF File
    ocean_crs_27572.pdf
    29/Mar/07 12:03 PM
    10 kB
    Jody Garnett
  1. IMG2007_181.jpg
    173 kB
    29/Mar/07 12:04 PM

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jody Garnett added a comment -
Here is the referenced pdf
Show
Jody Garnett added a comment - Here is the referenced pdf
Hide
Permalink
Philippe de Franclieu added a comment -
Could this be modified by the user (the value of the "8903" parameter), and saved?
Can I access the EPSG database? How?
Which version is used, 6-12?
Could a custom proj be saved by the user? How?
Show
Philippe de Franclieu added a comment - Could this be modified by the user (the value of the "8903" parameter), and saved? Can I access the EPSG database? How? Which version is used, 6-12? Could a custom proj be saved by the user? How?
Hide
Permalink
Jody Garnett added a comment -
You can use your own definition but placing it into a prj file (for the data) or by typing it on on the advanced tab for the map. The latest geotools uses a more recent version of the EPSG database (uDig trunk). The one included with uDig 1.1 is based on a text file format - if you send us the correction we can fix it.
Show
Jody Garnett added a comment - You can use your own definition but placing it into a prj file (for the data) or by typing it on on the advanced tab for the map. The latest geotools uses a more recent version of the EPSG database (uDig trunk). The one included with uDig 1.1 is based on a text file format - if you send us the correction we can fix it.
Hide
Permalink
Philippe de Franclieu added a comment -
Ok, I can type it on the advanced tab for the map, though it would be nice if it could be saved!

There are several formats available at http://www.epsg.org :
- Download EPSG Version 6.12 MS Access (zipped file). The MS Access [relational] database is only available in Access v97 but can be converted to Access 2000 or Access 2003. [Note that this zipped file is comprised of the database (in MS Access 97) and associated README documentation (in both Adobe Acrobat PDF and MS Word 97-2000& 6/95-rtf formats). The zipped file is approximately 2.5 mb in size.

- Download EPSG v6.12 SQL scripts providing a cross-platform version of the 6.12 tables (zipped file.) Three versions of these scripts are available: mySQL, Oracle or PostgreSQL. Details of additional SQL scripts to query the tables are given in Guidance Note 7 part 1 (see below).

"...if you send us the correction we can fix it. " : I already sent the correction.
See the PRIMEM "8903" parameters in the *.pdf file.
The UOM is grad, not decimal degrees and should read 2.5969213 (not 2.33722917)
Show
Philippe de Franclieu added a comment - Ok, I can type it on the advanced tab for the map, though it would be nice if it could be saved! There are several formats available at http://www.epsg.org : - Download EPSG Version 6.12 MS Access (zipped file). The MS Access [relational] database is only available in Access v97 but can be converted to Access 2000 or Access 2003. [Note that this zipped file is comprised of the database (in MS Access 97) and associated README documentation (in both Adobe Acrobat PDF and MS Word 97-2000& 6/95-rtf formats). The zipped file is approximately 2.5 mb in size. - Download EPSG v6.12 SQL scripts providing a cross-platform version of the 6.12 tables (zipped file.) Three versions of these scripts are available: mySQL, Oracle or PostgreSQL. Details of additional SQL scripts to query the tables are given in Guidance Note 7 part 1 (see below). "...if you send us the correction we can fix it. " : I already sent the correction. See the PRIMEM "8903" parameters in the *.pdf file. The UOM is grad, not decimal degrees and should read 2.5969213 (not 2.33722917)
Hide
Permalink
Jesse Eichar added a comment -
You can set it on the layer as well (right click and choose properties). In this case it will be saved... But only for that layer in that map.
Show
Jesse Eichar added a comment - You can set it on the layer as well (right click and choose properties). In this case it will be saved... But only for that layer in that map.
Hide
Permalink
Jody Garnett added a comment -
We just got a big email from Philippe talking about GDAL #1611
* http://trac.osgeo.org/gdal/ticket/1611

Looks like this is being put off to a later version of GDAL. Good Frank not changing things on a point release :-)
Show
Jody Garnett added a comment - We just got a big email from Philippe talking about GDAL #1611 * http://trac.osgeo.org/gdal/ticket/1611 Looks like this is being put off to a later version of GDAL. Good Frank not changing things on a point release :-)
Hide
Permalink
Martin Desruisseaux added a comment -
Just verified that Geotools 2.4 has the expected 2.5969213 value when using epsg-hsql module instead of the deprecated espg-wkt. If uDig trunk uses epsg-hsql, I would expect no offset there (may be worth to check).

The UOM for the prime meridian is the one declared in the GEOCS element according the WKT specification. Geotools is already compliant with this specification. It is not clear to me if GDAL is compliant or not, but the WKT[EPSG:4807] dump provided in GDAL #1611 suggests that it is not.

The WKT listed in the (deprecated) epsg-wkt module are derived from PostGIS. If PostGIS took them from the same library than GDAL, then Geotools is correct and the bug is rather in the library that produced those WKT. A short term fix would be to fix the prime meridian value at line "4807=" in the following file:

http://svn.geotools.org/geotools/trunk/gt/modules/plugin/epsg-wkt/src/main/resources/org/geotools/referencing/crs/epsg.properties

At longer term, uDig should abandon this deprecated epsg-wkt module and uses epsg-hsql instead. I would like to delete epsg-wkt completly in Geotools 2.5 since it is a source of many discrepancies.
Show
Martin Desruisseaux added a comment - Just verified that Geotools 2.4 has the expected 2.5969213 value when using epsg-hsql module instead of the deprecated espg-wkt. If uDig trunk uses epsg-hsql, I would expect no offset there (may be worth to check). The UOM for the prime meridian is the one declared in the GEOCS element according the WKT specification. Geotools is already compliant with this specification. It is not clear to me if GDAL is compliant or not, but the WKT[EPSG:4807] dump provided in GDAL #1611 suggests that it is not. The WKT listed in the (deprecated) epsg-wkt module are derived from PostGIS. If PostGIS took them from the same library than GDAL, then Geotools is correct and the bug is rather in the library that produced those WKT. A short term fix would be to fix the prime meridian value at line "4807=" in the following file: http://svn.geotools.org/geotools/trunk/gt/modules/plugin/epsg-wkt/src/main/resources/org/geotools/referencing/crs/epsg.properties At longer term, uDig should abandon this deprecated epsg-wkt module and uses epsg-hsql instead. I would like to delete epsg-wkt completly in Geotools 2.5 since it is a source of many discrepancies.
Hide
Permalink
Jody Garnett added a comment -
uDig 1.2 has migrated to epsg-hsql now - does that mean we can close this bug?
Show
Jody Garnett added a comment - uDig 1.2 has migrated to epsg-hsql now - does that mean we can close this bug?

People

  • Assignee:
    Unassigned
    Reporter:
    Jody Garnett
Vote (1)
Watch (1)

Dates

  • Created:
    Updated: