GeoTools
  1. GeoTools
  2. GEOT-4108

File based CoordinateOperation factory

    Details

    • Type: New Feature New Feature
    • Status: Resolved Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 8.0-M4
    • Fix Version/s: 8.0-RC1
    • Component/s: referencing
    • Labels:
      None
    • Testcase included:
      yes

      Description

      Define custom CoordinateOperations in WKT via a properties file.

      1. BETA2007.gsb
        82 kB
        Oscar Fonts
      2. epsg_operations.properties
        1 kB
        Andrea Aime
      3. epsg.properties
        1 kB
        Andrea Aime
      4. GEOT-4108_v2.patch
        44 kB
        Oscar Fonts
      5. GEOT-CoordinateOperationFactoryUsingWKT.patch
        42 kB
        Oscar Fonts
      6. LongitudeFirstFactoryOverrideTest_oscar.java
        6 kB
        Oscar Fonts
      7. LongitudeFirstFactoryOverrideTest.java
        4 kB
        Andrea Aime

        Issue Links

          Activity

          Hide
          Andrea Aime added a comment -
          Hi Oscar, I'd really want to avoid having directly knowledge between one factory and the other so I setup a test that reproduces the same conditions as GeoServer, forcing the usage of longitude first mode, and tested it the same way geoserver uses the referencing subsystem, that is, via the CRS utility class. The code is meant to be added among the gt-epsg-hsql module, where the official EPSG factory is available.
          Of course I modified your patch so that the DirectEPSGFactory does not get to know about the property based one.

          Now, there are two tests in there and they both pass, the only thing I had to do was to invert the ordinates since we're working in longitude/latitude mode, and avoid forcing a axis order in the epsg.properties file.
          So.. I cannot reproduce the problem.
          I'm about to catch a long flight (10 hours back to Europe) and in the next days I'll be pretty jet lagged, but could you write a test in GeoServer showing the issue? Maybe I failed to fully reproduce the GS enviroment.
          Show
          Andrea Aime added a comment - Hi Oscar, I'd really want to avoid having directly knowledge between one factory and the other so I setup a test that reproduces the same conditions as GeoServer, forcing the usage of longitude first mode, and tested it the same way geoserver uses the referencing subsystem, that is, via the CRS utility class. The code is meant to be added among the gt-epsg-hsql module, where the official EPSG factory is available. Of course I modified your patch so that the DirectEPSGFactory does not get to know about the property based one. Now, there are two tests in there and they both pass, the only thing I had to do was to invert the ordinates since we're working in longitude/latitude mode, and avoid forcing a axis order in the epsg.properties file. So.. I cannot reproduce the problem. I'm about to catch a long flight (10 hours back to Europe) and in the next days I'll be pretty jet lagged, but could you write a test in GeoServer showing the issue? Maybe I failed to fully reproduce the GS enviroment.
          Hide
          Oscar Fonts added a comment -
          Hi Andrea.

          Caveat: If no operation is found in the properties file, the CoordinateOperationFactoryUsingWKT (well, in fact, the DefaultCoordinateOperationFactory) will generate a "standalone" transform, not searching for further trasforms in the EPSG database. Added a testDefaultBehavior showing the case (it uses a NTv2 transform, which needs BETA2007.gsb).

          So, in a previous approach, I tried to call the "next available factory" from inside CoordinateOperationFactoryUsingWKT, before returning the control to DefaultCoordinateOperationFactory:
          https://github.com/oscarfonts/geotools/blob/dc1bde1c5d2952f81a19bdf636ff6d3b222b012d/modules/library/referencing/src/main/java/org/geotools/referencing/factory/epsg/CoordinateOperationFactoryUsingWKT.java#L246
          ...and that worked, except when forcing LongitudeFirst.

          Now, we need the DefaultCoordinateOperationFactory to try to split the operation into steps (from projected to geodetic, etc), but need also to prevent it to resolve a datum shift without previously visiting the EPSG database.

          I'm willing to code, but some architectural view will be of much value. Any suggestions on how to do this neatly?

          Thanks.
          Show
          Oscar Fonts added a comment - Hi Andrea. Caveat: If no operation is found in the properties file, the CoordinateOperationFactoryUsingWKT (well, in fact, the DefaultCoordinateOperationFactory) will generate a "standalone" transform, not searching for further trasforms in the EPSG database. Added a testDefaultBehavior showing the case (it uses a NTv2 transform, which needs BETA2007.gsb). So, in a previous approach, I tried to call the "next available factory" from inside CoordinateOperationFactoryUsingWKT, before returning the control to DefaultCoordinateOperationFactory: https://github.com/oscarfonts/geotools/blob/dc1bde1c5d2952f81a19bdf636ff6d3b222b012d/modules/library/referencing/src/main/java/org/geotools/referencing/factory/epsg/CoordinateOperationFactoryUsingWKT.java#L246 ...and that worked, except when forcing LongitudeFirst. Now, we need the DefaultCoordinateOperationFactory to try to split the operation into steps (from projected to geodetic, etc), but need also to prevent it to resolve a datum shift without previously visiting the EPSG database. I'm willing to code, but some architectural view will be of much value. Any suggestions on how to do this neatly? Thanks.
          Hide
          Andrea Aime added a comment -
          Oscar, I'm not the one that created the maze of factories that we have today, so I don't have a full understanding of it either, just been through them a few times so I hope to be able to figure out something if I have a test that shows the problem. But I don't know the solution in advance.
          Show
          Andrea Aime added a comment - Oscar, I'm not the one that created the maze of factories that we have today, so I don't have a full understanding of it either, just been through them a few times so I hope to be able to figure out something if I have a test that shows the problem. But I don't know the solution in advance.
          Hide
          Oscar Fonts added a comment -
          Hi Andrea,

          Solved the circular reference issue (it was the same situation described in GEOT-1161).

          New proposal attached, GEOT-4108_v2.patch. This is a full patch, not incremental.

          Passing tests, working in GeoServer, not touching preexisting factories.
          Show
          Oscar Fonts added a comment - Hi Andrea, Solved the circular reference issue (it was the same situation described in GEOT-1161 ). New proposal attached, GEOT-4108 _v2.patch. This is a full patch, not incremental. Passing tests, working in GeoServer, not touching preexisting factories.
          Hide
          Andrea Aime added a comment -
          Patch applied on trunk.
          I actually have another patch that avoids the custom wkt factory to use its own fallback mechanism, and uses the standard one instead, but it requires changes to some classes that I'm not comfortable with given that trunk is scheduled to become stable shortly, I'll open another jira and commit on the new trunk once we have it
          Show
          Andrea Aime added a comment - Patch applied on trunk. I actually have another patch that avoids the custom wkt factory to use its own fallback mechanism, and uses the standard one instead, but it requires changes to some classes that I'm not comfortable with given that trunk is scheduled to become stable shortly, I'll open another jira and commit on the new trunk once we have it

            People

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

              Dates

              • Created:
                Updated:
                Resolved: