https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112016-05-10T04:19:44ZRuby Issue Tracking SystemRuby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=585452016-05-10T04:19:44Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>On rubygems, I see a lot of gems with 'geo' in their name. Which one is yours? How popular is it? These days, it's easy to use something as a gem, so it's not that necessary to include things into the standard library.</p>
<p>You make a lot of comparisons with Time. Time has things such as timezones. Geo coordinates also have all kinds of complicated details. I happen to lurk on the IETF geojson list, and there such things get discussed. For example, there seems to be Lat/Long formats and Long/Lat formats. Why did you choose Lat/Long? Also, people there often talk about something called CRS (coordinate reference system, I guess). Which one do you use.</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=585492016-05-10T07:40:13Zshevegen (Robert A. Heiler)shevegen@gmail.com
<ul></ul><p>Would it actually not be better to instead add one or two methods to time, date or datetime?</p>
<p>I guess your proposal would add a default new toplevel namespace Geo, which I am not sure<br>
is a good idea per se since other projects may want to use it. Time/Date/DateTime on the<br>
other hand already exist more or less (at the least Time).</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=585542016-05-10T08:02:10Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p>Martin Dürst wrote:</p>
<blockquote>
<p>On rubygems, I see a lot of gems with 'geo' in their name. Which one is yours? How popular is it? These days, it's easy to use something as a gem, so it's not that necessary to include things into the standard library.</p>
</blockquote>
<p>I referenced "gem question" in original proposal: "This type is too "small" to be defined by separate gem, so, all of existing geo gems (GeoKit, RGeo, GeoRuby, Graticule etc.) define their own LatLng, or Location, or Point, whatever.".</p>
<p>I proposed it this way, because standard library is a "common denominator" for all gems and libraries. If some Ruby library works with time values, it returns either Time or DateTime, and if it is not -- that would be a common first suggestion for library design.</p>
<p>But about geographical coordinates, current state is: there is no gem which is "just geographical coordinates", well-designed and concise. All popular geo-* gems are some combines of coordinate reference systems, database access, file formats parsing, geocoding through some APIs and so on and so on. All of them (and many other geography-aware gems) frequently accept and return "pair of coordinates" type, and all of them use incompatible "basic type", or just a tuple of two values.</p>
<p>Whether Coord type would be in standard library, it can became common data exchange format; if it would be separate gem, it would definitely not.</p>
<p>So, its just a repo with proposal, not a gem.</p>
<blockquote>
<p>You make a lot of comparisons with Time. Time has things such as timezones. Geo coordinates also have all kinds of complicated details. I happen to lurk on the IETF geojson list, and there such things get discussed.</p>
</blockquote>
<p>Currently, I'm just following "principle of least surpise" and waiting for input from the community.</p>
<blockquote>
<p>For example, there seems to be Lat/Long formats and Long/Lat formats. Why did you choose Lat/Long?</p>
</blockquote>
<p>Because for "common user" the question of right order seems obsolete now, with spreading of casual GPS software and online maps, all of them seemingly using lat/long order.</p>
<blockquote>
<p>Also, people there often talk about something called CRS (coordinate reference system, I guess). Which one do you use.</p>
</blockquote>
<p>Same as with coordinates order, just a "common" WGS-84. <a href="https://github.com/zverok/geo_coord/commit/f1f50373c569b7f19199a6d5dcc70776d58fea1e" class="external">Added mention</a> of it to README and code.</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=585552016-05-10T08:11:08Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p>Robert A. Heiler wrote:</p>
<blockquote>
<p>Would it actually not be better to instead add one or two methods to time, date or datetime?</p>
<p>I guess your proposal would add a default new toplevel namespace Geo, which I am not sure<br>
is a good idea per se since other projects may want to use it. Time/Date/DateTime on the<br>
other hand already exist more or less (at the least Time).</p>
</blockquote>
<p>I'm not sure how coordinates processing can be added to Time/Date classes. Could you explain please?..</p>
<p>On other hand, I think adding <code>Geo</code> namespace can be justified exactly by fact of creating new "basic" types useful for everyone. And, as far as I can see, no existing and relatively popular geographic gem (RGeo, GeoRuby, Graticule, GeoKit) uses it currently</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=585562016-05-10T08:15:29Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/58556/diff?detail_id=41190">diff</a>)</li></ul> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=585592016-05-10T09:16:05Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>Victor Shepelev wrote:</p>
<blockquote>
<p>I referenced "gem question" in original proposal: "This type is too "small" to be defined by separate gem, so, all of existing geo gems (GeoKit, RGeo, GeoRuby, Graticule etc.) define their own LatLng, or Location, or Point, whatever.".</p>
</blockquote>
<p>Nothing is too small to be defined as a gem. I propose you create this as a gem, then have the existing geo gems use it, and then come back to your proposal here.</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=585602016-05-10T09:43:13Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p>You see, my point was not "I created a cool code, lets add it to stdlib!"<br>
My point was "We need standard Geo Coordinates type in stdlib" (because of <code><reasons></code>).<br>
I've just thought it would be easier to discuss with some sample code (but I can throw it away, if it affects the discussion).</p>
<p>Let's say it this way:</p>
<p><strong>Proposal:</strong> We need "geo coordinates" type in standard library.</p>
<p><strong>Reason:</strong></p>
<ul>
<li>in modern applications (web, mobile, scientific and so on) it is pretty common type;</li>
<li>there are many incompatible implementations in several popular libraries;</li>
<li>for such a basic type, no "external library" would be never widely accepted (think "ok, create your own C++ string class and make it widely accepted! but in the meantime, just use <code>char*</code>" -- <code>std::string</code> had to fight for years to be used in some of the libraries);</li>
<li>the earlier new type became "standard", the better.</li>
</ul>
<p>Whether my desing and implementation is good or not, is not exactly relevant to proposal -- it meant to be starting point for discussion.</p>
<p>And that's it.</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=591952016-06-13T14:50:10Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Rejected</i></li></ul><p>Although I feel it's good to have common coordination class, I don't think it's wise to pick one implementation over many and add it to the standard library. It should be done through sound competition.</p>
<p>If you need any help from the core team (other than adding it to the standard lib), let us know.</p>
<p>Matz.</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=591972016-06-13T14:52:43Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><p>Thanks. Already did it into gem: <a href="https://github.com/zverok/geo_coord" class="external">https://github.com/zverok/geo_coord</a> -- and will see how it is playing with ecosystem.</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=592002016-06-13T15:20:23Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><blockquote>
<p>Although I feel it's good to have common coordination class, I don't think it's wise to pick one implementation over many and add it to the standard library. It should be done through sound competition.</p>
</blockquote>
<p>To be honest, at first (it was ~February), I've just wanted to post here a mere proposal like "let's create a common class in stdlib" and call it a day.</p>
<p>Then, I've thought that some kind of "reference implementation" (which can be checked and discussed practically) will help to move into pragmatic matters as soon as possible.</p>
<p>Then, I've spent some time to create an implementation to go with the proposal.</p>
<p>And then, proposal was failed and rejected because it is implemented :) That's kind of funny.</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=592192016-06-14T09:40:07Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>Great to see the gem. With respect to</p>
<blockquote>
<p>And then, proposal was failed and rejected because it is implemented :) That's kind of funny.</p>
</blockquote>
<p>I think you misunderstood Matz. We could have picked just your basic data representation, without some or all of the methods. But what we would like to see is more buy-in from the geocommuting community. The best way to show such buy-in is to see your gem adopted.</p> Ruby master - Feature #12361: Proposal: add Geo::Coord class to standard libraryhttps://bugs.ruby-lang.org/issues/12361?journal_id=592202016-06-14T10:17:33Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><blockquote>
<p>We could have picked just your basic data representation, without some or all of the methods.</p>
</blockquote>
<p>Thing is, I thought about my proposal as a three parts (with each next point being less important):</p>
<ol>
<li>Standard library should have a class for geocoordinates</li>
<li>(Less important) It could have an interface like this, or something... Let's talk</li>
<li>(Even less important) Here is some experimental implementation, allowing to play with concept and discuss it.</li>
</ol>
<p>I'm absolutely totally 100% OK with rejection of (3), a bit concerned about rejection of (2) with no discussion, but my only real concern about rejection of (1).</p>
<p>Now I'm thinking maybe if this ticket was originally created with a short text "Add geocoordinates class to Ruby standard library, representing [latitude, longitude] pair + convenience methods." and no links to proposed interface/implementation, it would be more useful for community :)</p>
<p>And, faithfully, do you believe such a class could be added to standard library by joined effort of several different geography gem authors?..</p>
<p>My only point is: let's add it to stdlib at some point in future. Interface could be any, implementation could be any, but let's have the class with this role in stdlib.</p>