GeoTools

Bursa-Wolf parameters selection in the EPSG database

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.3.0, 2.4-M0
  • Fix Version/s: 2.7.6
  • Component/s: referencing
  • Labels:
    None

Description

Geotools currently try to select Bursa-Wolf parameters from the EPSG database using the following algorithm:

For a given source and target datum pair, we pickup the first set of parameters returned by a SQL statement that contains the following clause:

ORDER BY ABS(DEPRECATED), COORD_OP_ACCURACY, COORD_OP_CODE DESC

So deprecated parameters are last. If there is more than one non-deprecated set of parameters, the most accurate one is selected. If they all have the same accuracy, we choose the one with the highest primary key value, assuming that it is the most recently added. I admit that this last rule is not a very reliable one, but in the particular case of EPSG:4289, it seems to work.

However this algorithm lead to the selection of the following parameters for EPSG:4312 ("MGI"):

TOWGS84[426.9, 142.6, 460.1, 4.91, 4.49, -12.42, 3.5271281868253483]

This seem to be the values for Slovenia. The expected values should be:

TOWGS84[577.326, 90.129, 463.919, 5.1365988, 1.4742, 5.2970436, 2.4232]

This is in EPSG 6.12, Coordinate Transformation 1618: MGI to WGS 84 (3). The same issue apply to all projected CRS derived from the 4312 geographic CRS, like EPSG:31286

We need to improve the way Geotools selects the set of Bursa-Wolf parameters. Just looking at the source and target datum is not suffisient.

We also need a mechanism that warn the user when more than one set of Bursa-Wolf parameters were found for a given geographic CRS, so the user know that the set selected by Geotools may not be the most appropriate one. We also need a mechanism for forcing the selection of a particular set of Bursa-Wolf parameters, to override the automatic selection.

Issue Links

is related to

Wish - General wishlist item GEOS-1783 override an existing EPSG definition in the property file

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Peter Plumber added a comment -
Hi,

what is the suggested workaround until the problem will be solved?
for the moment I am using the gt2-epsg-wkt-2.X.X.jar with correct TOWGS84 section added to all PROJCS based on Datum Austria.

thanks

Peter

Show
Peter Plumber added a comment - Hi, what is the suggested workaround until the problem will be solved? for the moment I am using the gt2-epsg-wkt-2.X.X.jar with correct TOWGS84 section added to all PROJCS based on Datum Austria. thanks Peter
Hide
Permalink
Martin Desruisseaux added a comment -
I don't see any workaround right now. We need to hack straight into the EPSG factory code. If there is a volunter, it would be nice to make some experiments with the EPSG database. No need for Java programming, rather trying to see if we can find a more accurate SQL statement than the one written above.
Show
Martin Desruisseaux added a comment - I don't see any workaround right now. We need to hack straight into the EPSG factory code. If there is a volunter, it would be nice to make some experiments with the EPSG database. No need for Java programming, rather trying to see if we can find a more accurate SQL statement than the one written above.
Hide
Permalink
Andrea Antonello added a comment -
When trying to reproject two projections that need the towgs84 parameters, the geotools code from the following example:

CoordinateReferenceSystem mapCrs = CRS.decode("EPSG:3003");
CoordinateReferenceSystem gpsCrs = CRS.decode("EPSG:4326");
MathTransform mathTransform = CRS.findMathTransform(gpsCrs, mapCrs);
com.vividsolutions.jts.geom.Point gpsPoint = factory.createPoint(new Coordinate(longi, lat, elev));
reprojectedGpsPoint = JTS.transform(gpsPoint, mathTransform);

throws an exception complaining about the missing bursa wolf parameters.

This is right, since the towgs84 (or bursa wolf? are they the same thing?) can change the optimization of the transform. For example in the case of Italy, with the epsg 3003 there are three situations:
rome40 "towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68" "Italy (Peninsular Part)" "Accuracy 3-4m"
rome40 "towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48" "Italy (Sardinia)" "Accuracy 3-4m"
rome40 "towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08" "Italy (Sicily)" "Accuracy 3-4m"

and it would be important to be aware of the fact that these three things can result into meters of accuracy, which is very important not only in calculations, but also when doing overlay of data in different projections that need a certain precision.

