[Geojson] GeoJSON '1.0'?

[Allan Doyle]

On Mar 13, 2008, at 11:40 AM, Tim Schaub wrote:

> Hey-
>
> Martin Daly wrote:
>>> How about this:
>>>
>>> Current Draft 5:
>>>  "If a GeoJSON object has a member named "crs", it is assumed to
>>> represent the coordinate reference system of the included geometry  
>>> or
>>> geometries."
>>>
>>> Proposed fix:
>>>  "If a GeoJSON object has a member named "crs", it is assumed to
>>> represent the SOURCE coordinate reference system of the included
>>> geometry or geometries. In other words, the coordinates in GeoJSON
>>> elements ALWAYS follow the order x,y[,z] and ALWAYS are expressed as
>>> floating point numbers REGARDLESS of the order and representation  
>>> used
>>> in the source coordinate system. The "crs" member is STRICTLY a hint
>>> that expresses the mathematical relationship between the coordinate
>>> values in the GeoJSON geometries and the real world.  
>>> " [Capitalization
>>> can go away, that's just to make it stand out in this email]
>>>
>
> Alan, I like this direction.  I'm not entirely sure how saying
> "represents the coordinate reference system" is different from
> "represents the source coordinate reference system."  That said, I  
> like
> the idea of clarifying that we're not distributing EPSG data,  
> nothing in
> GeoJSON comes from the EPSG database, we're merely referring to the  
> CRS
> that one would use if you were to use the database to do transforms.

Let me try a different way of explaining it.

Think of GeoJSON as a means of transporting information from point A  
to point B. It's an encoding, and it's an encoding that's being used  
as a serialization. Our serialization happens to say that for any set  
of EPGS coordinates we choose to send an x,y[,z] representation, in  
that order, as floating point numbers. We make no mandate that the  
receiver is not allowed to reconstruct the proper EPSG form of the  
data. In fact, by describing the means of encoding, we provide for the  
proper decoding.


On Mar 13, 2008, at 10:20 AM, Carl Reed wrote:

> The OGC Architecture Board has been crafting an Axis Order  
> "Manifesto". One of the topics the manifesto provides guidance on is  
> the axis order case that you are describing. I would strongly  
> encourage this group to wait two weeks until after the OGC TC  
> meetings. The manifesto will be discussed and hopefully approved at  
> those meetings. There will then be guidance and rules concerning  
> axis order that the entire community can use that will allow us to  
> achieve a higher level of consistency and interoperability.
>
> We would also encourage comments and thoughts on the manifesto prior  
> to the OGC meetings. I need to make a few edits to the document and  
> will then provide the list a copy.
>

>

I guess it will be interesting to look at. But for GeoJSON, the  
feeling has always been quite strongly in favor of x,y[,z]. If the  
manifesto were to say that for EPSG one must follow the EPSG order,  
then that would be an argument to drop EPSG CRS values entirely from  
GeoJSON.

In that case I might prefer to go to a PROJ-like CRS description.

	Allan


-- 
Allan Doyle
Director of Technology
MIT Museum
+1.617.452.2111