Erdbeerbuden

Es gibt im Moment ja diese vielen Buden, die Erdbeeren aus der Region verkaufen. Wenn man vor Kurzem umgezogen ist, ist es ziemlich schwierig, diese ausfindig zu machen.
Ein Grund, sie zu mappen!
Aber wie?
shop=strawberries und opening_hours=Erdbeersaison?

Hmm. Gute Frage.
Ich würde bevorzugen:
shop=fruit_veg_stall (siehe auch fruit and veg stall http://dict.leo.org/?lp=ende&from=fx3&search=obst und http://dict.leo.org/ende?lp=ende&p=Ci4HO3kMAA&search=stall&trestr=0x8001 )
Damit lassen sich dann alle Obst- und Gemüsestände am Straßenrand mappen.

Nach Bedarf ergänzt man dann mit:
fruit=strawberries/cherry/ …
veg=potatoes/asparagus/pumpkin/…

Bei einem gemischten Angebot, läßt man die Ergänzung einfach weg.

Es gibt zwar auch noch shop=greengrocer http://wiki.openstreetmap.org/wiki/DE:Key:shop
Aber das meint ja wohl eher einen dauerhaft installierten Obst- und Gemüseladen.

Viele Grüße
tippeltappel

Ich würde plädieren für ein dem amenity=vending_machine ähnlichen Schema.
shop=stall
vending=vegetables;fruit;honey;flowers;…

Das wäre meiner Meinung nach allgemeingültiger und leichter erweiterbar.

Grüße,
Malte

vor ein paar tagen waren das noch spargelbuden und bald sind das kirschbuden (nicht kirsch-wasser-buden :wink: und dann sind se weg.
wollt ihr das korrekt halten?

wambacher

@ Malte

“vending” find ich nicht gut, weil das bereits mit Automatenverkauf assoziiert wird.
und aus “amenity” würd ich das auch raushalten

shop=fruit_veg_stall ist eine logische Ergänzung des shop-Schemas
shop=flower_stall wäre die nächste Variante
usw.
Die sind in manchen Gegenden sehr verbreitet und zumindest teilweise während der Saison immer wieder an denselben Stellen zu finden.

Ich fänd’s klasse, wenn die auf meiner Karte auftauchen würden.

Bei Deinem Schema-Vorschlag, Malte, wäre mir zu viel in einem “Topf”. Aber statt fruit= und veg= getrennt zu erfassen, könnte man das auch zusammen nehmen.

shop=xxx_stall läßt sich ganz allgemein auswerten. Etwa so:
Wenn shop enthält stall, zeige das Icon für einen Marktstand.

Will man es genauer:
Wenn shop=fruit_veg_stall, zeige das Icon für einen Einkaufskorb mit Obst und Gemüse und
erzeuge aus fruit_veg=xxx name=xxx damit ich weiß, was da verkauft wird

Soll der Name des Händlers nicht verloren gehen, kann man auch definieren, daß der Name um den Eintrag in fruit_veg= ergänzt wird usw.

Gruß
tippeltappel

Man muss ja nicht unbedingt die aufkreuzenden Buden taggen. Aber wenn beispielsweise jeden Samstag von 8 bis 18 Uhr Markt ist, halte ich es für durchaus sinnvoll die einzelnen Stände (mit Öffnungszeiten) zu taggen. Schließlich gehören sie auch irgendwie in die Geschäftslandschaft. Meistens sind auch am selben Ort dieselben Stände, insofern halte ich das für durchaus angebracht.

Dann gibt es auch noch “ständige Stände”, die kein Gebäude verdienen, weil es maximal Wohnwagen sind, aber trotzdem regelmäßig z.B. Blumen verkaufen.
Dafür halte ich shop=stall für sehr sinnvoll. :slight_smile:
Oder aber man sagt shop=xyz stall=yes. Vielleicht wäre das sogar noch besser.

EDIT: @tippeltappel: Die meisten Renderer sind nicht so gestrickt, dass sie schauen können, ob bspw. “stall” im Tag shop enthalten ist. Sonst wäre es ja auch üblicher Doppelkennzeichnungen durch Semikolon zu zeichen.

Grüße,
Malte

Einen Wortteil rausfischen geht mit dem Composer ganz leicht. Da müssen die Renderer, die das nicht können halt ein bissel dazu lernen. Je mehr in ein Tag rein gepackt wird, um so komplizierter wird es natürlich. Die Kombination von einem Ober- und einem auswechselbaren Unterbegriff, sollte aber keine Schwierigkeiten bereiten.

Zu Deinem Vorschlag
shop=xyz stall=yes

Und mit welchen Begriffen füllen wir das?
shop=fruits
shop=vegetables

stall=yes ist mir zu simpel
Der key:stall macht meines Erachtens nur Sinn, wenn values definiert werden, die deutlich machen, ob man den Stand durchgehend oder nur während der Erntesaison oder an Markttagen vorfindet.
stall=permanent/saisonal/marketday (oder so ähnlich)
Wer sich dafür interessiert, kann dann Marktstand-Icons in verschiedenen Farben kreieren, durch die das deutlich wird.

Gruß
tippeltappel

An der Stelle der Öffnungszeiten o.ä. muss man noch überlegen.
Marktstände sind ja ziemlich regelmäßig an ihrem Ort.
Bei Erdbeer- o.ä. -buden ist die Regelmäßigkeit aber ganz anders: regelmäßig jedes Jahr, aber je nach Erntebeginn wannanders im Jahr.
Aber in welcher Kalenderwoche jetzt genau geöffnet wird, ist für unsere Geodaten ja auch relativ egal.
Also wirklich: opening_hours=season?

Aber es gibt doch schon SHOP=GREENGROCER?
http://wiki.openstreetmap.org/wiki/DE:Key:shop

Ja OPENING_HOURS wäre nett und der Name bzw. OPERATOR zum gruppieren :slight_smile:

Macht das wirklich Sinn, derart temporäre Verkaufsstände (Spargel, Erebeeren) permanent in die Karte einzupflegen?

Je nach fertiger Karte stehen dann da ganzjährig Icons rum, die nur ein paar Wochen im Einsatz sind…

Ich warte schon auf die OSB Kreuze: Verkaufsstand fehlt, jetzt woanders, keine Kiwis dieses Jahr, hier nicht zu sehen, bitte checken…

Daher schließe ich mich der Meinung an.
Details in OSM ja, alles nein.

Das sollte jeder Kartenbauer für sich entscheiden dürfen.
Ich mag sie in meiner Karte haben. Also liebe Erdbeerbudenmapper bitte fleißig sein. :wink:
Und wenn Winter ist, dann nutz ich halt ein anderes Layout beim Rendern, wo sie nicht angezeigt werden.
Ist doch kein Problem.

Wer die Buden auf seiner Karte nicht will, braucht sie ja nicht rendern.

Damit diese Buden dann aber nicht vom Renderer mit normalen Geschäften verwechselt werden, muß das Tagschema so gebaut sein, daß das auch nicht aus Versehen passiert. Wenn für die Buden beispielsweise shop=greengrocer benutzt wird, ist das Chaos vorprogrammiert. Dann zwingt man alle, die die Buden nicht wollen, neue Renderregeln zu bauen, die die Buden ausschließen.

Es sollte besser umgekehrt sein. Wer die Buden haben will, muß eine neue Renderregel bauen. Deshalb finde ich besser:

shop=fruit_veg_stall
shop=flower_stall
shop=honey_stall
usw.

und wenn das und ähnliches nicht paßt:
shop=stall

Dann noch bereits angesprochene nützliche Ergänzungen:

fruit_veg=strawberries/cherry/ potatoes/asparagus/pumpkin/… um spezielle Warenangebote differenziert zu erfassen.
oder allgemeiner:
goods= …

stall=permanent/saisonal/marketday
opening_hours= *
operator=*

Auf diese Weise könnten unter anderem auch Weihnachtsmärkte systematisch erfaßt werden.
Wenn die Buden da sind, kommen sie auf die Karte.
Wenn die Buden abgebaut sind, fliegen sie wieder raus. - Also nicht aus der OSM-Datenbank, sondern mit Hilfe entsprechender Renderregeln aus der Karte.

Es liegt ganz im Ermessen des Kartenerstellers, ob er das mit macht oder nicht.
Für spezielle Freizeitkarten wäre das eine attraktive Sache.
Solche Informationen können auch als Overlay erstellt werden, das man nach Belieben über die normale Karte einblendet.

Da gibt es verschiedene sinnvolle Auswertungsmöglichkeiten.

Gruß
tippeltappel

Hallo tippeltappel

goods=* gibt es bereits für Lieferwagen bis 3.5 Tonnen.
Siehe: http://wiki.openstreetmap.org/wiki/Map_Features#Restrictions
Hier wäre products=… wohl die bessere Lösung.

Ansonsten fände ich shop=stall, products=…, opening_hours=…, operator=…
einen sinnvollen Ansatz.

Edbert (EvanE)

Du müsstest noch das Seasonal definieren. Für OSM wäre es ein bissl zu viel verlangt sie Saisons aller Früchte zu kennen. Ich weiß auch nicht, ob etwas, das den größten Teil des Jahres gar nicht da ist, in der OSM Datenbank sein sollte. Um bei Deinem Beispiel Weihnachtsmarkt zu bleiben. Du zeichnest …sagen wir mal… einen Glühweinstand als Fläche ein (Punkte hilfsweise, wenn die genaue Fläche nicht bekannt ist). Jetzt kommt da zum Ostermarkt ein Crepe-Stand, zum Stadtfest eine Würstchenbude, zum Ernte Dank Fest ein Karussel und zum Weinfest ein Werbestand der Anonymen Alkoholker hin, die an gleicher Stelle stehen aber unterschiedlichen Größen haben. Das wird nicht ganz trivial und unübersichtlich mit 5 überlappenden Flächen, alle stall=****. Nebenbei hast Du immer das Problem, dass Du nie genau weißt, ob ein temporärer Stand im nächsten Jahr/nächsten Saison wirklich wieder da ist und dann auch an der gleichen Stelle.

Oh, das mit goods hatte ich nicht mehr im Kopf.
products= ist eine gute Idee.

tippeltappel

Hmmm - Klar. Je nach Nutzung eines Areals kann das natürlich zu einer Anhäufung von sich in die Quere kommenden “Fliegenden Bauten” kommen.
Das Problem könnte man zumindest mindern, indem solche Marktstände ausschließlich mit Nodes dargestellt und diese in einer Relation zusammengefaßt werden. In der Relation kann man dann den Namen des Marktereignisses und andere zugehörige Daten hinterlegen.
Eventuel macht es auch Sinn, nebeneinander stehende Buden mit einer Linie zu verbinden, ähnlich, wie man es bei Hausnummern macht. Standnummern haben die Hütten auf großen Märkten ja auch. (Marktordnung?)

Die Zusammengehörigkeit der Hütten der jeweiligen Marktereignisse werden mit Hilfe von Verbindungslinien und Relationen gut zu erkennen sein. Es käme auf einen Versuch an.

Es gibt sicherlich Stände, die es sich lohnt zu mappen und welche nicht (Eintagsfliegen). Aber es deswegen gar nicht zu machen? Selbst wenn die Pächter wechseln, behalten die Standplätze auf etablierten Märkten ihre Nummern.

Ich find’s klasse, wenn ich auf dem GPS eine detaillierte Karte von einem Park habe und dadurch dann auf Anhieb alles finde, was mich interessiert. Über eine Karte vom Weihnachtsmarkt xyz würde ich mich genauso freuen.

stall=seasonal
würde ich als Schlüsselpaar so stehen lassen
Dann könnte man ergänzen
seasonal=01-02-03-08-09 (also die Monate in die “Kette” schreiben, in denen der Stand geöffnet ist)

Daraus können dann Renderer eines Kartenoverlays die Information beziehen, in welchen Monaten der Stand aufgebaut ist und dann dementsprechend den Stand mitrendern oder auch nicht.
Wahlweise kann die Information auch in einer Info-Blase angezeigt werden.
Vielleicht findet sich ja ein Overlay-Freak, der ein Overlay definiert, in dem man statt einer Auswahl verschiedener amenity, shops, education und was weiß ich noch die Auswahl hat zwischen Jan, Feb, März, etc.

Baut man seine eigene Karte, schreibt man vor dem Rendern für seasonal den Wert des aktuellen Monats hinein und schon hat man alle aktuellen Marktstände in der Karte.

Viele Grüße
tippeltappel

Jo, beim Lieblingsbordell könnte man eine OSM Relation dann einbauen, an welchen Tagen die Titensusi dienst hat und an welchesn Tagen die Fette Birgit arbeitet. An welchen Tagen die Studentin Babsi nicht am Straßenstrich steht, weil sie da grad Examen schreibt oder wegen der Periode grad kein Bock auf Strich hat.

Diese Buden eintragen ist ein riesen Quatsch! Ich war neulich von Stuttgart heim richtung Süden. Hab das GPS Rausgepopelt und nach Touristischen Sehenswürdigkeiten gesucht, um mir etwas die Beine zu vertreten. Dann hab ich Durst bekommen und hab nach den nächsten Tankstellen oder Einkaufen suchen lassen. Ich würde mich wahnsinnig aufregen, x km wo hinzufahren, wo es augenblicklich nicht das gibt, was es dort geben sollte. Der Openstreetmapper der diese Schrott POI eingetragen hat, würde ich meine Meinung sagen und diese POI löschen.

das Ziel finde ich auch sehr gut. Aber mir persönlich gefällt der vorgeschlagene Weg nicht, hört sich so …improvisiert…an. Und dann kommt da noch etwas Grundsätzliches dazu. Wie soll man bei OSM mit temporären Objekten umgehen. Ich kenne ein Zeltkino, das im Sommer aufgebaut ist. Im Winter sieht man nichts ausser einem Steinfußboden. Soll man das taggen? Vom Gefühl her ja. Aber wo zieht man die Grenze? In Stuttgart gibt es zweimal im Jahr ein Volksfest. Da stehen die Stände dann eine Weile. Soll man das mappen? Den Spargelstand, der nur 2 Wochen im Jahr an der Straße steht? Der Stand auf dem Firmenfest übers Wochenende?

Wo die Grenze zu ziehen ist, das sieht sicherlich jeder anders. Ich find’s zum Beispiel total übertrieben, Papierkörbe zu mappen. Ich kann meinen Müll auch zu Hause in die Tonne werfen. Aber jeder, wie er mag.

Zeltkino
Das ist meines Erachten irgendwie mit Freilichtbühne vergleichbar. Die ist da, wird aber auch nur zu bestimmten Jahreszeiten bespielt. Warum sollen solche Plätze nicht gemappt werden?

Und wenn ein Laden wegen Betriebsferien geschlossen hat, dann schmeißt man den POI auch nicht gleich aus der Datenbank, weil man vor der verschlossenen Türe stand. Die Chance, die Türe offen vorzufinden ist natürlich aufs Jahr gesehen um ein vielfaches größer, als eine Erdbeerbude, die allerdings nicht nur 2 Wochen da steht und auch die Spargelsaison ist länger als 2 Wochen. Wer im August nach einer Spargelbude sucht, ist selbst Schuld. Gilt die Tradition noch, daß die Spargelsaison am 24. Juni zuende ist? Na, auf ein paar Tage wird es nicht ankommen. …

Nee, das ist ein Zelt, das im Frühling aufgebaut wird und im Herbst wieder weg ist. Danach sieht man nur noch den befestigten Boden.

Alles verstanden. Nur wo zieht man die Grenze? WIe gesagt, es liegt eher daran, dass es noch keine Möglichkeit gibt mit temporären Objekten umzugehen.