Release Notes (Website: Coordinate entry and parsing experience)

[+Geocaching HQ]

Release Notes (Website: Coordinate entry and parsing experience)

 

This release addresses ongoing community feedback that inaccurate coordinates are an obstacle to a positive game experience, both for cache hiders and finders.

 

This latest web release improves the following experiences:

• The cache submission process
• The cache edit page
• The Update Coordinates log type

 

Going forward, these experiences will provide a consistent experience. The updates include:

• New tooltip with education about coordinate formats
• Coordinate entry:
  • Single coordinate entry field.
  • Improved coordinate parser to process player inputs.
  • Improved coordinate parsing for cardinal directions in languages supported on the website (when the cardinal direction abbreviations match the language selected on the website).
  • New reference display of the original coordinates entered by the cache owner: 
    • If the cache owner enters valid coordinates but they have to be parsed to match the site’s DDM format, we will now display those original coordinates underneath the coordinate entry field, as a reference. The coordinate entry field will display the translated DDM format.
• Map and red proximity circles:
  • The Update Coordinate log page now displays a map.
  • Red proximity circles have been added on the cache edit page and Update Coordinates log maps.
  • On the typelocation page, caches with multiple waypoints now always display a legend for map pin type.
  • New buttons on the map:
    • Zoom control 
    • Center map pins: zoom in on and center the pin(s) on the map, whether it is a single map pin or a cache with multiple waypoint pins.
• Alerts and error updates
  • Updated copy and styling for alerts and errors to increase clarity.
  • Additional error and alert handling for geographic and guideline conflicts:
    • "Locations within a red circle do not meet the minimum distance required between physical waypoints and aren't available."
    • "Waypoint matches the posted coordinates."
    • "These coordinates are far away from your home location."
    • "New coordinates match the current ones."
    • "Please enter more precise coordinates. Coordinate precision increases when there are more decimal places." 
• On Cache Edit page—waypoints
  • Updated labeling 
  • Clearer delete option 
• Accessibility improvements

 

 

 

 

 

 

 

 

 

 

Please see this Help Center section for more details about coordinate formats. 
 
Erin (Oceansazul) is watching this thread to answer questions whenever possible.
 

Any posts in this thread should relate to features in this release. Comments unrelated to the release may be removed. Please direct unrelated comments to other appropriate threads. Thanks!

[+brendan714]

This is great, but in my opinion it does not address the core fundamental issue of inaccurate coordinates on geocache hides. I strongly believe the majority of the issues with inaccurate coordinates (for new caches hidden by new hiders) stems from poor coordinate readings, not a misunderstanding of coordinate formats.

 

I think it would be extremely beneficial to have a built-in coordinate averaging tool in the official Geocaching App to help owners collect accurate coordinates for their hides.  This tool (which should be relatively simple to design, I would think) could include a suggestion of averaging coordinates for, say, a minimum of 5 minutes to confirm the location. Coordinate averaging leads to MUCH better coordinate accuracy, in my experience. 

 

Is it even understood how the average new hider collects coordinates for a new hide?  Are they simply taking a single coordinate point from where they are standing from some random GPS app (I bet they are)?  If so, that is obviously going to result in inaccurate coordinates.  

 

Poor coordinates on new cache hides continues to be one of the most frustrating issues in Geocaching.  Having a simple and effective way of accurately measuring and recording coordinates would go a long way to improving the game. 

[+thebruce0]

I wish I could remember where the discussion was on the net that addressed this, but IIRC, at least on iphones, 'gps averaging' is already done in the operating system. Apps that do their own averaging are effectively being redundant. So while it doesn't hurt, it's not really adding anything to the process of attaining accurate coordinates than what already exists.  Apps 'poll' the gps to attain the current reading from the OS. It's not like the reading the app receives is a raw, straightforward set of values. They're already calculated and averaged based on the OS's currently set period of GPS reception. IIRC an app can request a higher priority of attaining GPS readings for faster/better use, but that's as far as it goes. Even satellite count reading isn't available to apps - they estimate and calculate based on the gps data it receives (which doesn't include satellite count). 

Maybe that's changed in a recent update... but that's what I've come to understand from these discussions for Apple devices over the years. 

 

