search

opengeospatial / geoparquet

Specification for storing geospatial vector data (point, line, polygon) in Parquet
https://geoparquet.org
Apache License 2.0
825 stars 56 forks source link

PROJJSON for CRS, WKT for CRS and ISO19111 #167

Open chris-little opened 1 year ago

chris-little commented 1 year ago

The PROJJSON format for specifying CRSs is highlighted in the draft GeoParquet specification in the “crs”section.

In 2022, work was initiated in the OGC CRS SWG, with the collaboration of the PROJJSON people, to make PROJJSON CRS fully consistent and compatible with OGC/ISO19111 and WKT2 for CRS. Perhaps alignment with this should be explicitly mentioned in the GeoParquet Charter, or in a workplan annex?

rouault commented 1 year ago

In 2022, work was initiated in the OGC CRS SWG,

PROJJSON 0.6.0 should be aligned with the latest revision of WKT2:2019. That said the work to make it an official OGC standard is stalled due to lack of resources to do so.

Perhaps alignment with this should be explicitly mentioned in the GeoParquet Charter, or in a workplan annex?

Doesn't seem to me to be something GeoParquet itself should address as GeoParquet is "just" a user of PROJJSON. Of course GeoParquet users can contribute to PROJJSON if there are some gaps to fill.

chris-little commented 1 year ago

@rouault I would be happier if should be was is. I thought there was some technical detail that needed addressing or at least made explicit and explained, perhaps as informative good/best practice? These little wrinkles can develop into rather bigger "fault lines" which impede interoperability.

hobu commented 1 year ago

I would be happier if should be was is.

I think the should be is qualifying because WKT2 has had continued updates itself as issues have been found while Even was developing PROJJSON through his finding inconsistencies and misstatements – some of which materially changed things. The development of PROJJSON has bolstered WKT2 by tightening it up, and the relationship between the two documents is not necessarily one where PROJJSON is a subjugate. The effort also identified industry WKT2 implementations that are non-conforming.

The standardization story of PROJJSON going forward is a matter of resources, and no organization has stepped forward to be the benefactor of such an effort. PROJJSON is evolved and stable enough that other specifications are referencing it, but if entities need it to jump the motorcycle through the burning ring of standardization fire, they need to push in some resources for the "PROJJSON people" to jump on the bike.

rouault commented 1 year ago

I would be happier if should be was is.

My experience is that pretty much every human production larger than one line is likely to be buggy, including approved standards. Hence a cautious "should".

perhaps as informative good/best practice

The known deviations are documented at https://proj.org/specifications/projjson.html#deviations-with-the-wkt2-2019-specification. There are there for good reasons, are about rather esoteric use cases and unlikely to evolve at that point.

which impede interoperability.

My experience is that having independent implementations that implement the same spec is far from enough to guarantee they are interoperable. Interoperability is mostly the result of experimenting with making 2 implementations talk to each other and see what works and what doesn't, adjust, rince and repeat until it works (to the extent of what is tested). For example WKT (or PROJJSON) is just a grammar of how CRS are represented. WKT implementation need to follow the same grammar of course. But the real interoperability comes from the fact that they agree on "details" like datum names, projection and parameter names, etc. All of which are mostly opaque strings in the WKT spec itself. There is just a recommendation of following the content of the EPSG registry, but this is not requirement (I could point at at least one WKT2 implementation from a major GIS vendor that doesn't use EPSG names), and the EPSG registry itself is a moving target, sometimes modifying names.

chris-little commented 1 year ago

@hobu I am keen to support jumping through the standardisation "ring of fire". ( I have had several singes, though perhaps not willing on my 1966 Triumph Tiger 90).

In particular, I and colleagues have been straddling the JSON/WKT divide with OGC API-EDR (uses WKT for geometries and just string names for CRSs) and recommends, but not mandates, CoverageJSON for payloads. In CoverageJSON we had to leave the door open and postpone any PROJJSON/WKT2 CRS decision. Maybe that is the optinmal course, but it would be nice to allow both in a defined, consistent, stable way.

I raised this issue to try to identify some resources from wherever possible.

chris-little commented 1 year ago

@rouault Thank you for the reference which I had not seen. I will add it as issues to be discussed in the OGC EDR API Standards WG and the CoverageJSON task team, to influence their plans, but progress will depend on inidividuals' enthusiasm.

If that reference text was mentioned as appropriate in specifications like GeoParquet that mention WKT and PROJJSON CRSs, I would be happy to close this issue.