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

chris goad chris at platial.com
Fri Jun 1 10:50:00 PDT 2007


Andrew Turner wrote:

>What would the thoughts be on not requiring the namespace if the data
>was *just* GeoJSON, but require the namespace when the geo is brought
>into other JSON/JDIL data?


and Chris Schmidt wrote:

> 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.


It makes complete sense to define the notion of a GeoJSON consumer that 
ignores other varieties of content and doesn't understand namespaces. 
Observation: such a definition makes sense whether or not the 
geojson-empty-prefix-namespace line is required or optional. In the former 
case, the rule would be: GeoJSON consumers may assume that the GeoJSON 
namespace is   given the empty  prefix;  and  can simply ignore the 
namespaces property like other properties that they don't understand.

 If we imagine a future in which many vocabularies are mixed together in the 
JSON world  (as they are now in eg Atom), and in which many consumers are 
specialized to understanding subsets and ignoring the rest (as happens now 
in Atom too), it makes life a bit more complicated if there are little 
things that the subsetted consumers need to do to their subsetted variants 
to  make them work in the general format.

 A smaller point: the namespace line serves the auxilliary purpose of 
identifying the file as GeoJSON, even if ignored as boilerplate by some 
consumers.

All of this said, Chris' suggested language:


> 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:

will yield the same effect if people read it, and if in practice they are 
expecting their data to end up aggregated with other content.  So, although 
I did want to make points in favor of putting the namespace line in the 
spec, the optional approach will certainly work too.


Ok so those are my points re the namespace line. I also want to jump into 
the type vs @type discussion  but have run out of time for the moment.  More 
later...


-- Chris


----- Original Message ----- 
From: "Christopher Schmidt" <crschmidt at metacarta.com>
To: "Allan Doyle" <adoyle at eogeo.org>
Cc: <geojson at lists.geojson.org>
Sent: Friday, June 01, 2007 8:56 AM
Subject: Re: [GeoJSON] Integrating GeoJSON with other kinds of data via JDIL


> 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
> _______________________________________________
> geojson mailing list
> geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org 




More information about the GeoJSON mailing list