[GeoJSON] Aligning implementations
Allan Doyle
adoyle at eogeo.org
Wed Apr 11 05:22:54 PDT 2007
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
More information about the GeoJSON
mailing list