[GeoJSON] WFS Output

[Chris Holmes]

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 
the like.

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 
interiors?

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.

best regards,

Chris

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
> 
> 
> 
> 
> !DSPAM:4005,4603a368281089771116852!
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> geojson mailing list
> geojson at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> 
> 
> !DSPAM:4005,4603a368281089771116852!

-- 
Chris Holmes
The Open Planning Project
http://topp.openplans.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cholmes.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20070323/bd43b087/attachment.vcf>