[Geojson] GeometryCollection not treated as a Geometry type

[Sean Gillies]

John Herring wrote:
>  
>>> 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
> 

John, has it occurred to you that we could be developing GeoJSON not for 
the OGC but for our own real-life applications? (It originated more or 
less as a way to encode data for my Pleiades web app, and derives more 
from Atom than GML.) It's not that I don't want the OGC stamp of 
approval, but it's of secondary importance to me. More important to me 
is that I get interoperability with widely deployed applications like 
OpenLayers and CartoWeb.

I agree with your first point about the need to be consistent with the 
simple  features geometry model. It would be beautiful to be able to 
state that GeoJSON geometries have the same meaning as GML geometries. 
That said, I don't think it's important that the JSON and XML encodings 
be identical. XML doesn't have arrays. JSON does, and we should use them.

On your second point: GeoJSON doesn't need to implement ISO 19109 to be 
useful. KML and GeoRSS, for example, are widely adopted and very 
effective. Myself, I may not actually use what the draft calls features 
and and feature collections; the Atom community is talking about JSON 
representations which appeal to me. Geometry encoding is the most 
important part of GeoJSON. Specification of items and containers could 
very well be left to other working groups. Maybe the OGC could add JSON 
+ ISO 19109 to its mass market geo group?


Sean