Open thePanz opened 4 months ago
@thePanz Thanks for bringing this to my attention! I'm a bit reluctant to add something that has been removed from the spec, and am wondering if this belongs to this library or to a third-party library.
Do you actually have a use case for this?
@BenMorel Do you actually have a use case for this?
Our application is receiving a GeoJSON file, and we need to identify if it still contains the "deprecated" property. In this case what we do is to deserialize the JSON contents and parse that property (if available), and then use the Brick library to (again) deserialize the JSON contents and have the Geometry objects back.
What I would like is to avoid such double de-serialization happening, but as you suggested it would require to include handling a deprecated property from the GeoJson specification.
Not sure which is the best path here, WDYT?
In a previous version of the GeoJson format, a
Coordinate Reference System
https://datatracker.ietf.org/doc/html/rfc7946#section-4, was supported and defined in the format.According to the documentation:
Would you accept a PR introducing the parsing of the
crs
in theGeoJsonReader
class? This would help in the reading of such property, when GeoJson from a legacy format is provided, instead of requiring to parse the JSON contents twice (first with this library, and the second time to extract the CRS property and apply the SRID to all geometries in the GeoJson file).Note: other libraries supports that: https://rdrr.io/cran/geojson/man/crs.html
WDYT?