[Geojson] FW: Features without geometry

[Christopher Schmidt]

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_additional_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#placemark

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