Removing crsURN

[tschaub]

update (2014-01-08): The original CRS sections have been returned to the draft, but a strong recommendation for use of the default CRS84. Software, like Leaftlet, that has core support only for CRS84 is completely in line with the draft.

This makes all GeoJSON positions latitude, longitude [, elevation in meters] relative to an ellispoidal CRS based on the WGS84 datum.

I'm in favor of restricting the allowed coordinate reference systems for GeoJSON objects to 1: CRS84.

I think the second best alternative would be to restrict to 2: CRS84 or EPGS:3857. But that means we'll only be cool as long as Google Mercator is cool. And 2 is pretty arbitrary. Soon people will want 3.

I don't like the "allow any CRS and let axis order follow the CRS" because I think it either reduces interoperability or imposes an unreasonable burden on web clients (I don't know of a good web service - or really want to depend on one - that provides axis order information for arbitrary CRS URN, and the table is too big to ask every client to carry around).

With all GeoJSON coming in a known CRS, clients that want to consume any GeoJSON but work or render in a different CRS shouldn't have a hard time finding code to do coordinate transforms. This is a smaller burden than being able to look up axis order for any CRS URN.

(Note that this is a second pass at #2.)

[sthagen]

As long, as we remove the "promises we do not keep" portions I am OK with every proposal. I would like to have advice from the community members based on their knowledge of what really is in use today. So my +1 must be rescaled with the Stranger-Factor 0 (Zero) I fear ;-)

[sthagen]

Please cf. my comment on the patch#10 discussion for further delegating +1+1 from me ...

[mourner]

I'd love this! The simpler the better.

[elemoine]

