<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
I agree with deprecating CRS with no replacement.
<div><br>
</div>
<div>Maybe if people want other coordinate systems, they can reuse the GeoJSON syntax but embed it into some kind of CRS wrapper. That lets people reuse GeoJSON parsing code but the wrapper should not be called GeoJSON. (Not sure if I'm making sense here…)
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>Allan</div>
<div><br>
<div>
<div>On May 16, 2013, at 2:58 PM, Tim Schaub <<a href="mailto:tschaub@opengeo.org">tschaub@opengeo.org</a>></div>
<div> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">I like the proposal Sean. Curious exactly what you mean by deprecate (remove "crs" with no text mentioning it, or say "crs" is deprecated and describe what it used to be like?).
<div><br>
</div>
<div style="">Regarding GeoServer, it is a good question. I haven't discussed this with others in that community, but I'd say GeoJSON would become more like KML - GeoServer can serialize feature collections as both, but you can't request data in arbitrary
reference systems.</div>
<div style=""><br>
</div>
<div style="">It's also my opinion that clients can use other formats if they need functionality not covered by GeoJSON (we don't handle complex features particularly well, for example). A capable web client can consume GML from GeoServer's WFS if it wants
data in an arbitrary crs or needs complex features. In addition, I don't personally feel like GeoJSON + WFS is a natural mix (WFS-T for example, doesn't work).</div>
<div style=""> </div>
<div style="">Tim</div>
<div style=""><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, May 16, 2013 at 12:26 PM, Sean Gillies <span dir="ltr">
<<a href="mailto:sean.gillies@gmail.com" target="_blank">sean.gillies@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">All,<br>
<br>
How about this for a plan: submit an I-D that deprecates the old crs object, omits the new proposed crsURN object, and doesn't otherwise change the
<a href="http://geojson.org/" target="_blank">geojson.org</a> spec. After it is submitted, we reexamine the CRS situation in light of comments we'll (hopefully) get. My hypothesis is that this compatibility-breaking change doesn't actually break very much in
practice.<br>
<br>
As a consequence there will be what looks to a lot of GIS folks like a gap in the spec. We'll need to be able to live with the multiple gap-filling measures they'll come up with. For example, Tim, what's GeoServer going to do to satisfy WFS requests for GeoJSON
in EPSG:27700 (or urn:ogc:def:epsg::27700)? <br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
<div>
<div class="h5">On Wed, May 15, 2013 at 11:08 AM, Tim Schaub <span dir="ltr"><<a href="mailto:tschaub@opengeo.org" target="_blank">tschaub@opengeo.org</a>></span> wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
<div dir="ltr">
<div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Tim, I think the situation that we have at the moment is better than you describe, but not by much. We have “allow any CRS and axis order will always be lon/lat or easting/northing”.
We did that to avoid the burden of carrying around axis order knowledge. But it still has the burden on needing to know what EPSG:27700, or whatever, means. Web clients still have to get the WKT, Proj.4 string, etc, from that id (assuming that they can work
with the result). So we dodged one bullet, but not the other, arguably more complex, one.</span><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-GB">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> </span></p>
</div>
</blockquote>
<div><br>
</div>
<div>Regarding the bullet dodging, web clients don't actually have to know squat about EPSG:27700 if they use GeoJSON and WMS 1.1 - they just have to match strings to know that they are the same. WMS 1.1 described a rendering service where coordinate order
could be mapped to rendering concepts like "top" and "left" (well known by web clients who deal with images). GeoJSON maintained the same - a known mapping of coordinate order to rendering orientation. So we very intentionally made GeoJSON work well with
existing rendering services.</div>
<div>
<div><br>
</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-GB">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Here’s a pull request of mine:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a href="https://github.com/GeoJSONWG/draft-geojson/pull/3" target="_blank">https://github.com/GeoJSONWG/draft-geojson/pull/3</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Martin<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" lang="EN-US">
<a href="mailto:geojson-bounces@lists.geojson.org" target="_blank">geojson-bounces@lists.geojson.org</a> [mailto:<a href="mailto:geojson-bounces@lists.geojson.org" target="_blank">geojson-bounces@lists.geojson.org</a>]
<b>On Behalf Of </b>Tim Schaub<br>
<b>Sent:</b> 15 May 2013 05:41<br>
<b>To:</b> <a href="mailto:geojson@lists.geojson.org" target="_blank">geojson@lists.geojson.org</a><br>
<b>Subject:</b> [GeoJSON] Removing CRS from GeoJSON<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">So as to avoid hijacking Sean's thread, I'll start a new one here.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm in favor of restricting the allowed coordinate reference systems for GeoJSON objects to 1:
<span>latitude, longitude coordinates relative to an ellispoidal CRS based on the WGS84 datum.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span>I think the second best alternative would be to restrict to 2 CRS: CRS84 or EPGS:3857.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span>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).</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span>I apologize for having missed earlier "discussion" [1]. I haven't dug down to that epoch in my inbox yet.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span>And I'm in favor of the proposed RFC to IETF [2].</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span><a href="https://github.com/GeoJSONWG/draft-geojson/pull/2" target="_blank">https://github.com/GeoJSONWG/draft-geojson/pull/2</a></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span>[1] <a href="http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000712.html" target="_blank">
http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000712.html</a></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span>[2] <a href="http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000713.html" target="_blank">
http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000713.html</a></span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span>Tim</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span>PS - Do the build artifacts (xml, txt, etc) need to be in the repo? If so, can someone update the README.md with detail on building them?</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><span>PPS - Mildly curious what it means to be "commented out" as an author. I do see a comment that suggests authors should be asked if they are willing to be authors. Happy to entertain that question.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <br>
Tim Schaub<br>
OpenGeo <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>
Expert service straight from the developers.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<div><br>
<br clear="all">
<div><br>
</div>
-- <br>
Tim Schaub<br>
OpenGeo <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>
Expert service straight from the developers.<br>
</div>
</div>
</div>
<br>
</div>
</div>
<div class="im">_______________________________________________<br>
GeoJSON mailing list<br>
<a href="mailto:GeoJSON@lists.geojson.org" target="_blank">GeoJSON@lists.geojson.org</a><br>
<a href="http://lists.geojson.org/listinfo.cgi/geojson-geojson.org" target="_blank">http://lists.geojson.org/listinfo.cgi/geojson-geojson.org</a><br>
<br>
</div>
</blockquote>
</div>
<span class="HOEnZb"><font color="#888888"><br>
<br clear="all">
<br>
-- <br>
Sean Gillies </font></span></div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Tim Schaub<br>
OpenGeo <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>
Expert service straight from the developers.<br>
</div>
_______________________________________________<br>
GeoJSON mailing list<br>
<a href="mailto:GeoJSON@lists.geojson.org">GeoJSON@lists.geojson.org</a><br>
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org<br>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>