[GeoJSON] WFS Output
cholmes at openplans.org
Fri Mar 23 11:59:00 PDT 2007
First feedback - I think we should keep this list mostly focused on
geometry encodings for JSON. I could be ok to hit on feature encodings
a bit, but in a very basic way - ie no namespaces, no nested features,
ect. Maybe this group could eventually get to that, but I know we're
coming in with a variety of opinions about W*S and feature models and
Personally I'm very interested in WFS encodings, and will follow up with
a bit of feedback off list. But it seems to make more sense to talk to
wfs-dev than here about the json encodings to WFS. At least if they're
straight mappings of WFS. At some point I do want to pick Sean's brain
about what a more restful feature service might look like with JSON
objects. But for now lets stick to geometries and features.
As for Geometries, it looks like we're pretty in line, Bernard, which is
great. I defaulted to 4326 on my implementation, and I think a crs:
param makes sense. I'd like to see it able to inherit a default from a
collection of features, but no matter what a single geometry should be
able to have a crs.
I used type as well, with OGC names. I didn't see you touch on multi's
at all? I went with same OGC names, and then had a 'members' array,
which would be instances of the other geometries.
I'm +1 on card. I like the long array approach, and if you're doing 3d
then you need to look at the card.
env is fine with me, as an optional bounds.
I went with coordinates instead of 'data'. I personally like coords or
coordinates a bit better than data. We could also do 'posList' to align
with georss/gml 3+. Also, one thing to consider is that georss is
whitespace delimited by default. I have no strong preference, but I
think it could make sense to align with them.
Holes in polygons? I don't see that you have exterior or interior? Or
are you wanting to do it with arrays? I see you have an array of arrays
for data for a polygon - would the first be the exterior and the rest
As for the rest, let's take features a bit later. But I will say a
general feeling, which is that I'd like to keep features really simple,
and await a broader web consensus on things like namespaces in json and
the like, instead of us inventing something that makes sense to us that
no one else uses. Which is why I'd like it separated out from geometry
definitions - it's easier to become a (real) standard on narrowly
constrained areas you know well.
Bernard Snyers wrote:
> Dear all,
> I have completed the first pass of the document. (attached in openoffice
> and word format).
> I am awaiting feedback. We have a running implementation.
> PS: for the twiki manager, I try to upload these 2 files but always
> receive a warning saying the .odt/.doc is not recommended for an image
> file. Even if I select disable warning, I was unable to upload. Any hints ?
> Bernard Snyers
> geojson mailing list
> geojson at lists.geojson.org
The Open Planning Project
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 282 bytes
Desc: not available
More information about the GeoJSON