[Geojson] FW: GeometryCollection not treated as a Geometry type

Christopher Schmidt crschmidt at metacarta.com
Mon Oct 8 11:28:16 PDT 2007


On Mon, Oct 08, 2007 at 04:11:16PM +0100, Stephen Battey wrote:
> I think section 3.2.1 has too much information in it.
> Can we replace that section with the following, effectively splitting
> the definition of a geometry collection into its own sub-section.
> 
> 
> 3.2.1 A GeoJSON geometry object with type "GeometryCollection" is a
> geometry object which represents a collection of geometry objects.
> 
> 3.2.1.1 A GeoJSON geometry object of type "GeometryCollection" must have
> a member with the name "geometries". The value corresponding to
> "geometries" is an array. Each element in this array is a GeoJSON
> geometry object.
> 
> 3.2.2 A GeoJSON geometry object of any other type (other than
> "GeometryCollection") must have a member with the name "coordinates".
> The value of the coordinates member is always an array (referred to as
> the coordinates array below). The structure for the elements in this
> array are determined by the type of geometry.
> 
> Followed by sections 1-7 for the description of the coordinates member.

That seems good to me, though it does feel backwards to be defining
GeometryCollections (the less common case) first.  

> 
> Is it okay if I go in and make that change? (Is that the wiki way?)

I'd say 'yes'. sending a link with your changes back to the list seems
like a good thing.  

> And what version of the draft are we up to now? Things are moving so
> rapidly, I thought we were on version 5 earlier today but I think we
> might now be on version 7!

It looks like Andrew copy pasted draft5 -> draft6 and added some
examples -- this is not the best way to do things, because then we lose
history. 

Also, the only case in which I would say that hte draft version needs to
be updated is:
 * Consensus appears to have been reached, there are some
   implementations "in the wild"
 * Something changes which causes those implementations to no longer
   be correct.

This means to me that:
 * Example changes
 * Wording changes

Don't need a revision bump, nor do active edits during consensus
building -- only when the spec has been 'stable' for a while and changes
in the way it needs to be implemented do we need to bump the version.

To that end, I've copied Andrew's edits back to draft version 5, and
killed version 6, which only had those example changes (and no
functional changes) and we should continue working on 5 until we create
some kind of functional change that breaks backwards compatibility.
  
Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the GeoJSON mailing list