Feature request: allow empty Multi* geometries

[hholzgra]

RFC 7946 says in section 3.1:

o A GeoJSON Geometry object of any type other than
"GeometryCollection" has a member with the name "coordinates".
The value of the "coordinates" member is an array. The structure
of the elements in this array is determined by the type of
geometry. GeoJSON processors MAY interpret Geometry objects with
empty "coordinates" arrays as null objects.

So whether e.g. a MultiLineString with zero members is valid or not is up to the implementation

geometry: {
  type: "MultiLineString",
  coordinates: []
}

The Mapnik GeoJSON plugin does not accept such empty MultiLineString geometries.

Problem for is that the Leaflet GeoJSON implementation, which I use to verify GeoJSON files selected for upload before actual transmission to my rendering server, has decided on accepting such geometries, and there seems to be at least some official data source in France producing GeoJSON files that may contain such empty geometries.

So far I've only had a single such upload on my rendering service, and unfortunately I don't have any contact information to find out whom / what the uploaded file was created by, unfortunately.

[artemp]

@hholzgra #4432

{ \"type\": \"LineString\", \"coordinates\":[]} // LINESTRING EMPTY
{ \"type\": \"Polygon\", \"coordinates\":[]} // POLYGON EMPTY
{ \"type\": \"Polygon\", \"coordinates\":[[]]} // POLYGON EMPTY
{ \"type\": \"MultiPoint\", \"coordinates\":[]} // MULTIPOINT EMPTY
{ \"type\": \"MultiLineString\", \"coordinates\":[]} // MULTILINESTRING EMPTY
{ \"type\": \"MultiLineString\", \"coordinates\":[[]]} // MULTILINESTRING EMPTY
{ \"type\": \"MultiPolygon\", \"coordinates\":[]} //MULTIPOLYGON EMPTY
{ \"type\": \"MultiPolygon\", \"coordinates\":[[]]} //MULTIPOLYGON EMPTY
{ \"type\": \"MultiPolygon\", \"coordinates\": [[[]]]} //MULTIPOLYGON EMPTY

NOTE: "Point" can't have an empty array according to https://www.rfc-editor.org/rfc/rfc7946#section-3.1.1
Also "LineString" and "LinearRing" require >=2 and >=4 (first and last positions are equal for LinearRing) respectively but I decided to leave geojson parser flexible in those cases.