<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>Re: [GeoJSON] Aligning implementations</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText1329 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Hello Tim,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I'm talking about 'feature type
information', pretty much like that described by a DescribeFeatureType
request.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>...only simpler! :)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>It might seem overkill to have to support
that, and indeed in first the clients I built I didn't need that
information. </FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>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)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>That information was necessary to (among
many other things) propose the appropriate 'property editors' to the
users:</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> * A short <input> field for
numbers</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> * A long <input> field for
strings</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> * A calendar for dates</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> * A 'child' editing panel for
embedded features</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> * ...</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>To do so, we implemented a
preliminary 'json output' to the WFS.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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: <A
href="http://lists.geojson.org/pipermail/geojson-geojson.org/2007-March/000031.html">http://lists.geojson.org/pipermail/geojson-geojson.org/2007-March/000031.html</A></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr>
<DIV dir=ltr><FONT face=Arial size=2>That document that Bernard (*) has written
is based on what we had to develop for a complex project.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV></DIV>
<DIV dir=ltr><FONT face=Arial size=2>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)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> * namespaces support.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> * coherence with the WFS
spec</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2> * ability to hint the client about
some aspects of a feature type..</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Best regards,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>
A.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(*) 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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> geojson-bounces@lists.geojson.org on
behalf of Tim Schaub<BR><B>Sent:</B> Wed 4/11/2007 10:06 AM<BR><B>To:</B>
geojson@lists.geojson.org<BR><B>Subject:</B> Re: [GeoJSON] Aligning
implementations<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Arnaud Diederen wrote:<BR>> <BR>> Hello
everyone,<BR>> <BR>> since I've been reading this thread, I've seen
nowhere that a client<BR>> would make use of feature type information; hence
the necessity to have<BR>> the toplevel 'geometry' property, or the toplevel
'default_geom'<BR>> property to access the corresponding property in the
object.<BR>> <BR>> Since I'm pretty new to this list, maybe I missed
something, but.. why<BR>> does nobody take feature type information into
consideration?<BR>> I strongly believe a sufficiently advanced feature
inspecting/editing<BR>> client will *require* that
information.<BR>> <BR><BR>Do you mean geometry.type, or some other
type? In the structures we've<BR>been tossing around, geometry.type is one
of 'point', 'linestring',<BR>'polygon', etc. (or their CamelCased
equivalents).<BR><BR>Tim<BR><BR>_______________________________________________<BR>geojson
mailing list<BR>geojson@lists.geojson.org<BR><A
href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</A><BR></FONT></P></DIV>
</BODY>
</HTML>