[GeoJSON] Integrating GeoJSON with other kinds of data via JDIL
Panagiotis (Peter) A. Vretanos
pvretano at cubewerx.com
Sun Jun 3 10:36:28 PDT 2007
Sean bring up a good point. Consider this feature generated from a JSON
generating WFS (I've formated it for display purposes):
"NAM":"PARRY SOUND/GEORGIAN BAY",
What is the point of repeating "type":"Feature" with every feature
instance? Does JSON require this?
Sean Gillies wrote:
> 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
> 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.
> 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:
>> 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
>> 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
>> 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
>>>>> 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.
>>> Christopher Schmidt
>>> geojson mailing list
>>> geojson at lists.geojson.org
> geojson mailing list
> geojson at lists.geojson.org
Panagiotis (Peter) A. Vretanos CubeWerx Inc.
Big Kahuna (Senior Database Developer) http://www.cubewerx.com
Tel. 416-701-1985 Fax. 416-701-9870 pvretano at cubewerx.com
"Hail! Hail! Rock and Roll!" -- Charles Edward Anderson Berry
More information about the geojson