[GeoJSON] Integrating GeoJSON with other kinds of data (via Chris Goad)
crschmidt at metacarta.com
Thu May 31 16:44:43 PDT 2007
Chris was having problems sending this to the list, and I offered to
send it for him, since I know we're rapidly moving towards a 'final'
RFC, so I wanted this out there so people were aware of it before we
From: chris goad <chris at platial.com>
Date: Thu, 31 May 2007 16:30:34 -0700
Subject: Integrating GeoJSON with other kinds of data
I've been working with JSON for geo for a year or so at Platial. I love the elegance and conciseness of JSON, but there were things that I missed from earlier work with RDF - not the whole stack, but basic capabilities for data integration. JDIL ( http://jdil.org ) , which I formulated earlier this year, was my stab at retrieving what was missing; JDIL has nothing specific to do with geo, but implementing geo inside JDIL makes it play well with other data. I have been using GeoRSS for the geo aspect, but would like to switch to GeoJSON.
Here's a bit about JDIL:
JDIL specfies two simple ways to enhance JSON's capability for integrating data from diverse vocabularies and sources. The first is namespaces - namespace definitions appear as the value of the @namespaces property, and are utilized via qualified names for properties. The second is use of URIs as object labels (these labels appear as the value of the @id property). The latter allows encoding of object graphs, rather than only trees, and supports merging of property-value assertions from different sources about the same object. With very little effort, the major benefits of the RDF data model are captured within the JSON framework (RDF need not be mentioned in explanations of JDIL!)
Minor changes in GeoJSON would make it compliant with these conventions, and as a consequence would allow GeoJSON to be smoothly mixed with other kinds of data. This is an important benefit, since geo applications that involve data of other varieties are the norm rather than the exception. The changes : 1) support the namespace construct, and allocate a URI for the GeoJSON namespace, 2) utilize the generic JDIL "@type" name for the type-of concept.
In pure geo applications (eg sending feature geometry off to a client for rendering), the overhead is miniscule. A pure GeoJSON file would need only include this property in the root object:
This specifies a blank prefix for the GeoJSON namespace, removing the need to prefix GeoJSON properties in the body.
More information about the geojson