I'm not a projection specialist, so I have no idea where these info could be kept, or if there should be 3 possible projections choosable for the 3003 code.
For as it was last time I saw it, GRASS keeps the towgs84 infomation (which they collect coninuosly) in a separate file and whenever an epsg is choosen, which needs those, the different possibilities are proposed to the user.


Show
Andrea Antonello added a comment - When trying to reproject two projections that need the towgs84 parameters, the geotools code from the following example: CoordinateReferenceSystem mapCrs = CRS.decode("EPSG:3003"); CoordinateReferenceSystem gpsCrs = CRS.decode("EPSG:4326"); MathTransform mathTransform = CRS.findMathTransform(gpsCrs, mapCrs); com.vividsolutions.jts.geom.Point gpsPoint = factory.createPoint(new Coordinate(longi, lat, elev)); reprojectedGpsPoint = JTS.transform(gpsPoint, mathTransform); throws an exception complaining about the missing bursa wolf parameters. This is right, since the towgs84 (or bursa wolf? are they the same thing?) can change the optimization of the transform. For example in the case of Italy, with the epsg 3003 there are three situations: rome40 "towgs84=-104.1,-49.1,-9.9,0.971,-2.917,0.714,-11.68" "Italy (Peninsular Part)" "Accuracy 3-4m" rome40 "towgs84=-168.6,-34.0,38.6,-0.374,-0.679,-1.379,-9.48" "Italy (Sardinia)" "Accuracy 3-4m" rome40 "towgs84=-50.2,-50.4,84.8,-0.690,-2.012,0.459,-28.08" "Italy (Sicily)" "Accuracy 3-4m" and it would be important to be aware of the fact that these three things can result into meters of accuracy, which is very important not only in calculations, but also when doing overlay of data in different projections that need a certain precision. I'm not a projection specialist, so I have no idea where these info could be kept, or if there should be 3 possible projections choosable for the 3003 code. For as it was last time I saw it, GRASS keeps the towgs84 infomation (which they collect coninuosly) in a separate file and whenever an epsg is choosen, which needs those, the different possibilities are proposed to the user.
Hide
Permalink
Peter Plumber added a comment -
When I look at the EPSG 6.12 database the main difference is the area code.

for CRS base EPSG:4312 ("MGI")
CO AreaCode CoordTfmVersion
1786 1212 EPSG-Svn
1621 1076 EPSG-Hrv
1618 1037 BEV-Aut
1795 2547 JPET-Yug MB
1794 2547 JPet-Yug
1306 2370 NIMA-balk
1471 1037 BEV-Aut (deprecated)

maybe there is a possibility to give geotools the information which areacode is the most suitable?

