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
I assume the OGC Simple Features spec mandates this but I am unable to find a source:
boolean-validwill reject a MultiLineString which has coordinates with only one LineString, e.g. "coordinates": [ [...] ]
The GeoJSON spec is frustratingly silent on whether or not MultiLineString coordinates can be empty; however, we frequently encounter GeoJSON MultiLineStrings composed of a single LineString, typically from GPS devices.
Curiously, for the other multipart geometries, boolean-validdoes notenforce this. Why is that?
A GeometryCollection with an empty "geometries": [] is similarly rejected, though the GeoJSON spec explicitly allows this. Again, I assume the reason is the OGC spec, but I can't find a direct source.
As for MultiLineStrings, I observe that the case for MultiLineString is identical to the case for LineString, which would suggest this is a actually a bug; or at least that the MultiLineString case is missing an inner loop to validate that each coordinate has at least lng and lat, as is done with LineStrings.
The text was updated successfully, but these errors were encountered:
I assume the OGC Simple Features spec mandates this but I am unable to find a source:
boolean-valid
will reject aMultiLineString
which hascoordinates
with only oneLineString
, e.g."coordinates": [ [...] ]
The GeoJSON spec is frustratingly silent on whether or not
MultiLineString
coordinates can be empty; however, we frequently encounter GeoJSONMultiLineString
s composed of a singleLineString
, typically from GPS devices.Curiously, for the other multipart geometries,
boolean-valid
does not enforce this. Why is that?A
GeometryCollection
with an empty"geometries": []
is similarly rejected, though the GeoJSON spec explicitly allows this. Again, I assume the reason is the OGC spec, but I can't find a direct source.As for
MultiLineString
s, I observe that thecase
forMultiLineString
is identical to the case forLineString
, which would suggest this is a actually a bug; or at least that theMultiLineString
case is missing an inner loop to validate that each coordinate has at leastlng
andlat
, as is done withLineString
s.The text was updated successfully, but these errors were encountered: