[GeoJSON] Integrating GeoJSON with other kinds of data via JDIL

Sun Jun 3 10:36:28 PDT 2007

Actually,

Sean bring up a good point.  Consider this feature generated from a JSON 
generating WFS (I've formated it for display purposes):

{"type":"Feature",
"id":"CWFID.AEROFACP_1M.0.692.702A1BDB6AF85AD01F20020000",
"geometry":{"type":"Point","coordinates":[-79.829445,45.256943]},
"properties":{"ID":"693",
"F_CODE":"GB005",
"IKO":"UNK ",
"NAM":"PARRY SOUND/GEORGIAN BAY",
"NA3":"CA21277",
"USE":"999",
"ZV3":"254",
"TILE_ID":"114",
"END_ID":"24"}}

What is the point of repeating "type":"Feature" with every feature 
instance?  Does JSON require this?

Ciao.

Sean Gillies wrote:
> 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 
> _______________________________________________
> geojson mailing list
> geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-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