You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GeoJSON spec supports "unlocated" Feature objects where the "geometry" member is a JSON null value. The Geo library simply ignores Features of this kind, even if they have their properties populated. A real-world web service that returns GeoJSON of this type is the National Weather Service Alert API, https://api.weather.gov/zones.
I looked into resolving this issue via a pull request but I am not comfortable contributing structural changes to the library without further discussion. I would appreciate help with this issue.
The text was updated successfully, but these errors were encountered:
Sigh. Yeah, filtering these out was probably the wrong choice in #176—I knew at the time that the GeoJSON spec hinted that features with no geometry might be desired. I'll look into making these work.
@carstenpiepel Thoughts on what the best way to handle this might be? My initial thought was a %GeometryCollection{} with an empty list of geometries, but the GeoJSON spec warns:
To maximize interoperability, implementations SHOULD avoid nested GeometryCollections.
Should we therefore implement a new struct like %Geo.Null{coordinates: nil, properties: %{}, properties: %{}}? It's... kind of ugly. 😕
The GeoJSON spec supports "unlocated" Feature objects where the "geometry" member is a JSON null value. The Geo library simply ignores Features of this kind, even if they have their properties populated. A real-world web service that returns GeoJSON of this type is the National Weather Service Alert API, https://api.weather.gov/zones.
I looked into resolving this issue via a pull request but I am not comfortable contributing structural changes to the library without further discussion. I would appreciate help with this issue.
The text was updated successfully, but these errors were encountered: