[Geojson] GeometryCollection not treated as a Geometry type

[John Herring]

>> 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.  

But it is not more easily implemented, it is harder, and it does less.
Especially since the applications that should be using it are based on the
models in the OGC Abstract Specification, including ISO 19107 and the
feature model from ISO 19109, and not the version that GeoJson seems to be
using. Interoperability between all applications, either currently
implemented or not yet conceived necessitates a set of  semantically
consistent models. If GeoJson is going to be an alternative to GML or other
transfer mechanisms, it must support the common model and not some variant
based on a misinterpretation of Simple Feature WKT, which was only meant to
cover basic geometry, and not features. Drawing is not a hard thing to do,
and I would not base a test of adequacy on overly simple use cases. 

  
>> 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. 

"This" refers to the OGC Project Document listed, i.e. 06-103, which is the
Simple Features specification from which the WKT that you referred to was
taken. It is publicly available, like all OGC specification from the OGC
website, specifically from the list of standards at
http://www.opengeospatial.org/standards.  If something in GeoJson is not
explicitly derived from an OGC specification, or at least consistent with
the OGC specifications as a whole, then GeoJson is useless to OGC.  
   
>> 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. 

Then call it something else, because it that is all it is good for, then as
a geographic specification is it again useless.  Okay, it is not totally
useless, but that is because it has some of the key elements from the
mention specifications are in it, just implemented in a manner that makes it
difficult to integrate into the rest of the SOA that OGC is building. All I
have been doing is pointing out where it has gone off-the-rails in terms of
the OGC models for geometry and for features. The fixed are minor, their
importance is not. 

And just to catch you up on reality, geometry is just another attribute. GIS
technology and models have been based on that simple concept for at least 25
years. GeoJson needs to exchange features with their attributes and
relations, including their geometric attributes. 

>> 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.    

If all GeoJson were to do is transfer the sort of data in the Simple
Features specification, then would be both ISO 19107 and ISO 19109
conformant. ISO 19107 is a fairly large geometry model containing all sorts
of things, but is also has multiple conformance classes, one of which is
specifically designed for Simple Features. 

>> Instead, we seek to solve the problem of    
>> moving data around between clients and servers that    
>> speak JSON well. 

That is essentially the problem we want solved, but the clients and servers
are those engaged in geographic information and its processing. The models
spoken of are models accepted by that community, instantiated in the Simple
Features applications which has always been described as the basis for
GeoJson project.

>> 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.

What GeoJson undercooks, GML overcooks. If you want something that moves
geometry, use SVG or one of the other geometry-only mechanisms. If you want
to talk about features and CRS and geographic information, then do it right,
which means doing it according to the standards (both de facto and de jure)
that are accepted by that community. We are not talking about rocket
science, and if GeoJson as it existed  were that far off the mark, I
wouldn't waste my time writing this stuff. A GeoJson badly done is worse
than no GeoJson, since it would discourage anyone from trying to fix what
could have been done right the first time, while fighting the legacy of
existing applications. If it goes forward as is, it will eventually suffer
the same fate that the OLE/COM Simple Features volume you found, a deserved
place in obscurity, and no one willing to fix it. 

That does not entail much -  all that the OGC would require is:

	1. a consistency of the geometry model with simple features (and
thus with ISO 19107), meaning both in use and interpretation. 

	2. a consistency with the feature model with simple features (and
thus with ISO 19109). 

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: Christopher Schmidt [mailto:crschmidt at metacarta.com] 
Sent: Monday, October 08, 2007 5:06 PM
To: John Herring
Cc: geojson at lists.geojson.org
Subject: Re: [Geojson] GeometryCollection not treated as a Geometry type

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