Repository navigation
propose removal of bespoke in line crs #59
Description
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
Activity
jonblower commentedon Mar 30, 2022
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.
jonblower commentedon Mar 30, 2022
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:
(The above example is chosen because I'm not sure there is a defined CRS for that kind of thing)
jonblower commentedon Mar 31, 2022
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:
descriptionfield to describe their intent. In this case any interoperability with other tools cannot be ensured.", orAny thoughts @marqh ?
marqh commentedon Apr 5, 2022
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
marqh commentedon Apr 5, 2022
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
jonblower commentedon Apr 5, 2022
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".
jonblower commentedon Apr 5, 2022
Their wording is, "where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted."
marqh commentedon Apr 5, 2022
i think that we should ensure that the 'id' remains used for the identifier of the CRS
the current text is clear on this
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
idto be used to encode non-standard encodingsdescription 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