Consider more information about the CRS?

[cholmes]

Looking at Flatgeobuf they have a lot more information on the CRS: https://github.com/flatgeobuf/flatgeobuf/blob/6884cb05438686947f7bf3776c7ae5c9febfbf5a/src/fbs/header.fbs#L58

Org, code, name, description. It does seem like that stuff could be useful to display to users to know what CRS they are using. I'd still want to consider the WKT as the singular source for the definition - libraries just need to check one place and go, and if they are in conflict then you use the WKT. But perhaps there's value in providing informative fields, to be able to look at a file and recognize 4326 or another common projection, instead of having to match the WKT.

[hobu]

Org, code, name, description.

These short hands are often in conflict with each other as soon as you start additionally offering full definitions in formats such as WKT or projjson. Pointing to complex CRS standards inside data format standards means implementers have a much larger software responsibility surface.

A key challenge with GeoJSON was whether or not to place the burden of CRS dereferencing and consumption on the implementer. GeoJSON eventually gave up and did 4326, but one could argue that the dominant audience for GeoJSON was a web audience rather than a geo one that would have been more comfortable with doing that CRS work.

projjson didn't exist at the time GeoJSON was developed, and if it had, we might have been tempted to allow it to come along for the ride. WKT sucks vs projjson because of the need to write a custom parser if you are responsible for dereferencing its elements.

No easy and simple solutions here, but IMO it is important to think about what you expect the implementer of the format to be responsible for. If it is just the coordinates, their geometry relationships, and their attributes, that is a different burden than all of that PLUS any possible coordinate system in the universe.

[hobu]

I'll also add that https://github.com/stac-extensions/projection/ has a similar challenge.

[jorisvandenbossche]

In addition to what @hobu already said, most of those additional fields (at least org, code and name) can be present in the WKT string as well, and thus strictly speaking wouldn't provide additional value.
It's true that for display purposes WKT is not that friendly, but I would say that this is the responsibility of the software displaying this (and they can do the effort of extracting information for display purposes).

[hobu]

WKT's problem is more than just display. For example, where are the units of the coordinates in the geometry stored or referenced? An application that needs that is now responsible for parsing the WKT all the way down. Same for any CRS that is complex in any way (3D coordinate systems are the bane of my existence).

Does anyone know of an equivalent open source implementation of PROJ in JavaScript ecosystem with full parsing and dereferencing support of WKT? I don't think this exists.

[kylebarron]

Does anyone know of an equivalent open source implementation of PROJ in JavaScript ecosystem with full parsing and dereferencing support of WKT? I don't think this exists.

Proj4.js doesn't currently support WKT2, so with v0.1 of this spec in JS we'll just have to say "we can only support files in EPSG:4326".

While discussing on georust/proj, I learned someone has compiled Proj 8.1 to WASM, but it's GPL3 licensed, so I don't think I can touch it. 😔 And it will probably take me a while to figure out the right emscripten/cmake command to correctly compile it with statically-linked sqlite3. The uncompressed spatialite wasm bundle in that repo is 9MB. I'm not sure how much is emscripten/spatialite/geopackage/sqlite3/GEOS, but loading a several MB bundle just to parse input data wouldn't be ideal.