GeoTools
  1. GeoTools
  2. GEOT-1511

Support Google CRS (EPSG:900913)

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.5-M0
    • Fix Version/s: 2.4.1, 2.5-M1
    • Component/s: referencing
    • Labels:
      None

      Description

      Google projection ("EPSG:900913" is a weird spherical "Mercator1SP" projection using sphere radius equals to the WGS 84 semi-major axis length, but with "sphere to ellipsoid" conversion disabled.

      http://www.spatialreference.org/ref/user/google-projection/

      In other words, it is very similar to "EPSG:3395" with the flattening factor 298.257223563 replaced by 0 (a sentinal value for infinity) in the WKT. However we can not declare the Google projection just that way, because it has one weird behavior: when transforming from Google projection to any other CRS, for example WGS 84, the "sphere to ellipsoid" conversion should not be applied. So we need a way to disable this conversion using standard (if possible) WKT syntax. The proposed syntax is:

      PROJCS["Google Mercator", 
        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"]], 
        PROJECTION["Mercator (1SP)", AUTHORITY["EPSG","9804"]], 
        PARAMETER["semi_major", 6378137.0], 
        PARAMETER["semi_minor", 6378137.0], 
        PARAMETER["latitude_of_origin", 0.0], 
        PARAMETER["central_meridian", 0.0], 
        PARAMETER["scale_factor", 1.0], 
        PARAMETER["false_easting", 0.0], 
        PARAMETER["false_northing", 0.0], 
        UNIT["m", 1.0], 
        AXIS["Easting", EAST], 
        AXIS["Northing", NORTH], 
        AUTHORITY["EPSG","900913"]]
      

      This WKT is almost identical to the standard "WGS 84 / World Mercator" WKT, except that the "semi_major" and "semi_minor" parameters are explicitly defined. Usually those parameters should not be provided because they are inferred from the SPHEROID element. If they are provided anyway, current GeoTools implementation checks if the values are identical to the ones inferred from the spheroid. I don't remember what is the current behavior if they differ - throwing an exception or just logging a warning. This need to be checked.

      The proposed fix is:

      • Allows the values of PARAMETER["semi_major", ...] and PARAMETER["semi_minor", ...] to differ from the values inferred from the SPHEROID element. Maybe we should log a warning for any CRS other than the Google one since such mismatch is usually an error - this need to be determined.
      • Make sure that GeoTools uses PARAMETER["semi_major", ...] and PARAMETER["semi_minor", ...] for map projections. I believe that this is already the case. If GeoTools checks the consistency with SPHEROID, replace the exception by a warning, with no warning at least in the Google case.
      • Make sure that GeoTools uses SPHEROID for datum shifts. I believe that this is already the case.
      • Make sure that WKT formatting includes the PARAMETER["semi_major", ...] and PARAMETER["semi_minor", ...] elements if they differ from the values inferred from the SPHEROID element.

      That way, GeoTools would not apply any datum shift between Google projection and WGS 84 because the datum is already declared as WGS 84, but would still uses the spherical equations for the projection because of the PARAMETER["semi_minor", 6378137.0] element, which differs from what would have been inferred from SPHEROID. No WKT extension is required. The only thing we need to do is to make sure that GeoTools accepts a PARAMETER / SPHEROID mismatch and use the right elements for the right operation (PARAMETER for map projection, SPHEROID for datum shift).

        Issue Links

          Activity

          Hide
          Andrea Aime added a comment -
          Cool, I'll look for the diff and see if I'm up to the merge (that is, I have to check the diff does not modify tens of files)
          Show
          Andrea Aime added a comment - Cool, I'll look for the diff and see if I'm up to the merge (that is, I have to check the diff does not modify tens of files)
          Hide
          Andrea Aime added a comment -
          Ohi ohi ohi, that commit is massive, see here:
          http://www.nabble.com/svn---r28393---in-geotools-trunk-gt-modules-library%3A-coverage-src-main-java-org-geotools-coverage-processing-operation-coverage-src-test-java-org-geotools-coverage-grid-coverage-src-test-java-org-geotools-coverage-processing-referencing-src-main-java-org--td14368824.html#a14368824

          semi-minor and semi-major is mentioned in a number of places, but mixed with java5 construct changes, formatting and other unrelated stuff... I don't think I cannot back port it...
          Show
          Andrea Aime added a comment - Ohi ohi ohi, that commit is massive, see here: http://www.nabble.com/svn---r28393---in-geotools-trunk-gt-modules-library%3A-coverage-src-main-java-org-geotools-coverage-processing-operation-coverage-src-test-java-org-geotools-coverage-grid-coverage-src-test-java-org-geotools-coverage-processing-referencing-src-main-java-org--td14368824.html#a14368824 semi-minor and semi-major is mentioned in a number of places, but mixed with java5 construct changes, formatting and other unrelated stuff... I don't think I cannot back port it...
          Hide
          Martin Desruisseaux added a comment -
          Yes this is a bad practice of mine (mixing many tasks in a single commit). Very bad practice, but to my defense it is a side effect of GeoTools build being so heavy since I don't commit before a successfull "mvn install", and I don't have the courage to run a full maven build much more than once a day... ):
          Show
          Martin Desruisseaux added a comment - Yes this is a bad practice of mine (mixing many tasks in a single commit). Very bad practice, but to my defense it is a side effect of GeoTools build being so heavy since I don't commit before a successfull "mvn install", and I don't have the courage to run a full maven build much more than once a day... ):
          Hide
          Martin Desruisseaux added a comment -
          I will try to look for the merge this weekend. There is probably just one or two class concerned. Probable DefaultProjectedCRS.
          Show
          Martin Desruisseaux added a comment - I will try to look for the merge this weekend. There is probably just one or two class concerned. Probable DefaultProjectedCRS.
          Hide
          Martin Desruisseaux added a comment -
          WKT formatting update merged to the 2.4 branch as of revision 29128.
          Show
          Martin Desruisseaux added a comment - WKT formatting update merged to the 2.4 branch as of revision 29128.

            People

            • Assignee:
              Martin Desruisseaux
              Reporter:
              Martin Desruisseaux
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: