[Geojson] polygon point order

[Christopher Schmidt]

On Fri, Oct 12, 2007 at 09:49:21PM -0400, Andrew Turner wrote:
> On 10/12/07, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> > For the record, I'm against describing how Polygon coordinates should be
> > interpreted as part of GeoJSON. GeoJSON is an encoding format once you
> > have a polygon. It doesn't tell you how to craft the polygon in the
> > first place.
> 
> You can say that, but the fact is, people will craft services and
> interfaces that are public facing using GeoJSON - and not clarifying
> this will just result in confusion or problems.

I'm already crafting services and interfaces that serve up GeoJSON,
GeoAtom, KML and GML -- and I've never paid any attention to coordinate
ordering, but it has 'worked' anyway -- in OpenLayers, Google Maps,
Google Earth. 

> So better to agree on a standard spec now. 

That depends. If implementors aren't doing anything with it: OpenLayers,
FeatureServer, WPServer, for example, don't do anything with it -- then
creating it as a defined spec is just making the types of
implementations which don't know anything about clockwise vs.
counter-clockwise geometry and things like that no longer valid, as I
understand it.

My previous point stands: if there is a desire to encourage implementors
to implement geometry logic, then we should probably be spending a lot
more time referring to existing specifications for geometries than I
have... but maybe everyone else has read "OGC 06-103r3" but me.

I'm not about to make the statement that a non-closed linestring can not
be used as the linear ring of a polygon, for example: I like my bowties.
I can serialize them as GeoJSON, store them in FeatureServer, return
them as KML, and display them in Google Earth... even though they're not
valid. 

 http://featureserver.org/featureserver.cgi/scribble/851.geojson
 http://featureserver.org/featureserver.cgi/scribble/851.kml

It seems like any specification which is going to go into how to handle
x/y coordinates with regard to wrapping around a dateline is going to
have to define a lot more than that, and I'd be incompetent at it, so
I'm glad that others who are more knowledgable can do so. I just think
it's either going to be:
 
  * Pointing to an existing spec
  * Redoing a lot of work that is somewhat out of the scope of
    serialization.

Regards,
-- 
Christopher Schmidt
MetaCarta