[GeoJSON] Integrating GeoJSON with other kinds of data via JDIL
Sean Gillies
sgillies at frii.com
Sun Jun 3 08:17:08 PDT 2007
Chris,
Plain old dumb JSON is satisfying a web programmer's need to send dicts
over the wire. It's a sweet solution to a clearly demonstrated need.
Let's keep the distinction between GeoJSON (dumb data) and JDIL
(semanticly rich data) instead of putting unwarranted RDF and XML-isms
into GeoJSON.
I'm opposed to the @type and @values constructs, and also opposed to
magical-looking member names such as "@type". Frankly, I am holding my
nose about the "types" member of GeoJSON collections and features, and
I'd rather we made the types/@types confusion go away by dropping the
GeoJSON type members except in the case of geometries, where it is
needed to distinguish between otherwise identical line and polygon
representations.
I might very well use JDIL in some applications, but I'd rather we
didn't encumber the simplest thing that could possibly work: plain JSON.
Cheers,
Sean
chris goad wrote:
> 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