[Geojson] GeometryCollection not treated as a Geometry type

[Christopher Schmidt]

On Mon, Oct 08, 2007 at 10:30:10AM -0400, 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. 

That's probably true. Please feel free to suggest a wording change --
the only reason that it is worded like that is to exclude
GeometryCollections. In fact, that entire first chunk of text needs
rewording -- the key points are: 
 * All geometries have "coordinates":, EXCEPT:
 * If the geometry object is a GeometryCollection, which has
   'geometries' instead.

> A geometry collection is a single object, and
> represents a single geometry (albeit potentially disconnected). 

Agreed. Bad wording on my part -- I'm sorry.

> A multipoint
> is a geometry collection but is included as an example in a list from which
> geometry collections are specifically excluded. 

A MultiPoint is, in my mind, a single geometry, not a geometry
collection -- a geometrycollection is a list of disconnected components.
(In general, it probably only makes sense to create GeometryCollections
from objects of different types -- at least, that's all I can imagine.)   

> And Point is defined in such
> a manner as to confuse it with multipoint. 

Hm, I'm not sure I understand: multipoint says '"coordinates" must be an
array of the things described by Point' -- that means that since point
has [x, y], MultiPoint has [[x,y], [x,y]] -- That's clear to me, but
clearly isn't to you. Can you explain what you would prefer?

> 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. 

Understood. I *think* this is just a case of bad wording on my part,
becuase I was in a rush to go fix code instead of fixing the spec. Can
you propose a better wording for this section? I think it all stems from
the use of the term 'single geometry', which is obviously poorly
defined. 

> You guys are spending way too much time being different for no apparent
> reason. 

For the record, the change was an attempt to be exactly the same --
specifically, the same as WKT. (I don't understand GML well enough to
comment.) In WKT, a Union of a a point and a linestring returns a
geometrycollection with a Point and a Linestring in it: this
representation is mimiced in GeoJSON (and that's not changing!): the
same structure in GeoJSON, WKT, and GML (thanks to OGR):

>>> g.ExportToWkt()
'GEOMETRYCOLLECTION (POINT (0 0),LINESTRING (1 1,2 2))'
>>> g.ExportToGML()
'<gml:GeometryCollection><gml:geometryMember><gml:Point><gml:coordinates>0,0</gml:coordinates></gml:Point></gml:geometryMember><gml:geometryMember><gml:LineString><gml:coordinates>1,1
2,2</gml:coordinates></gml:LineString></gml:geometryMember></gml:GeometryCollection>'
>>> g.ExportToJson()
{'type': 'GeometryCollection', 'geometries': [{'type': 'Point',
'coordinates': [0.0, 0.0]}, {'type': 'LineString', 'coordinates': [[1.0,
1.0], [2.0, 2.0]]}]}

The only difference in the spec is that GeometryCollection is now
universally treated as a geometry object, meaning it can fill the
'geometry' member of a feature, whereas before the spec was unclear on
that. 

> 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. 

To me, I look at those three different representations ,and they all
seem to be saying the same thing. Where am I going wrong?

Regards,
-- 
Christopher Schmidt
MetaCarta