For Austrian CRS the area code is 1706, 1707, 1708 or 1037
Until now I have nowhere in the db found any information
that 1706, 1707, 1708 are more or less subsets of 1037 (which probably would help to choose correct operation)
Show
Peter Plumber added a comment - When I look at the EPSG 6.12 database the main difference is the area code. for CRS base EPSG:4312 ("MGI") CO AreaCode CoordTfmVersion 1786 1212 EPSG-Svn 1621 1076 EPSG-Hrv 1618 1037 BEV-Aut 1795 2547 JPET-Yug MB 1794 2547 JPet-Yug 1306 2370 NIMA-balk 1471 1037 BEV-Aut (deprecated) maybe there is a possibility to give geotools the information which areacode is the most suitable? For Austrian CRS the area code is 1706, 1707, 1708 or 1037 Until now I have nowhere in the db found any information that 1706, 1707, 1708 are more or less subsets of 1037 (which probably would help to choose correct operation)
Hide
Permalink
Martin Desruisseaux added a comment -
Changed "fix version" from 2.4.0 to 2.5-M0 since we don't have the resources to work on this issue in short term.
Show
Martin Desruisseaux added a comment - Changed "fix version" from 2.4.0 to 2.5-M0 since we don't have the resources to work on this issue in short term.
Hide
Permalink
Martin Desruisseaux added a comment -
Changed "fix version" from 2.5-M1 to "unknown" since I sincerly don't know when I will fix this issue, but I know for sure that it will not be in 2.5-M1.
Show
Martin Desruisseaux added a comment - Changed "fix version" from 2.5-M1 to "unknown" since I sincerly don't know when I will fix this issue, but I know for sure that it will not be in 2.5-M1.
Hide
Permalink
Martin Desruisseaux added a comment -
See [http://jira.geotoolkit.org/browse/GEOTK-80]
Show
Martin Desruisseaux added a comment - See [ http://jira.geotoolkit.org/browse/GEOTK-80 ]
Hide
Permalink
Steven Reynolds added a comment -
I have hit this issue too. I created crs with EPSG code 26715. It's
named NAD27/ UTM zone 15N. Then I do a crs.toWKT() on it. The WKT shows bursa
wolf parameters that are applicable to Cuba. My dataset is in Texas. Here is the WKT

PROJCS["NAD27 / UTM zone 15N",
  GEOGCS["NAD27",
    DATUM["North American Datum 1927",
      SPHEROID["Clarke 1866", 6378206.4, 294.9786982138982, AUTHORITY["EPSG","7008"]],
      TOWGS84[2.478, 149.752, 197.726, 0.526, -0.498, 0.501, 0.14129139227926102],
      AUTHORITY["EPSG","6267"]],
    PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
    UNIT["degree", 0.017453292519943295],
    AXIS["Geodetic latitude", NORTH],
    AXIS["Geodetic longitude", EAST],
    AUTHORITY["EPSG","4267"]],
  PROJECTION["Transverse Mercator", AUTHORITY["EPSG","9807"]],
  PARAMETER["central_meridian", -93.0],
  PARAMETER["latitude_of_origin", 0.0],
  PARAMETER["scale_factor", 0.9996],
  PARAMETER["false_easting", 500000.0],
  PARAMETER["false_northing", 0.0],
  UNIT["m", 1.0],
  AXIS["Easting", EAST],
  AXIS["Northing", NORTH],
  AUTHORITY["EPSG","26715"]]
  
This is causing our system to have about 20m error. I am actually using GeoTools
8.0.

I was wondering if GeoTools is making progress to fixing this issue (GeoTK-80).

It seems to me like doing a maximal area intersection to choose the parameters
will lead to errors too. For example, (from memory) there is a CRS in Columbia
that only applies to one specific oil field.

Using larger intersection area would presumably lead to a tie and random results.
It seems like the selection needs to be based on the source and destination CRS.
Show
Steven Reynolds added a comment - I have hit this issue too. I created crs with EPSG code 26715. It's named NAD27/ UTM zone 15N. Then I do a crs.toWKT() on it. The WKT shows bursa wolf parameters that are applicable to Cuba. My dataset is in Texas. Here is the WKT PROJCS["NAD27 / UTM zone 15N",   GEOGCS["NAD27",     DATUM["North American Datum 1927",       SPHEROID["Clarke 1866", 6378206.4, 294.9786982138982, AUTHORITY["EPSG","7008"]],       TOWGS84[2.478, 149.752, 197.726, 0.526, -0.498, 0.501, 0.14129139227926102],       AUTHORITY["EPSG","6267"]],     PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],     UNIT["degree", 0.017453292519943295],     AXIS["Geodetic latitude", NORTH],     AXIS["Geodetic longitude", EAST],     AUTHORITY["EPSG","4267"]],   PROJECTION["Transverse Mercator", AUTHORITY["EPSG","9807"]],   PARAMETER["central_meridian", -93.0],   PARAMETER["latitude_of_origin", 0.0],   PARAMETER["scale_factor", 0.9996],   PARAMETER["false_easting", 500000.0],   PARAMETER["false_northing", 0.0],   UNIT["m", 1.0],   AXIS["Easting", EAST],   AXIS["Northing", NORTH],   AUTHORITY["EPSG","26715"]]    This is causing our system to have about 20m error. I am actually using GeoTools 8.0. I was wondering if GeoTools is making progress to fixing this issue (GeoTK-80). It seems to me like doing a maximal area intersection to choose the parameters will lead to errors too. For example, (from memory) there is a CRS in Columbia that only applies to one specific oil field. Using larger intersection area would presumably lead to a tie and random results. It seems like the selection needs to be based on the source and destination CRS.
Hide
Permalink
Steven Reynolds added a comment -
Err, sorry, that should have read

...making progress to fixing this issue (GEOT-1179).
Show
Steven Reynolds added a comment - Err, sorry, that should have read ...making progress to fixing this issue ( GEOT-1179 ).

People

  • Assignee:
    Unassigned
    Reporter:
    Martin Desruisseaux
Vote (0)
Watch (4)

Dates

  • Created:
    Updated: