Opencaching.de

Die Plattform opencaching.de => Opencaching 3.0 - Ideen und Gedanken => Thema gestartet von: Seebaer777 am 04. Juli 2017, 13:00:38

Titel: Safari Nomenklatur
Beitrag von: Seebaer777 am 04. Juli 2017, 13:00:38
Seit einiger Zeit logge ich auf OC mehr Safaris als "normale" Caches, jedoch kommt es hin und wieder vor, dass ich an einer Stelle bin und forsche, ob es dazu eine Safari gibt (Stichwortsuche unter c:geo), dass ich dann nicht fündig werde, obwohl ich bei einigen weiß, dass es zu Thema X eine Safari gibt, mir fiel nur der exakte Suchbegriff nicht ein.
So könnte eine alphabetische Suche weiterhelfen, zumindest bei den Safari-Caches, die zuvor als gpx runtergeladen und c:geo zugänglich sind. Doch da ist das Problem. Denn es gibt:
Cache (Safari)
Auf Safari: Cache
SVC: Cache
und was es nicht noch alles an Varianten gibt. Der Begriff "Cache" soll hier als Platzhalter herhalten.
Wie wäre es, alle Safaris, sowohl neue, als auch nach Möglichkeit bestehende, Safaris nach einem einheitlichen Muster zu benennen?

Am PC ist es durchaus möglich, z.B. auf Wiki-Seiten zum Thema Safari oder flopps Safari-Map direkt auf der Seite eine Stichwortsuche durchzuführen, jedoch habe ich keine Ahnung, wie Stichworte auf einer Internetseite gezielt auf einem Smartphone unterwegs gesucht werden können.
Titel: Re: Safari Nomenklatur
Beitrag von: ekorren am 04. Juli 2017, 13:58:57
Ich glaube nicht, dass sich hier alle an eine einheitliche Nomenklatur halten würden - zumal die ja nur für neue Safaris gelten würde. Denn jeder hat ja schon seine eigenen Gründe, warum er/sie es so und nicht anders nennt... ich beispielsweise mag die Abkürzung "SVC" für "Safari Virtual Cache" gar nicht. Ich suche ja auch nicht nach LRC aka "Location Real Cache", sondern einfach nach Tradis.

Eine alphabetische Suche würde dir, ehrlich gesagt, am Ende aber auch nicht viel bringen, denn das Problem ist ja oft weniger, dass man die Safari im Alphabet nicht findet - sondern dass man sie deswegen nicht findet, weil man nicht mehr weiß, wie sie der Owner genannt hat. Und spätestens, wenn eine Safari "Wo sind welche" oder "Von Politikern und Steuern" heißt, hilft natürlich auch jede Stichwortsuche über die Titel (also z.B. in der Flopp-Karte) nicht weiter.

Aber...
Zitat
Am PC ist es durchaus möglich, z.B. auf Wiki-Seiten zum Thema Safari oder flopps Safari-Map direkt auf der Seite eine Stichwortsuche durchzuführen, jedoch habe ich keine Ahnung, wie Stichworte auf einer Internetseite gezielt auf einem Smartphone unterwegs gesucht werden können.
... das ist natürlich in den Smartphone-Browsern durchaus möglich, und auf der Wiki-Seite
http://wiki.opencaching.de/index.php/Safari-Caches_auf_einen_Blick (http://wiki.opencaching.de/index.php/Safari-Caches_auf_einen_Blick)
sollte die Chance auch ganz gut sein, mit einer Stichwortsuche zum Ziel zu kommen.

Beispielsweise im Mobile Firefox:
- Seite laden,
- Abschnitt "Sortierbare Liste" öffnen (auf Dreieck oder Titel tippen)
- Oben auf die drei Punkte tippen, um das Menü zu öffnen
- "In Seite suchen" auswählen
- Drauflos tippen und ggf. mit den Pfeilen zwischen den Treffern wechseln

Titel: Re: Safari Nomenklatur
Beitrag von: ClanFamily (Mirco) am 04. Juli 2017, 16:14:45
Das Thema beschäftigt uns in der Entwicklung bereits.
Die Idee, dass ganze irgendwie zu Katalogisieren und das Ganz zu Thematisieren ist schon ein schwieriges unterfangen.
Stichworte  - ja da sehen wir schon, sind die Cacher "sehr kreativ"...

Wenn Ihr Ideen habt - gerne raus damit... vielleicht finden wir ja den heiligen Grahl des Suchens ;)
Wir nehmen das Thema mal für den OC Talk Podcast im August auf.
Titel: Re: Safari Nomenklatur
Beitrag von: ekorren am 04. Juli 2017, 23:38:02
Wenn Ihr Ideen habt - gerne raus damit... vielleicht finden wir ja den heiligen Grahl des Suchens ;)

Zuallererst müssten mal die Safaris ein eigener Cachetyp sein. Bzw. etwas Eigenes, denn ob man es überhaupt Cache nennen sollte, ist nochmal eine ganz andere Frage - m.E. ist eine Safari genauso wenig ein Cache wie ein Event. Es ist eben eine Safari.

Wenn man dann mal Safaris von den vollkommen anderen location based virtuals getrennt hat, kann man sie auch viel besser als Safaris behandeln mit einem angepassten System anstatt der vielen Notlösungskrücken. Beispielsweise könnte dann die Eingabe und Behandlung der Fundkoordinaten beim Loggen auf Systemebene passieren, die Karten statt über einen externen Link direkt intern verfügbar sein. Anstatt die blauen Kästen überall reinzukopieren und anzupassen, könnten sie einfach direkt vom System eingeblendet werden. Anstatt in der newlogs-Seite bei den Ländern der Listingkoordinaten einsortiert zu werden, könnten sie als eigener Abschnitt geführt werden - womit es auch interessanter werden könnte, mal in den neuesten Safarilogs zu blättern. Anstatt alles zusammengemischt zu bekommen, wäre es im Profil ein eigener Zähler. Und so weiter... Man könnte so viel machen. Aber zuallererst müssten mal Safaris Safaris werden und nicht mehr mit den "echten" Virtuals zusammengemischt werden.

Für die Suche helfen wahrscheinlich am Ende am besten intuitive Beschreibungen, die auch dem Inhalt entsprechen. Leider sind viele Owner lieber kreativ als genau. Die Flopp-Map war da schon mal besser, weil sie nicht nur die Titel durchsucht hat, aber das war einmal...

Wenn man da eine große Lösung will, könnte man vielleicht Themen bzw. Tags bzw. Stichworte definieren, deren Listen man dann über eine spezielle Seite abrufen kann - ähnlich den Bookmarklisten, aber nicht von einer Einzelperson gepflegt. Wichtig wäre dabei aber, dass nicht nur der Owner eine Safari einem Thema zuordnen kann, denn sonst bleibt es wieder extrem lückenhaft - weil viele Owner gar nicht mehr aktiv sind, oder das System nicht verstehen würden, oder gar bewusst nicht mitmachen wollen, oder ganz andere Vorstellungen haben, welche Stichworte passend wären. Aber auch hier gilt: Zuallererst müssten Safaris mal etwas Eigenes werden, damit man überhaupt sinnvoll Funktionen einbauen kann, die nur für Safaris sinnvoll sind.
Titel: Re: Safari Nomenklatur
Beitrag von: cacher.ella73 am 05. Juli 2017, 01:01:04
Ich wäre auch für einen eigenen Cachetyp. Hab schon überlegt, ob ich einen zweiten Account nur für meine Safaris anlege, um sie so von meinen normalen Caches zu trennen.
Titel: Re: Safari Nomenklatur
Beitrag von: Slini11 am 05. Juli 2017, 01:14:21
Zuallererst müssten mal die Safaris ein eigener Cachetyp sein. Bzw. etwas Eigenes, denn ob man es überhaupt Cache nennen sollte, ist nochmal eine ganz andere Frage - m.E. ist eine Safari genauso wenig ein Cache wie ein Event. Es ist eben eine Safari.
Ich wäre auch für einen eigenen Cachetyp. Hab schon überlegt, ob ich einen zweiten Account nur für meine Safaris anlege, um sie so von meinen normalen Caches zu trennen.
Dazu kann ich nur sagen: Ja. Ja, Ja. Ja, Ja. Ja. Ja ja - Jaaa!
Ein eigener Cachetyp muss definitiv her.

D.h. man müsste alle Caches, die ein Safari-Attribut haben zu einem Safari-Cache machen, mit dieser Cacheart.
Da ist nur die Frage, ob OC dann nicht in die Copyright-Rechte des Nutzers eingreift. Aber wenn das Attribut durch den Typ ersetzt würde, wäre das meiner Meinung nach nicht der Fall.
Sonst kann man ja gar keine Innovationen mehr durchbringen.

Um nach unterschiedlichen Safari-Aufgabestellungen zu suchen, könnte man Tags (Hashtags?) einsetzen.
Auch eine Idee, um diese Doppelsafaris (zwei gleiche Safaris zu einem Thema) zu beheben wäre die Methode, die schon häufig in Foren genutzt wird.
Wenn man den Cachetitel eingibt, werden automatisch ähnliche Cachetitel als Drop-Down angezeigt. Das wäre doch was nützliches.
Titel: Re: Safari Nomenklatur
Beitrag von: 4_Vs am 06. Juli 2017, 17:36:01
Hallo zusammen,

warum muss der Safari-Cache ein eigener Cachetyp sein? Habe das nicht ganz verstanden.

Es gibt doch ein Attribut ... somit ist es doch letztenendes ein Virtual mit dem Attribut Safari, das entspricht doch auch der Tatsache ... oder wo habe ich hier einen Denkfehler?
Titel: Re: Safari Nomenklatur
Beitrag von: ekorren am 06. Juli 2017, 18:42:52
Es gibt doch ein Attribut ... somit ist es doch letztenendes ein Virtual mit dem Attribut Safari, das entspricht doch auch der Tatsache ... oder wo habe ich hier einen Denkfehler?
Darin, dass es eben nicht eine Untergruppe desselben ist, sondern etwas grundverschiedenes.

Tatsache ist doch: Ein Safari-"Cache" hat von allem, was wir hier bei OC suchen, am wenigsten mit allen anderen Typen zu tun. Es gibt keine Dose (ok, das gibt es bei anderen Virtuals auch nicht). Es gibt aber auch keine konkrete Stelle. Dort, wo man ihn auf der Karte findet, kann man im Allgemeinen überhaupt nichts dafür tun, um ihn zu "finden" - nicht einmal in der Nähe. Man muss beim Log ganz anders damit umgehen, z.B. darauf achten, was andere schon geloggt haben, und Koordinaten aufnehmen. Aber insbesondere ist es inhaltlich etwas vollkommen anderes: Bei allen anderen Typen geht es darum, etwas zu besuchen, was der Owner einem zeigen will und eine Aufgabe am vorgesehenen Ort zu erfüllen - bei Safaris geht es darum, selber etwas zu finden und anderen zu zeigen, und zwar gerade nicht am vom Owner genannten Ort. Es ist also vom Grundgedanken her das glatte Gegenteil eines normalen Virtuals!

Die einzige Gemeinsamkeit zwischen "normalen" Virtuals und Safaris ist demnach das Fehlen einer realen Dose. Alle anderen Cachetypen haben da mit der Existenz einer realen Dose eine wesentlich größere Gemeinsamkeit. Wenn man also der Ansicht ist, dass Safaris und Virtuals eigentlich dasselbe wären... nun, mit demselben Argument kann man auch alles andere zusammenfassen und die Typen gleich ganz abschaffen. Ein Rätselcache... ist das nicht sowieso dasselbe wie ein Virtual, nur halt mit Dose, und wie ein Tradi, also an den Koordinaten, nur halt an anderen als im Listing?

