[Geojson] GeometryCollection not treated as a Geometry type

[Christopher Schmidt]

On Mon, Oct 08, 2007 at 03:50:35PM -0400, John Herring wrote:
> Christopher, 
>  
> >> A MultiPoint is, in my mind, a single geometry, not a geometry 
> >> collection -- a geometrycollection is a list of disconnected  
> >> components. (In general, it probably only makes sense to create  
> >> GeometryCollections from objects of different types -- at least,  
> >> that's all I can imagine.)
> 
> This is a divergence from ISO 19107, and from Simple Features, which both
> subtype MultiPoint from GeometryCollection. 

Okay. That assumption isn't written into the spec, so improved text here
would solve the problem, so far as I can tell. The text that you
identified as a problem needs improvement, and once it improves, then
this disconnect will no longer be a problem. 

> This is what I meant when I said GeoJson was diverging from the rest of OGC,
> which uses ISO 19107 as the basic geometry model; even for those
> specification which predate ISO 19107, because ISO 19107 was derived in some
> sense from the earlier geometry models used in OGC prior to 1999 when Simple
> Feature came on-line (became a standard). 

If creating something which can be implemented more easily means a
divergence from OGC specs, or ISO19107, that doesn't bother me. I'd be
interested in seeing a concrete case where something that you want to
represent for, say, drawing into an OpenLayers map and allowing query
based on attributes, would be prevented based on the GeoJSON feature
model.  

> >> Hm, I'm not sure I understand: multipoint says '"coordinates"  
> >> must be an array of the things described by Point' -- that means  
> >> that since point has [x, y], MultiPoint has [[x,y], [x,y]] --  
> >> That's clear to me, but clearly isn't to you. Can you explain  
> >> what you would prefer?
> 
> The issue arose from the use of separators in GML and the way coordinates
> and coordinates strings are written (in some versions of GML). 

I'm sorry, I read the bit that followed this and didn't understand how
it related to why MultiPoint is confusing in the GeoJSON spec. Can you
propose alternative text that makes it more clear to you? 

> >> For the record, the change was an attempt to be exactly the same 
> >> -- specifically, the same as WKT. (I don't understand GML well enough to
> >> comment.) In WKT, a Union of a point and a linestring returns a 
> >> geometrycollection with a Point and a Linestring in it: this
> representation 
> >> is mimicked in GeoJSON (and that's not changing!): the same structure in 
> >> GeoJSON, WKT, and GML.
> 
> Ah ha, the dangers of backward engineering. WKT in Simple Features (06-103)
> is defined to be a representation of the semantics presented earlier in the
> document, especially as defined from the "Figure 1: Geometry class
> hierarchy". Now from  the diagram, only instantiable variants of the various
> classes need to show up in the WKT, but the semantics of the diagram are
> assumed to be preserved, even though some of the semantics finer points are
> lost in the transfer to a text format without a need to explicitly reflect
> inheritance. Now what occurred in GeoJson was a backward engineering from
> Clause 7 (the WKT) to get the semantics of what should have been gotten from
> Figure 1 (the UML) and its follow-on text (Clause 6). 

I have no idea what any of this refers to. Nothing that I've contributed
to GeoJSON is derived explicitly from any of the specifications made
available from anywhere -- instead, it's derived form observing needs
and existing designs found in place in various places on the web. That
may be good or bad, but to refer to 3 different clauses in some
specification that I don't know how to find (Googling for "WKT in Simple
Features" brings up a bunch of pages on OGR, and a PDF from OGC on
implementing in OLE/COM) isn't particularly helpful. 

> Further, since the feature model was never reflected in the WKT (nor for
> that matter in the Simple Feature UML) 

For the record, my statement re WKT was with regard to the geometry
types, not the Feature types. GeoJSON avoids full feature representation
-- it's a language designed to exchange geometry and attributes,
primarily.   

> but derived from the Feature volume
> of the OGC Abstract Specification, which is consistent with the Feature
> Model in ISO 19109, derivation from WKT could not and did not reflect the
> proper semantics for features and feature collections (most important is the
> subtyping of feature collection from feature). GML again is consistent with
> ISO 19109, and therefore has an ISO compliant mechanism defined for doing
> application schemata. 

And GeoJSON is consistent with none of these -- it's consistent with
delivering a set of key/value pairs and geometries back and forth between
a client and a server.

> GeoJson, being a "object" encoder, had to deal with
> features, feature collections, and the semantics of geometry; none of which
> are reflected in the less functional WKT. That is the major source of your
> divergence, not the "wording issues."

I disagree. The major source of the divergence is the fact that neither
I (nor, to the best of my understanding, others participating in the
specification creation process) are attempting to solve the problems
that ISO 19109 solves, or that GML solves, or that any other feature
representation solves. Instead, it's a specification for how to collect
a list of Features -- where a feature is defined by a geometry, and a
list of key/value pairs to go with it -- and pass them around.

I think there is a large divergence between that and ISO19109, and the
geometry model is designed to be simplistic, so it probably does not
fully conform to ISO19107. Instead, we seek to solve the problem of
moving data around between clients and servers that speak JSON well. If
you want ISO19109 support, then you probably want to be using GML -- and
if you care about JSON encoding strongly, there are a number of standard
XML -> JSON -> XML conversions that will take care of that for you.

GeoJSON is not trying to mimic those who have gone before in
specifications. Instead, it is trying to fill the gap already being
filled by applications writing their own JSON encoding, so that we can all
'get along'. 

My personal opinion is that GeoJSON does well at filling the relatively
'niche' role it fills for most users of OGC specs -- but for users of
OpenLayers, FeatureServer, WPServer, GeoServer, MapBuilder, and other
Open Source tools for doing web mapping, where you don't always need or
care about having a 'true representation' of the Feature -- you care
about having a representation of the Feature that lets you do some thing
with it. For Feature modeling, use GML. For Feature exchange between web
mapping clients and servers, you might be better off using GeoJSON. 

Regards,
-- 
Christopher Schmidt
MetaCarta