[GeoJSON] Integrating GeoJSON with other kinds of data via JDIL
chris goad
chris at platial.com
Sat Jun 2 07:16:34 PDT 2007
Re geojson:type and JDIL @type:
Yes, I agree, a best practices doc rather than a GeoJSON spec modification
(realized already in the GeoJDIL wiki page by Christopher Schmidt!) goes
almost all of the way towards achieving the practical goals of GeoJSON/JDIL
integration. However, there is one more possible improvement.
JDIL has a construct for representing multi-valued properties:, which looks
like this:
"propname":{"@values":["value0","value1"]}
If GeoJSON "type" and JDIL "@type" were collapsed into one property, then
the two lines:
"@type": "atom:item",
"type": "Feature",from the example on the GeoJDIL wiki page could be
written:
"@type":{"@values":["atom:item","Feature"]}
or
"type":{"@values":["atom:item","Feature"]}
depending on which direction of collapse is chosen. This way of doing
things is easier to understand. Unless I am mistaken, GeoJSON is using
"type" to mean type membership in the usual sense, and does not denote some
specialized typing that applies only to geometry. If so, it is confusing
to have two names for the same thing, and to mandate the use one or the
other depending on circumstances.
There are three ways to achieve the type/@type collapse:
1) The GeoJSON spec is left unchanged, but a transformation which replaces
"type" by "@type" is mandated when embedding GeoJSON in JDIL.
2) The JDIL spec is modified to endorse vocabulary-specific synonyms of
"@type" - either "every vocabulary's 'type' property, if present, shall be
construed as a synonym of '@type'", or "GeoJSON's 'type' property is a
synonym of '@type'"
3) The GeoJSON spec is modified to change the property name "type" to
"@type".
Option 3 involves zero addition of complexity to GeoJSON parsers - there is
no implication that the injection of one "@" symbol implies support for any
other JDIL primities. It is only a name change.
In contrast, options 1) and 2) add complexity and real work for developers.
Note that JDIL doesn't have the option of a simple name subsitution in the
opposite direction of option 1) - using "type" without the @. This is
because "type" might be defined in the base namespace (eg GeoJSON if
unaltered!), leading to conflict with JDIL's own "type".
Are there other options?
-- Chris
----- Original Message -----
From: "Christopher Schmidt" <crschmidt at metacarta.com>
To: "Panagiotis (Peter) A. Vretanos" <pvretano at cubewerx.com>
Cc: <geojson at lists.geojson.org>
Sent: Friday, June 01, 2007 10:17 AM
Subject: Re: [GeoJSON] Integrating GeoJSON with other kinds of data via JDIL
> On Fri, Jun 01, 2007 at 12:23:56PM -0400, Christopher Schmidt wrote:
>> On Fri, Jun 01, 2007 at 12:13:39PM -0400, Panagiotis (Peter) A. Vretanos
>> wrote:
>> > 3) Add a and @type parameter (e.g. "@type": "myns:BUILTUPA_1M").
>>
>> Hm. that's a point. Most people who think about 'types' in this way are
>> actually talking about feature types. I hadn't thaough about that. How
>> is 'myns:BUILTUPA_1M' described in the JSON now?
>
> Okay, after discussing with other people on #geojson, we've established:
>
> * KML has not seriously suffered due to lack of feature types.
> * Feature types in existing implementations (for example, my
> WFS translation of FeatureServer input from JSON) are just faked up
> based on using the layer name, and have little to no actual meaning.
>
> As a result:
> * '@type' is something which can be delivered in GeoJDIL. If it is
> available, it is expected to be a feature type. Users who ask how to
> use featuretypes should be using geojdil and geojdil friendly parser.
>
> I'm going to write this example into the specification.
>
> 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