srid in GeoJSON output

[larsbutler]

Hi! This isn't so much an issue, but rather, a question:

I see that GeoJSON output can contain an srid attribute:

%Geo.Point{ coordinates: {30, -90}, srid: nil}

This attribute isn't part of the official GeoJSON spec. How did you come to the decision to add it? I'm just asking because I'm working on a very similar library for Python. I didn't initially support SRIDs/EWKB/EWKT, but I've built a draft of the feature. In a discussion of the feature, one of the GeoJSON creators suggested the I put the srid right at the root of the GeoJSON object:

{"type": "Point", "coordinates": [30, 90], "srid": "4326"}

My alternative suggestion was to place it in a metadata object. Like so:

{"type": "Point", "coordinates": [30, 90], "metadata": {"srid": "4326"}}

My thought was that this would be more extensible. What are your thoughts? I'm curious about your thought process on your design.

Great library, by the way. The code looks really simple and elegant.

[bryanjos]

@larsbutler Geo puts it in the crs section which is part of the geojson spec as far as I can tell, but we are probably not using it correctly in Geo: http://geojson.org/geojson-spec.html#coordinate-reference-system-objects

I know there is also the properties field. Would it not work there either?

[larsbutler]

Ah, I misinterpreted the output; I thought you were putting the srid in an srid member like so:

{"type": "Point", "coordinates": [30, 90], "srid": "4326"}

But now I see that it's placed in a crs object:

iex(1)> import Geo
Geo
iex(2)> import Poison
Poison
iex(3)> point = Geo.WKB.decode("0101000020E61000009EFB613A637B4240CF2C0950D3735EC0")
%Geo.Point{coordinates: {36.9639657, -121.8097725}, srid: 4326}
iex(4)> Geo.JSON.encode(point) |> Poison.encode!  
"{\"type\":\"Point\",\"crs\":{\"type\":\"name\",\"properties\":{\"name\":\"EPSG4326\"}},\"coordinates\":[36.9639657,-121.8097725]}"

Geo puts it in the crs section which is part of the geojson spec as far as I can tell, but we are probably not using it correctly in Geo.

It does seem that the crs section was removed from the official spec, according to https://tools.ietf.org/html/rfc7946#section-4. I wouldn't say your usage is incorrect, though. Because the spec doesn't say anything specific, we can just do whatever we want. :) It would be nice to have some standardization, though; I'm a bit frustrated with the lack of specificity in the spec, to be honest.

I know there is also the properties field. Would it not work there either?

There is no properties in a Geometry object. In fact, the spec explicitly states that Geometry objects must not contain a properties object. :/ Therefore, I think your approach of including a crs object is the most correct approach, since it follows http://geojson.org/geojson-spec.html#coordinate-reference-system-objects. Even though the CRS spec there is obsolete, it's better than nothing.

[bryanjos]

Thanks for pointing that out. Will probably have to make some changes here, but not sure exactly what just yet

[larsbutler]

Hey @bryanjos, even though your approach uses a deprecated (but documented--in the old geojson spec) approach and there is no new spec to replace it, I think we can close this issue. For consistency I will follow your approach in geomet.

Thanks for the discussion!