<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=idOWAReplyText60177 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Allan,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>You're talking adoption curve and indeed
simplicity is fundamental in that regard.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</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>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>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 :)</DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> geojson-bounces@lists.geojson.org on
behalf of Allan Doyle<BR><B>Sent:</B> Wed 4/11/2007 1:45 PM<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>My concern with going the WFS route is the same as my concern
with <BR>the GeoRSS GML route. It might be flexible but it's not going
to <BR>catch on very fast. Imagine the iPod. Now imagine the Zune.
Which <BR>adoption curve do we want for GeoJSON?<BR><BR>First of all, I
don't think there is a "schema definition language" <BR>for JSON. That
means that you really have to either keep things <BR>simple enough to
describe the text itself, or you have to pick a <BR>programming language to
describe it in. Clearly Javascript is the <BR>leading candidate for that
but there's also not much schema support <BR>there either. In this case, I
consider that a good thing.<BR><BR>I would propose the following:<BR><BR>0. The
terms object, name, value, array, and number are defined at <BR><A
href="http://json.org/">http://json.org/</A><BR> The terms
may, should, and must are defined at <A
href="http://">http://</A><BR>www.ietf.org/rfc/rfc2119.txt<BR><BR>1. A feature
is an object.<BR><BR>2. A feature may have a name/value pair whose
name<BR> is 'geometry' and whose value conforms to rule
3.<BR> (A feature may have any other name/value
pairs,<BR> without restriction.)<BR><BR>3. The value of a
geometry must itself be an object with<BR> the following
name/value pairs:<BR><BR> 'type' - [Point | Line | Polygon |
Box]<BR><BR> 'coordinates' - In the case of a Point, an
array<BR>
of two or three number values
representing<BR>
x, y, and optionally z. In all other
cases,<BR>
an array of arrays of number values as in
Point,<BR>
restricted as
follows:<BR>
A Line must have at least two
values.<BR>
A Polygon must have at least three
values.<BR>
A Box must have exactly two values.<BR><BR> 'srs' - an
optional string specifying a spatial reference system
of<BR> the
coordinates.<BR>
If not present, WGS84 is implied and coordinates
represent<BR>
decimal degrees ordered as "longitude, latitude <BR>[,elevation]"
and<BR> z is
expressed as meters above mean sea level per
WGS84.<BR> If
present, the value of srs is to be interpreted as
in <BR>PROJ4's<BR>
EPSG tables and the values of the coordinates are to
be <BR>interpreted<BR>
accordingly.<BR><BR>4. A feature should have a name/value pair whose name is
'id' and <BR>whose value<BR> can be uniquely interpreted
by the source of the GeoJSON string, <BR>generally<BR>
identifying this GeoJSON object's resource.<BR><BR>5. A feature should have a
name/value pair whose name is 'properties' <BR>and
whose<BR> value is an object which has meaning within a
specific community <BR>of interest.<BR><BR>6. A feature having multiple
geometries should have an array of <BR>geometries
contained<BR> within a properties object (see 5) which is
called 'geometries' <BR>and whose values<BR> are as
described in 3.<BR><BR><BR><BR><BR>On Apr 11, 2007, at 04:28, Arnaud Diederen
wrote:<BR><BR>> Hello Tim,<BR>><BR>> I'm talking about 'feature type
information', pretty much like that <BR>> described by a
DescribeFeatureType request.<BR>> ...only simpler! :)<BR>><BR>> It
might seem overkill to have to support that, and indeed in first <BR>>
the clients I built I didn't need that information.<BR>> Then quite quickly I
started to need a bit of extra information: <BR>> Then I implemented a
'DescribeFeatureType-like' request, that <BR>> returns a _flat_
representation of the feature type (i.e., no XSD-<BR>> like hierarchy, but
rather a set of 'property descriptors', each <BR>> describing the type
of the property, among other things)<BR>><BR>> That information was
necessary to (among many other things) propose <BR>> the appropriate
'property editors' to the users:<BR>> * A short <input> field for
numbers<BR>> * A long <input> field for strings<BR>> * A
calendar for dates<BR>> * A 'child' editing panel for embedded
features<BR>> * ...<BR>><BR>> To do so, we implemented a
preliminary 'json output' to the WFS.<BR>><BR>> From that past experience,
we wrote a draft proposal for a real <BR>> json output to the WFS, to
which I encourage you to have a look: <BR>> <A
href="http://lists.geojson.org/pipermail/geojson-geojson.org/2007-March/">http://lists.geojson.org/pipermail/geojson-geojson.org/2007-March/</A><BR>>
000031.html<BR>><BR>> That document that Bernard (*) has written is based
on what we had <BR>> to develop for a complex project.<BR>><BR>>
Chris Holmes answered to this thread that he'd like to keep the <BR>>
features as simple as possible. While I'm all for simplicity <BR>>
(really), I have to say I'm concerned about the extensibility of <BR>>
the feature representation as it is described in this thread; I'm <BR>>
thinking (off the top of my head)<BR>> * namespaces
support.<BR>> * coherence with the WFS spec<BR>> *
ability to hint the client about some aspects of a feature
type..<BR>><BR>><BR>> Best
regards,<BR>> A.<BR>><BR>>
(*) While we work at the same company, we're not simply pushing
our <BR>> existing stuff forward: That stuff he describes in his
document is <BR>> actually *not* existing yet. It's based on experience
from a <BR>> complex project, and is a synthesis of what we did right
and how to <BR>> do better what we did wrong.<BR>><BR>><BR>>
From: geojson-bounces@lists.geojson.org on behalf of Tim Schaub<BR>> Sent:
Wed 4/11/2007 10:06 AM<BR>> To: geojson@lists.geojson.org<BR>> Subject:
Re: [GeoJSON] Aligning implementations<BR>><BR>> 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 <BR>> 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, <BR>> but.. why<BR>> > does nobody take feature
type information into consideration?<BR>> > I strongly believe a
sufficiently advanced feature inspecting/<BR>> editing<BR>> > client
will *require* that information.<BR>> ><BR>><BR>> Do you mean
geometry.type, or some other type? In the structures <BR>>
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>><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><BR>--<BR>Allan
Doyle<BR>+1.781.433.2695<BR>adoyle@eogeo.org<BR><BR><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>