Jump to content

Display found mystery caches at corrected coordinates


gasbottle
Followers 1

Recommended Posts

With the changes to the apps and web site recently I find I have a problem:

Caches with corrected coordinates only display at those coordinates while I haven't found them. Once I do find them they revert to displaying at the posted coordinates.

How can I display those mystery and multi caches I've found at the corrected coordinates?

This used to be the norm for the search map, but now I can find no way to do it, and when scouting for locations for new caches it's useful to know where the existing ones are.

I suspect the answer to this is "You' can't", in which case my question becomes "How do we get this changed?"

 

 

Link to comment

I have started this same topic some days ago here without any response. Maybe there is just so small number of geocachers who needs corrected coordinates that it does not matter at all. Anyone who is skillful enough will certainly be able to solve this problem himself, for example by buying or programming their own application that shows caches at the right place.

Edited by arisoft
Link to comment

The frustrating thing here is that the Search map on the web site used to do exactly this, while the Play map displayed posted coordinates. Somehow, during the drive to 'improve' things functionality is getting discarded in favour of, what?

The systems used to do it; the data is all there; the choice was available. How is this new idea better?

 

  • Upvote 2
Link to comment

You didn't specify what app your are having issues with, but If you are using Cachly, You can set a waypoint to "is corrected coordinates" and it stays there after you have found it. You can also have it show the 500ft circle around the corrected coordinate. As a temporary work around, you can always enter the know coordinates of a cache that may be too close and use google maps to measure the distance to the location you want to hide a cache.

Link to comment

GDAK also shows caches at their corrected coordinates. On the PC GSAK shows the "?" at the corrected coordinates and another icon on the original bogus.

With a few 100 solved mysteries in my database I want to know where I can find them, not some random location with no or little connection to the cache.

Link to comment
18 hours ago, gasbottle said:

....

Caches with corrected coordinates only display at those coordinates while I haven't found them. Once I do find them they revert to displaying at the posted coordinates.

How can I display those mystery and multi caches I've found at the corrected coordinates?

This used to be the norm for the search map, but now I can find no way to do it, and when scouting for locations for new caches it's useful to know where the existing ones are.

I suspect the answer to this is "You' can't", in which case my question becomes "How do we get this changed?"

I believe the reason for that is geo-art.  After you find them, they revert back to the "art" coordinates.  Personally, I'd prefer that they retain the solved location, same as you. But then a lot of folks like seeing the geo-art shape. A preferences setting for this in our profile would be nice.  But until they do something like that, this is the way it is now.

Link to comment
2 hours ago, AB&JB said:

You didn't specify what app your are having issues with, but If you are using Cachly, You can set a waypoint to "is corrected coordinates" and it stays there after you have found it. You can also have it show the 500ft circle around the corrected coordinate. As a temporary work around, you can always enter the know coordinates of a cache that may be too close and use google maps to measure the distance to the location you want to hide a cache.

With regard to how the mystery caches are displayed, the web site and the official Android app are both the same now. I don't have any Apple gear so Cachly is not an option. I could look at GSAK again but I've never found it useful.

The real issue here is that I didn't need any of this before because the official tools did what I needed. Now they don't and I don't understand what philosophy has led to an 'improvement' that discards functionality.

 

Link to comment
41 minutes ago, JohnCNA said:

I believe the reason for that is geo-art.  After you find them, they revert back to the "art" coordinates.

I doubt I'll ever create a geo-art series, but if I did, I think I'd make a point of using the posted coordinates to create one picture, and the solved coordinates to create a different picture.

  • Upvote 1
Link to comment
59 minutes ago, niraD said:

I doubt I'll ever create a geo-art series, but if I did, I think I'd make a point of using the posted coordinates to create one picture, and the solved coordinates to create a different picture.

Double challenge.  Interesting.

Link to comment
On 8/9/2017 at 4:00 PM, gasbottle said:

Caches with corrected coordinates only display at those coordinates while I haven't found them. Once I do find them they revert to displaying at the posted coordinates.

How can I display those mystery and multi caches I've found at the corrected coordinates?

You are correct that it's currently not an option.  I mentioned in the original Release Notes thread about this feature that a toggle option for corrected coords could be a good option.

  • ON = caches with corrected coords show at corrected locations, with puzzle icons - all other caches show at posted coords with standard cache icons
  • OFF = all caches show at their posted coords, with standard cache icons

 

On 8/10/2017 at 5:02 AM, arisoft said:

For someone who does not geocache, it may seem like a natural solution.

Could someone who needs this feature clarify when this is needed? Please!

I think it's great that icons show at their posted coords sometimes and at their corrected coords at other times  As the OP mentioned, there used to be a way to see both posted and solved coords, although you'd have to use multiple windows (one using the browsing map, the other mapping search results).

Here are some cases when using one, or the other, matters:

(1) When searching for a cache or planning a caching route - want to see corrected location

(2) When planning a hide - want to see corrected coords to avoid hiding too close

(3) When planning a hide - want to see posted coords to avoid overlapping icons

(4) When looking at GeoArt - want to see posted coords

 

  • Upvote 1
Link to comment

Although this thread is a little stale now I really wish the issue raised by the OP would get solved. Although using the search function used to show corrected coords as an acceptable (albeit clunky) workaround before the fact that this is now disabled is a major inconvenience. Personally I don't care where the posted coords are (geo art be damned) I just want to know where the caches are. I don't stop caring where they are just because I've found them. When placing caches this is an extremely important visualization tool. The live view "simply" needs an option to show corrected coords or not.

For now I've been using project-gc's live view instead of geocaching (the former is not as good or as fast and is prone to showing the wrong thing sometimes). I use c:cgeo on my Android phone which is great for showing me where things are (including other waypoints) in the field but on the geocaching web site things are... lacking.

Link to comment
28 minutes ago, Gill & Tony said:

Geo-art should be displayed at posted coordinates, other caches at corrected coordinates.

A simple tick box when setting corrected coordinates would fix this.  "Display at corrected coordinates? Yes or no."

Geo art is interesting for the artist only and when the artist uses corrected coordinates for cache maintenance then the artist is the only one, who will not ever see the art at all, as the artist is not going to find any of them. Can someone explain to whom this feature is really intented?

Link to comment
41 minutes ago, arisoft said:

Geo art is interesting for the artist only and when the artist uses corrected coordinates for cache maintenance then the artist is the only one, who will not ever see the art at all, as the artist is not going to find any of them. Can someone explain to whom this feature is really intented?

I don't understand the point you are making.  As a finder of geo-art I would like to see my smiley faces forming the image.  As a finder of a normal puzzle I would like to see where i actually found the cache.  I would, therefore, like the option, on a cache-by-cache basis, to say where the smiley face is to be displayed.  Unfound caches should always display at corrected coordinates for route-planning purposes.

Link to comment
1 hour ago, Gill & Tony said:

I don't understand the point you are making.  As a finder of geo-art I would like to see my smiley faces forming the image.  As a finder of a normal puzzle I would like to see where i actually found the cache.

If you count how many geo-artistic puzzles you have found and compare this to the number of ordinary puzzles you have found. Which of these is more important? For example I have found 1789 mystery caches and I think that only 10-20 of them are part of some geo-art.

The previous solution was best for me. Standard map displayed the posted coordinates (easier for servers) and filtered map showed corrected coordinates.

Edited by arisoft
Link to comment
7 minutes ago, Gill & Tony said:

Even if I have only found one geo-art series (and I am in the middle of my first) I would want found caches to show the image.  

Maybe the best solution is for the standard map to be configurable according to the flag I suggested, but the filtered map to show corrected always.

Now we have the same idea. One map shows posted and another map shows corrected coordinates. System worked this way until get broken.

Link to comment
On 10/29/2017 at 5:58 AM, Gill & Tony said:

I don't understand the point you are making.  As a finder of geo-art I would like to see my smiley faces forming the image.  As a finder of a normal puzzle I would like to see where i actually found the cache.  I would, therefore, like the option, on a cache-by-cache basis, to say where the smiley face is to be displayed.  Unfound caches should always display at corrected coordinates for route-planning purposes.

From a cache hiders point of view, having the solved and found puzzles in geo-art show at he location where the cache is actually located  helps in finding spots for their own hides.  Keep in mind that adding the ability for a geocacher to choose whether the icon should be placed at the published or solved location means that an extra field would have to be added to a database table so that every find can be tracked. It also would require changes to the UI and the code that reads/saves that data.  

Link to comment

As a GSAK user this is a non issue. I have two databases with my founds, One has all info, corrected coordinates, found info, found WPs.. in short, all that was necessary to get to the cache. The other is populated by the myfinds PQ. As I never use corrected coordinates on the website I can see all caches at their published coordinates if I want to in one database or see all caches and their WPs at the real coordinates (+ bogus coordinates) in the other.

 

 

Link to comment
9 hours ago, NYPaddleCacher said:

Keep in mind that adding the ability for a geocacher to choose whether the icon should be placed at the published or solved location means that an extra field would have to be added to a database table so that every find can be tracked. It also would require changes to the UI and the code that reads/saves that data.  

I am aware that an extra flag would be needed in the database.  However, every database that I designed had a bunch of redundant fields waiting to be needed so it was just a case of giving one field a meaningful name in the source file.  Since this is only an on/off switch even one spare bit in an existing flag field would be enough.  If their DB designers have allowed for this, only source changes are necessary.

Link to comment
26 minutes ago, The A-Team said:

or... rather than worry about changes to the database, why not just* add a toggle on the map to switch between posted and corrected coordinates?

 

*I'm not saying this would necessarily be simple to implement, but it's the cleanest solution

Yes. I only need the corrected coordinates of solved caches when I wish to draw a circle around them to check spacing on new hides. I can see my geo-art (which I have none) until I need to hide a cache near a solved puzzle..

Link to comment
19 hours ago, Gill & Tony said:
On 10/30/2017 at 6:27 AM, NYPaddleCacher said:

Keep in mind that adding the ability for a geocacher to choose whether the icon should be placed at the published or solved location means that an extra field would have to be added to a database table so that every find can be tracked. It also would require changes to the UI and the code that reads/saves that data.  

I am aware that an extra flag would be needed in the database.  However, every database that I designed had a bunch of redundant fields waiting to be needed so it was just a case of giving one field a meaningful name in the source file.

Really? I've been programming with databases for over 30 years and I've never created redundant fields.  It seems to me that it would just confuse someone that took over the project wondering what those extra fields are for.  It's easy enough to alter the database table *when necessary* and update the data access layer at the same time.  

Link to comment
6 hours ago, NYPaddleCacher said:

Really? I've been programming with databases for over 30 years and I've never created redundant fields.  It seems to me that it would just confuse someone that took over the project wondering what those extra fields are for.  It's easy enough to alter the database table *when necessary* and update the data access layer at the same time.  

Redundant was the wrong word.  Spare, extra or unnecessary would have been better choices.  The idea goes back to the early 70's, using languages such as COBOL and PL/1.  Unlike .db3 files, where multiple tables are contained in a single data file, each "table" was a separate physical file on disk and each file had a source-code file definition which was included into the program at compile time.

If you wanted to add a field to a file you had to make a copy of the include file, add the new field, write a program to read the old file according to the old include format and write the new version of the file according to the new format.  Then rename everything.  This might happen many times during development. Once the new version of the system was ready to go into production, you had to repeat each step on the production database (of course, you would combine multiple changes to one file into one step).   Remember that computers, disk access times and data transfer rates were very slow by modern standards.  One conversion I was involved in could only be done at Easter, where Friday and Monday were both public holidays because it was scheduled to take 80+ hours and we needed a 4 day period with no production system. 

If, on the other hand, when the file was first created, you added a half-a-dozen spare numeric fields and 100 bytes of text field which were not needed initially, you could call them SPARE001, SPARE002 etc.  Now adding a field to the file is simply a matter of getting the include file and renaming one of the numeric fields or breaking the text field into two parts.  Next time any program is compiled the include file has the new field ready to go.

I know almost nothing about the internal structure of a .db3 file (or any other modern database) but I would be surprised if that technique would not help.

 

Link to comment

I expect that the finds table is relatively huge thanks to Alamogul. If the table structure is such that running an ALTER locks the table then Groundspeak would put the hamster up and take the site down for a couple hours. 80 hours wouldn't be needed. This isn't relevant as Groundspeak doesn't need our database schema advice.

Or, just put a toggle on the map so we can see the map one way or the other on demand.

Link to comment
47 minutes ago, fbingha said:

Or, just put a toggle on the map so we can see the map one way or the other on demand.

This seems like the cleanest approach from a UI perspective too. I think allowing each puzzle cache to be toggled independently is just asking for confusion.

Link to comment

Agreed on the 'toggle' option.  I've mentioned it a couple times already:

On 8/11/2017 at 9:09 AM, noncentric said:

I mentioned in the original Release Notes thread about this feature [solved coords] that a toggle option for corrected coords could be a good option.

  • ON = caches with corrected coords show at corrected locations, with puzzle icons - all other caches show at posted coords with standard cache icons
  • OFF = all caches [whether solved or not] show at their posted coords, with standard cache icons

 

I hope TPTB are still open to adjusting some of the new features that were released, based on the community's continued feedbac, rather than moving on to the next thing without looking back.

Link to comment
10 hours ago, Gill & Tony said:

I know almost nothing about the internal structure of a .db3 file (or any other modern database) but I would be surprised if that technique would not help.

I can only speak from my own experience, but including 'extra' fields in database tables 'just in case' they become necessary later on is not standard practice when creating modern databases.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Followers 1
×
×
  • Create New...