[Geojson] coordinate order

[Tim Schaub]

Hey-

Martin Daly wrote:
> For completeness should we also add:
> 
> "coordinate_direction": [1,-1]
> 
> or similar? That would allow south, west and down positive ordinates. 
> Some country-specific (mostly projected) CRS-s are like this.

Isn't this getting to how a client would transform coordinates?  The 
coordinate_order is required before a (CRS respecting) client can even 
get to coordinates (in our coordinates array).  The coordinate_direction 
only becomes relevant when you are transformimg to another CRS, right?

I guess the answer is that we're already transforming into pixel space 
when we render - and we're making an assumption about coordinate direction.

I don't have experience doing GetMap requests (or any other) in a 
flipped system - so I don't even know what an image looks like (which 
side is up) when I ask for a bbox like (0, 0, 10, 10) when the 
y-direction is flipped.

Tim

> 
> However, I also agree that it is ready to go out into the wild.
> 
> M
> 
> On 7 Mar 2008, at 18:34, Tim Schaub wrote:
> 
>> Hey-
>>
>> See the updated GeoJSON spec v5
>> http://wiki.geojson.org/GeoJSON_draft_version_5
>>
>> We had a discussion on IRC today about geometry coordinates.  We all
>> agree that we want to support more than two dimensions.  We also want
>> simple clients to be able to know which dimensions at least the first
>> two elements in a coordinates array refer to.
>>
>> Regarding more than two dimensions, the spec talks about two dimensions
>> for point geometry and goes on to say "any number of additional
>> dimensions are allowed, and interpretation and meaning of these
>> coordinates is beyond the scope of this specification."
>>
>> Does this sit well?  We say you've got to have two elements in the
>> coordinates array but more are allowed.
>>
>> Regarding the order of elements in the coordinates array for GeoJSON
>> geometries, we say that the first two elements are in x, y order (lon,
>> lat for dd).  This is what we have said from the start.
>>
>> The change to the spec is to accommodate CRS that define a different
>> coordinate order.  Instead of requiring all clients to know about all
>> CRS coordinate order conventions, we require that GeoJSON geometries
>> referencing a CRS that defines non-xy coordinate order include a
>> "coordinate_order" member in the CRS object.
>>
>> This means a point geometry that references EPSG:4326 would look like 
>> this:
>>
>> {
>>    "type": "Point",
>>    "coordinates": [-180.0, 90.0],
>>    "crs": {
>>        "type": "EPSG",
>>        "properties": {"code": 4326},
>>        "coordinate_order": [1, 0]
>>    }
>> }
>>
>> The benefits of this are that it allows all clients simple access to the
>> proper dimensions in the geometry coordinates array and allows smarter
>> clients who are strict about CRS coordinate order to map to the correct
>> dimension in our coordinates arrays.
>>
>> The drawbacks of this are that people like to argue that the EPSG has
>> the right to assign meaning to any sequence of numbers in a data
>> structure that references EPSG.  I say that is fine, they get access to
>> our coordinate_order array.  If the EPSG says that the first value in a
>> sequence refers to the northing of a point, then they look at the first
>> value in our coordinate_order array and know which element to use from
>> our coordinates array.
>>
>> Makes things a bit more complex for clients who know about CRS and
>> simpler for the rest.
>>
>> I think this thing is ready to let out into the wild.
>> Tim
>> _______________________________________________
>> Geojson mailing list
>> Geojson at lists.geojson.org
>> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
> 
> 
> !DSPAM:4033,47d3d945270061804284693!
>