So, if the official app were to implement some way of encouraging better coordinate attaining by the user, I might rather suggest that the app do a bit of forced "wait for it" for a minute or few, providing the estimated accuracy and perhaps showing the current location 'wobble' while the app pings the device GPS. Recommend a suggested accuracy (or even deny using a reading that's above a threshold). I've seen apps and websites (even Wherigo does this) display the location and accuracy range with regular updates as the GPS is polled. Green accuracy is 'sufficient' and red is.. well, awful.

[+barefootjeff]

On 5/13/2024 at 4:12 PM, thebruce0 said:

I wish I could remember where the discussion was on the net that addressed this, but IIRC, at least on iphones, 'gps averaging' is already done in the operating system. Apps that do their own averaging are effectively being redundant. So while it doesn't hurt, it's not really adding anything to the process of attaining accurate coordinates than what already exists.  Apps 'poll' the gps to attain the current reading from the OS. It's not like the reading the app receives is a raw, straightforward set of values. They're already calculated and averaged based on the OS's currently set period of GPS reception. IIRC an app can request a higher priority of attaining GPS readings for faster/better use, but that's as far as it goes. Even satellite count reading isn't available to apps - they estimate and calculate based on the gps data it receives (which doesn't include satellite count). 

Maybe that's changed in a recent update... but that's what I've come to understand from these discussions for Apple devices over the years.

 

That might well be true, but any averaging the phone's OS is doing would have to be reasonably short term, at most over tens of seconds, otherwise there would be an unacceptable time lag between the displayed position and where you actually are now. For example, if it was averaging over 10 minutes, that average would be centred around where it was 5 minutes ago.

 

The suggested way of taking coordinates in the official app is to add a waypoint to an existing cache. The displayed "Current position" field when doing that doesn't update, though, it's just a static value that the app obtained when the + on the waypoints screen was tapped.

 

I can walk around over a considerable distance while displaying that screen and the "Current location" coordinates don't change. To update it, I have to tap the back arrow and then the + to add another waypoint.

 

To see your position in real time, you can go to the Navigate screen in compass view, which appears to update every second or so, but you can't capture the location from that screen, other than by taking a screenshot or writing it down in a notepad, I suppose.

 

Either way, the upshot is that this recommended way of taking coordinates in the app encourages just taking a single reading, and it's not surprising that coordinates taken in this way are often a considerable distance out.

 

By contrast, on my Garmin I can watch the drunken bee dance over a period of ten or twenty minutes and, once satisfied, can position my marker in the middle of it.

 

 

Something akin to that in the app, where coordinates can be averaged over many minutes either visually or algorithmically (ideally both), would be a boon, I think.

[+brendan714]

On 5/13/2024 at 12:12 AM, thebruce0 said:

Apps that do their own averaging are effectively being redundant. So while it doesn't hurt, it's not really adding anything to the process of attaining accurate coordinates than what already exists.

It is common practice in the GIS industry to use coordinate averaging to obtain more accurate coordinates. Typical procedure for obtaining coordinates for a control point is to take a minimum of 30 epochs (measurements) for averaging, drop initialization (lose satellites), reconnect, then take another 5 epochs to check and confirm accuracy.

 

This method works exactly the same for casual measurements taken by geocachers - taking a single point measurement on your phone will never be as reliable as an averaged set of data. 

 

This is anecdotally true, based on the "drunken bee" dance of coordinates as mentioned by @barefootjeff. Anyone who has tried searching for a cache should know this already - the compass and your location always jumps around at GZ. Averaging a wide set of data will always be better. It would be simple enough for Geocaching to build a tool to do this (there are several free apps available for Android and IOS) to help geocachers collect more accurate coordinates.

 

I also agree that the current Geocaching app very much promotes a single point measurement (as mentioned lower down in the link below for how to take coordinates on the App - I think we can do much better!). 

https://www.geocaching.com/help/index.php?pg=kb.chapter&id=128&pgid=673

 

Geocaching does think coordinate averaging is a good idea, but who is really going to do it by hand? It would be way better to provide a simple and effective tool that automatically averages for more accurate and reliable coords. 

Edited May 15 by brendan714

[+thebruce0]

3 hours ago, brendan714 said:

On 5/13/2024 at 2:12 AM, thebruce0 said:

Apps that do their own averaging are effectively being redundant. So while it doesn't hurt, it's not really adding anything to the process of attaining accurate coordinates than what already exists.

It is common practice in the GIS industry to use coordinate averaging to obtain more accurate coordinates. Typical procedure for obtaining coordinates for a control point is to take a minimum of 30 epochs (measurements) for averaging, drop initialization (lose satellites), reconnect, then take another 5 epochs to check and confirm accuracy.

I was referring to iPhone apps, running on iOS, which already does gps averaging while the gps functionality is active, so having an app do averaging manually on its own would be redundant. I know gps averaging is used in professional environments for more accurate coordinates.

 

3 hours ago, brendan714 said:

This is anecdotally true, based on the "drunken bee" dance of coordinates as mentioned by @barefootjeff. Anyone who has tried searching for a cache should know this already - the compass and your location always jumps around at GZ.