Sowohl technisch wie auch inhaltlich ist die Zusammenfassung von Safaris mit Virtuals bestenfalls eine Notlösung mit dem einzigen Vorteil, dass man dafür nichts Neues einbauen musste. Die allenfalls aus der Anfangszeit zu erklären ist, als "locationless virtuals" noch eine Ausnahme waren. Oder daraus, dass es Bodensprech halt damals auch so gemacht hat. Nur dass die dann irgendwann es ganz abgeschafft haben, während man sich hier entschieden hat, dass Safaris ein zentral integraler Bestandteil der Plattform sind. Und im selben Maße, wie die Safaris an Bedeutung gewonnen haben, ist die unlogische Zusammenfassung von Virtuals und Safaris störend geworden.

Ja, es stört mich, dass es im Profil eines Cachers nur ein Eintrag für "Virtual" gibt. Ich hätte gerne getrennte Statistiken für Safaris und location based virtuals. Alles andere wird ja auch getrennt aufgelistet.

Ja, es stört mich, dass Safaris auf der Landkarte an den Listingkoordinaten zu sehen sind und man immer erstmal reinklicken muss, um zu sehen, dass das eine Safari ist und da gar nichts zu loggen ist.

Ja, es stört mich, dass es keinen eigenen newlogs-Abschnitt für Safaris gibt. Denn neue Logs für Safaris machen neugierig, was die Leute so gefunden haben, da blättere ich gerne mal rein.

Ja, es stört mich auch, dass in der newlogs-Seite Safaris beim Land der Listingkoordinaten aufgelistet sind. Wenn jemand eine Safari loggt, die in Australien gelistet ist, hat er ja noch lange keinen Cache in Australien gemacht.


Und so ist am Ende das einzige Argument, was mir für die Beibehaltung des Status quo einfällt, das klassische:
Es ist schon immer so gewesen - am letzten Tag wird vorgelesen.
(ok, und dass jede Änderung Arbeit macht ;) )
Titel: Re: Safari Nomenklatur
Beitrag von: MikroKosmos am 06. Juli 2017, 20:07:48
Da stimme ich ekorren und anderen Vorschreibern sehr zu.
Ein eigener Cachetyp für Safaris wäre wirklich schön und nützlich.

Die Erkennbarkeit auf der Karte wäre sehr hilfreich.

Die Fund-Statistik sollte hinsichtlich der Safari-Caches ebenfalls modifiziert werden.
Das Werten der Safaris mit dem Land der Listing-Koordinaten finde ich bisher recht verwirrend und falsch.
Für Safaris wäre "gar keine Landesnennung" oder einfach "Erde" o.k..  :)
(Das echte Land des individuellen Fundes wäre wohl schwieriger zu realisieren.)
Titel: Re: Safari Nomenklatur
Beitrag von: 4_Vs am 07. Juli 2017, 20:08:43
Heho,

alle Argumente könnten auch mit der richtigen Steuerung von Attributen erledigt werden.

Wir hatten vor einigen Jahren mal die Idee, die Cachetypen zu reduzieren und alles über Attribute bzw. Hashtags zu regeln - wenn wir jetzt wieder mit einem extra Cachetyp anfangen, werden wir das nie schaffen.

Das würde z. B. auch für das Entfernen von Mathe / Physik Caches sprechen, und dafür Attribute setzen etc.

Man müsste die "Art" der Dose (oder eben nicht) anhand vom Cachetyp bestimmen und die "Art" des Caches anhand vom Attribut.

VG
Michael

Titel: Re: Safari Nomenklatur
Beitrag von: Der Windling am 10. Juli 2017, 12:55:51
Ich wäre auch dafür, dass Safaris ein eigener Cachetyp werden. Mit einem eigenen, klar von Virtuals zu unterscheidendem Symbol und eigenem Zähler.

Die Unterscheidung nur durch ein Attribut ist in der Praxis meist nicht wirklich praktikabel. Und wo ist das Problem mit mehr/weiteren Cachetypen?
Titel: Re: Safari Nomenklatur
Beitrag von: ekorren am 10. Juli 2017, 13:02:59
alle Argumente könnten auch mit der richtigen Steuerung von Attributen erledigt werden.

In der Theorie gebe ich dir insofern recht, dass der "Cachetyp" auch nur eine Art von Attribut ist. Allerdings kein gleichwertiges zu den anderen: Er ist ein übergeordnetes Attribut, nach dem Caches auf der Landkarte dargestellt und in der Statistik getrennt werden und so weiter.

Nun geht es aber doch gar nicht um die technische Frage, ob der Cachetyp auch als Attribut hinterlegt werden kann und ob das vielleicht technisch eleganter wäre oder so. Es geht darum, was man als Benutzer sieht und dass man möglichst leicht eine Vorauswahl treffen kann, was man überhaupt anschauen will. Und da ist eben die Frage: Was braucht man dafür? Und das ist nicht unbedingt ein elegantes Tag-System, sondern eine solide, verständliche und zuverlässige Grundklassifizierung. Und jetzt stellt sich eben die Frage, wonach man diese Grundklassifizierung vornehmen will.

Der eine ist vielleicht der Meinung, dass nur "Dose" und "keine Dose" eine Rolle spielt - wenn man natürlich eh nur "Dose" suchen will und sich für nichts anderes interessiert, reicht das.

Der andere mag aber ganz anderer Meinung sein, nämlich dass die Art der Aufgabe vielleicht sogar wichtiger ist. Bzw. die Frage, wo man etwas findet und was man finden soll. Das führt dann zu

* Ziel vom Owner bestimmt, Zielort auf Karte (Tradi und die meisten Virtuals)
* Ziel und Route am Startort vom Owner bestimmt, Startort wie auf Karte (Multi, leider manchmal auch Virtual)
* Ziel vom Owner bestimmt, Ort woanders, aber in der Nähe, Vorarbeit erforderlich (Mystery, leider manchmal auch Virtual)
* Es gibt überhaupt keinen vorgesehenen Zielort, Ort irgendwo, man muss selber etwas finden und präsentieren (Safari)

Und das ist einfach eine ganz andere Aufgabe, in absolut jeder Hinsicht. Safaris sind eigentlich ein eigenes Hobby, verwandt dem Cachen, aber nicht dasselbe. Dass es da keine Dose gibt, ist zwangsläufig, aber trotzdem ist ein "normaler" Virtual viel ähnlicher zum klassischen Cachen als es eine Safari ist. Und damit ist einfach die Grundklassifizierung "Alles, was keine Dose hat, ist eh dasselbe" falsch.

Wenn man mal träumen darf, würde die Plattform das Hobby "Safari" neben dem Hobby "Cachen" angepasst unterstützen. Das würde dann z.B. bedeuten, dass man die Fundkoordinaten in ein Extrafeld eingeben kann (muss), die Übersichtskarten intern verfügbar sind, oder auch Suchfunktionen einen dabei unterstützen, herauszufinden, ob ein bestimmtes Objekt schon mal geloggt wurde. Aber es würde eben erstmal bedeuten, dass man akzeptiert, dass es nicht dasselbe ist.

Wie gesagt: Wie man das intern technisch löst, ist eigentlich (!) egal. Natürlich könnte man das Safariattribut auswerten, um auf der Karte verschiedene Symbole darzustellen oder auch Safaris ganz auszublenden, und um die Statistiken und die newlogs-Seite zu trennen. Wichtig ist nicht unbedingt das "wie", sondern "dass". Dann kann man aber auch gleich einen eigenen Listingtyp nehmen, das ist m.E. deutlich logischer als erst zu sagen, es ist dasselbe (obwohl es das nicht ist) und dann an allen möglichen Stellen mit einer Extrabehandlung auseinanderzufummeln...

Titel: Re: Safari Nomenklatur
Beitrag von: 4_Vs am 11. Juli 2017, 17:43:55
Servus, ich bin ja bei euch - wenn ich mich recht erinnere "bestimmt" Garmin das GPX Format, beim Einführen weiterer Cachetypen gibt es aber Kompatibilitätsprobleme mit den Navis, da die dort als Unknown gezeigt werden ... oder so ähnlich.
Mic@, wir hatten doch mal eine ewig lange Diskussion zu dem Thema, findest Du die wieder?
Mir war, als gäbe es ein technisches nicht überwindbares Problem, weswegen wir überhaupt auf das Thema Attribut und Hashtags gekommen sind ...


Gesendet von iPhone mit Tapatalk
Titel: Re: Safari Nomenklatur
Beitrag von: Der Windling am 11. Juli 2017, 18:56:33
Servus, ich bin ja bei euch - wenn ich mich recht erinnere "bestimmt" Garmin das GPX Format, beim Einführen weiterer Cachetypen gibt es aber Kompatibilitätsprobleme mit den Navis, da die dort als Unknown gezeigt werden ... oder so ähnlich.

Das mit dem .gpx-Format bei Garmin ist zwar ärgerlich, aber es geht ja auch um die Darstellung auf der OC-Website. Auch wenn sich dann nichts am Symbol im Navi ändert, wäre eine klarere Darstellung auf der Karte doch wünschenswert. ;)
Titel: Re: Safari Nomenklatur
Beitrag von: mic@ am 11. Juli 2017, 21:05:22
Zitat von: 4_Vs
Mic@, wir hatten doch mal eine ewig lange Diskussion zu dem Thema, findest Du die wieder?

Meinst Du diesen Thread hier?
https://forum.opencaching.de/index.php?topic=2466.0
Titel: Re: Safari Nomenklatur
Beitrag von: ekorren am 11. Juli 2017, 23:45:01
Mir war, als gäbe es ein technisches nicht überwindbares Problem, weswegen wir überhaupt auf das Thema Attribut und Hashtags gekommen sind ...
Ein unüberwindbares technisches Problem, was einen Safari-Typ verbietet, müsste doch wohl wegen derselben Unüberwindbarkeit zumindest die Typen "Drive in" und "Mathe-/Physik" verbieten ;-)

Garmin kennt zumindest laut dieser Liste (https://www.gpsbabel.org/htmldoc-1.5.3/GarminIcons.html) ein Icon für "Locationless (reverse) Cache" - was nichts anderes ist (war) als unsere Safaris. Ok, nicht jedes Garmin-GPS, aber das gilt auch für die meisten anderen Icons.

Titel: Re: Safari Nomenklatur
Beitrag von: Schatzforscher am 16. Juli 2017, 22:57:32
Hallo zusammen,

bin auch für eine eigene Cacheart. Fände es richtig super, diese sofort auch ohne Anwahl von Attributten erkennen zu können. Außerdem wäre es auch ein tolles Abweichungsdetail zu anderen Plattformen.

Ich wäre allerdings weiterhin dafür diese in der Fundstatisik als vollwertigen Fund zu zählen. Sehe hier auch keinen Grund, warum das nicht so sein sollte. Denn die übrigen Virtuals werden auch ganz normal in der Fundstatistik addiert.

Viele Grüße
Schatzforscher

Titel: Re: Safari Nomenklatur
Beitrag von: 4_Vs am 19. Juli 2017, 14:44:46
Mir war, als gäbe es ein technisches nicht überwindbares Problem, weswegen wir überhaupt auf das Thema Attribut und Hashtags gekommen sind ...
Ein unüberwindbares technisches Problem, was einen Safari-Typ verbietet, müsste doch wohl wegen derselben Unüberwindbarkeit zumindest die Typen "Drive in" und "Mathe-/Physik" verbieten ;-)
Dieser werden aber auch nicht korrekt in Garmingeräten angezeigt ....

Garmin kennt zumindest laut dieser Liste (https://www.gpsbabel.org/htmldoc-1.5.3/GarminIcons.html) ein Icon für "Locationless (reverse) Cache" - was nichts anderes ist (war) als unsere Safaris. Ok, nicht jedes Garmin-GPS, aber das gilt auch für die meisten anderen Icons.
Na ja,

Safari ist streng genommen kein Locationless Cache, sondern ein Locationbased Cache :)

Und gerne nochmal, die Argumente von euch für eine eigene Cacheart schließen die Umsetzung als Attribut bzw. Hashtag nicht aus, es würde die ganze Sache nur eleganter machen ... und ob man dann bei einer Suchanfrage für Safaris virtuelle Caches mit Safari Attribut gezeigt (auch gerne mit einem anderen Icon) oder ob man die "Cacheart" Safari gezeigt (auch gerne mit einem anderen Icon), ist doch sekundär.

Streng genommen ist ein Safari kein "Cache", sondern ein "Collect" :) - denn beim Safari wurde nichts versteckt ^^

Ich glaube jetzt einfach eine weitere Cacheart einzuführen bedient zwar den aktuellen Wunsch, bringt uns aber später beim nächsten Cacheart oder Collectart :) vor die gleiche Diskussion ... Garmingeräte zeigen dann die ganzen neuen Cachearten als "unknown" an - das hilft dann den Navicachern nichts, sondern nur den Smartphonecacher ....

jm2c
Titel: Re: Safari Nomenklatur
Beitrag von: Der Windling am 20. Juli 2017, 12:16:17
Mir war, als gäbe es ein technisches nicht überwindbares Problem, weswegen wir überhaupt auf das Thema Attribut und Hashtags gekommen sind ...
Ein unüberwindbares technisches Problem, was einen Safari-Typ verbietet, müsste doch wohl wegen derselben Unüberwindbarkeit zumindest die Typen "Drive in" und "Mathe-/Physik" verbieten ;-)
Dieser werden aber auch nicht korrekt in Garmingeräten angezeigt ....
Mir persönlich geht es weniger um die Darstellung im Garmin als auf der OC-Karte. Dort suche ich mir meine Cachetour raus - und nicht auf dem GPS-Gerät. Unterwegs weiß ich dann schon ungefähr, was wo liegt. ;)

Und gerne nochmal, die Argumente von euch für eine eigene Cacheart schließen die Umsetzung als Attribut bzw. Hashtag nicht aus, es würde die ganze Sache nur eleganter machen ... und ob man dann bei einer Suchanfrage für Safaris virtuelle Caches mit Safari Attribut gezeigt (auch gerne mit einem anderen Icon) oder ob man die "Cacheart" Safari gezeigt (auch gerne mit einem anderen Icon), ist doch sekundär.
Ich finde, es macht die Suche wesentlich komfortabler, wenn man nur die Cacheart anklicken und nicht noch Attribute auswählen muss.
Außerdem schaffen es die meisten Owner durchaus, die richtige Cacheart zu wählen - die richtigen Attribute zu setzen fällt da einigen augenscheinlich schon etwas schwerer. Somit würde es eine eignen Cacheart "Safari" dann schon einfacher machen.

Ich glaube jetzt einfach eine weitere Cacheart einzuführen bedient zwar den aktuellen Wunsch, bringt uns aber später beim nächsten Cacheart oder Collectart :) vor die gleiche Diskussion ...
Ich kann mir zwar jetzt gerade auf Anhieb keine neue, weitere Cacheart vorstellen, aber: Wo wäre das Problem, gegebenenfalls noch eine weitere Cacheart einzuführen?
Wie von einigen Vorredner schon geschrieben: Mathe-/Physik-Caches sind für mich auch eher eine Unterart des Mysteries, die man mit Attributen gut darstellen könnte, haben aber auch ein eigenes Symbol auf der Karte...

Safari ist streng genommen kein Locationless Cache, sondern ein Locationbased Cache :)
Naja, gaaaanz streng genommen ist eine Safari dann ja eher ein Locationless-Locationbased-Cache... ;)


Alles in allem: Ich fände es schön, wenn man über ein eigenes Safari-Icon die Virtuals, die sich genau an den angegebenen Koordinaten befinden besser von den Safari-Aufgaben unterscheiden könnte.

Titel: Re: Safari Nomenklatur
Beitrag von: 4_Vs am 20. Juli 2017, 12:25:33
Ich glaube jetzt einfach eine weitere Cacheart einzuführen bedient zwar den aktuellen Wunsch, bringt uns aber später beim nächsten Cacheart oder Collectart :) vor die gleiche Diskussion ...
Ich kann mir zwar jetzt gerade auf Anhieb keine neue, weitere Cacheart vorstellen, aber: Wo wäre das Problem, gegebenenfalls noch eine weitere Cacheart einzuführen?
Wie von einigen Vorredner schon geschrieben: Mathe-/Physik-Caches sind für mich auch eher eine Unterart des Mysteries, die man mit Attributen gut darstellen könnte, haben aber auch ein eigenes Symbol auf der Karte...
Meine Worte, daher hatten wir damals den Gedanken die Cachearten zu reduzieren und mit Attributen zu arbeiten - und das mit dem Klicken auf der Karte/Suche ... wenn Du einen Haken bei Safari machst und dann im Hintergrund nach "ohne Dose, Attribut Safari" gesucht wird oder "Safari Cacheart" spielt doch "vorne" keine Rolle.

Wir sollten zwischen Frontend und Backend unterscheiden - Frontend bin ich ja bei euch, würde mir auch ein eigenes Symbol wünschen, backendig sehe ich eine Reduzierung der Cachearten als sinnvoller an.
Titel: Re: Safari Nomenklatur
Beitrag von: Der Windling am 20. Juli 2017, 14:33:31
Ich glaube jetzt einfach eine weitere Cacheart einzuführen bedient zwar den aktuellen Wunsch, bringt uns aber später beim nächsten Cacheart oder Collectart :) vor die gleiche Diskussion ...
Ich kann mir zwar jetzt gerade auf Anhieb keine neue, weitere Cacheart vorstellen, aber: Wo wäre das Problem, gegebenenfalls noch eine weitere Cacheart einzuführen?
Wie von einigen Vorredner schon geschrieben: Mathe-/Physik-Caches sind für mich auch eher eine Unterart des Mysteries, die man mit Attributen gut darstellen könnte, haben aber auch ein eigenes Symbol auf der Karte...
Meine Worte, daher hatten wir damals den Gedanken die Cachearten zu reduzieren und mit Attributen zu arbeiten - und das mit dem Klicken auf der Karte/Suche ... wenn Du einen Haken bei Safari machst und dann im Hintergrund nach "ohne Dose, Attribut Safari" gesucht wird oder "Safari Cacheart" spielt doch "vorne" keine Rolle.

...aber bei der Darstellung auf der Online-Übersichts-Karte und beim Listing anlegen spielt es eine Rolle! Wie oben schon geschrieben, ist es für den Owner, der ein Listing anlegt so einfach besser zu unterscheiden und auf der Karte liegen oft Safaris an Orten rum, die man dort nicht erfüllen kann. Das ist etwas störend, wenn man nicht auf Anhieb sieht, dass dort eben kein Virtual sondern eine Safari liegt. Selbst für die Leute, die keine Safaris mögen, aber gern mal einen Virtual besuchen wäre ein eigenes Safari-Icon praktisch, denn die könnten die Safaris auf der Karte dann noch leichter ausblenden...
Es wird doch auch zwischen Virtual und Webcam unterschieden, obwohl bei beiden keine Dose vor Ort ist. Safaris sind für mich (und einige andere hier) eben kein Virtual-mit-Attribut sondern etwas eigenständiges. So wie ein Multi und ein Mystery eigene Cachearten sind, auch wenn man bei beiden erstmal irgendetwas machen muss um danach eine Dose zu finden. Sonst könnte man ja z.B. auch die Mysteries als Tradi mit Rätsel-Attribut listen oder gleich überall nur ein einziges Icon verwenden und auf die Cachebeschreibung verweisen...

Daher nochmal die Frage: Wo ist das Problem mit zusätzlichen Cachetypen? (Das mit der Darstellung auf dem Garmin habe ich schon verstanden, aber ich finde nicht, dass man sich da unbedingt nach dem Garmin-Standart richten muss, andere Cachearten können da ja auch nicht dargestellt werden und das stört auch niemanden. Und die Attribute zeigt mir mein Garmin auch nicht an.)

Versteh mich nicht falsch, die Mathe-/Physik-Cachesymbole stören mich nicht - auch wenn ich persönlich sie unnötig finde, da es hier letztendlich doch immer um ein Rätsel geht.
Diese Cacheart könnte man -für mich- durchaus abschaffen, aber das ist eigentlich eine eigene Diskussion. Vielleicht findet ein anderer diese Unterscheidung total gut...


Wir sollten zwischen Frontend und Backend unterscheiden - Frontend bin ich ja bei euch, würde mir auch ein eigenes Symbol wünschen, backendig sehe ich eine Reduzierung der Cachearten als sinnvoller an.
Da verstehe ich jetzt leider nicht, wo da im Backend das Problem liegt...
Titel: Re: Safari Nomenklatur
Beitrag von: 4_Vs am 20. Juli 2017, 14:58:26
Also entweder drücke ich mich falsch aus oder ihr wollt einfach nicht meine Sichtweise verstehen:

Was hat denn ein eigenes Icon damit zu tun, ob es eine Cacheart oder ein Attribut ist?

Wir (oder ich) diskutiere hier doch 2 Sachen:

1. Frontend (also das was der Cacher sieht bzw. bedient)
- Ein Safari soll per eigenem Icon angezeigt werden
- man will Safari nicht per Attribut "bestimmen", sondern gezielt nach Safari suchen können

2. Backend (also das, was der Server im Hintergrund macht bzw. was andere Dienste im Hintergrund mit unseren / euren Daten machen)

ad 1) hier sind wir uns in allen Punkten einig und die beiden Punkte sind auch als nicht eigene Cacheart umsetzbar

ad 2) hier sollten wir die Sache anders umsetzen als bisher
- Physik / Mathe ist für mich keine eigene Cacheart, sondern entweder ein Virtual oder ein Tradi zum "Rätseln" - also Mystery - ob man dafür ein eigenes Symbol nimmt oder nicht ist Geschmackssache
- Safari ist für mich keine eigene Cacheart
- Webcamcache ist für mich keine eigene Cacherart
- Mysterie ist keine eigene Cacheart

- Multi ist ein Grenzfall, denn hier können ja "virtuals" und "physicals" gemischt sein, also das vllt. als eigene Cacheart lassen

Ich würde einfach die "Engine" im Hintergrund reduzieren und über eine Attributisierung das Ganze abwickeln, ich glaube damit würde man in die Zukunft blickend das ganze Thema charmanter darstellen können.



Finde ich beides Super!
Titel: Re: Safari Nomenklatur
Beitrag von: Der Windling am 20. Juli 2017, 22:29:21
Ich fürchte, ich verstehe Dich wirklich nicht...

Definiere doch bitte mal was Du unter "Cacheart" verstehst. Für mich ist das nicht nur das Icon, sondern eben auch das, was ich in der Liste "Cacheart" auswählen kann, wenn ich ein neues Listing erstelle. Und genau DA hätte ich auch gerne "Safari" zum auswählen - und eben nicht nur "Virtual" plus Attribut. Denn Attribute werden meiner Meinung nach oft nicht oder falsch gesetzt.

Nach meiner persönlichen Definition sind sowohl Safaris als auch Webcam-Caches, Multis und Mysteries eigene Cachearten. Bei Mathe-/Physik-Caches könnte man diskutieren (das würde ich dann aber lieber in einem eigenen Thread machen).


Vielleicht kannst Du uns allen auch mal die "Engine im Hintergrund" erklären - für die, die damit nicht so befasst sind...

Titel: Re: Safari Nomenklatur
Beitrag von: MikroKosmos am 10. August 2017, 19:53:22
Ein wichtiger Unterschied zwischen dem Cachetyp und den Attributen ist noch:

Der Cachetyp ist genau(!) 1 aus x. ("Pflichtfeld")

Attribute können hingegen n aus y sein und sie sind (alle) optional anzugeben.

Wenn man auf dem Server aus Kombinationen von Einzelattributen etwas herleiten möchte, wird das schwierig, oder?
Vor allem könnten sich Attribute eventuell sogar widersprechen.
Hmm, beim Programmieren fände ich es wesentlich einfacher, wenn man Unterscheidungen nach einem expliziten Typ machen kann.
Titel: Re: Safari Nomenklatur
Beitrag von: Le Dompteur am 09. November 2017, 20:16:42
Mein allererster Herzenswunsch ist und bleibt ein sinnvolles angepasstes Safari-Handling.
Das bedeutet in erster Linie, Safaris von den location based virtuals zu trennen und als eigenen Typ zu führen. Denn sie sind nun mal etwas völlig anderes und sprechen eine andere Zielgruppe an.
Ja, da bin ich auch sehr dafür! (Ich meine, da gibt es sogar schon irgendwo einen Thread dazu hier im Forum...)

Da Safari-Caches wegen ihrer schieren Quantität sich zu einer beliebten Alternative zu mangelnder Dosensuchoptioen entwickelt haben, warum nicht den Typ "Mathe/Physik-Cache" weg-tip-exen und darauf das Safari-Icon malen?[Salopp gedacht]... wenn es im Backend so kompliziert ist, den Bedarf eines neuen Typus umzusetzen?
Einen Mathe/Physik habe ich bisher erst einmal gelegt, hätte das aber auch mit einem Attribut kennzeichnen können. Ebenso für "drive-in".
Auch wenn sich die Diskussion schon ewig hinzieht und im Kreis dreht: Safaris sind da und kommen verstärkt in den Fokus. Es ist Zeit, eine Bedarfsanpassung vorzunehmen.
Titel: Re: Safari Nomenklatur
Beitrag von: Der Windling am 21. Januar 2018, 21:12:20
Schade, jetzt ist diese Diskussion schon wieder ergebnislos eingeschlafen...

In letzter Zeit werden es (gefühlt) immer mehr Safaris. Wäre es nicht langsam Zeit für einen eigenen Cachetyp?  ;)
Titel: Re: Safari Nomenklatur
Beitrag von: Slini11 am 21. Januar 2018, 23:51:22
Wäre es nicht langsam Zeit für einen eigenen Cachetyp?  ;)
Während der heutigen Jahreshauptversammlung von Opencaching Deutschland e.V. wurde beschlossen, dass es bald eine Abstimmung im öffentlichen Forum geben wird,
in der darüber abgestimmt wird, ob (u.a. dieser) Cachetyp in Zukunft eingeführt werden wird.
Titel: Re: Safari Nomenklatur
Beitrag von: Der Windling am 22. Januar 2018, 00:37:56
Klasse! Danke für die Info!
Titel: Re: Safari Nomenklatur
Beitrag von: Riedxela am 07. Februar 2019, 10:28:35
Ist das Thema "Safari-Cache" als eigener Cachetyp nun endgültig eingeschlafen oder gibt es da noch Bestrebungen vom OC-Entwicklerteam? Die Vorteile wurden ja in der Vergangenheit schon ausgiebig diskutiert und dargelegt. Ich würde mir jedenfalls einen eigenen Cachetyp für Safaris sehr wünschen.
Titel: Re: Safari Nomenklatur
Beitrag von: Le Dompteur am 07. Februar 2019, 22:08:34
Danke für das Wiederhervorholen eines alten, aber umso aktuelleren, Beschwers.
Ich würde mir jedenfalls einen eigenen Cachetyp für Safaris sehr wünschen.

Dito!

Allerdings müsste das Europaweit, auf allen Knoten, ähnlich passieren. Daß das Symbol, der *.gpx-code einheitlich interpretiert wird  Ein deutscher Alleingang würde am Ende zu Mehrarbeit führen. Gerade die Safaris sind prädestiniert für länder-/knoten-übergreifende Listings. Findet diesbezüglich schon / noch Kommunikation mit den anderen OC-Plattformen statt?
Titel: Re: Safari Nomenklatur
Beitrag von: FlashCool am 07. Februar 2019, 22:19:32
Danke für das Wiederhervorholen eines alten, aber umso aktuelleren, Beschwers.
Ich würde mir jedenfalls einen eigenen Cachetyp für Safaris sehr wünschen.

Dito!

Allerdings müsste das Europaweit, auf allen Knoten, ähnlich passieren. Daß das Symbol, der *.gpx-code einheitlich interpretiert wird  Ein deutscher Alleingang würde am Ende zu Mehrarbeit führen. Gerade die Safaris sind prädestiniert für länder-/knoten-übergreifende Listings. Findet diesbezüglich schon / noch Kommunikation mit den anderen OC-Plattformen statt?

Gibt meines Wissens nach nur 2 Knoten bzw. Seiten die federführend und jeweils eine eigene Codebasis haben. Polen und Deutschland. Die beiden müssten sich einigen. Andere Länder / Seiten sind darauf aufgeschaltet - soweit ich informiert bin. Lasse mich aber gerne berichtigen.
Titel: Re: Safari Nomenklatur
Beitrag von: ekorren am 08. Februar 2019, 10:36:15
Allerdings müsste das Europaweit, auf allen Knoten, ähnlich passieren. Daß das Symbol, der *.gpx-code einheitlich interpretiert wird  Ein deutscher Alleingang würde am Ende zu Mehrarbeit führen. Gerade die Safaris sind prädestiniert für länder-/knoten-übergreifende Listings.
Ich stelle eine Zusatzfrage: Sind Safaris in dieser Form überhaupt bei den anderen OC-Plattformen verbreitet oder sind die nicht eh schon ein deutscher Alleingang?

Mal ganz abgesehen davon, dass von einem automatisierten Austausch mit anderen OC-Plattformen schon lange nur noch als Fernziel die Rede war, aber nicht als etwas, was innerhalb einer absehbaren näheren Zukunft voraussichtlich tatsächlich umgesetzt wird. Wir sollten nicht heute notwendige Verbesserungen ablehnen mit der Begründung, dass vielleicht in vielen Jahren das ein kleines bisschen Mehrarbeit verursachen würde, vielleicht aber auch nicht.

Titel: Re: Safari Nomenklatur
Beitrag von: Le Dompteur am 09. Februar 2019, 01:20:45
Ich stelle eine Zusatzfrage: Sind Safaris in dieser Form überhaupt bei den anderen OC-Plattformen verbreitet oder sind die nicht eh schon ein deutscher Alleingang?
Nein; Kluckens Safaris: "Silent keyboard (https://www.opencaching.de/viewcache.php?cacheid=177602)", "Coat of arms" (https://www.opencaching.de/viewcache.php?cacheid=177606) (wegen welcher sich übrigens eine "gewisse Eskalation" in Meißen bzgl., ob man solch tolle Idee beliebig aufweichen könne / solle, z.Zt. eskalativ entwickelte) oder "Mosaic Wall Art" (https://www.opencaching.de/viewcache.php?cacheid=177517) sind feine, kleine, findfreudige Safaris, die von einem polnischen Kollegen auf unseren Knoten kopiert wurden. Es wäre nur mehr höflich, es ihnen gleichzutun und eine Schnittstelle zu entwickeln, die - im Hintergrund automatisiert - "unsere" OC.de-Safaris auf andere Plattformen 1zu1-übertrüge.
Vorausgesetzt, natürlich immer, daß eine gemeinsprachliche Version des Listing-Textes vorläge! Hierzu schlage ich "english", als die "lingua Franca" des 21. Jhdts. vor.

Zitat
Wir sollten nicht heute notwendige Verbesserungen ablehnen mit der Begründung, dass vielleicht in vielen Jahren das ein kleines bisschen Mehrarbeit verursachen würde, vielleicht aber auch nicht.
Sicherlich müssten wir das nicht, in sturem DE-OConly-Alleingang!
Aber wir könnten es besser! Wir könnten allen Interessierten, über vier-Ecken-und-irgendwie-doch-Blutsbrüderschafts-verschworenen-vernetzten-OConly-EUROPA-Knoten einen Dialog anbieten, wie eine gemeinsame OKAPI-Schnittstelle aussehen müsse, damit irgendwann die Safaris mit einem-Maus-Klick auf allen OC-Regionalablegern gelistet würden können. 'wäre doch cool: Du stellst zu Deiner Safari einen Listingtext unter dem Reiter "Englisch" ein und Deine Suchaufgabe würde sekundenschnell auf dem Niederländischen, Italienischem, Isländischen, Polnischem (aber scheinbar "eigenbrödlerischen") OPENcaching-knoten / Derivaten lanciert.

Zuviel verlangt?
Ja; aber: "I have a dream"...!
Titel: Re: Safari Nomenklatur
Beitrag von: FlashCool am 09. Februar 2019, 09:10:19
Zitat
Aber wir könnten es besser! Wir könnten allen Interessierten, über vier-Ecken-und-irgendwie-doch-Blutsbrüderschafts-verschworenen-vernetzten-OConly-EUROPA-Knoten einen Dialog anbieten, wie eine gemeinsame OKAPI-Schnittstelle aussehen müsse, damit irgendwann die Safaris mit einem-Maus-Klick auf allen OC-Regionalablegern gelistet würden können. 'wäre doch cool: Du stellst zu Deiner Safari einen Listingtext unter dem Reiter "Englisch" ein und Deine Suchaufgabe würde sekundenschnell auf dem Niederländischen, Italienischem, Isländischen, Polnischem (aber scheinbar "eigenbrödlerischen") OPENcaching-knoten / Derivaten lanciert.

Ein Gedanke, den ich immer mal wieder dazu hatte...

Wäre es denn technisch möglich, Caches (also Listing und alles was zum Cache gehört) vom Programmcode zu trennen? Also eine Datenbank nur für die Caches und der Programmcode in einer separaten Datenbank? Dann hätte man theoretisch eine Cache-Datenbank, die für alle Knoten z.B. über die OKAPI-Schnittstelle angesprochen werden könnte. Alles drum herum, d.h. wie geht der Programmcode mit der OKAPI um und welche zusätzlichen Programmfeatures bietet jeder Knoten, wäre dann losgelöst und kann jeweils "frei gelebt werden".

Das das sicherlich ein großes Projekt ist, ist mir schon klar. Die Entwicklerressourcen sind begrenzt, aber wenn die Idee von OC.de getragen würde, könnte man im nächsten Schritt mit den polnischen Kollegen in Kontakt treten und die Ideen diskutieren. Falls es dann einen Konsens gibt, bieten sich vielleicht mehr (polnische 😉) Entwicklerressourcen an?

Nur so ein Gedanke...