w1qa

That's probably accurate ... but its a little beyond the scope of my original post. Please consider giving the NPS GPSguidance policy PDF a quick read (the link for which is in my original post). It is clear that Geocaching and other GPS oriented activities in US National Parks need approval whether or not the location in question is an Earthcache. There's a better explanation in those pages; for me to quote them here would be redundant (and consume quite a bit of space).

Please consider taking a look at the links I provided. It is pretty well spelled out there - and covers anything where you give someone coordinates. The NPS policy document specifically mentions virtual caches, earthcaches and has a link to Waymarking as well. I tried to cover your situation in my original post: if you tell someone to go to a park and take a picture of a feature I don't consider that "geocaching" and is typical of what the land management agency would expect visitors to do. If I tell someone to go to a specific GPS location or follow a trail of GPS waypoints given the NPS documents that would likely require prior approval. (Again - both scenarios under the auspices of Geocachng and not just person to person.) Having successfully placed caches on property where land management approval is needed I think some of the concerns in my original post are valid.

I would like to point out a concern about challenges and the lack of any formal approval for them in areas that currently require land management approvals. The National Park Service (aka NPS) in the US indicates that "Geo-caching activities on national park lands is PROHIBITED, however some activities are permitted under special conditions as determined by the individual park." I'm sure that around the world there are other land management entities that likewise generally prohibit GPS based activities without prior approval. http://www.nps.gov/gis/gps/ http://www.nps.gov/policy/GPSguidance.pdf I recently setup an Earthcache in a large US National Park. This required the approval of the local park official as well as approval from the Geological Society of America. I'm thankful that both the NPS and the Earthcache folks found the new listing worthy of acceptance. With challenges I could create something like: take a photo at Old Faithful or some other location in Yellowstone National Park or do some other activity. While a challenge like taking a picture of Old Faithful is quite generic (and not necessarily GPS based) ... I can easily imagine a challenge that may require me to use my GPS for location assistance, e.g., get to a specific location, follow a specific path, etc. My interpretation would be that many challenges really should have prior land management approval - but there's no basis for that to happen in the way challenges have been implemented. What concerns me more is given the fact that challenges are on / part of the Geocaching web site any land management agency may just consider challenges another form of geocache (which needs prior approvals). The risk? Challenges could result in a land management agency possibly denying previous approvals for caches?! Although I'm concerned mostly about challenges in areas where geocaches would need approvals I think the larger issue is the general lack of challenge approvals. Though I can see the benefits of having the Geocaching community as a whole police challenges (the up/down thing) I wonder if the land management situation was carefully considered in the design of the challenge?

Here is one of the other errors that was received this morning: Microsoft OLE DB Provider for SQL Server error '80004005' [DBNETLIB][ConnectionOpen (PreLoginHandshake()).]General network error. Check your network documentation. /mark/details.asp, line 16

Yes - still - at 09:45 PDT. Although most of the errors returned were server busy errors did see a couple of other ones as well. Leaving shortly for a weekend trip - and all I've got is a map with the cache positions plotted on it (in MapPoint) Was hoping to snag a few caches along the way ... but don't have any info other than the map coordinates, GC waypoint and cache name. Really would like to read-up on a few of these to see if they fit into our travel plans! Let's hope the problem isn't anything too major ...

Hi ... Looking for some assistance with the Where's in a Name cache ... If I understand the algorithm correctly my username (W1QA) results in 92 degrees 12 minutes XX seconds That will leave just east and west ... which should not be a problem, as a north-south line cuts through much of the central US. Here's a list of states and cities that may qualify: AR Little Rock AR Sherwood IA Cedar Falls IA Waterloo LA Lafayette LA Monroe MN Duluth MN Rochester MO Columbia MO Jefferson City WI Superior Feel free to to contact me through the Geocaching site ... and would be glad to help anyone else out with a similar find in my area as well. Bob W1QA

Yes, the VBE file is compiled - so I know of no ways to change it. (I'm also really not too familiar with programming with today's tools - my programming skills are back a couple of decades on old DECSystem-10's and PDP-11's.) This is what's in the start of the VBE file: '**************************************************************** '* * '* This script reads .loc-files from Groundspeak.com and * '* converts them into .csv-files suitable for import into * '* Microsoft Mappoint 2002 * '* * '* Comments, suggestions and error reports are welcome. * '* * '* Per K. Nielsen * '* geocacher -at- pknielsen.dk * '* http://pknielsen.dk/geocaching/ * '* * '* Version 1.5 * '* * '**************************************************************** (I've munged his email address above). I wrote to Per Nielsen some time ago but didn't get any response. I don't think his web presence has been updated at all, either. I'll check out that link you provided and see if that helps!

Some time ago I came up with a very simple system for my own home grown Geocaching (and benchmark) tracking and mapping system. Here's how it worked: - weekly query generates 3282.LOC and 3418.LOC files - LOC2CSV.VBE converted them to CSV files - imported into Microsoft Access - merged inport file into appropriate table (no dupes) - ran a query to identify which caches (or benchmarks) were new My Geocaching Access table had the Latitude, Longitude, Information (URL to cache), Name (GCxxxx), Name2 (cache description) ... and a field called Status which I added to this flat file. The Status field contained values like: Cache (for a cache), Logged (for one I found), New (for one that's been newly imported), Archived, Hidden and Seek. I then use Microsoft MapPoint and link directly to the Access database. MapPoint displays each cache; the cache's icon depends on the status field in the database (different shape, colour, etc.) There's also a similar table for benchmarks ... I used to make all my decisions on caches and benchmarks to seek by working with the MapPoint map: just seems like the logical way to view it! And each cache and benchmark had a clickable URL that would (using the Information field) launch a web browser window for that cache (or benchmark). Sometime in the fall of last year I think something with the LOC files changed ... dropping the .LOC file onto the LOC2CSV programme generates the error: Wrong format. Tells me to open the .loc-file in notepad and verify that the file begins with "<?xml". If it does, please report the error to the author. The .LOC file does: <?xml version="1.0" encoding="ISO-8859-1"?> I sent a message off to the author ... but never heard back. I've searched around - but have not found anything that will convert this .LOC file from my queries to the flat file I'd like ... in order to continue importing to my database. I've looked at a couple of queries generated with the GPX format ... but more infomration and a bit more complicated than what I'm looking for. Specific comments about that: The URL has the very long GUID and not the simple details by 6-character cache or benchmark waypoint name. The description really combines TWO fields: the owner and the cache name Any pointers and suggestions would be greatly appreciated. Although I'd like to keep my simple access database as-is, I'm not against moving to something else ... the main criteria is being able to plot everything in MapPoint (with some ability to indicate what's been found) - and frequently update that information. Thanks in advance for any assistance.

Yea - I'd also say destroyed. This is one of those rare cases where you do have enough / the right information to log a destroyed report with the NGS. And this just gets back to other discussions / threads regarding Geocaching logging choices ... As others have noted: indeed, the Geocaching site should show us ALL the various benchmark log counts we have, not just "found". The Geocaching benchmark instructions tells us that we should not be logging found for finding a reference mark - though lots of people do (I suspect because they don't understand and just see a disc, etc.) We need something like: found as described, found in poor condition, found destroyed, not found.

OK - thanks. I will take some time in the future and drop her a line with those that I've encountered that warrant being changed and let her take it from there. (I never really considered doing that; I always thought that there was some reason or justification why these marks were still in the database as they were coded. And yes, I agree with you - about my logic being faulty. My assumption is that the NGS database is as it is. But with your suggestion in suggesting NGS clean-up those that shouldn't be coded as they are - that would go a long way. Of course, if Geocaching is not picking up updates from the NGS database ... that's not good, especially if a lot of the efforts of serious Geocaching benchmark hunters are helping with cleaning up the database and finding marks! Re: my feeling that Geocaching coding and skulls are a nuisance ... Ayup. Well - I'm not sure what the majority of users are in the Geocaching benchmark section ... from other experiences, I would guess that the more serious types would be the ones participating in discussion forums like this, etc. My frustration with the status / condition logging becomes more compounded with Geocaching destroyed reports. I guess it all depends on who's calling the station destroyed. For me, OK for NGS: its their database. But I think something that can cause a mark to be not listed (or give the presence of not listed) should be only done to some kind of standard. And my experience with a lot of the benchmark posts on Geocaching is that many cachers are not doing a good job in reporting their finds. Thanks again for your thoughts and the recommendation!

Yes, thank you - I had briefly looked at that and a few other things in the past. I focus my efforts around my Microsoft MapPoint implementation, which is dynamically linked to the Access database: a table of caches and a query against a benchmark table (that filters out PID's I don't want to see). I'm using an 'ole Garmin GPS II+ with an externally powered antenna (better in wooded environments). And I load waypoints using EasyGPS. So a combination of low-tech and high-tech implementations. The most important part for me is the ability to just browse my Microsoft MapPoint screen ... think about an area I'd like to visit - and then click on the mapped objects to read the cache descriptions and benchmark datasheets. I then come up with a travel plan - print out pages for everything I want to visit - load up the GPS - get the camers and backpack - and I'm on my way! If I only had more time - and better weather!

I disagree with this. There's plenty of PID's I've found in the NGS database (and therefore also on Geocaching) that should have the destroyed status, and do not. One example I recently encountered: an old station was destroyed by the military in the 1950's when they bulldozed the top of a hill and built an installation. The original PID notes this - but does not have the destroyed status. It shows up as any other station does - when it most certainly is NOT there! A new PID was established for a new station with the same name followed by a 2. (And in fact, each of the three new reference marks also have their own PID's for the new station.) Or location marks that are long gone, like a church that burnt down in 1911. Not much use in going out of your way looking for these. But: there are other marks that have been noted as not found or destroyed - and as other responders have also noted - were/are actually still there, they just took a bit more looking and research to find! Personally, I maintain my own little Microsoft Access database ... and flag stations that I don't want to search for as "no show" (so they don't show on my Microsoft MapPoint map). I make the determination to set them "no show" after reading the NGS datasheet and any Geocaching posts ... as well as removing all that are along Interstates and other high volume roadways where its not really safe to partake in this kind of thing. The Geocaching destroyed and skulls feature I find more of a nuisance than a benefit ...

Rich in NEPA's comments I feel are along the line of what I would like to see (changed) in the Geocaching benchmark site. To summarize, maybe we should end up with just three types of benchmark logs: Found Not Found Note and for the Found log type, a couple of conditions, which can describe the recovery: good poor or mutilated (in need of maintenance) destroyed The most important aspect of this is what is "destroyed". For example, I wrote Deb Brown at the NGS regarding a station that I had attempted recovery of. At the physical location indicated by the description I found a concrete post - located in the edge of a field by a railway line. The top of the post had been damaged - possibly from farm machinery, etc. I found a chunk of concrete that actually fit back in the top of the monument - but still, more of it was missing. And although there was actually a metal rod in the centre of the concrete there was no disc. In this case I had NO proof that this was the station; in fact, there is a conflicting point in the description. If you look at the historic USGS map I posted with my Geocaching log, you'll see that there are/were TWO benchmarks in the area - and the description for the two may have been mixed together! Note: there is NO PID for the "other" station! MZ0171 NGS datasheet MZ0171 Geocaching benchmark page

Here's what I've done using Microsoft MapPoint and Access: Laid out numerous overlapping 10-mile circles covering the area within a couple hours drive Determined the zip code for the centre of each circle Used Geocaching benchmark searches for each zip code Downloaded a waypoint file Created a Microsoft Access benchmark database: PID, name, lat, lon, status, NGS flag, and URL Loaded each waypoint file into Access removing dupes Plotted all in MapPoint When I recover a benchmark I then update its status, to indicate that I've either found it or didn't find it. I've also gone through and changed the status of many benchmarks along interstate highways (and others I'm not interested in) to "no show" - and an Access query then removes them from my map. And if I report it to NGS I set the NGS flag to indicate as such. Of course, this is all keyed off the Geocaching database - and I'm assuming (possibly incorrectly) that its static and no new benchmark PID's are or have been entered (since I downloaded my waypoint files). In the same Access database I also have a table for caches. This allows me to easily display a map with benchmarks and Geocaches and to make plans for my hunting activities. I weekly get additional cache waypoint files which are added to my Access database.

As someone else posted, I too enjoy searching for benchmarks that are old - the older the better - and especially the ones that have not been ever logged as found. These are the ones that require some research - especially updating decades or even century+ descriptions to today. In some ways, I enjoy this aspect a lot more than cache hunting 'cuz you're looking for something that maybe nobody's found in 50, 100 or more years. As for the comment that the Geocaching benchmark site isn't broken as far as us 'amateurs' are concerned, so don't try to fix it! ... I have to disagree with that. That was the purpose of my original post to attempt to see what others thought or felt. I think one of the best improvements could come with changing the Geocaching benchmark "condition" log status. Other replies seem to agree with this notion. Does anyone feel that these changes (fixes?!) would be breaking anything?

One thing that wasn't well addressed in replies to my post - was Geocaching benchmark logs that DON'T follow the rules as noted on the Geocaching main benchmark page. More specifically - people logging finds when they find just one of the reference marks for a station, etc. That may all somehow fit into BeachBum22's comments regarding speed ... maybe I'm too much of an engineer or purist - maybe I'm just bitching too much. But it frustrates me when I visit a Geocaching benchmark page, look at a previous found log and look at the associated picture(s) - only to see it is not the station ... or even worse, in one recent situation, it was for a location mark that wasn't even the right structure! In a couple of cases I've emailed through the Geocaching web interface to a few people noting that they've got the wrong station with suggestions that they update their entries. (I don't do this for someone logging an RM as the station - just incorrect stations, locations, etc.) Is this the right approach, or something that should be refrained from?

Occasionally I have been making logs on the NGS site. I usually do so in conditions such as: Description to reach station has significantly changed Station's location reference to local objects has significantly changed Station has not been logged at NGS in a long time (like decades) There's an obvious problem with the station (like building a disc was on is gone, disturbed or mutilated settings, etc.) I have also read the materials on the NGS site, including the proper way and order to supply information (although sometimes the 15-lines that are available isn't sufficient!). An important thing to note is that all NGS destroyed reports manually go into the system. I found it interesting to observe that although there may not be any recent log in the NGS database it doesn't necessarily mean that professionals are not visiting these stations. In a couple of cases I've been told (by property owners and even a surveyor) that a station has been frequently visited!

I fully agree with the comments regarding Geocachers and NGS logging. Maybe there was a bit of confusing in my original post: I was looking for a way to easily obtain the latest NGS datasheet from the Geocaching web site. The aforementioned post/quote does just that! The other aspect of my posting was to try to bring a better correlation with the condition and status descriptions that one finds on the NGS datasheets (and therefore embedded descriptions in the Geocaching site's copy of the NGS database) - and what Geocachers log - on Geocaching.com. If we speak the same language and use the same terms ...

Thanks to everyone who's added to this thread - I appreciate your comments and viewpoints. What follows are a few additional posts regarding your feedback. Regarding the desire to be able to call-up an NGS datasheet directly in a web brower's window: Indeed! And that seems to work just fine. In the past ... I've gone through the arduous process of navigating through a bookmarked NGS page, looking up the PID and then getting the datasheet. Gee ... this does it all in one URL. And it would be a no-brainer to have this on the Geocaching site as a link that opens a new window with the most current datasheet. As I'm new to the forums - how do we lobby or submit this request to the powers at be?

There's been a lot of discussion on the forums regarding the logging of benchmarks. This post may be a bit lengthy - but I feel its worthy of discussion. The Geocaching web site provides the following types of logs: found it couldn't find it destroyed post a note Whereas NOAA's NGS mark recovery form provides for these conditions: good not recovered, not found poor, disturbed, mutilated, requires maintenance destroyed The discussion: SYNC TERMS BETWEEN GEOCACHING AND NGS I would like to lobby for the synchronization of the terms between the Geocaching site and the NGS mark recovery entry form. Not only would this allow for easier posting of mark recovery and information between the two sites but would help with the interpretation of what log/condition should be selected. My recommendation would be to change the Geocaching log types as follows: found it ==> good couldn't find it ==> not recovered, not found N/A ==> poor, disturbed, mutilated, requires maintenance destroyed ==> destroyed post a note ==> N/A DEFINITION OF LOG / CONDITIONS I will list these out of the aforementioned order as it may make more sense to present it this way. POST A NOTE Only applies to the Geocaching web site. Useful for notes, an entry to log photographs with, etc. FOUND IT or GOOD The status when one has successfully recovered a station. One of my pet peeves is that I find a lot of geocachers are logging benchmarks found when they really are not finding them! In many cases, I see found logs for station reference mark disks when the geocacher has NOT found the actual station. I believe this is due, in part, to the fact that many people don't understand the concept of a station and reference marks! Even the default Geocaching benchmark page notes that one must find the station and not its reference marks. Worse yet - many people are logging found on station's geocaching page when they should really be logging not found, not recovered. This seems to be especially true for landmark stations. If counts are going to be at all meaningful we all have to have the same denotation as to what these status mean. A better definition of what to call each status would go a long way in accomplishing this! DESTROYED The NGS is pretty specific in the handling of the destroyed status. For NGS submissions, they suggest you either post a not recovered, not found condition with text comments indicating evidence of the mark's possible destruction. Alternatively, if you actually find a marker separated from its setting you can report it as destroyed - but can only do so by reporting this (via email) to Deb Brown at the National Geodetic Survey in Silver Spring, Maryland. (There is NO way to submit a destroyed status on the NGS site.) Deb and I have exchanged a number of emails on this and related subjects. Here is an excerpt of her guidelines from 24 July 2003: In subsequent correspondence from Deb on 27 Oct 2003 it was clarified that for stations that should have discs, that unless there is a photo of the actual disk available (to prove that the setting wasn't misidentified) the mark should be submitted as NOT FOUND or POOR with an appropriate note in the text portion of the form to indicate our findings. To summarize: for stations involving benchmark disks, etc. the destroyed status should only be used when recovery attempts results in finding the disc but separated from its setting. Otherwise it should be logged as not found or poor, which will help the responsible organisation in possibly resetting the station in the future. For landmark stations (like churches, towers, buildings, etc.) if they are not found or have had changes that effects the accuracy of their use (like a church tower burns down and is rebuilt but is not exactly the same) a station can be logged as destroyed, but only with photo evidence that it is either no longer there or has materially changed. POOR, DISTURBED, MUTILATED, REQUIRES MAINTENANCE This should be the category for stations where the mark is not found as described. Examples include: disc missing but with stem or drill hole evident, concrete or stone marker damaged, bolts, pins, etc. removed and so on. NOT RECOVERED, NOT FOUND This should be the catch-all for logging of a station that doesn't fit into any other category. In many cases I've spent an hour, two or even three looking for an old benchmark and come up empty handed. I log this as not found. In cases where I've found a station where I've recovered one or more reference marks but have not found the actual station I also log this as not found. This approach seems to follow the NGS standard - and it is also what you're instructed to do on the Geocaching default benchmark page GEOCACHING STATUS I would like to see the User Stats page of our Geocaching profiles updated. Currently it shows the number of NGS Benchmarks found. For those of us who put a lot of effort into benchmark hunting I believe it would be better to actually provide the rundown of each of the benchmark statuses above: if you spend the time to go to a benchmark location and search it out whatever the mark's situation it should count; there's really no guarantee whether a station exists or not, or what condition it may be in. Its not a cache... Providing only the found status on the stats page may be motivation for many people to treat logging benchmarks as the do caches (you either find it or your don't) - resulting in more inaccurate benchmark "finds" when the status or condition logged would have been more appropriately something else. To further the thought - I would propose changes to the User Stats page ... actually separating the benchmarks from the List of Items Found. Personally, I'd like to see this page broken in sections with totals underneath: List of caches found Traditional Multi Virtual Event Webcam Etc Total caches found List of items found Travel bug dog tags USA Geocoins Etc Total items found Benchmarks Good Not recovered, not found Poor, disturbed, multilated, requires maintenance Destroyed Total benchmarks List of Items Owned Etc Total items owned BETTER BENCHMARK INFORMATION ON GEOCACHING It took me quite some time and research to understand the whole benchmark thing on Geocaching. Most of what I've gleaned has been from other off-site resources (including the NGS) as well as in these discussion groups. But I fear that many people who have ventured into the benchmark hunting aspect have not been brought up to speed as well as they have been for the cache side of life. One resource that I feel is invaluable is the "original datasheet". Each Geocaching benchmark page has a link to it - but its obscured hiding in a small font at the top of the page. Many benchmarks have simple descriptions - and as such, the Geocaching page for the PID ("Official History") is sufficient. But in many cases, the loss of formatting on Geocaching's page is a run-on mess. To wit, take a look at PID MZ1557: I always print out the NGS datasheet, three hole punch it, and bring that with me. Not only is the information formatted a lot better - it contains other, valuable information that can aid in the recovery of a benchmark! But in speaking with other local Geocachers who also do benchmark hunting, none were aware of these NGS datasheets! On the NGS datasheet I usually draw a layout of the station showing the physical relation of the station to any of its reference marks as well as any azimuth points. This aids in quick recovery of the station and RM's. Additionally - I'll also often draw out the instructions on finding the station, whether it be by road or other indicated references. In the future, if it is at all possible, I would advocate some kind of linking of the Geocaching site to the NGS datasheets - if there's some facility that would easily allow supplying a PID to the NGS search engine and retrieving the most current datasheet for that PID. And although there is a wealth of information presented on the default Geocaching benchmark page maybe we can generate some additional or rewritten information to assist in improving this part of the Geocaching site - especially along the lines of benchmark logging as noted above?! What do you think? Best regards, Bob W1QA

And another URL that didn't work in that same notification message is: Visit 22News http://www.geocaching.com/track/track_detail.asp?guid=eb842bc6-5eec-463d-ab72-00eb3f32cb2f

Got an automated mail message regarding one of my travel bugs: quote:This is an automated message from Geocaching.com You are receiving this email because you are the owner of this listing. Brian - Team A.I. placed 22News (Travel Bug Dog Tag) in K9 Conclusion at 10/29/2003 Log Date: 10/29/2003 Visit this listing at the below address: http://www.geocaching.com/track/log.aspx?LUID=0d9fb946-3942-4695-9872-7d5eb3f9f305 But multiple attempts to go to the aforementioned link generates a 404 style error: quote:Server Error in '/' Application. -------------------------------------------------------------------------------- The resource cannot be found. Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly. Requested Url: /track/log.aspx -------------------------------------------------------------------------------- Version Information: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET Version:1.1.4322.573

Here is a suggestion regarding the Geocaching navigation scheme. Currently you have links on the left hand side of each page: - Main Page - About Geocaching - Hide & Seek a Cache - Track Travel Bugs - My Cache Page - Discuss Geocaching - Links What's missing is a link to the Benchmark Hunting page! Normally I manually type in this URL when I want to work on a benchmark hunting effort: http://www.geocaching.com/mark/ Maybe at some point it could be possible to add a persistent link in the menu structure for benchmarks?

On the My Cache Page (URL http://www.geocaching.com/my/) It would be great if the Logged Caches and Last 10 Benchmarks Logged had similar formats. To wit: - make the benchmark date line up the same under the Logged Caches dates - include the designation for the benchmark along with the benchmark's PID - include information like "So far, you have NN log(s)" for benchmarks, too. As I've started doing more benchmark searching it makes it a lot easier to go between the Geocaching web site and the NOAA NGS site (where I report my findings or lack thereof). Here's a brief text example of my suggestion: ----- Logged caches (Show all logs) The last 10 logs are listed, or logs in the last 10 days, whatever is greater) So far, you have 43 log(s) in the system. 9/21/2003 Flint's Fodder (Massachusetts) 9/13/2003 Camp White Cache (Massachusetts) 9/6/2003 * Cardiff Live! * - webcam cache 9/5/2003 Devil's Pulpit (Wye Valley) 9/3/2003 Where is Snowdon Summit??? 9/2/2003 Grandma's Buttons (Penmaenmawr, North Wales) 9/2/2003 Highest in Conwy 9/2/2003 Between The Bridges 9/1/2003 Between The Bridges 8/31/2003 Iron Age Cache Last 10 Benchmarks Logged (show all logs) 9/21/2003 MZ0093 R 24 9/21/2003 MZ0090 T 24 9/21/2003 MZ0085 K 9 9/21/2003 MZ0084 J 14 9/12/2003 MZ1606 QUABBIN TOWER 8/22/2003 MZ1725 FAIRVIEW 8/17/2003 MZ0070 N 3 8/17/2003 MZ1116 T 46 8/17/2003 MZ1115 S 46 8/17/2003 MZ1114 R 46

I agree with putting notes with travel bugs. I either attach a laminated note to the bug, or put the bug in a zip loc bag with a laminated note. Additionally, when I find a bug ... I started putting it in zip log bags with a note. I once placed a travel bug - and the next person who visited the cache picked it up ... but didn't know what it was. So they took the travel bug dog tag and level the object behind. Luckily I was able to contact both the cache owner as well as the person who took the dog tag - and although it took a month or more we were able to get them reunited.