Lieferservice und Lieferzeiten bei Fastfood

Und dazu dann freebie:what=bottle_of_wine, freebie:min_amount=20 EUR?
Wäre es nicht weitaus sinnvoller, einfach website=* anzugeben? Hat ja mittlerweile fast jede Pommesbude. Und da findet der Nutzer dann nicht nur die Lieferzeiten, sondern auch gleich die gesamte Speisekarte.

+1
von dort kann man dann auch gleich die vollständige Postadresse prüfen/übernehmen 😉

Also in meinem Ortsteil haben die meisten Einrichtungen dieser Art keine eigene Homepage. Ich habe die Daten aus einem Stapel gesammelter Speisekarten übernommen, das macht sie gerade so wertvoll. Zudem würde man doch wenn man etwas bestellen möchte, gezielt danach in der Nähe suchen können wollen.

Wiener Chicken und China Fast Food scheinen in der Tat keine Website zu haben, den Nikolaus Grill habe ich dagegen gefunden: http://www.nikolausgrill-eilendorf.de/

Meist korrelieren die Liefer- mit den Öffnungszeiten, auch wenn sie nicht exakt übereinstimmen müssen. opening_hours gibt also auch für den Lieferservice einen guten Anhaltspunkt. Interessant wäre m.E. in erster Linie, ob der Laden einen Lieferservice anbietet.

http://www.nikolausgrill-eilendorf.de
http://www.aldi-sued.de/de/html/service … zeiten.htm
😉

EDIT: Mist, Oli is schneller...lol

Aber: An beiden Gebäuden/POI's fehlen die Postadressen. Dank der Webseiten ist es kein Problem diese zu ergänzen.

Oli-Wan wrote:

Wiener Chicken und China Fast Food scheinen in der Tat keine Website zu haben, den Nikolaus Grill habe ich dagegen gefunden: http://www.nikolausgrill-eilendorf.de/.

Der ein oder andere hat natürlich ne Homepage, aber einige halt nicht. Hab hier noch mehr Speisekarten, die ich abarbeiten möchte. Die Homepage vom Nikolaus-Grill hatte ich aber tatsächlich noch nicht gefunden. Das könnte echt nützlich sein. Gerade die liefern aber leider nicht 🙁

Oli-Wan wrote:

Meist korrelieren die Liefer- mit den Öffnungszeiten, auch wenn sie nicht exakt übereinstimmen müssen. opening_hours gibt also auch für den Lieferservice einen guten Anhaltspunkt. Interessant wäre m.E. in erster Linie, ob der Laden einen Lieferservice anbietet.

Ich habe da keinen Überblick aber z.B. Wiener Chicken liefert nur abends und nicht bis zum Ende der Öffnungszeiten was mir schon mal zum Verhängnis wurde, da ich das nicht wusste 😉. Die anderen Angaben sind aber in der tat wichtiger.

reneman wrote:

http://www.nikolausgrill-eilendorf.de
http://www.aldi-sued.de/de/html/service … zeiten.htm
😉

Von Aldi habe ich die Zeiten natürlich auch aus dem Netz. Das war nicht gemeint.

Trockennasenaffe wrote:

Hab gerade mal angaben zu diversen Fastfoodrestaurants nachgetragen. Dabei ist mir die Idee gekommen, dass es extrem nützlich wäre zu wissen, ob so ein Laden auch liefert und wenn ja zu welchen Zeiten und vielleicht auch Mindestbestellwert. Gibt es dafür tags?

Solche Tags habe ich tatsächlich noch nirgends gesehen - aber es klingt tatsächlich nützlich. Sicher kann man solche Informationen auch auf der Homepage des Lieferservice nachlesen, wenn dieser denn eine hat, aber das müsste ein hungriger Suchender für jeden Lieferservice einzeln von Hand machen. Wenn man dagegen die Daten in OSM erfassen würde, könnte man automatisiert nur nach solchen Lieferdiensten suchen, die gerade liefern.

Als Zusatztag für amenity=restaurant/fast_food/cafe/... gibt es takeaway=*, um anzugeben, ob man das Essen mitnehmen kann. Vielleicht bräuchte es ein analoges Tag, das angibt, ob man sich das Essen bringen lassen kann? Analog könnte man delivery=yes/no/only taggen und dann mit delivery:opening_hours=* die Lieferzeiten angeben. Mit dem Mindestbestellwert ist es vielleicht etwas komplexer, weil der teilweise auch vom Liefergebiet abhängen kann... Für weiter entfernte Stadtteile ist der Mindestbestellwert höher als direkt neben dem Lieferservice.

MHohmann wrote:

Trockennasenaffe wrote:

Hab gerade mal angaben zu diversen Fastfoodrestaurants nachgetragen. Dabei ist mir die Idee gekommen, dass es extrem nützlich wäre zu wissen, ob so ein Laden auch liefert und wenn ja zu welchen Zeiten und vielleicht auch Mindestbestellwert. Gibt es dafür tags?

