@turf/boolean-valid requires MultiLineStrings to have at least two component LineStrings
I assume the OGC Simple Features spec mandates this but I am unable to find a source:
boolean-valid will 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-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 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.
@benjaminblack just do a change in code here
inlace of case "MultiLineString": if (coords.length < 2) return false; put :- case "MultiLineString": if (coords.length < 1) return false;
in their file. (https://github.com/Turfjs/turf/blob/master/packages/turf-boolean-valid/index.ts)
Thanks for reporting @benjaminblack, and for your PR @sharmaB01. I think you're right that the check is unintentional. It definitely doesn't seem based on the GeoJson spec.
@mfedderly, @twelch - if we go by the spec there doesn't seem to be any requirement that a Multi-Point/Line/Polygon have any Point/Line/Polygons at all. Just that any that do exist are valid within themselves.
The validation for MultiPolygon is probably a good model to follow. Just straight into looping over any component Polygons.
Can you foresee any issues with this being a breaking change? It would be making Turf more liberal in what it considered valid.
Am I the only one that finds it kind of weird that we're referencing the OGC at all? We aren't providing the methods as defined in the OGC spec in a lot of cases, and we are missing some of the hierarchy like curve. I agree that the 2 item spec is almost certainly a copy/paste mistake from the case above.
There's always a risk that being more liberal causes problems for consumers, but I think this is a valid bug to raise and fix with a non-breaking release. We're actively throwing away clearly valid geometries with a single LineString entry, and then the we-probably-should-accept-it-anyways empty MultiLineString even though the specs are a little quiet on exact details here.