[Geojson] GeometryCollection not treated as a Geometry type

Sean Gillies sgillies at frii.com
Mon Oct 8 08:01:48 PDT 2007


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




More information about the GeoJSON mailing list