Check "WGS 84 to" case
@marneson @joshtownsend
Basically someone needs to confirm in OSDU if a transformation is done from ETRS89 AsIngested, using BoundCRS with CT “WGS 84 to ETRS89 (2)”, EPSG CT code 9225, if the result is correct in OSDU. This should be included as a GIGS test/standard test in OSDU. CT may not even be in the standard set of BoundCRSs in OSDU.
Test input AsIngested ETRS89 (EPSG::4258):
- lat = y = 54
- lon = x = 5
Correct output WGS 84 (EPSG::4326) with transform "WGS 84 to ETRS89 (2)" (EPSG::9225):
- y = 54.00000430
- x = 05.00000618
Or since above is a time-specific transform OSDU may not be able to use, GDA2020 (EPSG::7844) using WGS 84 to GDA2020 (3), EPSG code 9690.
Test input AsIngested GDA2020 (EPSG::7844):
- lat = y = -30
- lon = x = 130
Correct output WGS 84 (EPSG::4326) with transform "WGS 84 to GDA2020 (3)" (EPSG::9690):
- y = -30.00001376
- x = 129.99999133
See: https://gitlab.opengroup.org/osdu/subcommittees/ea/projects/geomatics/home/-/issues/44 which has text:
Does the code assume that the CT is always given in the form of a “to WGS 84” CT, similar to like the ancient proj4 strings did this? It is general policy in EPSG Dataset to go from old to new, i.e., we will have “some CRS to WGS 84”, so that may work though I think some agencies wanted to have it the other way around… – we should just document these kind of assumptions because they are not a given to me and we may have to fix EpsgManifestGenerator to somehow flip the CTs. Though with an input NTv2 file that is defined as WGS 84 to GDA that is not possible I think.
I confirmed via epsg.org (in the UI or https://apps.epsg.org/api/v1/Transformation/?keywords=WGS%2084%20to&includeWorld=true&pageSize=9999 ) that there are currently 14 transformations that start with string “WGS 84 to”. Many are “geoid height” type. But there is “WGS 84 to ETRS89 (2)”, “WGS 84 to GDA2020 (3)”, and “WGS 84 to GDA2020 (4)”, and “WGS 84 to NTF (3)”.
This will also become a problem when executing a direct transformation, i.e., it will be difficult to replace “GDA94 to WGS 84 (1)” followed by “GDA2020 to WGS 84 (1)” – applied in reverse by a proper GDA94 to GDA2020 direct transformation if we cannot recognize (I mean guarantee to recognize on name or datum code) which is the “fromCRS” and which is the “toCRS”.
Comment from 2022 this is based on: From Michael: Yes, the OSDU Crs Conversion code assumes the transformation specified in the EarlyBound persistable reference is a "to WGS84" transformation. It would be possible to detect if the transformation specified is a "WGS84 to" by looking at the sourceCRS and targetCRS specified in the transformation. I was able to create two "WGS84 to" transformations using Apache SIS from the list you provided (15960 and 9189). The other "WGS84 to" transformations are not supported by Apache SIS at the moment. The OSDU Crs Conversion does not always do the conversion, transformation, transformation, conversion steps, the service will only perform the steps that are needed. This may be just performing the conversion steps if the fromCRS and toCRS share the same base CRS, for example.
Regarding the 2 points you mentioned:
- That conversion may be supported, what may happen during this conversion is 2 transformations (transformation from fromCRS to WGS84 and transformation from WGS84 to toCRS). Note that each transformation operation will include the conversion of points from CRS (either fromCRS or toCRS) to sourceCRS or targetCRS specified in the transformation. It is difficult to know without a concrete example, could you give one from the EPSG database?
- That would be supported. What would happen is there would be two conversions done, one conversion from 26715 to 4267 (the base crs), and another conversion from 4267 to 32065.