Open kylebarron opened 1 year ago
I think it makes sense to relax the test_json_schema.py
script so it doesn't make an assertion about the $schema
member of the crs
object. The important part is that the rest of the crs
object is compatible with the projjson schema (and that schema doesn't have any requirements about the $schema
property).
I agree for #179 specifically we don't need to resolve this, but as a broader question as GeoParquet gets closer to 1.0: how do we want to handle the fact that we're interlinked to another evolving specification? If we go to 1.0, and then PROJJSON makes a breaking change or goes to 1.0 itself, then would we need to release a 2.0 that uses the new version of PROJJSON?
Otherwise users on the latest version of PROJ would be writing Parquet files that don't pass the validator
Yeah, I agree that the broader question is important to address. Users cannot easily control what version of PROJ is installed, so they cannot easily control what version of PROJJSON is written. So tools that generate GeoParquet will have a difficult time ensuring that they write out metadata that is compliant with any particular GeoParquet version that depends on a fixed version of PROJJSON.
It get's even more difficult and an update might be required: https://github.com/OSGeo/PROJ/issues/4088
Right now the Parquet json schema links to PROJJSON schema version 0.5: https://github.com/opengeospatial/geoparquet/blob/ad32ccaf5534a3680e62bf9de3f9837befd9c717/format-specs/schema.json#L39
But PROJJSON is now on version 0.6: https://proj.org/en/9.2/schemas/v0.6/projjson.schema.json
How do we want to handle the referenced projjson schema version?