search

covjson / specification

CoverageJSON specification
https://covjson.org/spec/
45 stars 6 forks source link

use text string for WKT-CRS #89

Open marqh opened 5 years ago

marqh commented 5 years ago

I think it is beyond the scope of CovJSON to produce a JSON encoding of WKT-CRS.

Prefer the use of WKT strings as-is in CovJSON documents (as string values) represents a sensible position to take at this time.

My sense is that it is a treacherous path to include such a re-encoding of another standard within this specification.

I would suggest that initially this section be removed, following a consultation on who may be using it.

We can highlight the desire to encode WKT-CRS within JSON payloads to the Maintainers of CRS-WKT and request input on how to do this effectively. I suspect that, at a minimum, it would require the publishing of the controlled vocabularies encoded within the WKT-CRS specification.

Does this raise concerns with contributors?

Would further information help this section?

letmaik commented 5 years ago

CovJSON is all about ease of use and lots of examples. Can you re-add the vertical CRS example in WKT form to get a better idea of it?

marqh commented 5 years ago

CovJSON is all about ease of use and lots of examples. Can you re-add the vertical CRS example in WKT form to get a better idea of it?

That seems fine. I have added a WKT string.

I have included newlines but I have not justified the text. WKT is whitespace neutral so it can be formatted to aid readability. I can change it again if there's a view on what would read better.

letmaik commented 5 years ago

Your JSON is not valid, please use something like https://jsonlint.com/ to check it.

marqh commented 5 years ago

i have added escape characters to the double quotes and the line returns for the WKT string, and a comment highlighting this

letmaik commented 5 years ago

It also includes escaped line returns and extra whitespace; whilst these are not required for WKT-CRS they do aid readability.

Line returns should be \n only, not \\n, as otherwise you have a literal backslash followed by n.

How do the line returns aid readability here? If anything it makes it more complicated when looking at the raw JSON. Pretty-printing WKT strings is another matter and could be handled by some library if one really wants to print it out somehow (what's the use case?), but I don't think there's any way to make them pretty and accessible in JSON itself, which was the purpose of the existing object encoding.

marqh commented 5 years ago

Line returns should be \n only, not \\n, as otherwise you have a literal backslash followed by n.

i see, but no matter. If you also don't think they help, I'll remove them, I was pretty unsure about putting them in.