+1
delivery=yes wird schon verwendet für “frei für Lieferfahrzeuge”.
Ja, ich denke auch wir müßten uns zunächst mal auf einen Tag einigen und dann das Ganze im Wiki verankern.
Walter war ja nun wieder ganz schnell mit seiner Dorfapotheke, aber was bringt’s wenn wir letztendlich wieder ein “Sammelsurium” an Eigenschöpfungen haben.
Einheitliche Tags sind schließlich erstmal die Grundvorausetzung für Sachen wie eben von Trockennasenaffe in #16 beschrieben.
mfG Michael
Läßt sich ganz schnell anpassen - falls ihr euch wirklich einigen solltet.
Ansonsten halte ich delivery=* durchaus für angebracht, da hier auch immer der Zusammenhang zu beachten ist und es bestimmt keine Verwechslungsgefahr bei highway=* + delivery=* geben dürfte.
hab mal nachgefragt:
osm=# select count(*) from nodes where tags ? 'delivery' and tags ? 'amenity';
count
-------
173
osm=# select count(*) from ways where tags ? 'delivery' and tags ? 'amenity';
count
-------
65
kommt also schon einige mal in DACH+ und Umgebung vor. (3 von mir)
Ich würde das machen - Flyer gibt es hier nämlich keine. Und bevor ich die Webseiten der Restaurants einzeln absuche, schaue ich doch lieber auf eine zentrale Webseite.
Und warum gibt es keine OSM-basierte Handy-App oder Webseite dazu? Kein Wunder: Weil die Daten fehlen.
Klar gibt es z.B. in Deutschland diverse Webseiten, wo man einfach seine Postleitzahl eingibt und dann die Lieferservice angezeigt bekommt, die in diesem Gebiet liefern. Aber das ist keineswegs überall auf der Welt so. Und gerade dort, wo es sowas noch nicht gibt, halte ich es für durchaus sinnvoll, wenn man das mit OSM-Daten erreichen könnte - und damit einen weiteren Anwendungsfall von OSM erzeugen. Wenn man Restaurants mit Öffnungszeiten drin hat, was ist dann der Unterschied zu Lieferzeiten?
Ein Unterschied ist der weniger konkrete geographische Bezug:
Ein Restaurant hat einen Standort, dort muss man hingehen wenn man essen will. Damit ist ein unmittelbarer geografischer Bezug gegeben.
Das Essen für einen Lieferservice wird zwar auch irgendwo hergestellt, aber das muss nicht immer gleichzeitig ein Restaurant sein - und wo genau das Essen herkommt ist für den Nutzer des Lieferservices auch nicht so wichtig (es besteht ein loser Zusammenhang zu Dingen wie dem Liefergebiet, die für ihn tatsächlich wichtig sind, aber der Standort an sich ist eher egal).
Um mal einen Vergleich zu bemühen: Ein freier Webseitenkatalog wäre auch nützlich (gibt’s schon), aber das wäre für mich nicht unbedingt ein Grund, an Rechenzentren in OSM eine Liste der dort gehosteten Websites zu erfassen. Denn auch hier spielt der geografische Bezug zwar eine Rolle - die Geschwindigkeit beim Aufruf und rechtliche Fragen werden u.a. dadurch beeinflusst -, ist aber nicht unmittelbar entscheidend.
Wenn jemand Lieferzeiten erfassen will, darf er das natürlich trotzdem. Aber selber würde ich es derzeit wohl nicht erfassen, denn “es wäre nützlich, eine Webseite mit Lieferservices zu haben” überzeugt mich noch nicht, dass das konkret in OSM geschehen soll.
Und jetzt noch zur handfesten Tagging-Frage …
Warum denn überhaupt auf eine Lösung setzen, bei der man sich erst überlegen muss, ob es eine Verwechslungsgefahr geben dürfte, wenn es bei der Alternative ganz sicher keine Verwechslungsgefahr gibt? Zumal mich in OSM inzwischen gar nichts mehr überraschen würde, irgendwo auf der Welt gibt es immer unerwartete Sonderfälle. (Marktplatz mit Lieferservice und freier Zufahrt für Lieferanten…? 
)
Einen Schlüssel für mehrere Bedeutungen zu verwenden macht auch gleich wieder die Dokumentation z.B. im Wiki schwieriger. Wer bei deiner Apotheke auf “dispensing” klickt, kommt auf die Schlüsselbeschreibungsseite im Wiki. Bei “delivery” könnte das nicht funktionieren, weil der Schlüssel dann keine eindeutige Definition hätte. Denselben Effekt hätte man bei einer Suche im Wiki, die Auswertung in Taginfo würde schwieriger (nicht jeder kann Queries basteln) etc.
Ich finde, eindeutig benannte Schlüssel sind gegenüber kontextabhängigen normalerweise zu bevorzugen.
Das stimmt natürlich.
Als “eher egal” würde ich persönlich den Standort nicht unbedingt bezeichnen, und das nicht nur wegen des Liefergebiets. Wenn ich mehrere Lieferdienste zur Auswahl habe, die beide das gesamte Stadtgebiet beliefern, wobei aber manche in meiner unmittelbaren Nähe sind, andere dagegen auf der anderen Seite der Stadt, hätte ich eine deutliche Präferenz für den Lieferservice um die Ecke, weil er meine Pizza wahrscheinlich schneller und wärmer zu mir bringen kann als ein anderer Lieferant, der erst durch die Innenstadt muss, und das schlimmstenfalls noch im Berufsverkehr.
An und für sich ein schöner Vergleich, auch wenn ich finde, dass er ein kleines Bisschen hinkt: Wenn ich eine Webseite aufrufe, spielt es für mich keine große Rolle, ob der Seitenaufbau nun 10ms oder 100ms dauert und welchen rechtlichen Fragen die Seite unterliegt - mich interessiert der Inhalt und der wird durch den Serverstandort nicht beeinflusst (es sei denn natürlich bei Seiten mit Geolocation oder Anbietern von Inhalten nur für bestimmte Länder, aber die dürften eher die Minderheit ausmachen). Wenn dagegen eine physische Ware transportiert wird, deren Qualität unter einem längeren Transportweg leidet, dann finde ich, dass die Transportstrecke durchaus ein entscheidender Faktor ist.
Dazu kommt noch, dass Vor-Ort-Restaurant und Lieferservice in vielen Fällen kombiniert auftreten, d.h. in Ort, Anbieter, Kontaktinfo etc. übereinstimmen. Es ist also nicht so, dass man durch ein solches Tagging eine große Anzahl von neuen Objekten mit losem Ortsbezug mappen würde, sondern bereits bestehende Objekte, die als Restaurant einen festen Ortsbezug haben, detaillierter erfassen würde. Den Nutzen würde ich dann auch in einem “Gehe ich jetzt bei dem Wetter zu XY zum Essen… oh, brauche ich gar nicht, die liefern ja auch.” sehen.
Bei “detailliert” würde mir persönlich schon ein “liefert / liefert nicht / liefert von … bis … Uhr” reichen - keine n Zusatztags für Liefergebiete…
+1.
ok, überzeugt.
Jetzt einigt euch nur noch, und ich tagge “meine” 3 Nodes um
Gruss
walter
Hallo Walter
Ich hatte ja schon mal home_delivery vorgeschlagen,
was a) nicht mit dem Access-Schlüssel/-Wert verwechselt werden kann
und b) einigermaßen anschaulich ausdrückt, um was es geht.
Bleibt noch die Frage, ob ein Home-Delivery-Service auch in anderen Zusammenhängen als Essen&Trinken z.B. Lieferservice von Möbelhäusern oder Supermärkten auftreten kann und ob wir das mit dem gleichen Tagg bedienen wollten.
Edbert (EvanE)
Ich würde auch “home_delivery” unterstützen.
Steht meines Erachtens nach außer Frage; Heimlieferung ist Heimlieferung und wem das Ganze wieder noch zu trivial erscheint kann’s ja noch um Werte wie z.B.
home_delivery=fast_food
home_delivery=furniture
oder Ähnliches erweitern.
mfG Michael
Ich tendiere auch zu home_delivery
Gruß Jürgen
Da ich gerade vor dem Problem stehe - ein Restaurant zu taggen, dass gleich 3 unterschiedliche Zeiten hat:
- Öffnung-Zeiten (nach denen man aus dem Restaurant rausgeworfen wird
- Lieferzeiten (wann sie einem noch was ausliefern - theoretisch)
- Küchenzeiten (in denen man noch Essen vor ort bestellen kann <= Geographishcer Bezug und so)
Will ich mich mal hier beteiligen:
“home_delivery” scheint mir bezogen auf die breite Anwendbarkeit kein guter Tagg, weil er noch enthält wohin geliefert wird unterschwellig.
Ich schlage “delivery_service” = yes/no/only vor - ist allgemeiner.
mit den netten : für weitere Details.
:Open_hours =
:payment =
Und weil nicht alle Gerichte immer geliefert werden, die angeboten werden vor Ort
:cousine =
:diet =
Manchmal gibt es eine spezielle Bestellhotline
:phone =
usw…
Irgend einen Vorschlag für Küchenzeiten?
Viele Grüße,
MADetter
Nahmd,
So landet die Information beim Nutzer:
Mo-Sa 10:00-21:00 open “Warme Küche von 11:30 bis 13:30 und von 17:30 bis 19:30”
Alternative: ein Tag erfinden, das nicht ausgewertet wird, und damit die Information im Datennirvana verschwinden lassen.
Gruß Wolf
Moin,
stell Dir mal lieber die Frage was für tolle Apps man damit machen kann wenn man solche Informationen hat. Ein Bekannter von mir interessiert sich für ganz andere Sachen die er in die OSM einträgt, wo ich mich auch frage ob das sein muss. Letztlich bietet die OSM aber Raum für alle Nischen, also warum nicht. Vor allem bei opening hours sehe ich da noch viel Potential. Ich denke das alle Information, die dem Kommerz zuspielt irgendwann zu Anwendungen führt, die letztlich die Popularität von OSM erhöhen.
LG,
-moenk
Ich denke delivery=yes wird bereits häufiger für Restaurants mit Lieferservice eingesetzt als für den access-tag. Das sieht man auch daran, dass es laut taginfo häufiger für Nodes verwendet wird als für Ways.
Wenn ich z.B. in Berlin nach via Overpass-API nach delivery=yes suche, dann erhalte ich nur zwei Straßen aber 16 Fast-Food-Läden. Und diese übersicht über Bringdienste finde ich super praktisch. Grade weil OSM meist auch die websiite und telefonnummer mitliefert.
Hier mal ein kleiner Test dazu:
http://www.be2art.de/osm/tourist.php?checkbox=custom&custom=delivery%3Dyes&zoom=13