propose removal of bespoke in line crs

[marqh]

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 https://github.com/opengeospatial/CoverageJSON/issues/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: https://github.com/covjson/specification/pull/89)

the external link to a published CRS seems sufficient for v1.0

[jonblower]

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]

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)

[jonblower]

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:

1. Keep it and clearly mark it "non-normative" to show that it's not part of the spec, or
2. Replace it with a section saying something like "If there is no previously-defined CRS, then the data provider MAY insert CRS information in another format (e.g. WKT-JSON), in which case the data provider SHOULD provide a human-readable description field to describe their intent. In this case any interoperability with other tools cannot be ensured.", or
3. Remove it altogether and just leave it outside the scope of the spec

Any thoughts @marqh ?

[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

[marqh]

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]

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".

[jonblower]

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]

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 id to be used to encode non-standard encodings

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