[Geojson] GeometryCollection not treated as a Geometry type

[John Herring]

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

You do what you can when you can because you can.

The opinions expressed in this email are 
purely my own and do not necessarily 
represent the opinions of any organization
or otherwise sane person or persons.

John R. Herring
Architect, Spatial Products
Oracle Corporation
One Oracle Drive
Nashua, New Hampshire 03062
ph: 1 603 897 3216
fx: 1 603 897 3334

Annue cœptis - Novus Ordo Seclorum
  


-----Original Message-----
From: ajturner at gmail.com [mailto:ajturner at gmail.com] On Behalf Of Andrew
Turner
Sent: Monday, October 08, 2007 9:58 AM
To: John Herring
Cc: Christopher Schmidt; geojson at lists.geojson.org
Subject: Re: [Geojson] GeometryCollection not treated as a Geometry type

Interesting thoughts - but I'm not sure what your point is specifically with
regards to GeoJSON?

I wasn't sure what ISO19107 was:
ISO 19107:2003 specifies conceptual schemas for describing the spatial
characteristics of geographic features, and a set of spatial operations
consistent with these schemas. It treats vector geometry and topology up to
three dimensions. It defines standard spatial operations for use in access,
query, management, processing, and data exchange of geographic information
for spatial (geometric and
topological) objects of up to three topological dimensions embedded in
coordinate spaces of up to three axes.


Also, here are some pertinent links for reading ISO 19107 without paying
large amounts of money:
http://www.google.com/url?sa=t&ct=res&cd=1&url=https%3A%2F%2Fcommittees.stan
dards.org.au%2FCOMMITTEES%2FIT-004%2FPRIVATE%2FI0028%2FISO%252019107%2520.pd
f&ei=mTQKR_DND5jeiAHGwpzICQ&usg=AFQjCNF2ZYY-rNAQis_KrfVQb6GOMpNgww&sig2=yKcL
MO_iFIeb3liOvVvmJw

OGC's take on the ISO 19107
http://www.opengeospatial.org/standards/as

Andrew

On 10/8/07, John Herring <john.herring at oracle.com> wrote:
> Chris,
>
>         I usually avoid such discussions, but I am beginning to see a 
> divergence from what ISO 19107 actually says. So I'll make a couple of 
> quick observations  that need to be considered in any representation of
geometry.
>
>         First, a geometry is a (probably infinite) set of spatial 
> positions (generically called points). This it that old "loci of 
> points" stuff you get in high school geometry class, but it is 
> repeated in ISO 19107. There, a GM_Object is subclassed from a thing 
> called "Transfinite set of direct positions" which is UMLese for a 
> possibly infinite set of spatial location defined by coordinates (or 
> more precisely, definable by coordinates - as long as the points are 
> well-defined, how they are defined is of little or no consequence).
>
>         The only non-infinite (finite) geometry is the point, or a 
> finite collection of points. Ergo, any line or surface is never equal 
> to any Multipoint (you can get into some nasty epistemological circles 
> with this, because any fixed direct position representation is by 
> definition a finite set, but the geometry represented by those direct 
> positions can go far beyond the original representation used. A line 
> between two distinct integer points contains an infinite number of 
> real valued points, some of which would require a representation never 
> used in computers. The line from (0,0) to (5,5) contains the points
(SQRT(2), SQRT(2)), and (pi, pi).
>
>         Second, everything subtyped from GM_Object in ISO 19107 is a 
> geometry. This included all the collections. A collection is defined 
> as a geometry consisting of the set-union of its elements.
>
>         Third, any two geometry representations are equal to one 
> another if and only if the resulting "transfinite set of positions" 
> are equal as sets of positions.
>
>         Fourth, the content of a geometry is defined by its "stored
points"
> in combination with its interpolation mechanisms. Different 
> combinations can be equal even it they share very few stored points in 
> common. For example, a two point line is equal to a line-string of a 
> 1000 points if those points are all collinear, lie between the same 
> two endpoint as the first, and contains those same endpoints. 
> Orientation is an attribute of representation, not of the underlying 
> geometry, so a line from A to B is the same geometry as a line from B 
> to A. So a Collection containing these two lines, is equal to either line
by itself.
>
>         There are probably other things that folks like to try to 
> avoid about geometry by placing artificial restrictions on 
> representations, but none of that works in the long run, and none of 
> it is consistent with ISO 19107.
>
>
> Regards,
> John
>
> You do what you can when you can because you can.
>
> The opinions expressed in this email are purely my own and do not 
> necessarily represent the opinions of any organization or otherwise 
> sane person or persons.
>
> John R. Herring
> Architect, Spatial Products
> Oracle Corporation
> One Oracle Drive
> Nashua, New Hampshire 03062
> ph: 1 603 897 3216
> fx: 1 603 897 3334
>
> Annue cœptis - Novus Ordo Seclorum
>
>
>
> -----Original Message-----
> From: geojson-bounces at lists.geojson.org 
> [mailto:geojson-bounces at lists.geojson.org] On Behalf Of Christopher 
> Schmidt
> Sent: Friday, October 05, 2007 5:51 PM
> To: geojson at lists.geojson.org
> Subject: Re: [Geojson] GeometryCollection not treated as a Geometry 
> type
>
> On Fri, Oct 05, 2007 at 05:33:25PM -0400, Christopher Schmidt wrote:
> > Currently, GeometryCollection is not treated as a geometry type. 
> > This is essentially an oversight -- up until now, the people 
> > primarily working on the spec didnt' really use GeometryCollection, 
> > to the best of my knowledge.
>
> After re-reading the spec, I realized that we kind of treated 
> GeometryCollection as a geometry. But not really. I had bumped the 
> version before that (thinking 'oh, people support draft4 now, people 
> like OpenLayers 2.5'), but I'm just going to leave it at this point.
>
> The change made to the spec is:
>
> http://wiki.geojson.org/index.php?title=GeoJSON_draft_version_5&diff=1
> 57&old
> id=155
>
> Feedback welcome. Going to go through the rest of the doc now and see 
> if it's unclear anywhere else.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>


--
Andrew Turner
ajturner at highearthorbit.com      42.2774N x 83.7611W
http://highearthorbit.com              Ann Arbor, Michigan, USA
Introduction to Neogeography - http://oreilly.com/catalog/neogeography