[GeoJSON] Plug-Pull request to finalize a CRS-free I-D revision

Thu Jun 13 16:48:13 PDT 2013

On Jun 13, 2013, at 7:04 PM, Sean Gillies <sean.gillies at gmail.com<mailto:sean.gillies at gmail.com>>
 wrote:

Stefan, all:

I think we should continue with your proposal, but I hear that other authors are having second thoughts about removing CRS after all. Allan? Howard?

Second thoughts:

Item 1. People are using CRS. We know of one, Michael Geary. Based on the tweets below, it looks like there's another in the works, Ben Balter. We have to assume there are others.

Item 2. Assume we remove 'crs' from the spec. Then what happens when someone else makes a GeoJSON file with a 'crs' element that works differently from the one we had. Now we have the people in item one with different use of 'crs' than people in item two. Not only is that a Bad Thing, it seems very unfair to those people in item one.

Let's do this. Keep it in. Keep the documentation pretty much as is. Add a note that says we know this is not optimal, and that interoperability is better served if it's not used, but that if people are going to use 'crs' they have to use what's here as a starting point. If they want to add a different element, e.g. 'srs' or 'allans-excellent-reference-element', they can do that. But they do that will full knowledge that it's not part of the spec.

Philosophical version: Essentially, there are two namespaces for elements in GeoJSON. The standard namespace is the set of names we define in the spec. The non-standard namespace is everything else. If someone uses something in the standard namespace, they have to use it as described. If they use something in the non-standard namespace, they can do whatever they want.

Further second thoughts: We put together GeoJSON 1.0 and it's been out for a long time. I don't think we can cross the line of making a subsequent version that decreases interoperability, and I think that's what removing 'crs' or changing its definition would do.

Final thoughts: I admit I was one of the people originally advocating dropping crs. I've changed my mind. We screwed it up, but it would be worse to compound the error.

Allan

GitHub's new maps for .geojson files is revealing a lot about how people perceive the format. Here, Ben Balter (of GitHub) says support for other CRS is being considered:

  https://twitter.com/BenBalter/status/345280641715298305

I assume he doesn't mean different map tiles, but reprojection of Illinois State Plane X to Web Mercator. They'll need CRS in the file to accomplish this across all repositories. I'd rather the City of Chicago and everyone else did their GeoJSON in CRS84, but it seems we'll have to get GitHub on board to do so.

And here's someone who didn't realize that GeoJSON covered CRS at all:

  https://twitter.com/iandees/status/345281028132315137

IMO, this is because we didn't do it well and good examples never appeared.

On Tue, May 21, 2013 at 11:23 AM, Stefan Drees <stefan at drees.name<mailto:stefan at drees.name>> wrote:
Hi Tim,

yes I know, that there are partial clean-up attempts with focus on a specific topic (like your patch #6 removing crsURN) but not transporting the document into a consistent state, which is ok, but I think as time goes by not the best we can achieve. As I had to base my clean-up patch on some revision and repo, I picked the latest you merged, to be on the safe side.

In the light of the latest somehow diverging discussions, I thought a minimal consensus edition might help remain patient and have a clear view on the remanining tasks before entering the public comment phase, that will start when submitting the first revision to IETF I-D queue. The submission will just be the beginning :-)

So applying the patch #10 as wrap-up gives us all the advantage of a clean start for the finish and if many of the authors meet in person during this north american conference in Minneapolis, MN, USA all the better, to start placing the final golden minimal CRS statements into the cleaned-up consistent document as close as possible to a broad consensus (in my understanding of the exchanged messages).

My proposal is thus:
  a) Apply #10,
  b) some discuss the final statements about the relation of Coordinate Reference Systems and GeoJSON during the conference,
  c) short discussion on concrete pull request based on the outcome of b) then
  d) merge and
  ...)
  r) ready for submission we are :-).

Good idea? Not so good idea? Please share your thoughts.

Stefan.

On 21.05.13 18:57, Tim Schaub wrote:
Note also that I have a pull request outstanding to remove crsURN:
https://github.com/GeoJSONWG/draft-geojson/pull/6

I think we'd all agree that there needs to be some discussion of CRS in the spec.  This is missing from your pull request.  Minor work to add it in, but it needs to be there.

I imagine a number of us will be at the FOSS4G-NA conference through the end of the week.  So while discussion on this list might stagnate, we could have some in-person discussion about this.

Tim

On Mon, May 20, 2013 at 7:31 AM, Stefan Drees <stefan at drees.name<mailto:stefan at drees.name>> wrote:
Dear all,

I snet a pull request, where I:

* simply removed the CRS (and any crsURI stuff),
* also removed my intermediate notes,
* and removed the now unused references to HTTP, TLS, URx RFCs,
* rephrased the Polygon section for readability,
* edited some lines to remain inside line length limit,
* updated the date to May 2013,
* enhanced the security considerations section (using the JSON Patch
  RFC as role model) to somehow delegate security back to JSON where it
  belongs, as we do not add anything security relevant on top
* and sync'ed the section number for the bounding box references inside
  our document.

The pull request #10 is at

https://github.com/GeoJSONWG/draft-geojson/pull/10

If one likes to se the outcome of merging it, maybe

http://sdrees.github.io/draft-geojson/draft.html

is a good place or

http://sdrees.github.io/draft-geojson/draft.txt

This patch should merge the essence of our latests planned changes for the to be submitted draft (as far as I understood the ideas of most on this list).

Am I right? Not so right? What do you think?

PS: If you read an archived version of this mail, some links stated in above text may result in HTTP 404 Not found as these mostly point to intermediate working material.

All the best,
Stefan Drees.
_______________________________________________
GeoJSON mailing list
GeoJSON at lists.geojson.org<mailto:GeoJSON at lists.geojson.org>
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

--
Tim Schaub
OpenGeo http://opengeo.org/
Expert service straight from the developers.

_______________________________________________
GeoJSON mailing list
GeoJSON at lists.geojson.org<mailto:GeoJSON at lists.geojson.org>
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

--
Sean Gillies
_______________________________________________
GeoJSON mailing list
GeoJSON at lists.geojson.org<mailto:GeoJSON at lists.geojson.org>
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20130613/57dfe732/attachment.htm>