[Geojson] GeometryCollection not treated as a Geometry type
Christopher Schmidt
crschmidt at metacarta.com
Mon Oct 8 09:26:02 PDT 2007
On Mon, Oct 08, 2007 at 10:30:10AM -0400, John Herring wrote:
> 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.
That's probably true. Please feel free to suggest a wording change --
the only reason that it is worded like that is to exclude
GeometryCollections. In fact, that entire first chunk of text needs
rewording -- the key points are:
* All geometries have "coordinates":, EXCEPT:
* If the geometry object is a GeometryCollection, which has
'geometries' instead.
> A geometry collection is a single object, and
> represents a single geometry (albeit potentially disconnected).
Agreed. Bad wording on my part -- I'm sorry.
> A multipoint
> is a geometry collection but is included as an example in a list from which
> geometry collections are specifically excluded.
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.)
> And Point is defined in such
> a manner as to confuse it with multipoint.
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?
> 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.
Understood. I *think* this is just a case of bad wording on my part,
becuase I was in a rush to go fix code instead of fixing the spec. Can
you propose a better wording for this section? I think it all stems from
the use of the term 'single geometry', which is obviously poorly
defined.
> You guys are spending way too much time being different for no apparent
> reason.
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 a point and a linestring returns a
geometrycollection with a Point and a Linestring in it: this
representation is mimiced in GeoJSON (and that's not changing!): the
same structure in GeoJSON, WKT, and GML (thanks to OGR):
>>> g.ExportToWkt()
'GEOMETRYCOLLECTION (POINT (0 0),LINESTRING (1 1,2 2))'
>>> g.ExportToGML()
'<gml:GeometryCollection><gml:geometryMember><gml:Point><gml:coordinates>0,0</gml:coordinates></gml:Point></gml:geometryMember><gml:geometryMember><gml:LineString><gml:coordinates>1,1
2,2</gml:coordinates></gml:LineString></gml:geometryMember></gml:GeometryCollection>'
>>> g.ExportToJson()
{'type': 'GeometryCollection', 'geometries': [{'type': 'Point',
'coordinates': [0.0, 0.0]}, {'type': 'LineString', 'coordinates': [[1.0,
1.0], [2.0, 2.0]]}]}
The only difference in the spec is that GeometryCollection is now
universally treated as a geometry object, meaning it can fill the
'geometry' member of a feature, whereas before the spec was unclear on
that.
> 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.
To me, I look at those three different representations ,and they all
seem to be saying the same thing. Where am I going wrong?
Regards,
--
Christopher Schmidt
MetaCarta
More information about the GeoJSON
mailing list