Ich habe jetzt viel darüber nachgedacht und ich denke ich werde in nächster Zeit, wenn die Langweile droht, diese Projekt mal angehen.
Ich denke grad in Deutschland gibt es immer mehr solcher 24h Automaten beim Bauern um die Ecke, aber wenn man doch mal etwas am Reisen ist, wäre es schön wenn es eine Karte mit Automaten in der Nähe gibt.
Momentan gibt es auch viele unscharfe Daten, wie bspw. Food für Süßwaren oder Food im Allgemeinen wenn es ein Käseautomat ist. Oder vending=cheese, obwohl es eig. vending=food und food:cheese=yes heißen müsste. Auch die Wiki Seite ist noch etwas dünn: https://wiki.openstreetmap.org/wiki/Tag:vending%3Dfood.
Wäre schön wenn es in diesen Punkten saubere und aktuellere Daten bald gibt.
Hm, generell scheint das tagging in dem Bereich nicht so ganz eindeutig. o.g. Projekt scheint z.b: Automaten zu ignorieren, die mit vending=eggs;milk;food getaggt sind und sich auf vending=food zu fokussieren.
Ich hab’ mal einen request in Github aufgemacht … aber es scheint (noch) nicht so ganz genau definiert zu sein was “richtig” ist.
Unabhängig davon finde ich die Karte, schon mal so weit wie sie bis jetzt programmiert ist, toll
Dass die Auswerter die Semikolon getrennten Werte nicht so gerne auswerten, kann man ja verstehen, da dabei mehr Code geschrieben werden muss.
Von daher, würde es denn “unserer” Datenbank sehr schaden, wenn wir diese aufzählenden Werte im ähnlichen Format angeben, wie wir es auch bei den verschiedenen Kraftstoffarten bei Tankstellen so machen, Beispiel:
fuel:octane_95 yes vending:milk=yes
fuel:GTL_diesel yes vending:egg=yes
fuel:adblue no vending:food=yes
Auch beim sport=* tagging gefällt mir ehrlich gesagt diese Aufzählerei durch Semikolon getrennt nicht wirklich.
Ich komme mit dieser Semikolon-Aufzählung überhaupt nicht klar (kommt da zb. ein Leerzeichen oder nicht) und so geht’s wohl auch den Auswertern. Ich vermeide derartige Einträge nach Möglichkeit.
Welchen Schaden haben wir dadurch? Wir müssen mehr tags taggen, aber imho zugunsten der Übersichtlichkeit und Wartbarkeit.
Auch auf Programmiererseite (hab kaum Ahnung von proggen) halte ich es für einfacher vending:milk auszuwerten, statt in Dillionen vending=schiess;mich;tot nach milk greppen zu müssen.
Nein, es geht nicht um das akzeptierte Tagging (amenity=vending_machine)!
Es gibt sicher eine Menge Automaten, die nur ein Ding “verkaufen”. Das passt also.
Nur das Second-Level Tagging um vending_machine=food ist quasi überhaupt nicht definiert. Und das lässt sich durchaus auch über eine Forumsdiskussion verbessern, ergänzen, erweitern.
Ein Ansatz ist ja schon dein Vorschlag selbst. Bei Automaten, die mehrere verschiedene Lebensmittel anbieten, funktioniert das Semikolon Tagging nicht, wie hier dargestellt wurde.
Da die neuen eher Exoten und ggf. zu mehrfach Lagerung pro Automat tendieren, könnte man doch generell diese Art einführen:
vending:milk=yes
vending:egg=yes
vending:food=yes
vending:drinks=yes
vending:sweets=yes
vending:bread=yes
vending:parking_tickets=yes
und zwei Taggingarten parallel weiterlaufen lassen. Ich meine das gibt es in anderen Bereichen auch…
Meh. Ich hatte kurz überlegt auf das völlig unpassende schlechteund imho falsche food einzugehen, es mir dann aber verkniffen.
Andererseits, guter Vorschlag, kann man drüber nachdenken und verwerfen oder auch nicht.
Da hast Du wohl meinen Vorschlag falsch verstanden. (Dieser war allerdings noch nicht ganz offensichtlich formuliert)
Ich wollte zum einen gar keine 3.Level-Ebene einführen (bzw. die bis jetzt angefangene unstrukturierte 3.Level-Ebene abschaffen) und zum anderen aber auf 2.Level-Ebene das neue Schema 2 (vending:*=yes/no) allerdings für alle vendings einführen. Wenn schon denn schon
(Deswegen war in meiner vorherigen Mitteilung in der unteren Liste der meistbenutzte Wert parking_tickets auch im Format von Schema 2 vending:parking_tickets=yes aufgeführt)
Schema 2 dann halt parallel zum alten Schema 1 (vending=*) laufen lassen, aber so damit keine neuen (komische/aufwendige) Semikolon-Aufzählungen in die Datenbank hereinkommen:
Wenn ein Automat nur eine Sorte von Verkaufsgütern anbietet, könnte gerne weiterhin nach Schema 1 definiert/gemappt/getaggt werden. Falls dann jemand in Schema 1 gerade “ausversehen” dabei ist wieder eine Aufzählung einzubauen, könnte JOSM eine Warnung ausgeben, das man doch erwägen könne Schema 2 zu verwenden
Natürlich sollten dann neue Automaten die nur eine Sorte anbieten auch durch Schema 2 getaggt werden dürfen…
Um die bestehenden Aufzählungen langsam aus der Datenbank herauszubekommen, könnte man neben den JOSM-Warnungen irgendwann vielleicht sogar Osmose/Streetcomplete/Keepright/maproulette Aufgaben generieren.
…finde ich nicht durchdacht. Es darf nur eine 3.Level Ebene geben, wenn EIN! Automat die Möglichkeit hat, Warenunterschiedliche Produkte anzubieten. Wenn es z.B. ein Hofhäuschen gibt, der mittels 2 Automaten frische Milch und frische Eier hergibt, bedeutet das natürlich das tagging von 2 amenity=vending (obwohl es dann sehr eng zugeht). Besonders bei vending=food kommt das 3.level zum Einsatz, so z.B.
Da ich so einen Automaten in meinem Bereich taggen möchte, versuche ich hier auch einen Versuch des einheitlichen Taggings.
Es wäre schön, wenn wir uns auf ein Schema einigen könnten. ( Korrektur: Hier verteilt sich das Angebot auf 3 Automaten)
P.S. Es ergäben sich imho weitere 3.level tags bei:
Grundsätzlich geht es darum, Semikolon-Anreihungen zu vermeiden.
P.P.S Korrektur eingefügt. Obwohl ich es selber beantwortet habe, aber was ist, wenn sich an einem Standort mehrere Automaten befinden, und man nicht sofort weis, was sich die Automaten aufteilen?
in iD wurden leider letztens erst die Aufzählungen (Schema 1) implementiert, da dies aus Erläuterungen des Wikis so verstanden wurde, dass das so gemacht werden soll.
Und nein, das soll jetzt kein Argument sein. Der Trend geht glaube ich allgemein weg von Semikolon-Werten. Früher nahm man healthcare:speciality= und dann ggf. mehrere Werte, in healthcare 2.0 wird auch schon wieder die Änderung in
health_specialty:=yes vorgeschlagen.
Ich nehme das als Beispiel, weil es das 2.0 Proposal auch schon länger gibt, aber healthcare:speciality hält sich bisher auch mit Aufzählungen.
Was bei “…=yes/no” oft auffällt ist, dass ganz gerne viel öfter “…=no” gesetzt wird als das eigentlich häufig relevantere “…=yes”.