[Geojson] Closure?

[Christopher Schmidt]

On Tue, Sep 11, 2007 at 10:37:21PM -0400, Allan Doyle wrote:
> Has it been that long? It must be Web 3.0 by now!
> 
> Any objection to unanimous consent?

After learning slightly more of the complexity of Spatial References, I
would like to put one additional item up for discussion:

Section 4.1 changes from:

"""

4.1. The value of a member named "crs" must be an object. This object must
have at least two named members: "type" and "properties". The value of
the member named "type" must be a string. The value of the member named
"properties" must be an object. This specification defines no further
requirements for the structure of these objects. Instead, a convention
is offered.

   4.1.1. To use EPSG codes to describe coordinate reference system, the
"crs" member should have the following structure: "crs": {"type":
"EPSG", "properties": {"code": 4267}}. "crs", "type", and "properties"
must be lower case. When used as a value, "EPSG" must be upper case.
   4.1.2. Note that the use of EPSG codes does not change the meaning of the
coordinate order for a GeoJSON data structure. All coordinates in
GeoJSON are in x, y order (longitude, latitude). This is true regardless
of the schema used to represent the coordinate reference system.
   4.1.3. The use of a "crs" member for EPSG:4326 is discouraged since the
default of not having a "crs" member would result in the same coordinate
values. 
"""


To the following, which instead offers two conventions, one which uses
the standard EPSG database, and the other which uses user-namable
properties via URLs. This does not indicate how to parse these -- note
that "EPSG:4326" doesn't indicate how to parse that either. It's
expected to be treated as an opaque identifier which the consuming
application understands. This is equally true for URLs. 

The reason to do this *now* instead of later is simply because if we
don't do it now, people will begin inventing their own EPSG  codes
(cough, EPSG:900913) instead of using shared references which can
possibly be dereferenced for further information.   

"""
4.1. The value of a member named "crs" must be an object. This object
must have at least two named members: "type" and "properties". =="crs",
"type", and "properties" must be lower case.== The value of the member
named "type" must be a string. The value of the member named
"properties" must be an object. This specification defines no further
requirements for the structure of these objects. Instead, ==two
conventions are== offered. 

 (4.1.1 is reorganized, but no different.) 

   4.1.1. To use EPSG codes to describe coordinate reference system, the
"crs" member should have the following structure: "crs": {"type":
"EPSG", "properties": {"code": 4267}}.  When used as a value, "EPSG"
must be upper case.
     
     4.1.1.1. Note that the use of EPSG codes does not change the
        meaning of the coordinate order for a GeoJSON data structure. All
        coordinates in GeoJSON are in x, y order (longitude, latitude). This 
        is true regardless of the schema used to represent the coordinate 
        reference system.
        
     4.1.1.2. The use of a "crs" member for EPSG:4326 is discouraged
        since the default of not having a "crs" member would result 
        in the same coordinate values. 
   
   (4.1.2 is new.)
   
   4.1.2. To use a URL as a unique identifier to a coordinate reference 
          system, the "crs" member should have the following structure:
          "crs": {"type":"URL", "properties":{"url":
          "http://example.com/mysrs/"}. When used as a value,
          "URL" must be uppercased.         
      4.1.2.1. The specification does not offer any information on how
               to convert this URL into a spatial reference system: its
               use is inteded to provide users the ability to define
               their references outside the EPSG namespace *only*.
"""

Feedback welcome.               
               
Regards,
-- 
Christopher Schmidt
MetaCarta