[Geojson] GeometryCollection not treated as a Geometry type

Mon Oct 8 06:57:36 PDT 2007

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.standards.org.au%2FCOMMITTEES%2FIT-004%2FPRIVATE%2FI0028%2FISO%252019107%2520.pdf&ei=mTQKR_DND5jeiAHGwpzICQ&usg=AFQjCNF2ZYY-rNAQis_KrfVQb6GOMpNgww&sig2=yKcLMO_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=157&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