Es gibt den Schlüssel opening_hours, um genau so etwas abzubilden.
Die Renderer werten so etwas nach meinem Kenntnisstand
allerdings (noch) nicht aus.
Edbert (EvanE)
Das ist falsch. Es geht nicht um opening_hours. Ein Glühweinstand kann 10:00 - 22:00 offen haben. Das sagt aber rein gar nichts drüber aus das ehr nur vom 10.Dezember bis 23. Dezember da ist, wo er gemappt wurde. Ansonsten müssten ja alle shops ausserhalb ihrer Öffnungszeiten von der Karte verschwinden.
@ SunCobalt
Um die Öffnungssaison darstellen zu können, schlug ich in #16 vor:
Man kann sich nun streiten, ob ganz exakte Terminangaben notwendig sind. Falls vorhanden, kann auf die Homepage des Betreibers hingewiesen werden.
Im Laufe der Diskussion erwähnte ich mehrfach Overlay-Karte und selbst gerenderte Karten. Ich denke nicht, daß es Sinn macht, solche Temporären Objekte z.B. in Mapnik anzuzeigen. Die Auswertung der stall-Daten ist für Themenkarten oder Overlays wesentlich interessanter. Es gibt ja bereits Vorbilder (Stolpersteine / Buslinien / Wanderwege … ) Warum nicht auch eine Karte für temporäre Objekte wie Märkte, Obststände oder was auch immer?
Ich fasse mal zusammen, welche Schlüsselpaare bislang am sinnvollsten erscheinen:
shop=stall
products=*
stall=permanent/saisonal/marketday
seasonal=01-02-03-08-09 (nur die Monate in die “Kette” schreiben, in denen der Stand geöffnet ist)
marketday=mon-tue-wed-thu-fri-sut-sun (nur die Tage in die “Kette” schreiben, an denen geöffnet ist)
opening_hours= *
operator=*
Noch was vergessen?
Gruß
tippeltappel
Verlangt kein Mensch, dass OSM alle Erntesaisons kennt!
Bei opening_hours = sunrise-sunset (nur im englischen Wiki) reicht ja auch so ein vager Wert.
Also, ich hab mit opening_hours angefangen, weil unter http://wiki.openstreetmap.org/wiki/DE:Key:opening_hours#Syntax auch von Monaten die Rede ist. “hours” ist natürlich irreführend.
Das möchte ich sehr unterstreichen! Es ist doch glasklar, dass wir nicht nur solche Sachen erfassen, die sofort in Mapnik oder auf dem Garmin erscheinen müssen.
Tippeltappels Vorschläge sind ja regelrecht darauf ausgerichtet, es den Renderern zu erleichtern, Obstbuden o.ä. nicht zu rendern. Was wollt ihr mehr?!?
noch eine Anmerkung. Bitte nicht böse werden…Nur ein Vorschlag. Vielleicht wäre es besser, sich an der Syntax der opening_hours zu orientieren, sprich
seasonal=05-06 (Mai bis Juni)
seasonal=05;12 (Mai und Dezember)
seasonal=05-06; 12 (Mai bis Juni und Dezember)
marketday dann analog. Wenn Du es universaler machen möchtest, vielleicht Die Monate schreiben. Wenn man später auf die Idee kommt das genaue Datum anzugeben, kommt man so weniger durcheinander. Also
seasonal=May-Jun
seasonal=15.05.-15.06.
…
seasonal=15.05.-15-06.; 10.12.-23.12.
nur so ein Gedanke noch: Vielleicht stall=permanent in permanent=yes[default]/seasonal/… Dann wäre der Tag einheitlich und ich könnte das für mein oben erwähntes Zeltkino auch anwenden.
Hier zeigt sich wieder das Problem von OSM (und seinen Mappern) - eine Datenbank für alles! Da wird dann alles rein geworfen, ob es Sinn macht oder nicht.
Die eigentliche Datenbank von OSM sollte nur die Landschaft selbst enthalten, also Straßen, Schienen, Wälder, Wiesen, Flüsse, Häuser von mir aus auch Oberleitungen. Also Sachen, die das ganze Jahr da sind und grundsätzlich auch in zwei Jahren noch genau an dieser Stelle zu finden sind.
Alles andere, also welches Geschäft die sich im Haus befindet, welcher Zug auf der Schiene fährt, Verkehrszeichen und die ganzen POI gehören in andere Datenbanken.
Am Ende hat man dann einen schnelle sauber Kartendatenbank und in der POI-Datenbank kann dann jedes Schlagloch, Hundehaufen usw. eingetragen werden.
Zu den Erdbeerhäuschen: hier stehen dieses Jahr zwar einige wie letztes Jahr, andere aber auch nicht. Also müssten die Daten jedes Jahr geprüft werden. Saisonstart war auch unterschiedlich, einige hatten vor zwei Wochen schon offen, andere erst seit dieser Woche. Tägliche Öffnungszeiten sind immer bis die Ware verkauft ist. Wozu also irgendwas mappen, auf das sich keiner verlassen kann?
Das Rad der Zeit wirst du schwer zurückdrehen können. Die Unterscheidung, die du auf machst, ist im Detail überhaupt nicht durchzuhalten.
Das wäre schon eher ein Einwand. Ich gebe zu, wenn nicht einigermaßen vorhersehbar ist, dass die Bude (wann genau auch immer) im nächsten Jahr auch da steht, brauche ich auch keinen OSM-Eintrag. Nur: Die Buden, die ich kenne, die waren immer in den letzten Jahren da. Und daher meine ich, dass man die dann auch erfassen kann.
Das mit dem Saisonstart ist doch schon diskutiert worden! OSM muss doch gar nicht genau wissen, zu welchem Tag jetzt geöffnet wird! Sondern vor allem, wo ein Bude ist, verbunden mit dem Hinweis, dass sie nicht das ganze Jahr dort steht, sondern nur, wenn eben Saison ist.
Und die täglichen Öffnungszeiten müssen ja gar nicht erfasst werden, wenn die so unregelmäßig sind!
@ geogast
dito!!! 
@SunCobalt
Warum sollte ich böse werden? kopfkratz-grübel
Dein Vorschlag für seasonal liest sich logisch. Verrätst Du mir auch, wie man das dann ganz leicht in eine Renderregel umbaut?
Mit dem key opening_hours kann ich derzeit nicht viel anfangen. Ich kann ihn höchstens als info anzeigen lassen. Aber ich wüßte nicht, wie ich den als Filter einsetzen soll, der dafür sorgt, daß der Marktstand in der Dezemberkarte angezeigt wird und in der Märzkarte nicht.
Bei der “Kette” hatte ich im Sinn, daß man mit dem Filter "enthält x|y|z " alle Stände herausfiltern kann, die in den Monaten x, y, z aufgebaut sind und daß man keine “größer/kleiner” “und” “oder” - Konstrukte austüfteln muß. Werden einfach alle Öffnungs-Monate aufgezählt, ist es ein Leichtes durch Aktualisieren der Monatsangabe in den Renderregeln die kleine selbst gerenderte Karte aktuell zu halten. Das Trennzeichen - ist dabei allerdings ein ungünstiger Vorschlag. Vielleicht funktioniert + oder ; besser. Wer kann dazu etwas sagen?
Die exakte Datumsangabe könnte man dann ja immer noch in opening_hours unterbringen. Oder?
Auswertung - Wie?
Wenn ich z.B. Stände mit seasonal=05-08, seasonal=06-09, seasonal=04-06;8-10 usw. habe, wüßte ich gerne, wie dann z.B. alle im Juni geöffneten/aufgebauten Stände heraus gefiltert werden? Wie muß dann der größer&kleiner-oder-dann Filter gebaut sein? Und mit welchem Programm muß ich dann arbeiten? Oder müßten dann sämtliche x-y Varianten, also die möglichen Zeitspannen angegeben werden, innerhalb derer 06 liegt zuzgl der Einzelangabe 06? Um mit Kalenderdaten einen Öffnungszeitraum ermitteln zu können, müßte seasonal als Datumsfeld oder so erkannt werden. Das erfordert besondere Eingabeformate. Oder nicht? Das finde ich schrecklich kompliziert für jemanden, der von der Programmierung von Datenbanken nicht viel oder keine Ahnung hat. Bei der Vereinbarung der Tags würde ich mir als Mapper wünschen, daß sie hinterher möglichst leicht auszuwerten sind. Dann hat auch Otto-Normal-Anwender die Chance, sich von seiner Umgebung statt einer Wander-Karte eine Markt-Karte zu bauen. Die ist mit Nops Composer nur wenige Klicks entfernt.
Der Schlüssel permanent=yes erlaubt als Alternative nur no
Alles andere ist meines Erachtens unlogisch.
permanent und seasonal oder maketday sind value-Alternativen von denen ich keinen als key nutzen würde, um damit die anderen abzufragen.
Ich würde statt dessen permanent als default ansehen und immer dann annehmen, wenn der Schlüssel fehlt. Der Klarheit wegen sollte er bei stall natürlich gesetzt werden. Dasselbe gilt z.B. für Strandbars usw.
Ich verstehe, daß Du stall austauschen möchtest, um das Tag allgemeiner zu gestalten. Aber im Moment habe ich keine Idee, welcher Begriff dafür taugt. Man könnte aber “stall” gegen “cinema” oder “Strandbar” austauschen. Fehlt cinema=permanent, was ja bei den bislang eingetragenen Kinos der Fall ist, wird der Wert “permanent” auch hier als default angenommen. Trägt man ein “Saisonkino” ein, fügt man cinema=seasonal ein. Solange das bei den Renderern nicht bekannt ist, werden die Saisonkinos wie die ganzjährig geöffneten Einrichtungen angezeigt. Wäre aber nicht schlimm. Wird der Schlüssel cinema=* schon anderweitig benutzt, spricht auch nichts dagegen, dieses Tag komplett wegzulassen und nur seasonal=xyz anzugeben. Käme letztlich zumindest ungefähr auf dasselbe heraus.
Bei Marktständen, Erdbeerbuden etc. funktioniert das auch. Interessant ist das Tag stall=permanent/seasonal/marketday aber deshalb, weil man damit drei Grundtypen der jeweiligen Einrichtung bzw. des Geschäftes herausfiltern kann, ohne das Tag seasonal oder marketday auswerten zu müssen.
In seasonal oder marketday die Syntax von opening_hours zu übernehmen, halte ich wegen der dann möglichen Angleichung/Verwechslung nicht so geschickt. Diskussionen das eine durch das andere zu ersetzen sind dann vorprogrammiert.
Vielleicht sollte man das auch berücksichtigen.
Gruß
tippeltappel
P.S. Finde die Diskussion sehr anregend
keine Ahnung wie man das den Renderern beibringt. Soweit ich weiß, ist der Syntax der Opening-Hours deswegen so, dass sie besser auswertbar ist. Daher mein Vorschlag sich daran zu orientieren. Zumal unterschiedliche Konventionen für verschiedene Tags mit Zeitangaben nicht hilfreich sind.
Die Tage hatte ich ins Spiel gebracht, da man das gleich richtig machen sollte wenn man damit anfängt. Sonst kommt in sechs Monten jemand -evtl durch Deinen Vorschlag inspiriert- der das gerne genauer haben möchte. Und dann fangen die Probleme an die alten Tags zu ändern, beide auszuwerten oder die nur die neuen Tags zu berücksichtigen. Kurz gesagt, die Syntax von Opening_hours ist abgestimmt und bewährt.
Mir ist aber klar, dass es für Dich einfacher wäre die Zahlenreihe auszuwerten.
Die Datumsangabe in den opening_hours unterzubringen, halte ich für Frevel. Das sind Öffnungszeiten und sagen nichts darüber aus, ob ein Objekt zu einem bestimmten Zeitpunkt an dem definierten Ort existiert oder nicht. Nehmen wir ein Freibad. Das kann sagen wir mal vom 01.05.-30.09. offen haben → opening_hours. Danach ist es aber nicht weg und soll auch weiterhin auf der Karte erscheinen. Steht vor dem Freibad ein mobiler Eisstand, der genau zur gleichen Zeit (Saison) da sein Eis anbietet aber im Winter weg ist, würden die gleichen Daten in den opening_hours stehen, aber besagen bei dem einen Objekt die “echten” Öffnungszeiten, bei dem anderen Objekt aber ob es wirklich da ist. Ein identischer Tag hätte dann zwei Bedeutungen.
Wie wäre es statt permanent mit temporary=no[default], seasonal, etc?
@ SunCobalt
Opening-Hours von der Datumseingabe getrennt halten, wäre auch in meinem Sinne.
Für den Rest hätte ich aber gerne konkrete leicht auswertbare Vorschläge. Eine Syntax kreieren ohne konkrete Idee, wie die dann ausgewertet werden kann, finde ich sinnfrei.
temporary
Liest sich gut.
Was sagen die anderen dazu?
Der Begriff ist sehr vielschichtig: http://dict.leo.org/?lp=ende&from=fx3&search=temporary
moin,
das Thema hatten wir ja nun schon öfter.
Da gibt es ja auch die Weihnachtsmärkte, Jahrmärkte usw. usw. . Das Problem ist z.B. die Aktualisierung von Karten; die Tags müßten ein ein/aus-Datum haben, das sowohl die Renderer als auch Router auswerten können und da fehlt wohl noch der “Geistesblitz”
VG
Jörk
wie wäre es damit
temporary=no[default], yes, repeating (statt seasonal)
temporary=repeating:
repeating_frequency=weekly, annually, monthly
repeating_day=Sa (bei weekly, z.B. der Markt am Samstag)
repeating_date_on=01.05. (bei annually)
repeating_date_off=15.06.
repeating_day=15 (bei monthly, wenn es später mal eine Möglichkeit gibt das auszuwerten, kann man evtl auch so Dinge wie dritte Freitag im Monat ergänzen)
temporary=yes
date_on=01.07.2010
date_off=15.08.2010
delete=yes (könnte dann nach dem Endedatum automatisch gelöscht werden)
@ jorkh
ein/aus-Datum
opening_on=mm-tt
openig_off=mm-tt
Auswertung:
Prinzip: wenn opening kleiner/gleich heute und opening_off größer/gleich heute, dann zeigen
Funktioniert aber nur, wenn es nur eine Öffnungssaison gibt.
Umsetzung im Detail müßte ich tüfteln, wie sich das beispielsweise im Composer mit Hilfe einer Ersetzungsregel umsetzen läßt. Eine konkrete Vorstellung hab ich da noch nicht. Eine automatische Einspeisung für “heute” wüßte ich beispielsweise nicht. Da würde ich dann wohl händisch aktualisieren müssen.
Mir würde die Eingabe der Öffnungsmonate als Zahlenkette reichen. Das ist für die Auswertung am simpelsten.
“On” ergibt sich automatisch, wenn der passende Monatswert in der Kette enthalten ist und “Off” ergibt sich automatisch, wenn der passende (Monats-)Wert fehlt.
Händische Aktualisierung: Als Anwender beispielsweise des Composers öffnet man die Renderregeln, tauscht die abzufragende(n) Monatszahl(en) aus und los geht’s.
Die Leute, die fit sind im Programmieren, können den manuellen Austausch des abzufragenden Monatswertes vermutlich durch eine einprogrammierte Routine ersetzen. Nach dem Motto, wenn Datum größer mm-tt und kleiner mm-tt dann setze in seasonal als Sollwert mm.
Gruß
tippeltappel
EDIT
@ SunCobalt
Habe Dein Post erst nach Fertigstellung meines Beitrages gelesen.
Gruß
tt
Ahh! Gut!
Wozu dann was neues erfinden?
moin,
access paßt aber nicht gut auf fliegende Bauten, die dann einfach nicht mehr da stehen
VG
Jörk
???
Da steht doch dann gar nicht access=
http://wiki.openstreetmap.org/wiki/DE:Key:access#Zeitlich_begrenzte_Beschr.C3.A4nkungen
Zeitlich begrenzte Beschränkungen
* date_on=* (Startdatum)
* date_off=* (Enddatum)
* day_on=* (Starttag)
* day_off=* (Endtag)
* hour_on=* (Startstunde)
* hour_off=* (Endstunde)
Wäre mir persönlich zwar zu detailliert, aber das drückt doch das Gewünschte aus.
Da das exakte Öffnungs/Schließungsdatum der Stände in vielen Fällen von Jahr zu Jahr vermutlich variiert, würde ich es weder recherchieren, noch eintragen wollen.
Außerdem wüßte ich gerne, ob diese Tags schon von jemanden dazu benutzt wurden, die Anzeige der erfaßten Objekte (in diesem Fall wären es die fliegenden Bauten/Stände) zu passender Zeit an und aus zu “knipsen”.
seasonal=mm+mm+mm…
Gefällt mir als “Knipser” immer noch am besten.
Gruß
tippeltappel
Gehen würde es schon…
Aber ob die Bude nächstes Jahr auch da steht, weiß Du nicht.
Nur wann ist Saison? Beginnt die am 1. Juni oder am 12. oder 17.?
Ich habe dann also eine Karte in der steht, dass man am Punkt X/Y in der Saison Erdbeeren kaufen kann. Dann weiß ich noch nicht, wann die Saison beginnt da das auch von Bude zu Bude unterschiedlich ist. Was nützt mir die Karte also? Nicht viel! Ich weiß letztlich nur, dass an dieser Stelle irgendwann mal in der Saison Erdbeeren verkauft wurden. Ich weiß nicht, ob das dieses Jahr auch so ist und wenn ja wann.
Die Erdbeerbauern (ich beziehe mich da mal auf eine Firma aus Rostock, die hier stark vertreten sind) dagegen kennen diese Daten genau. Die müssten dann eine POI Datenbank dynamisch auf eine OSM-Karte legen. DAS wäre sinnvoll und praktikabel.
Ich würde nur eintragen, WAS man dort kaufen kann und das dies nur in der Saison möglich ist. Ich traue dem Nutzer zu, selbst zu wissen, ob jetzt gerade Erdbeersaison ist oder nicht. Normale Renderer sollten so gekennzeichnete Objekte nicht rendern, Spezialkartenersteller werden wissen, was bei ihnen Sinn macht und was nicht.