Update multi coords from start to final after finding.

[+Hidey-Rob]

I have used the pencil function on the website cache page to update multi coords from start location to final location after finding, and the coords have updated ok. I have then used the website to do a Pocket Query and loaded the result to my GPSr, and the icon has correctly moved from the start location to the final location on the GPSr map. However, the maps on the website and the app still show the icon at the start location. This was done a few days ago, and I have checked again today just in case there is a time lag in the updates of the maps, and I have also tried logging off and back onto the website and the app, but they still display the icon at the start location. Is there something else I have to do to get the change to happen on the website and app maps, or is this a known problem or correct functionality that we have to live with?

 

Thanks,

Rob

[+IceColdUK]

Corrected coordinates revert to posted coords once a cache had been found.  The reason (mostly) given is to preserve Geoart.  There have been a number of requests to alter this behaviour, or to provide a toggle function.  I guess it’s on the list...

[+Isonzo Karst]

edit, IceColdUK was typing the same time I was, saying the same thing.  What you're seeing is expected behavior

Edited January 13, 2020 by Isonzo Karst

[+Max and 99]

1 hour ago, Hidey-Rob said:

is this a known problem or correct functionality that we have to live with?

 

It's something we have to live with, for now at least.

[+Hidey-Rob]

Thanks for the replies. I actually found and logged the multi caches ages ago, so I am surprised that if your responses are correct, that the recent PQ following changing the coords on the website a few days ago resulted in the GPSr moving the icons to the final positions on its map, as this was soley as a result of changing the coords on the website, doing the PQ and copying the PQ result to the GPSr ..... I made no direct changes on the GPSr.

 

Following receipt of your replies, I have re-run the test, with exactly the same results, the updated coords are retained by the website, but not updated on the website map or the app map, but they are passed to all subsequent PQs and therefore the icons are displayed at the final coords on the GPSr map. It would have been nice to have all the maps in sync, but at least having the icons in the final positions on the GPSr means they are easier to avoid when deploying new caches. Up until now, I have been saving these positions as separate waypoints, but letting the website do it for me saves me the extra overhead, and I also no longer have an icon at the start position which I have to remember I can ignore and even deploy at. I still have to ensure the final location has not been moved since I updated it though, although this rarely seems to happen. Hopefully the programmers won't read this and block the PQ update, to bring everything into line, but at least I could still fall back to my waypoints again.

 

Rob

[+arisoft]

18 hours ago, Isonzo Karst said:

What you're seeing is expected behavior

 

Not expected but the actual behaviour.

[+arisoft]

2 hours ago, Hidey-Rob said:

Thanks for the replies. I actually found and logged the multi caches ages ago, so I am surprised that if your responses are correct, that the recent PQ following changing the coords on the website a few days ago resulted in the GPSr moving the icons to the final positions on its map, as this was soley as a result of changing the coords on the website, doing the PQ and copying the PQ result to the GPSr ..... I made no direct changes on the GPSr.

 

To confuse you more, PQ works as expected (At least "My Finds" PQ). It is only the map which is failing expectations.

Edited January 14, 2020 by arisoft

[+Hidey-Rob]

Not confused, that was my conclusion as well. I just wondered why none of the other maps kept is sync, particularly as the help files specifically say they do keep in sync, so one could say the help files need updating. I was hoping the help files were correct and I was missing something, but unfortunately for us all, it is the functionality and the help files that are wrong. What we used to call a BUG, later became a DESIGN FAULT, and now programmers are two a penny (cent), anything goes, and very little is tested!! Glad I am not doing all the programming and taking all the flack though!!

[+arisoft]

2 minutes ago, Hidey-Rob said:

What we used to call a BUG, later became a DESIGN FAULT,

 

It is not a bug. Originally the search map worked as expected. Then it was streamlined to show these unexpected results. And then, for a short period after the streamlining, there was a bug that made it work as expected. The bug was fixed very quickly. I suppose that the actual unexpected behaviour is strictly intended.

[+Isonzo Karst]

I think this is intended behavior, as IceColdUK posted, largely to preserve GeoArt. 

For the most part, the site (and the app) is built around the expectations and needs of finders, not of hiders.   

 

 

[+Hidey-Rob]

Ah ok, perhaps just a bit of a documentation update is required, so that users know what is supposed to happen, rather than have unfulfilled expectations. I keep a waypoint file which has finals where I can't deploy, and starting points where I can deploy, each with the proximity zone around them, so this workaround has been in use for about 5 years, and I was hoping to simplify things, and still can as the PQ works, which is great as I always deploy using the GPSr. 

 

Have fun everyone,

Rob

[+Hidey-Rob]

Thanks Isonzo Karst. It is a shame the powers that be seem to always put the finders before the hiders. Not much of a hobby, or business, without hiders though!!