The analog to iOS already averaging gps readings would be that the average centerpoint is 'dancing' just as much as if you were watching the pin in the app on iOS. At best, redundant averaging gives more data points, but the result generally won't be any better. If you visually take the centerpoint, you're just effectively altering a parameter, like the window of time to average readings, or the quantity of points in a set amount of time. If you physically move, it's all thrown out the window again anyway. Smartphones, iPhones at least, last I researched this, don't provide the same high level access to GPS data for sandboxed apps. The apps can only provide to the user as much data as the OS gives it, with perhaps some more analysis. But the app isn't getting any 'better' data by analyzing the data it gets. It's just averaging an average, like copying and copy; and at that point it's just averages all the way down.   One way to visualize it might be when you turn on the gps and you watch the pin dance around closer to your location and the accuracy bubble shrinks - that honing of the location is the effect of the gps averaging already happening at a higher level in the background, and the OS telling the app its results. AFAIK the OS doesn't simply send raw gps readings to any app that requests it, it provides its current 'best calculation' by polling the hardware and providing the periodically calculated results. The app may control how frequently the OS obtains that data from the gps, but it doesn't get raw gps data.

I'd be happy to learn if that's no longer the case on iOS.  Maybe Nic who developed Cachly would have some recent input on the matter of gps data access on iOS, for example.  

 

All that said, there is certainly no harm in having an app do additional gps averaging. Nor for the holder to manually average location readings or do the dance physically around the centerpoint and estimate an average reading from that process (it can be like giving the hardware a nudge).  But (since my last research) the phone is already providing the best gps readings to apps that the OS will allow, save for telling the OS to do more intense/faster polling of the gps hardware which is a bigger battery drain.

 

But that's why I say one improvement would be for the app to clearly indicate the phone's current coordinates and calculated accuracy, and only allow using those coordinates when it's down to within a reasonable range, knowing that's based on the OS already averaging its gps readings; even show the overhead 'dance' to indicate where the phone thinks it is on the map. If it doesn't get to the needed accuracy, then don't allow the app to create a listing (or perhaps override the limit if specific coordinates would be entered).

 

ETA: found a post I linked to a relevant discussion (re satellite count and gps data access)

On 2/2/2024 at 10:51 AM, thebruce0 said:

To followup - it's confirmed still recently that iOS apps do not have detailed access to satellite info, and any apps that show things like "satellite count" are estimating and 'guesstimating' based on the information that the API from the OS provides. This thread talks a bit about whether apps can access such data (and even mentions the aforementioned diagnostic app). There isn't yet a response from the user who said he'd ask the developer how they managed to provide the satellite count value if by some other indirect means.  Without having a jailbroken phone, I don't think Apple would knowingly permit a 'loophole' around something they seem extremely closed about since iPhone first introduced GPS capability.  Likewise, other apps for years have shown a 'satellite count' pseudo variable based on estimations from other gps readings, not based on a hard actual number provided by the device's OS.

 

ETA2: Here's a blog post talking about higher tech specs in iphone 14 and a point about gps data access on apps he was testing with:

"Because the retrieval and initial processing of GPS data is handled by the iPhone's hardware and iOS, developer's don't need to update their apps to support dual-frequency GPS, they essentially benefit from it for free."

Edited May 15 by thebruce0

[+barefootjeff]

27 minutes ago, thebruce0 said:

I was referring to iPhone apps, running on iOS, which already does gps averaging while the gps functionality is active, so having an app do averaging manually on its own would be redundant. I know gps averaging is used in professional environments for more accurate coordinates.

 

As I said earlier, the phone OS's averaging can only be short term averaging otherwise there'd be a considerable lag between where the phone actually is and where the average puts it. For cache placement, though, you need to average for more than a few seconds or even tens of seconds, because (depending on the location) there can be considerable wander over the course of tens of minutes. That drunken bee dance screenshot I posted earlier was taken over about a ten minute period, during which time it slowly traced out the zigzag path shown. A phone OS that's averaging over five or ten seconds won't remove that slow wander.

 

For my own coordinates, I'll watch my position wander around over the course of 20 to 30 minutes and place my marker in the centre of that. Then I always confirm them on a different day to when I first took them, typically after I finish making the cache and go back to place it. If there's a discrepency of more than a few metres, I'll return again on multiple days and ultimately use an average of those (and make the hint pretty explicit too).

Edited May 15 by barefootjeff

[+thebruce0]

1 minute ago, barefootjeff said:

As I said earlier, the phone OS's averaging can only be short term averaging otherwise there'd be a considerable lag between where the phone actually is and where the average puts it.

If you move, everything is out the window. So lets assume the phone did not move while you're averaging a single location. There's no 'lag', since the app receives the most recent possible GPS coordinate calculation from the OS that it can obtain from the GPS hardware provision.

 

2 minutes ago, barefootjeff said:

A phone OS that's averaging over five or ten seconds won't remove that slow wander.

It seriously depends on which phone you're looking at. My gps 'dance' never really improves over more than maybe 20-30 seconds tops. And that's in rough conditions. Staring at the screen that long would not provide any more accurate a location, just a big cloud of dancing around the same location.  The phone weeds out the outliers and random jumps doing all the averaging behind the scenes before the app even gets it.

 

4 minutes ago, barefootjeff said:

For my own coordinates, I always confirm them on a different day to when I first took them, typically after I finish making the cache and go back to place it. If there's a discrepency of more than a few metres, I'll return again on multiple days and ultimately use an average of those (and make the hint pretty explicit too).

I think this tends to be a holdover (not a bad holdover of course) from the days when there was very little alternate confirmation of location - on smartphones that can be done visually with satellite imagery (apart from misalignment of tiles) especially in areas with lots of detail, and using other networks, even such as A-GPS. Out in the wilderness? Yeah I'd still say for sure make use of the strategies you describe, whether you're on a GPSr or a smartphone.

 

 

Hm. If an algorithm says its best guess at a number is between 5 and 9, and samples to test are all equally somewhere within that range (they defined that range), then averaging upon averaging will only narrow down the centerpoint of that equally possible range of values - you may average all the numbers and infer a result of "7", but it's no more reliable a correct result than 5, 6, 8, or 9.  Now you could tell people to use 7 give or take 2. That 7 is your best chance at being closest to the correct number. But that's a different description of the result.

It's sort of like the issue of geocaching coordinates in DD MM.MMM format having only 3 digits precision and only being accurate to the size of the 1000th minute grid region at any particular latitude. A container could be anywhere, equally, between any of the four corners. A more accurate device won't get you any reliably closer than the coordinates digital 'boundary' rectangle indicates. I'd say that's similar to redundant averaging. At some point the OS says 'I can't get you any more reliably accurate coordinates than these...' and if that's the case, you're doing extra work. No harm in it, and sure it could weed out exceptional mistakes, but as a rule of thumb, if my understanding of the iOS GPS functionality is right, it won't provide any new data to work with (towards a more reliably accurate result).

[+barefootjeff]

27 minutes ago, thebruce0 said:

It's sort of like the issue of geocaching coordinates in DD MM.MMM format having only 3 digits precision and only being accurate to the size of the 1000th minute grid region at any particular latitude. A container could be anywhere, equally, between any of the four corners. A more accurate device won't get you any reliably closer than the coordinates digital 'boundary' rectangle indicates. I'd say that's similar to redundant averaging. At some point the OS says 'I can't get you any more reliably accurate coordinates than these...' and if that's the case, you're doing extra work. No harm in it, and sure it could weed out exceptional mistakes, but as a rule of thumb, if my understanding of the iOS GPS functionality is right, it won't provide any new data to work with (towards a more reliably accurate result).

 

Three decimal places in the minutes corresponds to 1.8 metres on the ground in latitude and something less than that in longitude, depending on how far from the equator you are. If a cache is within a couple of metres that's great, but the sort of problem that opened this discussion is errors an order of magnitude greater than that, often 10, 15, 20 metres or more. This is typically happening (I think) when someone using the app just follows the suggested process of adding a waypoint to an existing cache and that single reading becomes the coordinates they put in their new listing. There's a cache I found earlier in the year (well truth be told I didn't find it, the other cacher who turned up while I was searching did) that was about 13 metres out and was subsequently corrected by the owner. It's not in a difficult location with limited view of the sky, it's on flat open land in amongst playing fields and car parks, so it really should have been possible to get better accuracy than that.

 

I rarely use my phone for caching, but on the odd occasion I have, something I've noticed a few times is that, if I'm stationary for a while, it'll stop updating its position and I have to walk 20 or 30 metres away before it'll suddenly decide I've moved and update my position. I suspect this is a battery-saving thing though I don't know whether it's being done in the app or the phone itself (a Samsung Android), but it's the sort of thing that could easily explain the large errors I see all too frequently on new caches placed by phone users.

 

Surely there has to be a better way of getting decent coordinates in the app beyond just adding a waypoint to an existing cache.

[+arisoft]

4 hours ago, brendan714 said:

Geocaching does think coordinate averaging is a good idea, but who is really going to do it by hand?

 

I do. Previously (years ago) I calculated the avarage on a spreadsheet, but I have developed a better and quicker way to average manually. In my opinion, it gives better results.

 

The method is pretty simple. When I measure coordinates, I add a marker in the App for every measured position. This forms a pattern and then I aim in the center of the pattern to record the coordinate as the final. No calculations needed at all. Many times I just turn around GZ several times taking these measurements.

[+thebruce0]

12 minutes ago, barefootjeff said:

Three decimal places in the minutes corresponds to 1.8 metres on the ground in latitude and something less than that in longitude, depending on how far from the equator you are. If a cache is within a couple of metres that's great, but...

Yes, that's what I was describing. But quote:

59 minutes ago, thebruce0 said:

It's sort of like the issue of...

My analogy was about making use of data that's assumed to already be as accurate as it can be. iOS provides its best analysis of the data its gps provides, essentially giving an inferred accurate location to some degree with a margin of error based on the parameters set (ie quantity/speed of polling and time period to calculate avg within). The app doesn't have control over this other than to say less or more, and receive the OS's answer at any one time. Two apps using the same gps hardware will receive via API what the OS (not the gps) tells it.  The OS is the "3-decimal precision" limitation if you will. Keep asking the OS, and you'll get averages that hover within the 'boundary' of its best estimate, what it has calculated from what it reads from the gps on its own.

 

 

17 minutes ago, barefootjeff said:

This is typically happening (I think) when someone using the app just follows the suggested process of adding a waypoint to an existing cache and that single reading becomes the coordinates they put in their new listing.

Right, because the app received a single reading of the OS's GPS reports. And as the time averaging window moves along, resulting in different raw gps points and average calculations, those coordinates will shift and the display will no longer be consistent if the user were to back out to the map or compass. Rather if they were to be shown the 'live' update of the reported gps location, once 'settled', it would seem to hover around a location. So yeah, one recommendation (as I discussed above) is to indicate the current (live) coordinates and estimated accuracy, only allowing coordinate use once the OS reports the accuracy is below a reasonable threshold (which of course could be accompanied by a map visualization of the reading).

I imagine the current 'bubble' accuracy circle to contain all the gps data points the OS received and averaged for its latest poll, resulting in my pin at the center/average of the circle, the collection of points. The app didn't do that, the OS did. But that centerpoint would be equally as accurate as the next averaged location the OS tells my app. And so the next, and the next. If I average all those, I don't get a "more" accurate location, I just get another equally likely location, and a likely less accurate/larger 'bubble'.

 

 

29 minutes ago, barefootjeff said:

I don't know whether it's being done in the app or the phone itself (a Samsung Android)

I can't speak to Android hardware... I can only hope I'm accurate about iPhone hardware.   I need to start developing ios apps...

 

[+brendan714]

12 hours ago, barefootjeff said:

Surely there has to be a better way of getting decent coordinates in the app beyond just adding a waypoint to an existing cache.

100% agree and this is the point.

 

There should be a dedicated tool in the Geocaching App that:

A. Clearly provides instructions on how to obtain coordinates - place your phone down near the cache, leave it for several minutes, don't move, etc

B. Collects/averages/summarizes coordinate data in whatever method is best for your device to provide the most accurate coordinates possible.  Maybe set a built-in countdown timer to let it "cook" for a minute or two (ideally even longer) to ensure you get the best accuracy possible? 

C. Clearly displays and saves the final calculated coordinates.  I'm sure a lot of coordinate issues are due to misread/mistyped errors too.  Make the numbers big and clear.  Not a tiny piece of text in the bottom-left corner of the app (as it currently is). 

 

Within the past week I've searched for 2 brand new hides with poor coordinates. On one cache I later learned that the coordinates were 18m off.  It really takes away from the game.

[Oceansazul]

Thank you for your interest and passion for collecting coordinates. As this feature release is for the website CSP, Cache Edit page, and Update Coordinates log, please direct comments about coordinate averaging to other appropriate threads.

[+PiratencrewDK]

Why comes the Pop-Up Window "These coordinates are far away from your home location." even for already published caches?

[+Toa Ignika]

This example would be better if it was the same point in different formats

[+thebruce0]

On 5/23/2024 at 3:32 PM, Toa Ignika said:

This example would be better if it was the same point in different format

It's actually kind of funny to see You'd think they are different formats of the same coordinate, so it implies that the formats do wonky things to the coordinates!

They should all be the same coordinates, really.  The only numerical differences should be due to the literal conversions between DMS degree values and their decimal equivalents (as that also helps show that you can't just transliterate between degrees and decimal values)

Edited May 27 by thebruce0