Jump to content

Question regarding reviewers and new caches


ThePropers

Recommended Posts

I was setting up my caching day tomorrow and this thought occured to me as I was pulling up each cache and reading the descriptions for parking coordinates.

 

With the somewhat new feature of child waypoints, if a cache is submitted where the owner has listed parking coordinates (or other) in the cache description, but not added a child waypoint, are the reviewers forcing the owner to add a child waypoint before the cache is approved?

 

I would hope they are, but am just curious if the child waypoint feature is being enforced for new caches.

 

I believe GSAK is implementing something in the new release to "scrape" the descriptions and add them as child waypoints in the next release (currently it will only add it as a new waypoint, but not a child waypoint of the cache it was scraped from, and the scraping feature is spotty at best, since it has to make a 'best guess' as to if there is a child waypoint or not in the description).

Link to comment

I got this reply when I entered our multi without the child waypoints (I didn't know you could hide them from being seen :unsure: !):

 

Hello there, I just reviewed your new cache, and I am requesting that you add (an) additional waypoint(s) to your cache before I list it on the site.

 

It is now possible to use the "Additional Waypoints" function to store intermediate/final waypoints in a standardized way -- see http://forums.Groundspeak.com/GC/index.php?showtopic=120543 . Could I please ask you to add your extra waypoints in this way. Anything that is "secret," like the final location of the cache, can be hidden from view by anyone except you as the cache owner, and site admins/volunteers. Waypoints such as parking coordinates can be viewed by anyone.

 

I encourage you to go back and add these to all your multi and puzzle caches. You probably wouldn't be too happy if a new traditional cache gets published that is right on top of the final of your puzzle or multi-cache. The reviewers have automatic tools that they use that will prevent this, but it depends on all the waypoints being in the database. Thanks for your cooperation.

 

Once your additional WPs are added, please re-enable the cache and email me at XXXXXXX or via the link to my profile. [red]Please be sure to include the cache name and GCxxxx number, or better yet, the URL of the cache page.[/red]

 

Thank you for your understanding and for your contributions to the sport.

 

XXXXX

Volunteer Cache Reviewer

 

So, I'd say it's strongly advised-- at least in our area.

Link to comment

1. Most or all of the reviewers now request the additional waypoints for multicaches and puzzles.

 

2. Don't be surprised if someday the listing guidelines make this mandatory.

 

3. Many reviewers are going back into their records and adding the waypoints on older caches. EVERY cache owner who does this on their own will be saving their reviewer a lot of work.

Link to comment

3. Many reviewers are going back into their records and adding the waypoints on older caches. EVERY cache owner who does this on their own will be saving their reviewer a lot of work.

 

I did this with mine when it first came out. I wonder if it would acceptable/rude to post a note to any caches I run across with waypoints in the description that haven't been added as child waypoints. What we really need is a "Needs Child Waypoints Added" logtype :unsure:

Link to comment

I wouldn't clutter up someone's cache page with such a note. It would also make you sound like the cache police.

 

What I do recommend is for everyone to discuss this issue in their local geocaching forums. The hidden waypoints benefit the cache owner, not just the cache reviewer. Ever try finding the scrap of paper with the coords for the final stage of your multicache a year later when the first stage goes missing? Ever have someone hide a cache 50 feet away from one of your puzzle caches?

 

There is a tutorial on Additional Waypoints in the FAQ thread over in the Getting Started forum, for anyone not yet familiar with it.

Link to comment

I wonder if it would acceptable/rude to post a note to any caches I run across with waypoints in the description that haven't been added as child waypoints.

If I came across a situation where I really thought it was a problem (haven't yet...), I'd probably just contact the owner with a friendly email.. I don't think it warrants a note or it's own log category, personally. I also don't think it's fair to expect child waypoints for parking, etc..., unless a cacher has specifically listed those coords in their description already (as you said).

 

We don't post parking coords for our traditionals because there are many options and that's part of the fun! :unsure:

Edited by Cache Heads
Link to comment

If I came across a situation where I really thought it was a problem (haven't yet...), I'd probably just contact the owner with a friendly email.. I don't think it warrants a note or it's own log category, personally. I also don't think it's fair to expect child waypoints for parking, etc..., unless a cacher has specifically listed those coords in their description already (as you said).

 

We don't post parking coords for our traditionals because there are many options and that's part of the fun! :unsure:

 

Yeah, that's what I was getting at...it's really only a "problem" per se if it's in the description but they didn't list a child waypoint. I certainly don't want to be the cache police (unless I'm getting a uniform), which is why I've been hesitant to post logs or email the owners when I run across them...also 9 times out of 10 it's not that big of an issue anyways.

Link to comment

Here's what I like.

 

You get a two files. On my auto-routing GPS I can upload both gpx and wpt files. On my trail gps I can upload just the gpx.

 

I don't have to include the wpt if I don't want them.

 

I would like to see some of these caches that already post the parking coords in the comments update the wpt information.

Link to comment

GSAK already scrapes cache text for child waypoints. It works okay too.

 

I've been asking for cachers to use the waypoints tool for caches since February or so. Most do. On parking coords or trailhead coords I mention that the coords will load automajically for cachers that download a gpx. and have their own distinct field for cachers working from paper. If parking coords are the only additional coords, I use my standard waypoints tool reviewer note, then hit publish. How often cachers go into edit and add those parking coords to the waypoints post publication I can't say. I've only had one cacher ignore me on using the waypoints tool for multi or puzzle coords.

 

One of Locus Prime's Excellent Scripts makes waypoint entry highly automated (fills all the text fields with a single mouse click). http://gmscripts.locusprime.net/index.html

Link to comment

I applaud any effort to get the child waypoints listed explicitly for each cache. I've looked into having GeoBuddy parse each geocache's description, looking for coordinates, and it is a nightmare. Some geocachers have come up with some very "creative" ways of writing out coordinates in deg min.min format.

 

GeoBuddy tip: if you highlight a coordinate in the built-in Web browser and click New Waypoint, GeoBuddy will attempt to parse the highlighted text and automatically enter it in the Coordinates field of the new waypoint. http://www.geobuddy.com

Edited by topografix
Link to comment

I am quite conflicted about adding waypoints to old caches, especially intermediate stages for multicaches.

 

In my opinion, the additional waypoints feature is being abused, and the proximity rule ("guideline") for multicaches is being interpreted in a manner that has adversely affected the quality of new caches. So I am not very inclined to contribute to the ongoing abuse by submitting waypoints for intermediate stages of existing caches.

 

On the other hand, I do feel badly for my local reviewers, who are being forced to apply the rules in a nonsensical way, and I don't want to add to their burden.

Link to comment

In my opinion, the additional waypoints feature is being abused, and the proximity rule ("guideline") for multicaches is being interpreted in a manner that has adversely affected the quality of new caches. So I am not very inclined to contribute to the ongoing abuse by submitting waypoints for intermediate stages of existing caches.

 

Please provide the evidence (or an example) of abuse and I'll try to address it, especially the quality of cache issue.

 

On the other hand, I do feel badly for my local reviewers, who are being forced to apply the rules in a nonsensical way, and I don't want to add to their burden.

 

In our weekly chat I've heard of none of this, nor am I sure of what you mean by "nonsensical way." Can you please explain? Perhaps there needs to be some clarification.

Link to comment

In my opinion, the additional waypoints feature is being abused, and the proximity rule ("guideline") for multicaches is being interpreted in a manner that has adversely affected the quality of new caches.

Please provide the evidence (or an example) of abuse and I'll try to address it, especially the quality of cache issue.

Sure. I'd love to! I have a very clear example:

 

A local cacher wanted to do a great history-based multi in our town. You would go to various plaques around town, gather information, and use it to determine the location of the final. So far, so good.

 

Unfortunately, one of the crucial plaques was within 0.1 mile of an existing cache. A cache that could never have been confused with the plaque in question, since it is a micro hidden nowhere near. But the plaque couldn't be used in the multi. Period. The reviewer would not or could not allow an exception.

 

As a result, the cache is missing a big piece of history; the cache hider basically had to provide it on the cache page instead of letting the seeker visit the spot.

 

Result: proximity rule decreased the quality of the cache.

 

If the reviewers have never mentioned this kind of situation, I would be quite surprised.

Link to comment

 

A local cacher wanted to do a great history-based multi in our town. You would go to various plaques around town, gather information, and use it to determine the location of the final. So far, so good.

 

Unfortunately, one of the crucial plaques was within 0.1 mile of an existing cache. A cache that could never have been confused with the plaque in question, since it is a micro hidden nowhere near. But the plaque couldn't be used in the multi. Period. The reviewer would not or could not allow an exception.

 

As a result, the cache is missing a big piece of history; the cache hider basically had to provide it on the cache page instead of letting the seeker visit the spot.

 

Result: proximity rule decreased the quality of the cache.

 

If the reviewers have never mentioned this kind of situation, I would be quite surprised.

 

I had a similar situation with a KY cache hider. He was able to get his cache published and still point cachers to the point of interest by using the "Reference Point" waypoint option.

 

Also of note: historical markers are their own category on Waymarking.

 

I really do not see how the proximity guideline is "hurting" the quality of geocaches.

 

GCY5TH

Link to comment
I had a similar situation with a KY cache hider. He was able to get his cache published and still point cachers to the point of interest by using the "Reference Point" waypoint option.
The "reference point" waypoint option mainly causes confusion. It does very little to help in this case, because the cache hider was required to provide the information some other way.

 

Also of note: historical markers are their own category on Waymarking.
Don't even get me started. 'Nuff said.

 

I really do not see how the proximity guideline is "hurting" the quality of geocaches.
Well, I do. Apparently we differ. That's probably part of the reason why you are a reviewer and I am not.

 

I probably shouldn't even have said anything. I have this feeling that the horde of nares fuscusa are descending even as I write this.

Edited by fizzymagic
Link to comment

I think there should be a distiction for the waypoints in a multi with regard to the 'saturation/confusion' problem.

Waypoints where information for the cache is hidden (micro, coordinate tag,..) should be counted for the proximity to other caches/states.

Waypoints where normaly available information is used (plaquette, numbers on lightmasts, routenumbers,...) should not be included.

 

It also seems that some reviewers miss the fact that it is a guideline, and not a hard to follow rule.

quote:

The reviewers use a rule of thumb that caches placed within .10 miles (528 feet or 161 meters) of another cache may not be listed on the site. This is an arbitrary distance and is just a guideline, but the ultimate goal is to reduce the number of caches hidden in a particular area and to reduce confusion that might otherwise result when one cache is found while looking for another. This guideline applies to all stages of multicaches and mystery/puzzle caches, except for any 'bogus' posted coordinates for a puzzle cache.

endquot

Edited by Kalkendotters
Link to comment
I think there should be a distiction for the waypoints in a multi with regard to the 'saturation/confusion' problem.

Waypoints where information for the cache is hidden (micro, coordinate tag,..) should be counted for the proximity to other caches/states.

Waypoints where normaly available information is used (plaquette, numbers on lightmasts, routenumbers,...) should not be included.

 

It also seems that some reviewers miss the fact that it is a guideline, and not a hard to follow rule.

I would agree that some of us miss that. That is part of the "human" part of the process though. If it were automated, then it would be an absolute. Adding the human element isn't perfect, but it allows for exceptions based on the situation and the reviewer's opinion of that situation. I am sure that even Fizzy would agree that an automated solution isn't the answer, nor is a free-for-all the answer. This is where the appeals process comes in. In my opinion, Groundspeak tends to be flexible in some of these situations. Hydee is an exceptional judge regarding issues of this sort, as well as Jeremy. In talks with her regarding this, I value her input and understand the importance of flexibility. Jeremy has stressed the same as well. But still, the reviewer knows the area better than most usually, so their opinion is important to the individual situation.

 

Regarding the importance of the historical waypoint, as cachers go to these areas, I have seen two distinct things happen. I've done it. If I'm interested in the area and the history of it, I will go to these additional areas when written into a cache page. I love it when its added to the description. Still, there are times when I go to a "virtual" waypoint and get the word or number I need and don't even read the rest of the plaque. Forcing cachers to a waypoint doesn't mean they will learn diddly-squat. A well written cache page will peak the interest of a cacher more than "go to stage one and give me the third number on the second line". That's a fact. I've seen it over and over in group caching. I've done it myself.

 

Regarding the topic, I do not enter parking coordinates in review, sorry. I ask that they be entered, but I don't do it for the cacher. I do enter multi stages if it is the first time they have submitted a cache. I post a note telling them how to do it and then I do it to give them an example. If I see I have done it before and they still have not entered them an a new submission, I make them do it this time.

Link to comment

I think there should be a distiction for the waypoints in a multi with regard to the 'saturation/confusion' problem.

Waypoints where information for the cache is hidden (micro, coordinate tag,..) should be counted for the proximity to other caches/states.

Waypoints where normaly available information is used (plaquette, numbers on lightmasts, routenumbers,...) should not be included.

I agree, and would enhance it to suggest that your first point refers to physical containers which contain elements of the cache. So two micros containing cache coords must be 0.1mi apart whether they're for the same cache or two different caches.

 

"Virtual" elements, however, should not be so restricted. I can't see why it matters if two multis start with clues from the same noticeboard and then go off in different directions.

 

Still less can I see the point of reviewers asking cache owners to put parking coords for different caches at different places in the same car park. What part of the proximity rule relates to parking? :D

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...