[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