Re: [Gpsbabel-code] incorporation of GeographicLib

[tsteven4 <tst...@gm...>]

Robert,

I can accept that the naviguide format is of limited interest, and then 
the interest is local to Israel where the existing solution is adequate, 
and thus it is not worth pursuing the licensing issues.  I am not ready 
to accept the giant library argument.  I could have pared it down to a 
three classes, and even then most of the methods in those classes 
probably aren't necessary to our usage.  I wasn't willing to fiddle with 
the needed classes themselves, that would just make it too hard to stay 
in sync and I didn't want to assume maintenance of those classes while 
there is active work that I highly regard by the original developer.   
Given the availability of a global ICS projection solution that is much 
better written than the existing jeeps projection I was willing to go 
with it even though naviguide users probably don't care.  Paring down 
false test issues is beneficial in that it makes real issues stand out, 
and can save somebody the time of figuring out that they are false 
issues. But with the licensing questions I agree inclusion of 
GeographicLib probably isn't worth pursuing for these limited benefits.

The GeographicLib author did indicate some flexibility on licensing 
might be possible:
> Please let me know if it is the case that the MIT license prevents your
> using GeographicLib (and, if possible, explain to me what the problem
> is) and I can look into providing you with a difference license. 
But given the limited usage we would make of GeographicLib I don't think 
it is worth asking him to look into it.  I can't explain the licensing 
problem, I think lawyers could argue about it for as many hours as you 
would be willing to pay them for.

> D) The license thing isn't immutable.   But I'd rather not revisit it 
> for a bug fix in a function that's never actually executed in the real 
> world on data that actually matters.
For future reference, what license terms are acceptable to not require 
revisiting licensing?  Is it only the licenses we use, GPL >= v2?  Would 
the LGPL license require revisiting the issue?  I can see where some 
authors would prefer a less restrictive license than the GPL with the 
intent that proprietary and free software developers could both use 
their software.

> To me, this means that the Naviguide developers simply don't expect 
> that program to be used outside of Israel.
And sadly it appears they didn't expect it to work, or hadn't noticed 
that it didn't work, in the Sinai about 100km from the central 
meridian.  I did fix this in r4229 
<http://code.google.com/p/gpsbabel/source/detail?r=4229> , call me an 
optimist.

> The Israel Tranverse Mercator/Cassini stuff in Jeeps was added by one 
> of those devs; it wasn't part of Jeeps;
Actually the projection was part of the last jeeps distribution that I 
can find (0.1.3).  It was, and still is, in our jeeps/gpsproj.c. There 
are a number of other bits that got pasted from the original gpsproj.c 
into our gpsmath.c as well.
> So it's probable that it's "right" for points in Israel, but wrong for 
> points farther from their artificial meridian. 
Baring some undiscovered implementation error in jeeps I believe this is 
the case.  The testo test cases confirm nearly identical behavior 
between GeographicLib and jeeps for data in or near Israel.

I remain incredibly impressed with GeographicLib.  The documentation, 
references, and methodology are some of the finest I have ever seen in a 
software package.  I thought it was clever to do the series expansions 
in maxima and have it print out the code and equations for the series 
approximations.  I appreciate the history lesson in the references, and 
their availability.  I did look at Helmert, 1880 (949 pages), Rapp (~400 
pages between two parts), and Snyder (~400 pages).   I admire goals like 
Karney's "The accuracy is increased to match the standard precision of 
most computers. This is a relatively straightforward task of retaining 
sufficient terms in the series expansions and can be achieved at little 
computational cost."  The web is changing the world, can you imagine 
what collaboration was like for Cassini, Soldner, Bessel or Helmert 
compared to what we have today?  Where will this take us in 100 years?

Thanks for all the comments,
Steve

On 12/30/2012 1:09 AM, Robert Lipe wrote:
> Now that I'm back to a desktop and can dig through a bit of history, I 
> recall the story here.
>
> Naviguide was implemented independently and submitted separately by 
> two different developers (Amit and Erez) in 2009 about a week apart.   
> The Israel Tranverse Mercator/Cassini stuff in Jeeps was added by one 
> of those devs; it wasn't part of Jeeps; it was clearly copy/pasted and 
> beaten into submission.  So it's probable that it's "right" for points 
> in Israel, but wrong for points farther from their artificial meridian.
>
> Since _every_ mention of Naviguide on our mailing lists was either 
> during that flurry of activity around checkins or with other, 
> unrelated issues, I can't say that Naviguide - especially with North 
> American data - is really very strategic to us.   We've not had a 
> single question about it.   That means it either works exceedingly 
> well or that nobody is using it.  Roaming around Google doesn't show 
> any blog posts describing how to get your bike ride in or out of 
> Naviguide or such. All of the mentions that I can find of Naviguide 
> (that aren't pirate links) are from the middle of last decade. So my 
> inclination is to say this is a dead format that probably was never 
> actually used by anybody other than the two devs.
>
> It's going to sound condescending and judgemental (Hey, I get to be 
> Linus!) but the reality is that Naviguide picked an internal 
> representation that was specific to one country - 
> http://en.wikipedia.org/wiki/Israeli_Transverse_Mercator - instead of 
> the extremely common WGS 84, a worldwide standard.  This is the 
> equivalent of storing local time in your file formats - of _course_ 
> it's going to work badly for people in other areas.   To me, this 
> means that the Naviguide developers simply don't expect that program 
> to be used outside of Israel.
>
> While I think it's awesome that we strive to maintain data fidelity in 
> and out of their program (Thank you, Steve) I can't really hold us to 
> higher standards than the program's own developers.  I'm pretty 
> intolerant of making up your own coordinate systems.   I can't fake 
> shock that a program that stores data interanlly in an Israeli-centric 
> format doesn't deal with with data in, say, California.
>
> So my grumpy reaction is to say that based on our user traffic that 
> Naviguide in general - and certainly, Naviguide with locations outside 
> of Israel - are not strategic to the health of GPSBabel.    I'm 
> totally fine ignoring Naviguide in our contrived torture tests and 
> frankly, it wouldn't take much of a dare for me to suggest removing it 
> completely.
>
> Now, for short answers and history lessons on other issues mentioned.
>
> A) ICS_EN support in jeeps is messy for the reasons mentioned above.   
> It's unfortunate that it's needed at all.
>
> B) I regard Jeeps as one of the best and one of the worst decisions I 
> made in this project.  It was abandonware when I decided to use it to 
> fast-forward through the horrible, undocumented Garmin serial protocol 
> of the era.  It was also horribly buggy and the code is tortured. But 
> in 2002, there was no way I could afford one of everything that Garmin 
> made (still can't...) and it gave us a big boost onto those devices.   
> I performed rather unnatural acts making jeeps work on USB Garmins and 
> supporting the newer hardware.  (Thank Google for funding that work.) 
>   Over time, I did indeed identify parts of jeeps that we didn't care 
> about and started compiling them away.
>
> C) C++ is in our short term future.  Yes, I know I've been saying that 
> for a long time.
>
> D) The license thing isn't immutable.   But I'd rather not revisit it 
> for a bug fix in a function that's never actually executed in the real 
> world on data that actually matters.
>
> E) The Expat situation is unfortunate.  I hadn't really realized it 
> before, but since it's been that way for 10+ years, I'm not going to 
> wig out about it, but I'd rather not use it as a reason to do it 
> again.  At the geocaching HQ there is a sign that says “Let’s make 
> better mistakes tomorrow.”
>
> With this background, does this test-all case in Naviguide _really_ 
> matter, Steve?
>
>