Der Multicache oder auch Multi-Stage-Cache genannt, hat die Besonderheit, dass man erst nach Besuchen einer oder mehrerer Stationen und mit den dort gewonnenen Informationen zu Koordinaten kommt, wo der Cachebehälter versteckt ist. Es gibt sehr viele verschiedene Varianten von Multicaches. Manche haben nur eine Stage und man hat schon die Cachekoordinaten (auch Off-Set-Cache genannt). Manche haben bis zu 30 Stationen bevor man zu den Versteckkoordinaten kommt. Bei diesem Cachetyp hat der Owner eine breite Gestaltungsmöglichkeit.Auch Caches, wo es nicht möglich ist, genaue GPS-Koordinaten zur Verfügung zu stellen (z.B. weil der Cache in einer Höhle liegt), ist das Listing als Multicache zu klassifizieren.
Voraussetzungen, dass ein Multicache reviewt werden kann
Voraussetzung ist, dass bei einem neu eingereichten Listing eines Multicaches alle Koordinaten der Stages inklusive der des Cacheversteckes als additional waypoint zu listen sind. Zum Thema additional waypoints gibt es hier bereits mehrere Beiträge. Weiters gelten die selben Voraussetzungen die für alle physischen Geocaches gelten: Mindestinhalt ist ein Logbuch.
Posts
"Auch Caches, wo es nicht möglich ist, genaue GPS-Koordinaten zur Verfügung zu stellen (z.B. weil der Cache in einer Höhle liegt), ist das Listing als Multicache zu klassifizieren."
AntwortenLöschendemnach müßte aber ein cache, wo die dose ständig in bewegung ist (z.b. GC1JJCZ) auch als multi eingereicht werden, oder?
da es in österreich inzwischen ja mehrere cache gibt, bei denen die dose ihren aufenthaltsort wechselt - wie trägt man das als additional waypoint ein? mehrere final-location-waypoints? oder reicht dann einer? einen bereich kann man ja nicht angeben, soweit ich weiß?!
N ein. Eine Dose die ständig in Bewegung ist, gibt es lt. guidelines von gc.com nicht. In dem konkreten Fall, hat der Owner die Beschreibung nach der Veröffentlichung nun schon zum drtitten mal geändert.
AntwortenLöschenAber solange kein NA-log von einem GECAPO kommt, erfährt der Reviewer von solchen sehr sehr bösen Machenschaften nichts. Da hat die GECAPO wohl versagt.
diese antwort wundert mich etwas. angeblich soll ja der reviewer bei einem NA-log nicht automatisch informiert werden. dem ist also doch nicht so (hätte mich auch gewundert).
AntwortenLöschenunabhängig davon bist du ja jetzt über diesen beweglichen cache informiert und kannst deiner reviewertätigkeit nachkommen. ein NA ist ja jetzt nicht mehr notwendig.
der zweite bewegliche cache ist der GC14VDV, bei dem die dose an 2 verschiedenen positionen sein kann. davon besitzt du, wie man aus den logs nachvollziehen kann, bereits kenntnis. ich kann also davon ausgehen, daß du auch bei diesem cache aktiv werden wirst?!
oder wolltest du mit der phrase "gibt es lt. guidelines von gc.com nicht" nur andeuten, daß sie nicht regelkonform sind, du sie aber trotzdem in ordnung findest und deckst?
@ gumbo67:
AntwortenLöschenIch muss deinen Kommentar korrigieren. Nirgendwo steht, dass der Reviewer nicht von einem NA-log informiert werden soll. Deine Aussage ist daher nicht richtig. Richtiger wäre, dass die Notification an den Reviewer derzeit nicht funktioniert. Das ist etwas ganz anderes.
Es braucht trotzdem ein NA-Log beim Listing, damit ich als Reviewer aktiv werden kann. Eine Info abseits von gc.com reicht dafür nicht aus. Leider muss man zusätzlich dem zuständigen Reviewer ein mail schicken, um ihn zu informieren. Dadurch erspart man sich aber nicht das NA-Log in GECAPO-Manier.
GC14VDV ist nicht als Tradi gelistet, daher geht das Beispiel hier absolut am Thema vorbei. Es ist ein Offset-cache wie viele andere auch. Er ist daher weder "nichtregelkonform" (dies kann nur zutreffen, wenn kein Logbuch im Cache wäre, denn das ist eine der wenigen Regeln) noch brauche ich ihn daher zu decken.