[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