On the detail point of the proposal, I would support amending the current text:
> There will be occasions when a given CRS property value is duplicated in both > a single-property grid mapping attribute and the crs_wkt attribute. In such > cases the onus is on data producers to ensure that the property values are > consistent. However, in those situations where two values of a given property > are different, then the value specified by the single-property attribute > shall take precedence. For example, if the semi-major axis length of the > ellipsoid is defined by the grid mapping attribute semi_major_axis and also > by the crs_wkt attribute (via the WKT SPHEROID[…] element) then the former, > being the more specific attribute, takes precedence. Naturally if the two > values are equal then no ambiguity arises. To remove the latter precedence statement. > There will be occasions when a given CRS property value is duplicated in both > a single-property grid mapping attribute and the crs_wkt attribute. In such > cases the onus is on data producers to ensure that the property values are > consistent. ~~However, in those situations where two values of a given > property are different, then the value specified by the single-property > attribute shall take precedence. For example, if the semi-major axis length > of the ellipsoid is defined by the grid mapping attribute semi_major_axis and > also by the crs_wkt attribute (via the WKT SPHEROID[…] element) then the > former, being the more specific attribute, takes precedence. Naturally if the > two values are equal then no ambiguity arises.~~ It is my view that there is too much of an onus placed on the data consumer here, to parse both content representations, map terms to one another and interpret outputs. This is complicated and difficult to implement. There are many opportunities for mistakes and problems. If there is WKT in a file, I want my application to trust it, not to have to parse it to look for mistakes. If i can just parse it then I can delegate this to a supporting application, which is great for maintainability. I think that placing the onus on the data producer to produce content that they assert is consistent is sufficient. I think the value of data consumers being able to simply parse the WKT directly is very large. I think the cost of managing the assertion of consistency on data producers is much smaller. In a sense the status quo is standardising for mistakes in encoding, which i don't think the standard should do, especially given the cost here. all the best mark -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/222#issuecomment-569938096 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
