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

[Stephen Battey]

I've put this change into draft 5.
http://wiki.geojson.org/index.php?title=GeoJSON_draft_version_5&diff=165
&oldid=163


I'm still not 100% happy that the term "GeoJSON geometry object" is
formally introduced in section 3.2.
In other sections the wording used is something like:
 >  A GeoJSON object of type "Feature" ...
But that wording doesn't work in this case because we want to refer to a
group of types - we need a collective name.
I quite like "GeoJSON geometry object", it sounds like an
extension/sub-set of "GeoJSON object".


Steve


> -----Original Message-----
> From: Christopher Schmidt [mailto:crschmidt at metacarta.com] 
> Sent: 08 October 2007 19:28
> To: Stephen Battey
> Cc: geojson at lists.geojson.org
> Subject: Re: [Geojson] FW: GeometryCollection not treated as 
> a Geometry type
> 
> 
> 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
> 
> Incoming e-mail scanned by Altman Technologies
> 
Email has been scanned for viruses and spam by Altman Technologies