[GeoJSON] Integrating GeoJSON with other kinds of data via JDIL

[Christopher Schmidt]

On Fri, Jun 01, 2007 at 11:29:51AM -0400, Allan Doyle wrote:
> Chris,
> 
> I think there would be a willingness to support this if it's really  
> as minor as adding the namespaces member. However, I'd like to see a  
> few parallel examples of GeoJSON and GeoJDIL just to better  
> understand the implications.

My opinion is that the best thing to do in this regard is to provide a
transformation process for transforming GeoJSON into GeoJDIL, but not
stating that there is an expectation that GeoJSON consumers understand
GeoJDIL. Language something like this:

"""
The GeoJSON specification does not include namespacing. However, it is
legal to include additional information at the top level of each GeoJSON
object, which means that it is possible to add information causing the
GeoJSON to be GeoJDIL as a secondary step. To alter your GeoJSON to
produce GeoJDIL, you should include the following at the top level of
your GeoJSON object:

{'namespaces': {'':'http://geojson.org/ns#'}}

Note that although GeoJSON includes a 'type' attribute, that attribute
should *not* be mapped to JDIL 'type' via the '@type' style notation.
The reason for this is that it is expected that few GeoJSON parsers will
be GeoJDIL consumers. However, any GeoJDIL consumer can treat the 'type'
property of all GeoJSON objects as being equivilant to the '@type'
property in JDIL. 

Because property names can be any string, it is expected that GeoJSON
parsers will be able to consume properties with ':' in the property
label. This means that if you consume JDIL from other sources, and wish
to 'namespace' the output, you can use namespaces. However, GeoJSON
parsers are not expected to understand these namespaces.

In summary: 
 * GeoJDIL is said to be GeoJSON which includes a top level 'namespaces' 
   property which defines a default namespace, and may define additional
   namespaces for any attribute name which contains a ':'. 
 * GeoJDIL producers should *not* transform the 'type' element to the
   JDIL style '@type' and expect to exchange information with
   GeoJSON/GeoJDIL implementations.
 * General JDIL consumers who are consuming GeoJSON, which does not have
   a top level 'namespaces' property, can transform GeoJSON to JDIL by
   adding a 'namespaces' element at the top level. General JDIL
   consumers can also transform GeoJDIL to be more consistent with usage of
   JDIL by treating any 'type' properties as equivilant to JDIL '@type'
   properties. However, JDIL produced with a '@type' property and no
   'type' property is not valid GeoJSON, and should not expected to be
   exchanged with GeoJSON/GeoJDIL consumers.
"""

Or something along those lines.

I feel that the base GeoJSON spec needs only to address this with a
reference as to how to create GeoJDIL, and best practices in that
regard.

Regards,
-- 
Christopher Schmidt
MetaCarta