GeoTools
  1. GeoTools
  2. GEOT-3423

Datum mapping values are trashed if gt-jp2k is on the classpath

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.7-M3, 2.7-RC1
    • Fix Version/s: None
    • Component/s: jp2k plugin, metadata
    • Labels:
      None
    • Environment:
      RHEL 5.3, jdk 1.6.0_12
    • Testcase included:
      yes

      Description

      I am trying to map from from NAD83 (EPSG:4152) to WGS84 (EPSG:4326) using the ReferencedEnvelope.toBound() API. I am able to do the mapping and get results which seem reasonable unless I have gt-jp2k<version>.jar on my classpath.

      Example:
      When mapping the following box (North, East, South, West)
      (29.938194274, -90.28570556, 29.924352645, -90.30159759)

      I get the following result (without gt-jp2k.jar on classpath)
      (29.938199672378193, -90.28572067250404, 29.924358038341936, -90.30161270910881)
      And WITH gt-jp2k.jar on the classpath I get...
      (-89.69840445522946, -150.06687862669452, -89.71429649289404, -150.08100271184813)

      As an interesting side note... if I use gt-epsg-hsql-2.7-M3.jar instead of gt-epsg-wkt-2.7-M3.jar I also get..
      (-89.69840445522946, -150.06687862669452, -89.71429649289404, -150.08100271184813)

        Activity

        Hide
        Joe Boese added a comment -
        One other quick note from futher investigation on my part... It seems that a delivered Geo Tools unit test "org.geotools.geometry.iso.operations.TransformTest.testReprojection() is also broken when gt_jp2k is on the CLASSPATH. I am noting that this unit test case is under "geotools-2.7-M3/modules/unsupported". Does this mean that Datum transformations themselves are an unsupported function?

        Unit test output is as follows...
        POLYGON ((48.543261561072285 -123.47009555832284, 48.55009592117936 -123.46972894676578, 48.54973520267305 -123.45463828850829, 48.54290089070186 -123.4550070827961, 48.543261561072285 -123.47009555832284))
               junit.framework.AssertionFailedError
                at junit.framework.Assert.fail(Assert.java:47)
                at junit.framework.Assert.assertTrue(Assert.java:20)
                at junit.framework.Assert.assertTrue(Assert.java:27)
                at baex.gl.geo.crstransform.TransformTest.testReprojection(TransformTest.java:157)
        Show
        Joe Boese added a comment - One other quick note from futher investigation on my part... It seems that a delivered Geo Tools unit test "org.geotools.geometry.iso.operations.TransformTest.testReprojection() is also broken when gt_jp2k is on the CLASSPATH. I am noting that this unit test case is under "geotools-2.7-M3/modules/unsupported". Does this mean that Datum transformations themselves are an unsupported function? Unit test output is as follows... POLYGON ((48.543261561072285 -123.47009555832284, 48.55009592117936 -123.46972894676578, 48.54973520267305 -123.45463828850829, 48.54290089070186 -123.4550070827961, 48.543261561072285 -123.47009555832284))        junit.framework.AssertionFailedError         at junit.framework.Assert.fail(Assert.java:47)         at junit.framework.Assert.assertTrue(Assert.java:20)         at junit.framework.Assert.assertTrue(Assert.java:27)         at baex.gl.geo.crstransform.TransformTest.testReprojection(TransformTest.java:157)
        Hide
        Joe Boese added a comment -
        More info.. it looks like I'm getting different CoorindateReferenceSystem objects based on having gt-jp2k on (of off) the CLASSPATH. Without jp2k, I believe my CRS is coming from gt-epsg-wkt-2.7-M3; and with it from gt-epsg-hsql-2.7-M3. The well known text I get from EPSG:4236 (WGS84) when I don't have jp2k on the CLASSPATH is:
        GEOGCS["WGS 84",
          DATUM["World Geodetic System 1984",
            SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
          PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
          UNIT["degree", 0.017453292519943295],
          AXIS["Geodetic longitude", EAST],
          AXIS["Geodetic latitude", NORTH],
          AUTHORITY["EPSG","4326"]]
        and when I DO have jp2k on the CLASSPATH...
        GEOGCS["WGS 84",
          DATUM["World Geodetic System 1984",
            SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
          PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
          UNIT["degree", 0.017453292519943295],
          AXIS["Geodetic latitude", NORTH],
          AXIS["Geodetic longitude", EAST],
          AUTHORITY["EPSG","4326"]]

        Note.. that the AXIS are reversed. This was causing my failure. I'm still confused as to way adding jp2k suddenly causes CRS.decode() to use the hsql jar.
        Show
        Joe Boese added a comment - More info.. it looks like I'm getting different CoorindateReferenceSystem objects based on having gt-jp2k on (of off) the CLASSPATH. Without jp2k, I believe my CRS is coming from gt-epsg-wkt-2.7-M3; and with it from gt-epsg-hsql-2.7-M3. The well known text I get from EPSG:4236 (WGS84) when I don't have jp2k on the CLASSPATH is: GEOGCS["WGS 84",   DATUM["World Geodetic System 1984",     SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]],     AUTHORITY["EPSG","6326"]],   PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],   UNIT["degree", 0.017453292519943295],   AXIS["Geodetic longitude", EAST],   AXIS["Geodetic latitude", NORTH],   AUTHORITY["EPSG","4326"]] and when I DO have jp2k on the CLASSPATH... GEOGCS["WGS 84",   DATUM["World Geodetic System 1984",     SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]],     AUTHORITY["EPSG","6326"]],   PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],   UNIT["degree", 0.017453292519943295],   AXIS["Geodetic latitude", NORTH],   AXIS["Geodetic longitude", EAST],   AUTHORITY["EPSG","4326"]] Note.. that the AXIS are reversed. This was causing my failure. I'm still confused as to way adding jp2k suddenly causes CRS.decode() to use the hsql jar.

          People

          • Assignee:
            Unassigned
            Reporter:
            Joe Boese
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: