Return to Project-GC

Welcome to Project-GC Q&A. Ask questions and get answers from other Project-GC users.

If you get a good answer, click the checkbox on the left to select it as the best answer.

Upvote answers or questions that have helped you.

If you don't get clear answers, edit your question to make it clearer.

+5 votes


I have idea for useful extension of the page

  1. Owner throw OM (Owner Maintenance) log size of a new logbook.

For example owner wrote: New logbook {200} was inserted. Happy caching.

  1. Project-gc calculates FI (Found It) logs for such marked cache.
  2. In the NeedsMaintenance reports the cache, if the number of free logbook position approaches to zero (probably border for 10 free log will be better).

What is your opinion? I think it's simple and useful.

Based on history it might even be possible to predict the date when the logbook go out (+/- of course). But it is perhaps unnecessary luxury.



in Feature requests by Dratenik (170 points)
As Domino_67, I think it is not a bad idea.
But an other "problem" is the geocachers who geocache with friends by using a Team name. So, ten players can log the cache (on but just one place on the logbook was used !

7 Answers

+2 votes
except cases mentined above (stamps, stickers, big letters) is there also problem of group logging where group uses one nick but on web is logged 3+ FI from different geocachers
by drobec (4.5k points)
edited by drobec
+1 vote
Indeed, in theory this should work but the problem I see is that frequently it is difficult to predict how many log entries are possible:

- the log book may be a standard booklet without pre-defined fields (or clean pages at all)

- even if there are pre-defined fields, logs can vary in size significantly

- sometimes even a large number of available entries can get used (when there is an event nearby for example) when by empty field count it would have been expected to last for another six months or so

- sometimes a log get dirty or damaged.

Not a bad idea but I would not put this on the top of my list.
by Domino_67 (6.8k points)
+1 vote
The idea is as old as geocaching i think. ;-)

But it would not work, because there are too many users, that cannot use the backside of a page, or users that use stamps or stickers way too big for one log entry.

And then there are the ones that do not log online. They do exist! :-)
by NoobNader (Expert) (15.9k points)
+1 vote
As people have already said, I don't think it's useful to state the number of expected logs in the log book since a log may take up too much space (stamps, stickers, etc) or less space (several cachers logging with a team name).

What would be useful, though, is if the "Needs Maintenance" page could report on a separate tab how many Found logs each of my caches have received since my last Owner Maintenance log (or publication, if there are none). When I replace full logs I write an OM log. If I visit one of my caches and don't replace the log I try to write an OM log anyway to note the status so that I know later how full the log was.
by pinkunicorn (Moderator) (176k points)
+1 vote
Apart from the issues mentioned already, what puzzles me over and over again is why people often leave e.g. half a page empty. Even in logbooks with predefined spaces things tend to get messy because some colleagues rather start a new page than use the next available space. You then have the choice between adding your name after the last log wasting sometimes a lot of space or break the chronological order of logs by using one of those spaces others have jumped. Both are not really satisfying. And why people are reluctant to use both sides of the paper is also a constant source of bewilderment ... :-)
by k+gw+a (12.6k points)
0 votes
Love the theory on this one but as with others I tend to agree that there may be too many variable to be able to maintain accuracy.
by NSCR (4.5k points)
0 votes
Hi :o)

basically a good idea, but the problem I see is: A lot of Geocachers use a stamp for logging, which mostly needs more than one log line :o(


by wottles (1.8k points)