CRS-related attributes in the root group

[rmalyankar]

S-100 5.0.0 added several attributes to the root group related to horizontal CRS and projections. S-102 adds a table for codes for UTM zones, defined by reference to the EPSG registry (clause 5.2).

The remarks in S-102 Table 8(?) "Root group attributes" for the new S-100 5.0.0 attributes related to horizontal CRS and datums (which are taken from S-100 Table 10c-6), should be reviewed for compatibility with the use of EPSG datums from S-102 clause 5.2, especially the dependency on "-1" as a special value for horizontalCRS and horizontalDatum.

[hasel001]

Noted for further work. (lhh, PT12, 13Feb2023)

[rmalyankar]

Since S-102 encodes the CRS's for UTM zones using EPSG codes in the root group attribute horizontalCRS, the various 'If horizontalCRS = -1' conditions for several following attributes are never satisfied and those attributes are in principle not required (sic) to be present. This has similar secondary effects on some additional attributes. The result appears to be that the projection parameters in Table 8 are not required to be encoded for the projected CRS's listed in Table 1 (S-102 Coordinate Reference Systems (EPSG Codes)).

Noting that -

1. The projection parameters were added to the HDF5 format at OEM request.
2. The ISO 8211 encoding also provides for projection parameters to be encoded in datasets.
3. The parameters for the UTM zones are standardized and available in the EPSG registry, and could in principle be encoded in an OEM table in the application, they don't necessarily have to be encoded in every dataset that uses UTM coordinates.

Notwithstanding (3) above, the most robust solution is probably to require encoding of the relevant coordinate system and projection parameters in the root group attributes anyway if the horizontalCRS value indicates a projected CRS.

[RohdeBSH]

Hi @rmalyankar,

Your observation is of course correct. Personally, the only thing that bothers me is the fact that we, as the producers, are now supposed to fill in all the parameters. For us, the coordinate system is maintained in PostGIS. Of course, we can output the definition of the coordinate system there, e.g. as a WKT or ProJ4 string. But then we have to parse the output to get the parameters. But now there are many more HOs than OEMs. Why should the HOs now be burdened with the additional work? Surely this will result in many more man-hours and implementation errors worldwide than if the OEMs were to process the EPSG registry database. The EPSG code is clear and sufficient in my opinion. Anyone who cannot handle the EPSG code should consider a solution. Since undefined CRSs are not possible in the S-102, I think everything can stay as it is.

Alternatively, one could specify the ProJ4 string or the WKT instead of all individual parameters.

[rmalyankar]

The parameters could be automatically filled by production software, depending on the EPSG code selected for horizontalCRS. In effect that amounts to shifting the burden from application software to production software.

As to why - maybe legacy reasons? I think the original idea may have been that everything needed for an application to process a dataset should be in the dataset file. I don't find that a convincing reason now for encoding the projection parameters in datasets rather than internally in applications, but anything more than a "Clarification" to S-100 5.x is unlikely for the near future.

[HolgerBothien]

Since S-102 only allows a few horizontalCRS which are all defined by an unique code in the EPSG, there is no need to include the parameter that are only required for user defined CRS. In fact there cardinality becomes 0 for all S-102 data. They should be removed from the PS. They only create confusion as you can see in this discussion. And I don't think it is a good idea to repeat the parameter for projected CRS because:

1. S-100 does not allows it
2. It could be a source of inconsistency (What if those parameters are not identical to the EPSG registry)
3. It causes unnecessary work for data producers and OEMs.

[hasel001]

Chair has action to ensure changes have been made in PS. If so, chair will close this issue (per decision in PT16).

[tfilppula]

@hasel001 These still seem to be included. Are they going to be removed (5-19)?

[hasel001]

I have removed those items and renumbered the subsequent items in the table under the 5.2 alignment pull request. (I know that isn't the most correct place to effect the changes, but I don't want to open yet another pull request, and I can make an argument for putting it there.) Regardless, it is done, and I am marking this issue closed. Thanks!