…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.
Ich durfte letztens wieder nen Automaten taggn und bin zufällig auf meinen alten Beitrag gestoßen :D.
Find es toll was alles darüber diskutiert wurde.
Ich bin eigentlich ein Fan von Semicolons, string.split(“;”) und schon hat man alle Werte. Man muss natürlich prüfen wo Semicolons auftauchen und das entsprechend zusätzlich auswerten. Ich weiß auch nicht wie overpass damit umgeht.
Wenn ihr das ganze so mit Tankstellen vergleicht, dann würde ich auch diese Levelstruktur favorisieren.
Ich würde halt gerne sowas im Wiki dokumentieren, damit es ein für alle mal klar ist, wie wir jetzt solche Automaten taggn.
Auch würde ich gerne die in #25 genannten Imbissbuden rausschmeißen, wobei ich glaub die ist nicht mehr drin oder? Aber food ist halt food. Ob healthy oder nicht. Ich würde mich aber schwer tun zwischen raw_food und food zu unterscheiden, da ne ungebratene Wurst im Automaten halt auch kein raw_food mehr ist, sondern eher der in einer Imbissbude gleicht, in der der Grill noch nicht angeschmissen wurde.
