Projjson and CRS defaults

[cholmes]

I've been thinking about CRS's and defaults, as we talked about in our co-working session

Thanks @brendan-ward for putting together the #97 to get a sense of what the 'recommendations' would look like for a naive implementation if we required them.

I do think that an extra field that non-CRS clients can easily rely upon to know data is long/lat makes for a simpler story (be it a 'profile' as suggested in #89 or a simpler true/false field).

The biggest downside is that information between the two could be out of sync, and we'd need all kinds of corner case guidance as to which to 'trust', what to do if the crs is null, etc.

But I was wondering if we could just enhance the projjson spec in some way to include the 'simple' information, or make some requirement for the use of projjson in geoparquet. Like since projjson is a spec that we are proposing as part of geoparquet can we make it work better for us? Then there would just be one place to check. I'm thinking ideas like:

• Add the same true/false field that says 'this is long/lat' that we were contemplating adding to geoparquet, but add it directly to projjson. Naive clients can just look it up then.
• Require ID in the geoparquet spec, for anytime you use of 'common' (all epsg database? long/lat ones?) ones. So that the explanation of what non-crs aware clients need to do is just 'look for ID', but we more strongly require crs aware writers to always include the id.
• Require ID in projjson spec? At least for cases when the projjson is a representing a 'common' one? I'm not deep in the projjson spec, and I feel like there's been pushback, but I'm wondering if that pushback is because 'that's what wkt2 does and projjson just wants to map it'. Like could we have projjson further 'upgrade' things by making ID a required field? Perhaps with some special id to say 'this really is a custom one', but to nudge people more to actually always including the ID and enabling clients to rely on it.

And there may be better ideas if we open the aperture to include tweaking with projjson spec.

I do think if we could reliably tell non-crs aware clients that 'you can reliably look at projjson ID and if it's EPSG:4326 or OGC:CRS84 then you can treat it as long/lat' then that seems straightforward enough for me. I think it's ok if that doesn't capture custom ones that are equivalent to a proj reader, especially if we have some clear recommendations to writers to always include the id if at all possible. Like ideally a 'geoparquet validator' would at least raise a 'warning' if it finds a crs that is equivalent but does not include an ID. I do think the extension/profile idea could be interesting, though more as just a 'validation profile' that would tell you that if you included the ID then you'd meet that certain profile (but there wouldn't be an explicit identifier that clients would read to be able to make assumptions, which is how COG works, there's not a field that says 'I am a COG', you're just a COG if you meet the requirements).

[rouault]

Add the same true/false field that says 'this is long/lat' that we were contemplating adding to geoparquet, but add it directly to projjson.

Isn't it just a matter of testing crs["type"] == "GeographicCRS" ? If clients don't care about datums and the like, that's enough to check if it is a lat/lon type of CRS.

Require ID in projjson spec?

No, we can't do that. One legitimate use case of PROJJSON is to specify CRS not present in EPSG or any other authority. That's actually the main use case for PROJJSON (or WKT). Otherwise, if you always use "known" CRS, they you just use things like "srsId" = "EPSG:4326"

But of course I agree that as a recommendation we ask writers to write the "id" member when it is known.

Perhaps with some special id to say 'this really is a custom one', but to nudge people more to actually always including the ID and enabling clients to rely on it.

I don't like this...

[tschaub]

testing crs["type"] == "GeographicCRS"

That ^ would be nice and tidy.

Does PROJJSON always normalize the type to exactly this value (i.e. not "GEOGCRS" or any other spelling)?

[rouault]

Does PROJJSON always normalize the type to exactly this value

yes, this is a constraint of the schema: https://github.com/OSGeo/PROJ/blob/9f89c7288e44c64ba234a299b1d5528a54d9d61e/schemas/v0.4/projjson.schema.json#L561

[tschaub]

don't care about datums and the like

I guess making a bad assumption about the units (degrees instead of radians) would be a bigger mistake but pretty unlikely. Also not too bad to dig in and confirm the units.

[rouault]

I guess making a bad assumption about the units (degrees instead of radians) would be a bigger mistake but pretty unlikely

radians never occur in practice. One exception I can think of in the EPSG registry is the ancient French "NTF (Paris)" / EPSG:4807 which uses grad as units.
The check for degree can be done with crs["coordinate_system"]["axis"][0]["unit"] == "degree" or ("name" in crs["coordinate_system"]["axis"][0]["unit"] and crs["coordinate_system"]["axis"][0]["unit"]["name"] == "degree") (the normal form output by PROJ is to use the string value "degree" . Using an object with "name", "conversion_factor" members is what is done by PROJ for other units)
Another complication is geographic CRS in degrees but that uses a non-Greenwhich prime meridian, which could lead to very bad coordinate interpretation. That can happen for ancient CRS. Like "Monte Mario (Rome)" / EPSG:4806.
One way to detect if it is Greenwich is to check for "datum" in crs and ("prime_meridian" not in crs["datum"] or crs["datum"]["prime_meridian"]["longitude"] == 0) (PROJ will always omit the prime_meridian if its longitude is 0)

[brendan-ward]

It seems like a core issue here is whether or not we are trying to distinguish between a CRS that holds longitude / latitude data (based on in whatever sphereoid, meridian, etc) and one that is equivalent enough to OGC:CRS84 / EPSG:4326. The former runs the risk of misinterpretation especially when there is no clear documentation between the data producer and consumer (via a more complete PROJJSON record, for instance), which I'm hoping we can agree here would be a bad thing and we shouldn't make that eaiser to do.

Is there a case where a CRS can be functionally equivalent to OGC:CRS84 / EPSG:4326 but not have an ID set? It seems that any of the custom ones that lack an ID would also no longer be functionally equivalent. Thus it might be sufficient simply to check for these IDs specifically, and not probe other properties to try and determine functional equivalence.

[cholmes]

Yeah, I'm leaning towards just having non-crs-aware clients check ID's, and then recommending in GeoParquet that ID's are always set for OGC:CRS84 and EPSG:4326. Even if there is a way to make one functionality equivalent without an ID I'm ok if non-CRS-aware readers ignore it, and we recommend to data producers to always include the ID if they want to be read by the widest number of clients.