-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
propose removal of bespoke in line crs #59
Comments
I'm also in favour of removing (or at least deprecating) this for 1.0. I'm not aware of anyone that's using the bespoke syntax anyway and it's not well defined. |
I guess there may be an issue if there is not an externally-published CRS that matches the data provider's intent. We should probably have a recommendation for this, even if it's "do what you like, but don't expect interoperability if you use a non-standard format". As a worst-case fallback, people might want to just provide some information that can't be easily parsed by computers but could at least help a reader: {
"type": "VerticalCRS",
"description": "Height in metres above moving deck of the RSS Research Ship"
} (The above example is chosen because I'm not sure there is a defined CRS for that kind of thing) |
Spoke to Maik offline. We're both happy to remove this part of the text - it was never intended to be normative anyway. We could either:
Any thoughts @marqh ? |
hi @jonblower i think that i would prefer option 3 and to remove this altogether, and have it out of scope for 1.0 i think that having non-normative setctions with unstandardised contents is risky and encourages use that we will change in the future |
i agree that providing a description field for the CRS is useful people can always add contextual descriptions for humans in the scenario where no CRS URI can be used, a text description only is better than nothing |
So does that mean you'd support option 2? I see this as analogous to what GeoJSON does: GeoJSON only supports CRS84, but has some text that says "use other CRSs if you want, but that's outside the spec and would be application-specific". |
Their wording is, "where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted." |
i think that we should ensure that the 'id' remains used for the identifier of the CRS i think adding a description attribute is useful i'm wary of adding an attribute name to store anything else, or giving options for the description is already free text in other uses, and can be co-opted for non-standardised exchange So, i prefer removing the section on in-line definitions all together and adding the optional description field to the other sections defining use |
https://github.com/opengeospatial/CoverageJSON/blob/master/standard_template/standard/clause_specification_text.adoc#514-providing-inline-definitions-of-crss
the bespoke in line definition is likely to alter significantly as #26 and similar angles are pursued
given the liklihood of these options for 1.1, having this bespoke syntax in 1.0 seems to be storing up problems for backwards compatability
i propose removng this section from the 1.0 version
(this is a long standing discussion: covjson/specification#89)
the external link to a published CRS seems sufficient for v1.0
The text was updated successfully, but these errors were encountered: