Hi Benoît, On Sat, 22 Dec 2018 at 09:02, Benoit St-Jean <bstj...@yahoo.com> wrote: > > Hi Alistair! > > First off, thanks for the "thank you note" in this email & on GitHub. > > Would you be interested in working on a port of GeoSphere > (https://cran.r-project.org/web/packages/geosphere/geosphere.pdf) to > Pharo ? I'll have some spare time in the next weeks so we could work on > that together. Since this package is widely known and used, it could > serve as a base for a Geo package for Pharo. I have R installed with > this package here so cross-checking Pharo results vs R calculations > wouldn't be a problem! That also means plenty of unit tests are > possible ! ;)
I'm happy to work on this together (and with whoever else is interested). Pharo is my hobby which has to fit in with family, etc., so my time is rather sporadic. > I noticed (at least on Pharo 6.1) that you reference "WebBrowser" which > is either present in P7 (and not in P6) or it indicates a dependency > problem. That's why I put "Pharo 7" in the installation section :-) I haven't tried, but I expect that loading WebBrowser in to Pharo 6 is straightfoward. With Pharo 7 about to go GA I have to admit that personally I'm not interested in putting much effort in to supporting earlier versions (other than a bit of testing, I haven't used Pharo 6 since it was released :-)). > I also noticed that you use the WGS84 reference ellipsoid as a hardcoded > constant (in other works, assuming the earth radius is 6378137 meters > for all calculations). Modifying the code to have reference ellipsoids > objects and use the WGS84 as the default (which is what everyone uses) > would be a more flexible solution. Actually, there's #haversineDistanceTo:radius: for exactly this reason (more below). > Besides, it would also allow funky > stuff like being able to use the same framework to work for every known > spatial body like say, the Moon or Mars or whatever! Besides, that way > (using reference ellipsoid objects), older maps/coordinates/calculations > could still be used just by changing the ellipsoid reference. At the moment the EarthRadius is a class variable. It would be better and more flexible to remove it and create separate objects for the different standards and bodies. > Let me know if you're interested! Sure. I had planned to extend this as required, but if you've got a particular approach I'm happy to try and fit in (within the time limitation mentioned above). > P.S. I couldn't find a similar package/framework for > Pharo/Squeak/WhateverSmalltalk. If I missed it, let me know guys!! I'm > not a big fan of reinventing the wheel!! Ditto. Cheers, Alistair > On 2018-12-19 02:32, Alistair Grant wrote: > > Hi All, > > > > If anyone is interested, I've created the beginnings of a library for > > handling coordinates at: https://github.com/akgrant43/GeoSphere > > > > It only: > > > > - Parses string coordinates > > - Calculates the distance between coordinates > > - Opens a web browser in OpenStreetMap at the receiver's coordinates > > > > Examples of string formats that can be parsed: > > > > - 144.61025 @ -38.28697 > > - 38° 17′ 13.09″ S, 144° 36′ 36.9″ E > > - 38 deg 17' 13.09" S, 144 deg 36' 36.9" E > > - https://www.openstreetmap.org/#map=18/-38.28697/144.61025 > > > > The distance calculation uses haversine (assumes the earth is a > > sphere), which is good enough for my needs at the moment. > > > > Thanks again to Sven, Benoit, Pierce and Richard for their input. > > > > Cheers, > > Alistair > > > -- > ----------------- > Benoît St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >
