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

[Stephen Battey]

Okay, I re-read the spec a few times and I think I've got confused over
the use of the term 'single geometry'.
Where section 3.2.1 states:

> ... any GeoJSON object that represents a single geometry
> (referred to as a geometry object below) must have a member
> with the name "coordinates".

I read on to section 3.2.1.8.1:

> ... The value corresponding to "geometries" is an array.
> Each element in this array is a geometry object as defined above.

and took that to mean "Each element in this array is a single geometry
object as defined above."


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.


Is it okay if I go in and make that change? (Is that the wiki way?)
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!

Steve






-----Original Message-----
From: Stephen Battey 
Sent: 08 October 2007 13:11
To: 'Martin Daly'; Christopher Schmidt; geojson at lists.geojson.org
Subject: RE: [Geojson] GeometryCollection not treated as a Geometry type


If MultiPoint, MultiLineString and MultiPolygon objects provide
compatibility with OGC SF then they are not redundant.
My thoughts were that a MultiPoint, say, has better type safety than a
GeometryCollection that contains multiple Points. That would explain why
you might use one or the other but it doesn't explain why a Geometry
object with MultiPoints is a single geometry while a GeometryCollection
with multiple points is not. Should there be a distinction?

Maybe I'm mis-reading the spec. Maybe there isn't a distinction between
single geometry and geometry collections.
Are geometry collections allowed inside geometry collections - or is the
geometries array restricted to single geometry objects?

Steve



> -----Original Message-----
> From: Martin Daly [mailto:Martin.Daly at cadcorp.com] 
> Sent: 08 October 2007 12:17
> To: Stephen Battey; Christopher Schmidt; geojson at lists.geojson.org
> Subject: RE: [Geojson] GeometryCollection not treated as a 
> Geometry type
> 
> 
> > Well, this got me wondering ... if we can define a geometry using a
> > geometry collection (i.e. multiple geometries), are MultiPoint,
> > MultiLineString and MultiPolygon redundant?
> 
> That is an entirely arbitrary cut-off point.
> 
> One could just as easily argue that, because GeometryCollection could
> contain a single Geometry, that Point, LineString and Polygon are also
> redundant.  It has also been argued, a month or so ago
> (http://lists.geojson.org/pipermail/geojson-geojson.org/2007-S
eptember/0
00206.html) that Point, LineString and Polygon are redundant because a
single-Geometry MultiPoint, MultiLineString or MultiPolygon is the same
thing, thus ending up with a different, but also arbitrary, subset.

For me, either we have all types (+1, and +compatibility with OGC SF),
or we have one type (-1).

M
Incoming e-mail scanned by Altman Technologies
Email has been scanned for viruses and spam by Altman Technologies