GeoTools
  1. GeoTools
  2. GEOT-1179

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

          Activity

          Hide
          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
          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
          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
          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
          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
          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.
          Show
          Martin Desruisseaux added a comment - See [ http://jira.geotoolkit.org/browse/GEOTK-80 ]
          Hide
          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
          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
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: