Closed rmalyankar closed 4 weeks ago
There is no case and encoding the values if we have a CRS defined by an EPSG code opens the door for inconsistencies. Also note that an implementation might not look for those attributes if the CRS is already fully described by the EPSG code.
For S-102 I don't see a case either. Also fully agree with @HolgerBothien, having multiple definitions can lead to inconsistent definitions.
Including the possibility for user-defined CRS might be worth considering for the later non-nav version of the S-102.
Per our decision in PT14, @hasel001 has an action to amend the Root Group Attributes table.
Below is what I interpreted as the proper changes. @rmalyankar and @HolgerBothien, would you please advise as to whether these are correct? I certainly appreciate the help.
Row: 8 [Old] Remarks: Mandatory if horizontalCRS = -1 // EPSG code or -1 if user defined [New] Remarks: Mandatory if horizontalCRS = -1 // EPSG code
Row: 9
[Old] Remarks: Mandatory if horizontalDatum = -1
[New] Remarks:
Row: 10 [Old] Remarks: Mandatory if horizontalDatum = -1; // EPSG code [New] Remarks: EPSG code
Row: 11 [Old] Remarks: Mandatory if horizontalDatum = -1; // EPSG code [New] Remarks: EPSG code
Once I receive your feedback, I'll incorporate the proper changes. Thank you!
@hasel001 I guess this issue can be closed, since user-defined horizontal datums are not allowed in S-102 and #15 is closed.
@tfilppula I agree--I appreciate the heads up. I am marking this issue closed.
Given that S-102 restricts horizontal CRS to EPSG 4326 and UTM/UPS zone CRSs, is there a use case (considering world-wide usages) for allowing a user-defined horizontal datum (see Table 8 item 8 - horizontalDatum)? If not, items 8 and 9 in Table 8 should be amended accordingly.
Also, I take it items 10 and 11 in Table 8 (primeMeridian & spheroid) can be encoded anyway, i.e., even if horizontalDatum is a standard EPSG code.
(depends on the final outcome for #15)