[Geojson] GeometryCollection not treated as a Geometry type

[Sean Gillies]

John Herring wrote:
> Case in point (pardon the semi-pun):
> 
> From the place cited:
> 
>>> In addition to the type member, any GeoJSON object that represents 
>>> a single geometry (referred to as a geometry object below) must have  
>>> a member with the name "coordinates". This does not apply to geometry  
>>> objects of type "GeometryCollection". 
>>> For type "Point", each element in the coordinates array is a number  
>>> representing the point coordinate in one dimension. The order of  
>>> elements follows x, y, z order (or longitude, latitude, elevation for  
>>> coordinates in decimal degrees).
>>> For type "MultiPoint", each element in the coordinates array is a   
>>> coordinates array as described for type "Point".
> 
> This has a couple of semantic disconnects. First, the concept of a single
> geometry is undefined. A geometry collection is a single object, and
> represents a single geometry (albeit potentially disconnected). A multipoint
> is a geometry collection but is included as an example in a list from which
> geometry collections are specifically excluded. And Point is defined in such
> a manner as to confuse it with multipoint. Three sentences with three
> confusions of terminology is a bit dense for special casing. While I do not
> mind folks ignoring ISO 19107 (which is the official OGC geometry volume) in
> small things, it is disconcerting to have the requirement to catalogue the
> disconnects to understand what is suppose to be a simple specification. 
> 
> You guys are spending way too much time being different for no apparent
> reason. It is a waste of your time, and will be a waste of the time of the
> reader who will have to realize the differences in rules in each
> specification instead of following a consistent approach for all OGC
> specification of geometry representations. Occam and Einstein both saw that
> simple things should be done simply. 
> 
> 
> Regards,
> John

John,

Agreed, there is no good reason to diverge from the well known SFSQL 
geometry model. I think we're getting there now in the latest revision 
to the draft spec, and just need to clarify and simply the language used 
in the draft.

Cheers,
Sean