[Geojson] GeoJSON, OGC, ISO and everything in between

[Tim Schaub]

Huge thanks for making things readable Martin.

My opinions below.

Martin Daly wrote:
> Reading John's document, his concerns seem to be:
> 
> 1. Coordinate order should respect EPSG (esp. geographic in crs)

No.  GeoJSON is about simplifying things (communication between server 
and client, working with dumb clients, working with dumb servers).

Forcing every participant (application component) who deals with GeoJSON 
to carry around an EPSG table that tells them which coordinate to modify 
when a user moves a point east is a waste of resources.  We want simple 
clients to play with geo.

> 
> 2. Geometry definitions should be more explicit, for completeness, e.g. "The interpretation of a point is the single location described by 
the coordinate.", Polygon ring ordering, no self intersections, etc.

Regarding "no self-intersections": no.  We want to be able to represent 
geometries before they have been simplified, cleaned, etc.  A client 
that does not have the ability to detect intersections should be able to 
represent a geometry and send it somewhere that will simplify it.  Need 
a reality check?  Open up Google Map or Google Earth, digitize a 
self-intersecting polygon.  See it happily remain self-intersecting. 
(If you don't believe it stays self-intersecting, copy the KML and 
investigate.)  People want dumb clients to play with geo.

> 
> 3. GeometryCollection-s should be allowed to own any geometry type, including other GeometryCollection-s.

No comment.

> 
> 4. Demote Box to a special case
> 

I've always seen Box as a special case.  Don't care if it gets demoted 
or not.

> 5. The feature model should not require a geometry member, and should treat it as "just another property".
> 

Agree with Martin's description here.  We can agree on a convention for 
  representing a schema in JSON, but we're not going to succeed forcing 
all clients to fetch a schema just to deal with a geometry.

Tim