[Geojson] polygon point order

[Tim Schaub]

I agree with Chris that we shouldn't make clients clean up or simplify 
geometries, but I do think linear ring coordinate ordering makes sense.

KML doesn't touch this:
http://code.google.com/apis/kml/documentation/kml_tags_21.html#linearring

And the result is a bit odd.

You can't digitize a polygon that crosses the dateline in Google Earth. 
  You can in Google Maps (you can also really screw up Google Maps by 
editing polygons that wrap the dateline).  The coordinate order in the 
resulting KML is the order that points were digitized.

If you paste a dateline wrapping polygon from Google Maps to Google 
Earth, you get the complimentary polygon (or whatever you want to call 
the wrong one.)

If you paste a dateline wrapping polygon from Google Maps into 
OpenLayers, you get the same one that Google Earth gives you.

Anyway, I agree that it is a problem that people can't specify polygons 
that wrap coordinate systems in a unique way.

That said, I'm happy leaving it out of this version - and waiting to see 
if KML ever addresses it.

Tim


Christopher Schmidt wrote:
> 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,