I like the simplicity of the approach too. But I think restricting the coordinate systems to WGS84, or to WGS84 and EPSG:3857 would be too restrictive. In particular, it would make people using GeoJSON with other coordinate systems violate the specification. And we, at Camptocamp, use GeoJSON for specific custom web services that transport EPSG:21781 data. (We don't even set the "crs" currently, so we may already violate the specification, but it just works for us.) As proposed on the mailing list there could be known projections (WGS84 or WGS84 and EPSG:3857), and every other projection could just be ignored by GeoJSON parsers. I think it would work great for us, but the simplicity is preserved.

[atlefren]

At my pervious place of work we used GeoJSON to transport data from server to client. Our maps used WGS84 UTM zone 33N, and to avoid using proj4.js we put these coordinates into a GeoJSON structure. As @elemoine said, we also never set "crs".

The ease of use is a key value of GeoJSON, and having a few (one?) known projection(s) and simply ignore the rest (without any validation errors) seems to me like a great idea.

(That's my two cents for what they're worth anyways. .)

[tschaub]

I think these are both examples of people successfully using invalid GeoJSON in applications. This will continue to be possible as long as parsers aren't more strict (rejecting coordinates outside the range of valid Geographic coordinates).

The proposed changes in the spec should make it easier to build a strict parser - the reason the OpenLayers parser is lenient to your use is that it is impossible to properly deal with the current crs member. But we could also keep the parser lenient and just pass coordinates directly through to geometries.

The proposal to remove crsURN would encourage interoperability - people can consume data that they didn't have a hand in preparing, or they can host data for other consumers. My impression is that people using GeoJSON in alt-projections aren't taking advantage of this type of interoperability.

[elemoine]

(rejecting coordinates outside the range of valid Geographic coordinates)

Or trying to transform the data assuming it's CRS84 data.

But we could also keep the parser lenient and just pass coordinates directly through to geometries.

Yes, but other parsers may be stricter. Maybe there's very little chance that parsers would reject, or do bad things with, our projected data.

Thanks.

[tschaub]

More support for CRS84 only GeoJSON (in my opinion):

If your points aren't appearing where you'd expect (e.g., in the middle of the ocean),
chances are you're using a projection, which is currently unsupported.

https://help.github.com/articles/mapping-geojson-files-on-github#troubleshooting

[pramsey]

In a world of client-side coordinate re--projection support for both raster and vector (a world that didn't really exist when WMS established the "clients may ask for data in one of a set of supported projections" pattern we find it hard to mentally break from) it is perfectly reasonable to support only one well-established CRS and expect the client to do the heavy lifting of putting it into whatever display projection it wants.

Important note: if you're in spherical coordinates (hello, CRS84) you need to enforce ring orientation to distinguish between POLYGON ((0 0, 0 1, 1 1, 1 0, 0 0)) which encloses a bit of ocean and Africa and POLYGON((0 0, 1 0, 1 1, 0 1, 0 0)) which encloses the whole world except a bit of ocean and Africa (or vice versa, depending on your standard).

[tschaub]

Thanks for weighing in @pramsey.

you need to enforce ring orientation

I think what we should do is say that left of exterior rings is inside and left of interior rings is outside, right? I don't think we need to enforce anything about validity (a client may want to transmit a candidate geometry to a server for a validation check).

[pramsey]

Yes, or vice versa. A little research into common orientation rules is needed first. Shapefile uses exterior-clockwise/interior-anti-clockwise, which is the reverse of the rule you articulated.

[sgillies]

Paul,

Would that second polygon in your important note be strictly simple?
Wouldn't we really have to represent it as a global surface with a
box-shaped hole?

Maybe a better example would be hemispheres: does a ring along the equator
bound the northern or southern hemisphere?

On Thu, Jun 13, 2013 at 2:25 PM, Paul Ramsey notifications@github.comwrote:

In a world of client-side coordinate re--projection support for both
raster and vector (a world that didn't really exist when WMS established
the "clients may ask for data in one of a set of supported projections"
pattern we find it hard to mentally break from) it is perfectly reasonable
to support only one well-established CRS and expect the client to do the
heavy lifting of putting it into whatever display projection it wants.

Important note: if you're in spherical coordinates (hello, CRS84) you need
to enforce ring orientation to distinguish between POLYGON ((0 0, 0 1, 1 1,
1 0, 0 0)) which encloses a bit of ocean and Africa and POLYGON((0 0, 1 0,
1 1, 0 1, 0 0)) which encloses the whole world except a bit of ocean
and Africa.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/6#issuecomment-19422624
.

Sean Gillies

[pramsey]

The "simple features" spec becomes different on the sphere. How would you
represent "a global surface with a hole", for example? POLGON((-180 -90,
-180 90, 180 90, 180 -90, -180 -90), (0 0, 1 0, 1 1, 0 1, 0 0))? The first
"ring" in the example consists of a line from the north pole to the south
pole and back again along the dateline. No more or less "crazy" than my
oriented ring, IMO.

I don't think you can get away from ring orientation once you're on the
sphere, but yes a spherical bisection should make the problem more obvious
to the lay reader. Or perhaps the box, POLYGON((90 -45, 90 45, -90 45, -90
-45, 90 -45)). Does it cover Africa, or the Pacific?

Similarly for lines, does LINESTRING(100 0, -100 0) cross Africa or the
Pacific? What about LINESTRING(100 0, 0 0, -100 0)?

P.

On Thu, Jun 13, 2013 at 2:38 PM, Sean Gillies notifications@github.comwrote:

Paul,

Would that second polygon in your important note be strictly simple?
Wouldn't we really have to represent it as a global surface with a
box-shaped hole?

Maybe a better example would be hemispheres: does a ring along the equator
bound the northern or southern hemisphere?

On Thu, Jun 13, 2013 at 2:25 PM, Paul Ramsey notifications@github.comwrote:

In a world of client-side coordinate re--projection support for both
raster and vector (a world that didn't really exist when WMS established
the "clients may ask for data in one of a set of supported projections"
pattern we find it hard to mentally break from) it is perfectly
reasonable
to support only one well-established CRS and expect the client to do the
heavy lifting of putting it into whatever display projection it wants.

Important note: if you're in spherical coordinates (hello, CRS84) you
need
to enforce ring orientation to distinguish between POLYGON ((0 0, 0 1, 1
1,
1 0, 0 0)) which encloses a bit of ocean and Africa and POLYGON((0 0, 1
0,
1 1, 0 1, 0 0)) which encloses the whole world except a bit of ocean
and Africa.

—
Reply to this email directly or view it on GitHub<
https://github.com/GeoJSONWG/draft-geojson/pull/6#issuecomment-19422624>
.

Sean Gillies

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/6#issuecomment-19426829
.

[sgillies]

Let's deal with ring orientation (or not) in a different issue. I'm +1 on merging and closing this one.

[sheppard]

Hi, what do you think about updating the ticket description to reflect the fact that the (original) CRS definition is back in the draft? As you can see, a few of us have been referencing this ticket as evidence that CRS was going away entirely.

[sgillies]

@sheppard Yeah, this is my fault. I was certain we (GeoJSON authors) would agree on removing CRS but it turns out that we could not reach agreement.

What I've done for the draft that I'm going to submit is this bit of wisdom:

This document recommends a single coordinate reference system based
on WGS 84. Other coordinate reference systems are not recommended.

By "NOT RECOMMENDED" I mean it to say that software like Leaflet is right in having no core support for CRS other than CRS84.

[sheppard]

This approach makes sense, and I agree that there should not be an expectation that core libraries will implement a not-recommended feature. I'm working on how to best describe this situation in Proj4leaflet - follow kartena/Proj4Leaflet#60 if you're interested.