[GeoJSON] Aligning implementations

[Arnaud Diederen]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20070411/107dd06b/attachment.htm>