Consider using your own Fraction.js as a dependency

[eXeDK]

Hi!

Using the package I've noticed that the lat/longs sometimes suffers from normal precision issues. Maybe a solution could be to use your own package? This will still keep the dependencies down to an acceptable number.

Thanks for the great package! Really saved me for a lot of work!

Best
Thomas

[infusion]

Hi Thomas,

thanks! That's a pretty good idea! Actually I avoided using fraction.js for exactly the reason of keeping the dependencies small. I would not make a breaking change on this, but as an optional feature, I will implement this.

Robert

[eXeDK]

That was my guess as well which is why I was happy to find Fraction.js. I would assume it would still use Fraction.js for returning normal numbers with a fixed precision just like it is possible with something like decimal.js?

[infusion]

It is! Fraction.js implements the valueOf() method, so that 123 + fracObj works. From that perspective, there are no differences to be expected. But when I introduce Fraction.js as a regular dependency, it is a breaking change, since some users might check for fracObj instanceof Number or something.

[infusion]

So, I'm not quite sure how to implement it. When I require the dep in the main gps.js file, things get ugly. One option would be to create a new main.js file, which modifies the number parser. This way gps.js still can be used in browsers without the need of a require-environment.

[infusion]

Okay, I think I found a way. Do you think it makes sense to get all numbers as fraction then?
Do you have an example where the coord parser does not work? I actually avoided numerical parsing to circumvent exactly these problems.

[infusion]

On a feature branch, running the test suite results in this (this is just for demonstration, it can be fixed later):

      -  "lat": {
      -    "d": 8000
      -    "n": 99633
      -    "s": -1
      -  }
      -  "lon": {
      -    "d": 37500
      -    "n": 4906783
      -    "s": 1
      -  }
      +  "lat": -12.454125
      +  "lon": 130.84754666666666

The longitude is interesting here, as it has a period of 6. However, I wonder where this precision gain is necessary. The error is < 1e-15. There are certainly other problems on GPS precision.

[eXeDK]

I would still expect numbers to come out but without the calculation that can occur with plain node math. So just a normal number with a maximum precision. In that way there is no breaking change. So Fraction.js is only used internally to do the calculations.

[infusion]

Okay, makes sense. But could you give an example where the current string-parsing approach misses accuracy? I wouldn't embed the whole library then, but try to calculate everything with rational numbers.

[eXeDK]

Actually now I re-calculated the numbers again myself and it looks correct. I was first set of by a number that ended with a lot of sixes and then a seven which made it look incorrect.
I apologise for the confusion. Nonetheless the idea still might be valid. I see you have a comment on this in your parser already anyway.

[infusion]

Yep, I added the comment when I wrote the code. However, the numerical error is insignificant in contrast to the error GPS has on its own. So, what would be a better option is adding the Kalman filter from the Maps example to the actual library to infer the true state.
I think the way the coordinates are calculated at the moment is super precise. I work with strings on the input and what might introduce the imprecision is the division by 60 at the end. But actually, you have the same problem when converting a rational number to a double.

[eXeDK]

I agree with you. Thanks for the swift answers. Much appreciated.

[infusion]

But what do you think about a state estimator right within the state object? At the moment, latitude and longitude and speed are just collections of the underlaying data. More interesting would be a filter to give a more robust position. I added a naive implementation only for maps now, but this could help improve your case as well.

[eXeDK]

I agree with you that it would be a cool addition and definitely useful in real-work applications!
I think it is a matter of whether it is within the scope of this package. But as the author you of course have the power to expand the scope from a parser of NMEA sentences to something a bit more.

Personally I think it would be cool and if you don't add it directly I will probably add it myself using your maps example.