CRS Conversion V3 (convertGeoJson)

Here my observations from 2022-04-29

• Reference data relationships in OSDU are declared as {{record-id}}:{{reord-version}} for versioned targets or {{record-id}}: for 'latest target version'. I don't expect people to use versioned reference-data, whiever, this is a general pattern. The example JSON fragments in the Postman collection request Body are not validating against the AbstractAnyCrsFeatureCollection. When I add a trailing colon I get 500 server error.
• This would perhaps be more a @bert.kampes concern - but the "17 CRS Conversion - Convert GeoJson success scenario" takes a point in the Carribean and puts it into a CRS valid in the Norwegian sector south of 62°N.
• In the successfully converted response the persistableReferenceCrs string is updated to the toCRS in the request but not CoordinateReferenceSystemID. This must become the requested toCRS.
• VerticalUnitID - using the "toUnitZ": "osdu:reference-data--UnitOfMeasure:ft%5BUS%5D" fails with 400 but succeeds with osdu:reference-data--UnitOfMeasure:ft (I created them as UnitOfMeasure records before)
  • With input "persistableReferenceUnitZ": "osdu:reference-data--UnitOfMeasure:m" and toUnitZ ft, no unit conversion takes place (the log confirms that). However, here persistableReferenceUnitZ must be a serialized JSON string, sending a relationship ID must lead to an error. Changing the key to VerticalUnitID makes the unit conversion happen.
  • In the successfully converted response the persistableReferenceUnitZ is updated but the VerticalUnitID is not (same as in point 3 above).

Minor - some Postman requests came

1. without variable {{osduonaws_base_url}}
2. withou variable definitions (and values) for {{DATA_OWNERS_GROUP}}, {{DATA_VIEWERS_GROUP}}, and {{LEGAL_TAG}}

CC @fhoueto.amz @kogliny @spencer