[Geojson] Fixing problems in section 4

[Sean Gillies]

Hi all,

I'm pretty much a +1 to go to 1.0 after we address 2 things:

>                     4.1.2.2.4. Unless your data falls under one of the
> exceptions above, you should prefer EPSG codes to OGC URNs.

I'm -1 on this (which I've been overlooking until now). OGC URNs should
be preferred to the legacy EPSG:n identifiers. Let's make GeoJSON about
best practices.

I'd also like to simplify the CRS section 4. The spec describes 3
different categories: 1) the default CRS, 2) identifiers for
data/parameters that clients and servers have in hand, and 3) CRS that
are fetched from the web as needed.

The default case is already done exactly right in the spec. We could
make it more clear that almost every open source GIS user could use the
default instead of specifying "EPSG:4326".

Category 2 includes both OGC URNs and legacy EPSG:n identifiers. I think
we can radically simplify to

"crs": {"value": "urn:ogc:..."} or "crs": {"value": "EPSG:..."}

with a strong preference for the former. This simplifies the data and
also (in my opinion) is less offensive to the Category 3, the case where
clients dereference a URL to get CRS parameters, can be represented by

"crs": {"link": {"href": "http://spatialreference.org/..."}}

So, my rewrite of section 4 would be something like

4. Coordinate Reference Systems
4.1 The default
4.2 CRS identifiers
4.2.1 "OGC URNs should be used whenever possible in preference to legacy
EPSG:n identifiers"
4.2.2 "value" member
4.3 CRS links
4.3.1 "link" member
4.3.1.1 mandatory "href" member
4.3.1.2 "optional type member"

As I recall, the "properties" member specified currently in 4.1.2 is
nothing more than a leftover of early discussions about putting PROJ4
parameters directly into a crs object. That use case seems to have
evaporated, yes?

A less radical departure from the current text of section 4, but that is
 still a simpler way to treat the 3 CRS categories above would be: for 2)

"crs": {"type": "id", "value": "urn:ogc:..."}

and for 3)

"crs": {"type": "link", "value": {"href":
"http://spatialreference.org/..."}}

Sean