Add support for Coordinate Reference System

[thePanz]

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:

Note: the use of alternative coordinate reference systems was
specified in [GJ2008], but it has been removed from this version of
the specification because the use of different coordinate reference
systems -- especially in the manner specified in [GJ2008] -- has
proven to have interoperability issues.

Would you accept a PR introducing the parsing of the crs in the GeoJsonReader 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?

[BenMorel]

@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?

[thePanz]

@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?

[BenMorel]

Hi, after digging a bit more, I found that supporting CRS (under the $lenient flag, or a new $legacy flag), would imply:

for "type": "name"

"crs": {
  "type": "name",
  "properties": {
    "name": "urn:ogc:def:crs:OGC:1.3:CRS84"
  }
}

We'd have to maintain a map of name to SRID, e.g. urn:ogc:def:crs:OGC:1.3:CRS84 => 4326.

for "type": "link"

"crs": {
  "type": "link",
  "properties": {
    "href": "http://example.com/crs/42",
    "type": "proj4"
  }
}

I'm not sure exactly how these work, and not supporting the link type would probably violate the old spec we're trying to support.

---

I feel like this is too much work for something that has been removed from the spec, and is probably a niche use case nowadays.

That being said, the GeoJSONReader does not complain when additional properties are passed, so you can very well:

• parse the GeoJSON with the crs property, get a Geometry with SRID 4326
• parse the GeoJSON through your custom parser that locates the crs and returns an SRID
• call $geometry->withSRID() to recursively convert the Geometry to the given SRID

This is supposing that the SRID is the same for all geometries in the GeoJSON. Things are much more complicated if it's not.

[thePanz]

We'd have to maintain a map of name to SRID, e.g. urn:ogc:def:crs:OGC:1.3:CRS84 => 4326.

yes, if we would like to fully automate the conversion of the geometries. And keeping that map aligned with all the possible values and variations would be quite a lot of work.

We could flag this request as "wont-do" and close it :)

[BenMorel]

Sounds reasonable 😉