[Geojson] FW: Features without geometry

[Stephen Battey]

I think I'm partly responsible for the negative vibes and, after a few
negative comments, I feel I should set the record straight because on
the whole I'm very excited about GeoJSON.
We've been using JSON to send feature data back from our server for some
months and I'm pleased to see there's going to be a standard that will
make it easier to describe the data structure we send and easier for
anyone developing a client app to parse that data.
What ever the content of the finalised spec we'll be able to make use of
some elements of it and feel a benefit. I guess it's natural to focus on
and talk about the one aspect of the spec that's causing me a problem
rather than the many other elements that I'm really happy with.


Having read Andrew's email yesterday I'd like to pick up on one point he
made that a JSON document has GeoJSON rather than is GeoJSON, which
reflects my approach to using GeoJSON.

I have a JSON document that contains a set of features, and those
features may or may not have geometry (depending on the type of
request). The JSON string will always contain a GeoJSON
FeatureCollection so it seems sensible to start by sending the string
through a GeoJSON parser and seeing what comes out.
If the parser is true to the spec it should throw a temper-tantrum (or
an Exception) exclaiming "This isn't GeoJSON, there's no geometry."
My client then has to parse the JSON 'manually' (using custom code) to
read the feature collection, the features and the properties of the
features.

If data (like "geometry" or even "properties") is missing from the JSON
I'd prefer GeoJSON parsers not to fail at that point. A parser would be
more robust if it continued but left those members undefined.
Obviously, some members are essential to understanding GeoJSON (e.g. the
"type" member) and the parser couldn't parse an object without knowing
its type. So it's understandable if the parser ignores objects without a
"type" member.

Relating this back to Andrew's point; my JSON document has GeoJSON and
I'd like a GeoJSON parser to extract as much GeoJSON data as it can from
that JSON.
So, if I have a JSON fragment like this:
{
   "type": "Feature",
   "centroid": {
       "type": "Point",
       "coordinates": [100.5, 0.5]
   },
   "properties": {
       "prop0": "value0"
   }
}
I'd like a GeoJSON parser to recognise this as a feature (since it's
declared as "type": "Feature") and read as much as info as it can (i.e.
"properties" and other geometry info, like a bounding box or centroid).


I feel we're back to that philosophical question about whether a feature
should have geometry.
I agree that a feature always has geometry (even if it's an empty
geometry). But sometimes you don't want to exchange that information.
On the flip side, making the geometry mandatory has benefits - you know
that when you receive a feature through GeoJSON the geometry member will
always be there and you can access it without question.
My gut instinct is to make the spec flexible. Make the geometry member
non-mandatory so people have the option to include it. That opens the
door for GeoJSON to be used in more situations.


Steve



> -----Original Message-----
> From: geojson-bounces at lists.geojson.org 
> [mailto:geojson-bounces at lists.geojson.org] On Behalf Of 
> Christopher Schmidt
> Sent: 03 October 2007 18:05
> To: Andrew Turner
> Cc: geojson at lists.geojson.org
> Subject: Re: [Geojson] FW: Features without geometry
> 
> 
> On Wed, Oct 03, 2007 at 10:37:52AM -0400, Andrew Turner wrote:
> > On 10/3/07, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> > > On Wed, Oct 03, 2007 at 08:15:40AM -0400, Andrew Turner wrote:
> > > > So, I'm still not clear if/how GeoJSON is used to just 'add' 
> > > > geographic content to larger/richer JSON content.
> > >
> > > The GeoJSON geometry objects can be used in any other JSON.
> > 
> > Yeah, that's all I'm asking for in clarification - and probably 
> > include in the documentation as well - to illustrate how it can be 
> > used to "add to" existing JSON.
> 
> Yep. It looks like you're 100% on the right page, and I'd be 
> glad to have you add your example below to 
> http://wiki.geojson.org/GeoJSON_draft_version_4#Including_addi
> tional_members
> or some other similar section (and put your name in Authors, of course
> :))
> 
> > > > Also - regarding omitting vs. null geometry. KML ... 
> valid without 
> > > > any geometry element
> > >
> > > It is?
> > >
> > > "In KML, a <Placemark> can contain one or more geometry elements, 
> > > such as a LineString, Polygon, or Model."
> > > -- http://code.google.com/apis/kml/documentation/kml_tut.html
> > 
> > According to the 'spec':
> > "Elements Specific to Placemark
> >     * 0 or one <Geometry> elements" 
> > 
> http://code.google.com/apis/kml/documentation/kml_tags_21.html#placema
> > rk
> 
> So, it seems like even KML is confused :)   
> 
> > > > and RSS/Atom both are
> > > > valid without any geometry element.
> > >
> > > JSON is valid without any geometry element. GeoJSON is 
> not. Atom is 
> > > valid without geometry: GeoRSS is not 'georss' without 
> the geometry. 
> > > (Unless there is a claim that every RSS feed on the web is 'valid 
> > > GeoRSS' :))
> > 
> > No, but including GeoRSS namespace doesn't require that 
> every <entry> 
> > or <item> have a <georss> element. So you can have a valid 
> GeoRSS feed 
> > (brings in the namespace) without any geometry. Same with KML.
> 
> I don't think that having a namespace declaration in a file 
> makes it a particular type of feed, but I think your point is 
> just "You don't have to have everything in your JSON be a 
> GeoJSON feature to be using GeoJSON" -- I agree with that. 
> 
> > Right, my point is that GeoJSON isn't *the* format, it is an
> > *extension* to a JSON format that provides Geographic features. So 
> > instead of saying it *is* GeoJSON, I want to say my JSON document
> > *has* GeoJSON.
> 
> Yep, I think that's fine.
> 
> The Geometry model of GeoJSON is probably what is likely to 
> see the most widespread use -- in gdal/ogr, shapely, other 
> things like that, this is already happening. The feature 
> representation will possibly make sense for some things, but 
> for others, it's not going to be neccesary. I think the case 
> where you're representing atom entries probably makes sense 
> to simply describe the features in atom, and state that there 
> is a property which references a GeoJSON geometry. 
> 
> Does that answer the question you're asking? I'm still not 
> sure, and I'm feeling negative vibes that I'm not sure how to 
> resolve.  
> 
> I *think* that the GeoJSON Geometry Obect provides the 
> equivilant to what GeoRSS provides. This is a subset of 
> 3.1.1, specifically, the subset 
> described in 3.1.2. These can be used anywhere. For people 
> who want GeoJSON features, you have to be more careful -- 
> it's only a GeoJSON feature if it has type, properties, 
> geometry -- and FeatureCollections are similar -- they must 
> have type, and features, where features is a list.
> 
> Does that make sense? Does it resolve the questions you have? 
> 
> Regards,
> -- 
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Geojson mailing list
> Geojson at lists.geojson.org 
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> 
> Incoming e-mail scanned by Altman Technologies
> 
Email has been scanned for viruses and spam by Altman Technologies