Solche Tags habe ich tatsächlich noch nirgends gesehen - aber es klingt tatsächlich nützlich. Sicher kann man solche Informationen auch auf der Homepage des Lieferservice nachlesen, wenn dieser denn eine hat, aber das müsste ein hungriger Suchender für jeden Lieferservice einzeln von Hand machen. Wenn man dagegen die Daten in OSM erfassen würde, könnte man automatisiert nur nach solchen Lieferdiensten suchen, die gerade liefern.

Das ist ja alles nützlich, aber muss das wirklich in der globalen OSM-DB stehen? Das wäre doch ein ideales Beispiel für ein Mash-Up, wo jemand die Informationen über die Lieferservices in seiner Gegend in einer lokalen DB vorhält und pflegt(!) und diese Infos kombiniert mit OSM-Daten auf einer Website anbietet. Wenn man solche Infos sucht, dann sucht man sie ja üblicherweise nur für eine bestimmte Gegend und nicht für den Rest der Welt.

lyx wrote:

Das ist ja alles nützlich, aber muss das wirklich in der globalen OSM-DB stehen?

Ich sehe nicht, warum da ein Unterschied zu Angaben wie Öffnungszeiten oder der Art des Essens gemacht werden sollte.

Trockennasenaffe wrote:

lyx wrote:

Das ist ja alles nützlich, aber muss das wirklich in der globalen OSM-DB stehen?

Ich sehe nicht, warum da ein Unterschied zu Angaben wie Öffnungszeiten oder der Art des Essens gemacht werden sollte.

+1. Sehe ich genau so.

MHohmann wrote:

Trockennasenaffe wrote:

Hab gerade mal angaben zu diversen Fastfoodrestaurants nachgetragen. Dabei ist mir die Idee gekommen, dass es extrem nützlich wäre zu wissen, ob so ein Laden auch liefert und wenn ja zu welchen Zeiten und vielleicht auch Mindestbestellwert. Gibt es dafür tags?

Solche Tags habe ich tatsächlich noch nirgends gesehen - aber es klingt tatsächlich nützlich. ...

Als Zusatztag für amenity=restaurant/fast_food/cafe/... gibt es takeaway=*, um anzugeben, ob man das Essen mitnehmen kann. Vielleicht bräuchte es ein analoges Tag, das angibt, ob man sich das Essen bringen lassen kann? Analog könnte man delivery=yes/no/only taggen und dann mit delivery:opening_hours=* die Lieferzeiten angeben. Mit dem Mindestbestellwert ist es vielleicht etwas komplexer, ...

Ich würde home_delivery=yes/<Lieferzeiten> vorschlagen.
Das macht klar, dass es sich um einen Bringservice handelt. Mit home_delivery gibt es keine Verwechslung mit einem Access-Recht wie *=delivery.
Zusätzliche Informationen WIe Gebühren oder Mindest-Bestellung können mit home_delivery:*=* erfasst werden.

Jetzt fehlt nur noch ein Tagg dafür, nicht vor Ort speisen zu können. Das geht bei vielen Lieferservices nämlich nicht. home_delivery=only reicht nicht, da man meist auch selber abholen (takeaway=*) darf.

Mir persönlich gehen Angaben zu Mindestbestellwert und Lieferzonen zu weit und ändern sich auch zu leicht/oft.

Edbert (EvanE)

Manchmal könnte man hier denken 1.April ist öfter als nur einmal im Jahr. 🤣
Eventuell sollte man sich selbst zuerst die Frage stellen "wer kann was, wann und wo gebrauchen?
Wieviele Leute welche Appetit auf eine Pizza o.ä. haben werden wohl auf die Idee kommen in OSM nachzuschauen?
Da kommen doch wohl Zeitungsinserate, Werbeflyer und "Gelbe Seiten" noch einige Plätze vor OSM, ganz abzusehen von diversen Handy-Apps welche es heute dazu schon gibt!

lyx wrote:

Das ist ja alles nützlich, aber muss das wirklich in der globalen OSM-DB stehen? Das wäre doch ein ideales Beispiel für ein Mash-Up, wo jemand die Informationen über die Lieferservices in seiner Gegend in einer lokalen DB vorhält und pflegt(!) und diese Infos kombiniert mit OSM-Daten auf einer Website anbietet. Wenn man solche Infos sucht, dann sucht man sie ja üblicherweise nur für eine bestimmte Gegend und nicht für den Rest der Welt.

+1

r-michael wrote:

Manchmal könnte man hier denken 1.April ist öfter als nur einmal im Jahr. 🤣
Eventuell sollte man sich selbst zuerst die Frage stellen "wer kann was, wann und wo gebrauchen?
Wieviele Leute welche Appetit auf eine Pizza o.ä. haben werden wohl auf die Idee kommen in OSM nachzuschauen?
Da kommen doch wohl Zeitungsinserate, Werbeflyer und "Gelbe Seiten" noch einige Plätze vor OSM, ganz abzusehen von diversen Handy-Apps welche es heute dazu schon gibt!

