GeoTools

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: