GeoTools
  1. GeoTools
  2. GEOT-1745

MapProjection: relax coordinate checks/make them configurable

    Details

    • Type: Improvement Improvement
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.4.2, 2.5-M1
    • Fix Version/s: 2.5.9
    • Component/s: referencing
    • Labels:
      None

      Description

      As reported in this mail thread:
      http://www.nabble.com/Relaxing-coordinate-checks-in-MapProjection--td16154359.html

      it would be very useful to relax the current bound checks on MapProjection (line ...) as they are breaking rendering in at least two applications depending on GeoTools (GeoServer and uDig).
      Implementation ideas:

      • add a new hint to ask for transform leniency
      • use the current "lenient transform" hint to act on bound checks as well

      The latter is probably the easiest way, but has backwards compatibility issues. At the moment the CRS.findMathTransform(from, to , lenient) javadoc states:

      param lenient {@code true} if the coordinate operations should be created
                  even when there is no information available for a datum shift.
      

      Most datastore and rendering code sets lenient to true in order to get a best effort behaviour, so the change proposed above would be consistent with the current intended usage, but not fully with the javadoc (thought it can be argued that it doesn't say anything about exception being thrown either, so the current behaviour is not specified in the javadocs either?).

        Issue Links

          Activity

          Hide
          Andrea Aime added a comment -
          Fixed in gt2 2.4.x and trunk. For reference, the commit was made on 2.4.x at r29680 (should Jody need to backport this on trunk).
          For the record, this fix allows us to properly overlay data with google maps one even when extremely zoomed out (when google enters in map repeating mode like in http://maps.google.com/?ie=UTF8&ll=37.0625,-95.677068&spn=177.007106,360&z=1). Whoa! :)
          Show
          Andrea Aime added a comment - Fixed in gt2 2.4.x and trunk. For reference, the commit was made on 2.4.x at r29680 (should Jody need to backport this on trunk). For the record, this fix allows us to properly overlay data with google maps one even when extremely zoomed out (when google enters in map repeating mode like in http://maps.google.com/?ie=UTF8&ll=37.0625,-95.677068&spn=177.007106,360&z=1) . Whoa! :)
          Hide
          Andrea Aime added a comment -
          Bah, not backport on trunk, backport on 2.2.x (uDig is affected by this one as well).
          Show
          Andrea Aime added a comment - Bah, not backport on trunk, backport on 2.2.x (uDig is affected by this one as well).
          Hide
          Martin Desruisseaux added a comment -
          Reopening this issue, since the consequences of allowing the coordinates to go beyong the [-PI ... PI] range are not well understood. For example the Lambert projection performs the following calculation:

              sin(lambda * n)

          where n is some factor. Unfortunatly this is not the same than:

              sin((lambda + 2*PI) * n) =
              sin(lambda * n + (2*PI) * n) =
              sin(lambda * n) * cos(2*PI * n) + cos(lambda * n) * sin(2*PI * n) =
              sin(lambda * n) * cos(n) + cos(lambda * n) * sin(n)

          This is yet more complicated if we want to get the n factor out of sin or cos trigonometric function: http://en.wikipedia.org/wiki/Chebyshev_polynomials

          So by allowing the longitude or latitude to goes out of their range, we are really getting different result than what we would get by rolling back the longitude (for example) in the -180 ... 180° range. I'm not sure which behavior is the appropriate one...
          Show
          Martin Desruisseaux added a comment - Reopening this issue, since the consequences of allowing the coordinates to go beyong the [-PI ... PI] range are not well understood. For example the Lambert projection performs the following calculation:     sin(lambda * n) where n is some factor. Unfortunatly this is not the same than:     sin((lambda + 2*PI) * n) =     sin(lambda * n + (2*PI) * n) =     sin(lambda * n) * cos(2*PI * n) + cos(lambda * n) * sin(2*PI * n) =     sin(lambda * n) * cos(n) + cos(lambda * n) * sin(n) This is yet more complicated if we want to get the n factor out of sin or cos trigonometric function: http://en.wikipedia.org/wiki/Chebyshev_polynomials So by allowing the longitude or latitude to goes out of their range, we are really getting different result than what we would get by rolling back the longitude (for example) in the -180 ... 180° range. I'm not sure which behavior is the appropriate one...
          Hide
          Martin Desruisseaux added a comment -
          We should consider deprecating AbstractMathTransform.rollLongitude(double) and remove any usage of it. Generally speaking we should make sure that MapProjection do not introduce any discontinuity (rolling longitude is a discontinuity). Things may be a little bit cleaner if we get the central meridian shift and normalization to unit sphere out of MapProjection code, in an affine transform.
          Show
          Martin Desruisseaux added a comment - We should consider deprecating AbstractMathTransform.rollLongitude(double) and remove any usage of it. Generally speaking we should make sure that MapProjection do not introduce any discontinuity (rolling longitude is a discontinuity). Things may be a little bit cleaner if we get the central meridian shift and normalization to unit sphere out of MapProjection code, in an affine transform.
          Hide
          Martin Desruisseaux added a comment -
          This is cleaned in Geotidy, exactly in the way described in the previous comment. However the "rollLongitude" functionality has not been removed. Instead it has been made configurable as an optional parameter.
          Show
          Martin Desruisseaux added a comment - This is cleaned in Geotidy, exactly in the way described in the previous comment. However the "rollLongitude" functionality has not been removed. Instead it has been made configurable as an optional parameter.

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrea Aime
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: