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”.
iD generiert solche “Werte in den Schlüssel” verschobene Ungeheuer aus Taginfo und nicht aus einer expliziten Konfiguration. Das ist zwar “Unterstützung” macht das ganze aber auch nicht sinnvoller (und bitte Healthcare 2.0 nur als schlechtes Beispiel für ein Taggingproposal verwenden, für was anderes ist es nicht gut).
Vom UI her ist es problemlos möglich Mehrfachwerte in einem Tag mit Checkboxen darzustellen, man muss also nicht wegen UI-Bedenken auf einen von der Datenstruktur hoffnungslosen Ansatz wechseln. Wenn schon sollte man die bestehenden Unfälle, z.B. payment:* auf was vernünftiges zurück migrieren.
Bezugnehmend auf #21 sehe ich leider doch das von mir beschriebene Problem:
Gerade für Food-Automaten stehen an einem Standort oft mehrere Automaten z.V.
Ich möchte nun als Mapper, der es (noch) nicht genau vor Ort recherchiert hat, nun sämtliche Food dort an dem Standort unterbringen.
Eine Anzahl der Automaten ist bekannt und deren gesamter Inhalt. Mein Vorschlag im 2.Level:
vending_machine:number=3
( …mit einem Node )
Dazu halt in der 2. Ebene alle Angebote mit:
vending=food
Weiter mit der 3. Ebene wie beschrieben.
Ist nur ein weiterer Vorschlag, um das Tagging ohne Vor-Ort Kenntnisse zu erleichtern.
Die Seite farmshops.eu ist tatsächlich eine interessante Lösung um Hofläden und Milch- und Lebensmittel-(Fleisch-, Eier-, Käse- …)Automaten schnell zu finden. Auf so etwas habe ich gewartet!
Leider scheint aber hinsichtlich der “food”-Automaten möglicherweise unser Mapping mehrdeutig zu sein. Hier https://farmshops.eu/#50.83939,12.93064,18z zum Beispiel werden die Imbiss(?)-Automaten auf dem Bahnsteig auch angezeigt, die aben aber nichts mit “farmshops” oder den im übertragenen Sinne dazu gehörigen Milch- und Fleisch-, Eier-, Käse-Automaten der Direktvermarkter zu tun.
Müssen wir da vielleicht was ändern oder wird falsch ausgewertet?
Zu #24 vending_machine:number=3
Ich vergleiche das mal mit einer Tankstelle. Hier erfassen wir ja auch nur die verschiedenen Spritsorten, nicht aber die Anzahl der Zapfsäulen. Insofern werden würde ich auf das vending_machine:number verzichten können ohne störenden Informationsverlust.