Das stimmt leider alles aber ich denke, das liegt genau daran, dass es dafür noch keine gute, verbreitete OSM basierte Anwendung gibt. Ich denke wenn es eine universelle Anwendung gäbe, mit der man fast beliebige Arten von POIs in der Nähe suchen könnte, würde das auch genutzt werden (Ich zumindest wünsche mir so etwas schon lange). Google Maps macht das ja erfolgreich vor, auch wenn hier die theoretischen Möglichkeiten noch nicht annähernd ausgeschöpft werden. OSM fehlt einfach noch die Killeraplikation, die den immensen Datenbestand wirklich für alle produktiv nutzbar macht.

r-michael wrote:

Manchmal könnte man hier denken 1.April ist öfter als nur einmal im Jahr. 🤣
Eventuell sollte man sich selbst zuerst die Frage stellen "wer kann was, wann und wo gebrauchen?
Wieviele Leute welche Appetit auf eine Pizza o.ä. haben werden wohl auf die Idee kommen in OSM nachzuschauen?
Da kommen doch wohl Zeitungsinserate, Werbeflyer und "Gelbe Seiten" noch einige Plätze vor OSM, ganz abzusehen von diversen Handy-Apps welche es heute dazu schon gibt!

Auch hier: +1

Ich denke nach längerem Nachdenken letztendlich auch, dass man es nicht übertreiben sollte mit Angaben, aber die Information ob es einen Lieferservice gibt halte ich für essentiell und sehr nützlich.

Trockennasenaffe wrote:

Ich denke nach längerem Nachdenken letztendlich auch, dass man es nicht übertreiben sollte mit Angaben, aber die Information ob es einen Lieferservice gibt halte ich für essentiell und sehr nützlich.

O.k., ein Tag zur Kennzeichnung ob ein Auslieferungsservice vorhanden ist mag schon seine Berechtigung haben.
Lieferservices gibt es ja nicht nur bei Fast Food sondern z.B. auch bei Restaurants, Möbelgeschäften, Baumärkten und vielen mehr. Hierfür z.B. "delivery=yes/no" zu verwenden erschiene mir sinnvoll.

mfG Michael

r-michael wrote:

O.k., ein Tag zur Kennzeichnung ob ein Auslieferungsservice vorhanden ist mag schon seine Berechtigung haben.
Lieferservices gibt es ja nicht nur bei Fast Food sondern z.B. auch bei Restaurants, Möbelgeschäften, Baumärkten und vielen mehr. Hierfür z.B. "delivery=yes/no" zu verwenden erschiene mir sinnvoll.

Hab's mal an meine Dorf-Apotheke gepappt - die liefern auch aus.
Irgendwie verständlich, damit die gegen Doc M. & Co noch ankommen.

Gruss
walter

EvanE wrote:

Ich würde home_delivery=yes/<Lieferzeiten> vorschlagen.
Das macht klar, dass es sich um einen Bringservice handelt. Mit home_delivery gibt es keine Verwechslung mit einem Access-Recht wie *=delivery.

+1
delivery=yes wird schon verwendet für "frei für Lieferfahrzeuge".

chris66 wrote:

EvanE wrote:

Ich würde home_delivery=yes/<Lieferzeiten> vorschlagen.
Das macht klar, dass es sich um einen Bringservice handelt. Mit home_delivery gibt es keine Verwechslung mit einem Access-Recht wie *=delivery.

+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

r-michael wrote:

Walter war ja nun wieder ganz schnell mit seiner Dorfapotheke, aber was bringt's wenn wir letztendlich wieder ein "Sammelsurium" an Eigenschöpfungen haben.

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)

r-michael wrote:

Wieviele Leute welche Appetit auf eine Pizza o.ä. haben werden wohl auf die Idee kommen in OSM nachzuschauen?

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.

Da kommen doch wohl Zeitungsinserate, Werbeflyer und "Gelbe Seiten" noch einige Plätze vor OSM, ganz abzusehen von diversen Handy-Apps welche es heute dazu schon gibt!

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?

MHohmann wrote:

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 ...

wambacher wrote:

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.

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.

Tordanik wrote:

Ein Restaurant hat einen Standort, dort muss man hingehen wenn man essen will. Damit ist ein unmittelbarer geografischer Bezug gegeben.

Das stimmt natürlich.

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).

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.

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.

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...

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.

+1.

Tordanik wrote:

Ich finde, eindeutig benannte Schlüssel sind gegenüber kontextabhängigen normalerweise zu bevorzugen.

ok, überzeugt.
Jetzt einigt euch nur noch, und ich tagge "meine" 3 Nodes um 😉
Gruss
walter

wambacher wrote:

Tordanik wrote:

Ich finde, eindeutig benannte Schlüssel sind gegenüber kontextabhängigen normalerweise zu bevorzugen.

ok, überzeugt.
Jetzt einigt euch nur noch, und ich tagge "meine" 3 Nodes um 😉

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)

EvanE wrote:

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.

Ich würde auch "home_delivery" unterstützen.

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.

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,

MADetter wrote:

Irgend einen Vorschlag für Küchenzeiten?

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

r-michael wrote:

Eventuell sollte man sich selbst zuerst die Frage stellen "wer kann was, wann und wo gebrauchen?
Wieviele Leute welche Appetit auf eine Pizza o.ä. haben werden wohl auf die Idee kommen in OSM nachzuschauen?

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?ch … es&zoom=13