[GeoJSON] Aligning implementations
Allan Doyle
adoyle at eogeo.org
Wed Apr 11 05:43:38 PDT 2007
For those of you who don't visit the RFC-001 page, let me add that I
basically codified Sean's PCL stuff that's at http://
trac.gispython.org/projects/PCL/wiki/PythonFeatureProtocol
The nice thing is that he's already got an implementation.
On Apr 11, 2007, at 08:22, Allan Doyle wrote:
> I've posted my proposal as http://wiki.geojson.org/RFC-001
>
> I agree that for feature editing, this might be too limiting, but
> Sean's example at http://zcologia.com/news/430/feature-demo/ shows
> that even this level can be edited.
>
> I think the issue really boils down to which community you want to be
> a part of. If you want to be part of the "completely general,
> editable feature via auto-generated web forms" community, then you
> need to follow the path of #5 in http://wiki.geojson.org/RFC-001
> which is the moral equivalent of "vendor specific parameters" in WMS.
> If you define a bunch of stuff there, the people who don't have the
> desire to parse it all can still have the geometries.
>
> Allan
>
> On Apr 11, 2007, at 08:03, Arnaud Diederen wrote:
>
>>
>> Allan,
>>
>> You're talking adoption curve and indeed simplicity is fundamental
>> in that regard.
>>
>> Computing an envelope around a geometry is pretty easy so, yes, a
>> single 'geometry' key/value in the toplevel object representing a
>> feature is enough to pan a map to that feature, or zoom to it's
>> extent.
>>
>> But what is the extent of that binding discussed here? If that's
>> actually feature editing, I'm just saying I'm afraid this approach
>> seems to me a tad too limitating.
>>
>> Best regards,
>> A.
>>
>> PS: We don't need no "JSON schema definition language"; you'd just
>> fetch a flat array, holding info about the properties and their
>> types from the WFS, that's all :)
>>
>> From: geojson-bounces at lists.geojson.org on behalf of Allan Doyle
>> Sent: Wed 4/11/2007 1:45 PM
>> To: geojson at lists.geojson.org
>> Subject: Re: [GeoJSON] Aligning implementations
>>
>> My concern with going the WFS route is the same as my concern with
>> the GeoRSS GML route. It might be flexible but it's not going to
>> catch on very fast. Imagine the iPod. Now imagine the Zune. Which
>> adoption curve do we want for GeoJSON?
>>
>> First of all, I don't think there is a "schema definition language"
>> for JSON. That means that you really have to either keep things
>> simple enough to describe the text itself, or you have to pick a
>> programming language to describe it in. Clearly Javascript is the
>> leading candidate for that but there's also not much schema support
>> there either. In this case, I consider that a good thing.
>>
>> I would propose the following:
>>
>> 0. The terms object, name, value, array, and number are defined at
>> http://json.org/
>> The terms may, should, and must are defined at http://
>> www.ietf.org/rfc/rfc2119.txt
>>
>> 1. A feature is an object.
>>
>> 2. A feature may have a name/value pair whose name
>> is 'geometry' and whose value conforms to rule 3.
>> (A feature may have any other name/value pairs,
>> without restriction.)
>>
>> 3. The value of a geometry must itself be an object with
>> the following name/value pairs:
>>
>> 'type' - [Point | Line | Polygon | Box]
>>
>> 'coordinates' - In the case of a Point, an array
>> of two or three number values representing
>> x, y, and optionally z. In all other cases,
>> an array of arrays of number values as in Point,
>> restricted as follows:
>> A Line must have at least two values.
>> A Polygon must have at least three values.
>> A Box must have exactly two values.
>>
>> 'srs' - an optional string specifying a spatial reference
>> system of
>> the coordinates.
>> If not present, WGS84 is implied and coordinates
>> represent
>> decimal degrees ordered as "longitude, latitude
>> [,elevation]" and
>> z is expressed as meters above mean sea level per WGS84.
>> If present, the value of srs is to be interpreted as in
>> PROJ4's
>> EPSG tables and the values of the coordinates are to be
>> interpreted
>> accordingly.
>>
>> 4. A feature should have a name/value pair whose name is 'id' and
>> whose value
>> can be uniquely interpreted by the source of the GeoJSON string,
>> generally
>> identifying this GeoJSON object's resource.
>>
>> 5. A feature should have a name/value pair whose name is 'properties'
>> and whose
>> value is an object which has meaning within a specific community
>> of interest.
>>
>> 6. A feature having multiple geometries should have an array of
>> geometries contained
>> within a properties object (see 5) which is called 'geometries'
>> and whose values
>> are as described in 3.
>>
>>
>>
>>
>> On Apr 11, 2007, at 04:28, Arnaud Diederen wrote:
>>
>>> Hello Tim,
>>>
>>> I'm talking about 'feature type information', pretty much like that
>>> described by a DescribeFeatureType request.
>>> ...only simpler! :)
>>>
>>> It might seem overkill to have to support that, and indeed in first
>>> the clients I built I didn't need that information.
>>> Then quite quickly I started to need a bit of extra information:
>>> Then I implemented a 'DescribeFeatureType-like' request, that
>>> returns a _flat_ representation of the feature type (i.e., no XSD-
>>> like hierarchy, but rather a set of 'property descriptors', each
>>> describing the type of the property, among other things)
>>>
>>> That information was necessary to (among many other things) propose
>>> the appropriate 'property editors' to the users:
>>> * A short <input> field for numbers
>>> * A long <input> field for strings
>>> * A calendar for dates
>>> * A 'child' editing panel for embedded features
>>> * ...
>>>
>>> To do so, we implemented a preliminary 'json output' to the WFS.
>>>
>>> From that past experience, we wrote a draft proposal for a real
>>> json output to the WFS, to which I encourage you to have a look:
>>> http://lists.geojson.org/pipermail/geojson-geojson.org/2007-March/
>>> 000031.html
>>>
>>> That document that Bernard (*) has written is based on what we had
>>> to develop for a complex project.
>>>
>>> Chris Holmes answered to this thread that he'd like to keep the
>>> features as simple as possible. While I'm all for simplicity
>>> (really), I have to say I'm concerned about the extensibility of
>>> the feature representation as it is described in this thread; I'm
>>> thinking (off the top of my head)
>>> * namespaces support.
>>> * coherence with the WFS spec
>>> * ability to hint the client about some aspects of a feature
>> type..
>>>
>>>
>>> Best regards,
>>> A.
>>>
>>> (*) While we work at the same company, we're not simply pushing our
>>> existing stuff forward: That stuff he describes in his document is
>>> actually *not* existing yet. It's based on experience from a
>>> complex project, and is a synthesis of what we did right and how to
>>> do better what we did wrong.
>>>
>>>
>>> From: geojson-bounces at lists.geojson.org on behalf of Tim Schaub
>>> Sent: Wed 4/11/2007 10:06 AM
>>> To: geojson at lists.geojson.org
>>> Subject: Re: [GeoJSON] Aligning implementations
>>>
>>> Arnaud Diederen wrote:
>>>>
>>>> Hello everyone,
>>>>
>>>> since I've been reading this thread, I've seen nowhere that a
>> client
>>>> would make use of feature type information; hence the necessity
>>> to have
>>>> the toplevel 'geometry' property, or the toplevel 'default_geom'
>>>> property to access the corresponding property in the object.
>>>>
>>>> Since I'm pretty new to this list, maybe I missed something,
>>> but.. why
>>>> does nobody take feature type information into consideration?
>>>> I strongly believe a sufficiently advanced feature inspecting/
>>> editing
>>>> client will *require* that information.
>>>>
>>>
>>> Do you mean geometry.type, or some other type? In the structures
>>> we've
>>> been tossing around, geometry.type is one of 'point', 'linestring',
>>> 'polygon', etc. (or their CamelCased equivalents).
>>>
>>> Tim
>>>
>>> _______________________________________________
>>> 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
>>
>> --
>> Allan Doyle
>> +1.781.433.2695
>> adoyle at eogeo.org
>>
>>
>>
>> _______________________________________________
>> geojson mailing list
>> geojson at lists.geojson.org
>> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>>
>
> --
> Allan Doyle
> +1.781.433.2695
> adoyle at eogeo.org
>
>
>
> _______________________________________________
> geojson mailing list
> geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
--
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org
More information about the GeoJSON
mailing list