the Seagnoid
-
Posts
168 -
Joined
-
Last visited
Posts posted by the Seagnoid
-
-
Yup, I was looking at the default layer, "MapQuest OSM" which still has some of the tracks missing. "OpenStreetMap Default" has the missing tracks included so I guess you are right, A-Team, it is just slow to update. Thanks for the help.
Tom
-
There is a bug somewhere, although I am not sure that it lies with Groundspeak's ability to fix - updates within OpenStreetMap used to replicate into Geocaching's Leaflet maps within a few days, but some changes made over two weeks ago still have not appeared. The maps are still there, so it is obviously working off cached data, but not being refreshed.
For a test example, look at GC60KKZ - it lies on a track, this information is in OpenStreetMap and shows on my cellphone in the geocaching app in my phone, but is not showing on the website.
Some of the tracks in the test area do show - they were added into OpenStreetMap two weeks earlier, and came into Geocaching's map two days after that.
Geocaching bug? Leaflet bug?
Thanks,
Tom
-
Logs of the same type within less than a minute are not necessarily duplicate logs that happen by mistake.
Someone who logs a longer story with more than 2 parts will end up with at least 2 notes. It would be annoying to have these logs deleted
because you and a few others have an issue with some duplicate logs.
A long log with two parts logged as a find would result in a distorted find count. The second should be a write note. However you do have a valid point for long write note or DNF logs. I challenge anyone to write a log that long on a cellphone!
-
You know we are talking about the Groundspeak API don't you? Adding a popup means Groundspeak have to modify the API to return an already found status, and EVERY APPLICATION out there has to be modified to recognise it.
Modifying the API to simply discard a duplicate log is easier, especially as a duplicate log is obviously unintentional.
The API can return that you have found this cache, but that is a separate request from the logging process. Not all logs are found logs, any log type sent from a cellphone could be duplicated.
-
See also:
SUGGESTION: Prevent duplicate finds of same cache for 24 hours.
Feature Request: Sort for Duplicate "Found" entries
FEATURE REQUEST: Warn if logging Found on cache you've already found
Add feature to find duplicate finds
[FEATURE] site will not permit logging Found/Attended more than once on the same cache
Hey Groundspeak! This is obviously a problem!
-
Wasn't quite sure where to place this, under android and iphone didn't seem to quite fit.
There are a growing number of cachers by cellphone out there, and sometimes their caching application does not appear to get a timely reply when performing an online log on the phone, so that they resend the log. This results in a resend and two (or more) identical logs being posted. This is not a problem easily fixed at the application end, as it related to problems with congestion, etc. This also appears to happen with more than just one geocaching application.
Could we have the server ignore a second log for a cache logged by the same person if the second log is the same log type and sent within a minute of the earlier log? That does require that Groundspeak store the time stamp along with the date stamp. One minute should be sufficient to solve this problem without affecting legitimate second logs.
In New Zealand (as in most of the world) we do not have moving caches, so every instance of doubled found logs are screws around with our cache statistics.
Thanks,
Tom
-
I think this is a great idea. Exported GPX files use updated coordinates where they exist, but it would be nice to have a separate icon confirming this.
I get around it by excluding puzzles from my general purpose GPX exports, and using Project-GC to give me my solved puzzles. Of course, this doesn't help for online (smartphone) users.
-
No, it is not. it is a very large question mark, and occurs on caches where the cache size is stated (small, regular) . Incidentally I just refreshed the page, and the question marks are gone. I wonder if it was because the page script was unable to pull the data from the server, and this question mark represents unknown D/T/size.
-
On the Your Caches listing, some of my caches have a grey question mark superimposed over the size and D/T ratings. The size and D/T are specified, so it is not because one or more is unknown. Does anyone know what the question mark means?
Thanks, Tom
-
I like the new page - but how about putting the contour lines back in the green header, would then match the brown trailer
-
I use both but prefer pocket queries and a dedicated GPS. The main reason is that the GPS can be dropped onto rocks or into streams with no damage and that maps still works great even out of cell coverage. (A dedicated GPS needs to have maps installed, otherwise the phone is MUCH better - buy one without maps and add then add them. http://garmin.openstreetmap.nl/ is a good source)
I use the phone when I am racing out for a FTF - just because it saves me 15 minutes.
I take both on trips, using the phone as backup (set to airplane mode to save battery). The phone downloads images which may be needed for some caches, gps usually does not include images.
Another possible advantage with a phone is immediate online logging. I don't use this feature - typing on those screen keyboards is too hard. I take a notebook and log when I get home.
-
"Create a cache" method of identifying needs maint/disabled caches doesn't work - there is nothing to tell me to go and look. Pocket queries work better - I can send myself a pocket query once a week or so, but extracting the cache names out of the query is awkward. I think Groundspeak should make it **VERY** easy for cache owners to identify caches that need maintenance, and I think the Quickview page is the medium best suited for that.
-
Recently I came across a cache of mine that needed maintenance that I had forgotten about. Which made me realise that this is a place where geocaching.com could improve the experience for all geocachers:
Could we please have a list of my caches that need maintenance or are disabled (but not archived) in the Your Pofile > Quickview page. Already on this page is a list of Your Unpublished Disabled Caches, this would be an ideal area to place the list of caches that need some love. Like Your Unpublished Disabled Caches, this needs maintenance/disabled cache list would dissappear if it has no entries.
Yes, I can get this information for other places (my emails, external tools), but that requires me to actively go and look for it. A reminder of the Quickview page would keep these caches in mind, and thus make them less likely to be forgotten about, and thus maintained more quickly.
This would be a simple solution for Groundspeak to improve the uptime of caches, which improves the experience for everyone.
Thanks,
Tom
-
Yep, I am missing out. I drove past about 400 caches last week - I should log them all as finds!
I have had maybe just 10 people log finds on my caches when they didn't. In each case it was accidental. Clicking the usual thing instead of picking the Did Not Find option. I email them and let them know that they accidentally logged it as a find and they change it. It has never been a problem on my caches. I do not allow non finds to be logged as finds.
-
Also sand the plastic with a very coarse sandpaper. This gives the glue a better surface to hold onto.
-
My only peeve about geocaching.com is that it counts Found It logs, not caches, and the support it has for logging more than one Found It log on a cache. Recent changes make it look like the website is actively supporting this method (for those who really like going for the numbers and just want to find the nearby cache every day?)
There were historical reasons why multiple logs on a single cache were allowed, but that does not seem to apply anymore. And now the website has removed the "You have x finds on y unique caches" which alerted me to my accidental double log. Yes, I can get this from other sites, but at least geocaching.com would let me know.
Me, I'd like to see gc.com change to prevent double Found It logging. Existing double logs would stay (historical reasons, remember). And while we are on that topic, deny finds of own caches, which are against the rules yet are allowed. (Okay, there are two peeves!)
I appreciate that it is about how you cache, and that while I don't like the ability to double log, others might.
What do you think?
Tom
-
All emails being sent via the geocaching send mail facility arrives at it destination with noreply@geocaching.com as the from address. However, if we leave "I want to send my email address along with this message" ticked, then the email reply to field is populated withthe senders email address. "noreply" is incorrect, as the email can be replied to.
The point is that currently it is very unintuative. It suggests I cannot reply to this email at all. I cannot tell if I can reply until after I try and I see noreply@geocaching.com as the email address. I should know this BEFORE I try it.
How about use noreply@geocaching.com when the "send email address" is unticked, and use <username>@geocaching.com (with the reply-to field set as the correct email address) when "send email address" is ticked.
Thanks,
Tom
-
Seriously, guys, you are not thinking this through. I appreciate the church micro series is a significant one where you are (England?) but you are asking for an attribute to describe the location, rather than the hide. Let's say you get what you want - the precedent is now set. Next there will be a car park attribute (which is not the same as a park and grab), a railway station attribute, road barrier attribute, bridge attribute, railway-but-not-the station attribute, LPC attribute, park (green space) attribute, supermarket attribute, hardware store attribute, disused road attribute, roadside fence attribute, seat attribute... the list is endless. You are asking for a thousand attributes to be added!
I definatly do NOT support the church micro attribute idea. Better is for Groundspeak to upgrade their SQL backend, to provide full text searching, and for COs of the church micro series to standardise their cache names. And then to allow for searching for a phrase (such as "church") within the title or the description on the Find a Cache screen.
-
In the old days - a year ago? The cache count on the statistics page was reported as Found x caches on y discrete caches.
The problem is that geocaching.com counts Found It logs, not caches. This was due to some earlier caches moving, inviting people to find them again.
So the message Found x caches on y discrete logs was an easy way for me to find that I had accidentally double logged a cache, something that needs fixing. This message is gone - can it be restored please.
Actually, a better solution is to show the finds by cache type stats, both on the my profile page and on the public profile page, to count the actual caches (rather than number of Found It logs) and provide a self explanatory title, eg "Number of discrete caches found: y"
Yes, this information can be found in third party tools, such as Project-GC. I think it is something that Groundspeak should support, especally as moving caches are no longer supported, and multiple Found It logs are now simply errors.
(I also think Geocaching should no longer provide a Found It option on a existing find, or automatically change a new Found It log to a Write Note.)
-
I too would like to see the cache owner's name in a publish log. But...
To clarify what someone else said - the notification is a generic notification. A notification of a new cache is EXACTLY the same template used to notify about a found it log. Thus the reviewer's name is there because that was the person that placed the log.
There are two main options here. Either:
1. Add the cache owner to the template. This means every time you receive a found it log, you will be told what cache it was found on, and that you are the owner. You already know that, I suspect that this will raise change requests to remove the cache owner name!
2. Get rid of the generic log template, and allow for different templates per log type - a publish log uses this template, a found it uses that one, a DNF uses this other one. This is my preferred option, but will require a little work from Groundspeak. They would have to make 20 copies of the existing template, rename them for each log type, then put in a bit of code that appends the log type so that the notification system can find the right template.
-
Apologies, I could not find an GPX forum.
Is it time to start work on version 2 for the geocaching GPX format? This would allow those suggestions that are problematic at the moment.
Features:
1. Require the mobile device to support 15 geocache sizes:
We already want to add nano. The size name would be delivered as part of the GPX download, along with a number marking size order/max sizes, allowing a correct display of the name and/or size graph. The device manufacturer could still limit the displayable text length. eg <SizeName>nano <SizeOrder>1/8 (zero = virtual, 1 = nano, 2 = micro, etc, 8 = not specified). If new sizes are added sizes are reordered to suit.
2. Require the mobile device to support 50 cache types:
Currently there is some discussion about adding "challenges" as a unique cache type. "Labs" is another that might get added. As with cache sizes, deliver the cache type name with the GPX. Maybe dowload a bitmap image of the icon, or allow the device manufacturer to use no/generic icons for caches types it didn't know about. Where possible, the manufacturer should allow the reading of a file to pick up new cache types, so that new types can be added after purchase.
3. Anything else?
In the user profile have a checkbox specifying which GPX version to download - by default the old one. The device manufacturers and the user community will announce when their devices or software upgrades will support the new version.
For the existing GPX format, the new cache sizes will be converted to their nearest equiv, or be flagged as not specified, and new cache types as puzzles.
Come to think of it, if we use new tag fields then we could use the same GPX version, as applications will ignore fields they don't know. However, I suspect this will slow device manufacturers from converting to the new format.
Yes? No? Comments? Brickbats?
-
Actually Groundspeak have a precedent, if that is the right word. There used to be an FTF challenge series where then FTF of a cache was "cursed" until they laid a new cache, and on that cache they would then challenge the FTF to place yet another cache continuing the series.
This is no longer permitted, because, as some above have said, some people are not ready to place a cache, do not want to, and should not feel they are under obligation to do so.
I don't like the idea of any cache encouraging the hiding of additional caches.
-
Or are you no longer saving your cookies? Check your cookie settings.
-
Actually - I like this idea. Ignore the phrase "church micro" - it's irrelevant. Add a field to add "where cache name includes xxxxx" as part of the pocket query parameters. Also, while we are on that, another for "where favourites => x"
map updates not updating
in Website
Posted
The OSM maps used by GC are being updated, but it seems to be a very long time between updates, perhaps six months. To get an up-to-date version (updated within 1/2 hour to a day), click the layers icon in the top right corner of the map, then select OpenStreetMap default. Much better!