[GeoJSON] Aligning implementations
Arnaud Diederen
ad at ionicsoft.com
Wed Apr 11 05:03:39 PDT 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20070411/e83a08d8/attachment.htm>
More information about the GeoJSON
mailing list