Uploaded image for project: 'Spatial Information Systems'
  1. Spatial Information Systems
  2. SIS-377

Latitude of natural origin = -90 wrongly rejected for Transverse Mercator

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 0.6, 0.7, 0.8
    • 1.0
    • Referencing
    • None

    Description

      Attempt to parse the following WKT (from EPSG geodetic dataset)

      PROJCRS["Campo Inchauspe / Argentina 7",
        BASEGEODCRS["Campo Inchauspe",
          DATUM["Campo Inchauspe",
            ELLIPSOID["International 1924",6378388,297,LENGTHUNIT["metre",1.0]]]],
        CONVERSION["Argentina zone 7",
          METHOD["Transverse Mercator",ID["EPSG",9807]],
          PARAMETER["Latitude of natural origin",-90,ANGLEUNIT["degree",0.01745329252]],
          PARAMETER["Longitude of natural origin",-54,ANGLEUNIT["degree",0.01745329252]],
          PARAMETER["Scale factor at natural origin",1,SCALEUNIT["unity",1.0]],
          PARAMETER["False easting",7500000,LENGTHUNIT["metre",1.0]],
          PARAMETER["False northing",0,LENGTHUNIT["metre",1.0]]],
        CS[cartesian,2],
          AXIS["northing (X)",north,ORDER[1]],
          AXIS["easting (Y)",east,ORDER[2]],
          LENGTHUNIT["metre",1.0],
        ID["EPSG",22197]]
      

      causes the following exception:

      java.text.ParseException: Value ‘Latitude of natural origin’ = -90 is invalid. Expected a value in the [-90 … 90] range.
          at org.apache.sis.io.wkt.MathTransformParser.parseParameters(MathTransformParser.java:317)
          (...snip...)
          at org.apache.sis.parameter.Verifier.ensureValidValue(Verifier.java:219)
          at org.apache.sis.parameter.DefaultParameterValue.setValue(DefaultParameterValue.java:734)
      

      Note: CRS.forCode("EPSG::22197") succeed.

      This issue has been reported on the mailing list.

      Attachments

        Issue Links

          Activity

            After examination, it appears that this exception is not because of TransverseMercator being too strict - it accepts latitude of natural origin set at pole. The problem is the low accuracy of the conversion factor in ANGLEUNIT["degree", 0.01745329252] - the conversion factor should have 7 more digits for an IEEE 754 double representation: 0.017453292519943295. This lower accuracy cause 90° to be greater than PI/2 after conversion to radians.

            desruisseaux Martin Desruisseaux added a comment - After examination, it appears that this exception is not because of TransverseMercator  being too strict - it accepts latitude of natural origin set at pole. The problem is the low accuracy of the conversion factor in ANGLEUNIT ["degree", 0.01745329252] - the conversion factor should have 7 more digits for an IEEE 754 double representation: 0.017453292519943295. This lower accuracy cause 90° to be greater than PI/2 after conversion to radians.

            A fix has been applied despite SIS-433 not yet fixed. But the fix will be more complete after SIS-433 is resolved.

            desruisseaux Martin Desruisseaux added a comment - A fix has been applied despite SIS-433 not yet fixed. But the fix will be more complete after SIS-433 is resolved.

            Update (August 2019): the fix applied last year introduced a new bug, in which standard feet (0.3048 metre) was confused with US survey feet. A fix is pushed today.

            desruisseaux Martin Desruisseaux added a comment - Update (August 2019): the fix applied last year introduced a new bug, in which standard feet (0.3048 metre) was confused with US survey feet. A fix is pushed today.

            People

              desruisseaux Martin Desruisseaux
              desruisseaux Martin Desruisseaux
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: