WISH: store precision information for waypoints

[jesse-94]

Would it be possible to store the plus/minus precision information when saving waypoints? I don't see that it would violate the GPX standard, and would be very helpful in making decisions on how much to trust the data generated. Otherwise this has been an awesome app to use!

[vincentneo]

Hi @jesse-94, any examples and use cases to depict this?

[jesse-94]

Hi, absolutely! First, and in general as a GIS and data manager, I just like knowing the precision of the data I'm working with. The specific example that brought me here is this: my employer (a small city) has some 640 wifi radios positioned across our town. They were simply "eyeballed" on a paper map when placed, which was later digitized. Then many of them have been moved in the 10 years since installation. And finally, SOME of their locations have been captured by GPS, but the data was often (it seems) just collected inside a truck near the actual radio location. So there are lots of instances where the locations are off by hundreds of meters and no good way to know why.

Now they want better location data, and of course have no budget. In testing, I found your app to be by far the easiest to train others to use, and I like the non-proprietary GPX data format. But as the app shows onscreen, the precision can vary wildly from moment to moment, and although i can tell the operator to wait until the circle gets smaller, I have no way to know whether he did.

The precision information is obviously being collected, because it shows in the live map. Storing that information as an element of the waypoint would be immensely valuable to me. I'm not certain if I'm referring to PDOP or another measure of precision, but if this is PDOP, then it's already referenced in the GPX schema.

Sorry for the wordiness - this is my first time actually posting anything on GitHub. I hope I've answered your question adequately.

[vincentneo]

Nice to hear you back so soon. I always feel that a lengthy response with valuable information, will always be miles ahead of a vague and short response, hence the wordiness is appreciated.

Your use case sounds particularly interesting, and it's great to hear that the app from our collective efforts works out well for many purposes.

Now to the main point, I personally don't have much knowledge as to what kind of a measure PDOP is, but I have did a quick google search to try and understand what H/V/PDOP is. It seems like PDOP, is not a provided data by iOS APIs, possibility due the the so called 3D positioning, I'm guessing. (Would be nice if you could share a little more on this)

That said, both horizontal and vertical dilution of precision (HDOP/VDOP) seems to be available, and the value shown on screen (the signal bars and its number) is the horizontalAccuracy, which I am presuming to be HDOP. If my interpretation is true, VDOP (as verticalAccuracy) is definitely available. I do know that all three 'DOPs' are natively declared in the GPX schema, meaning implementation is indeed possible, without the need of extensions.

However, I am not entirely positive that the horizontalAccuracy and verticalAccuracy is indeed HDOP/VDOP, as according to Wikipedia, it seems like DOP is a measure as a numerical value, some sort like a level, without a unit? (and that for DOP values > 20 is "measurements are inaccurate by as much as 300 meters", suggesting that it should not be a number measured in meters?)

I know that regardless, the values stored in the file would definitely benefit in your use cases, but I feel like getting the values right and accurate is very important as to making sure that no confusions will occur for any future user, that happens to need HDOP/VDOP data as well, some sort of like a standardization, or conformation.

Also, apologies for the initial late response. I have been quite busy for the past months of 2020, for personal stuff, and I presume @merlos is busy as well. Hope to hear back from you soon.

[vincentneo]

@jesse-94 I did some additional research, and it does seem to prove that horizontal/vertical accuracy is a computed value from HDOP/VDOP.

https://forums.developer.apple.com/thread/62115 https://stackoverflow.com/questions/33108060/how-can-i-calculate-gps-dop-dilution-of-precision-using-iphone-sensor-data

While this talks a bit about what accuracy kinda is in Apple APIs: https://stackoverflow.com/questions/30673627/location-accuracy-defined-ios https://stackoverflow.com/questions/10634734/what-does-horizontalaccuracy-exactly-mean

[jesse-94]

@vincentneo Sorry about the delay! Some of those personal obligations you mentioned.

Good information. I had read through a couple of them already. So yes, it sounds like the DOPs are the basis for of the horizontal/vertical accuracy. It appears to refer to a standard deviation, from which people then infer a guess at accuracy. Standard deviations were one of those things that I understood well enough to pass tests on in school.

But I see now why the GPX schema doesn't include a "horizontalAccuracy", as each of the various platforms (iOS, Android, I even saw one that thought Garmin had its own) use their own nondisclosed algorithm to calculate an estimate, and it would be tough to maintain an apples-to-apples comparison of two datasets, given that we don't know how they were calculated!

For my own purposes, and since I'm not sure what else could be done, including the HDOP (assuming that it is, in fact, available) would be enough for me to be able to say "yes, I think this is a good data point," or "no, you need to go reshoot this one", without having an actual horizontalAccuracy distance (especially since the distance is Apple's guess with a 68% chance of being right).

Thanks for researching this!

[vincentneo]

@jesse-94 I understand that simply adding the current horizontalAccuracy to HDOP of GPX file would be good for you to ascertain if it is accurate enough or not, but what I'm afraid of is that if I were to implement this for the entire GPX Tracker app that would be up in the App Store, it could be hard for people to understand / would be misled into thinking that the value is precisely HDOP, since the GPX schema seems to dictate that hdop should be a number, not any text (hence I couldn't write 65m for example). Computing the horizontalAccuracy into HDOP is definitely nice, but considering that nobody knows the algorithm, and that making educated guesses, could still be potentially misleading.

This would unfortunately lead to potential confusion that isn't currently in existence. One of the possible ways of mitigation, that I am thinking of, would be to allow a new setting to let users choose to write values of horizontalAccuracy or verticalAcurracy (computed or not) into corresponding, tags like HDOP/VDOP.

This is like an 'at your own risk/understanding/may not be accurate' setting, but would definitely be up to @merlos on whether he would allow this or not.

Another idea, would be extensions...

[jesse-94]

@vincentneo Oh, my apologies, I thought I understood that HDOP is available:

That said, both horizontal and vertical dilution of precision (HDOP/VDOP) seems to be available

but rereading it I see that you meant it might be the horizontalAccuracy measure.

I definitely don't want to cause anyone (else?) confusion. If this doesn't seem like a workable idea, we can certainly drop it.

[vincentneo]

@jesse-94 Sorry, I wrote that when I haven't got much of an idea between horizontalAccuracy and HDOP...

But as I said, I see that this idea could be possible if we've made it optional.

[pvezid]

Hi All,

First, I would like to thank you very much for this app ! it is exactly what I was looking for. I am an OpenStreetMap contributor.

I would second @jesse-94 ask to have the precision added when creating a waypoint, for example it could be added to the default name of the waypoint so that the user can reuse it or delete it as he see fit.

I am not sure to understand the issue that prevent this feature to be added. Today, Open GPX Tracker is showing a precision at the top of the screen (with some colored bars), wouldn't it be possible to add that info to the default waypoint name (a timestamp) when the user is creating it ?