Diese Changeset braucht vielleicht ein Blick von Deutsche OSM-Gemeinschaft. Ich bin eher zufällig darauf gestoßen:
Ich denke, dass wir das reverten sollten. Der Account sieht nach einem “Arbeitsaccount” der Bremer Verkehrsbetriebe (VBN) aus. Auch wenn opening_hours korrekt getaggt wurde (2.&3.10.) so ist das aktuell kein Feature, was OTG sichtbar ist und was mMn auch nicht lange genug besteht, um es einzutragen.
@JeroenHoek Danke für den Hinweis
Edit: User im CS angesprochen und auf diesen Thread verwiesen
Wenn es schon mal drin ist, kann man es auch bis zum nahen Datum drin lassen.
Hoffentlich nimmt es der Ersteller dann selbst raus.
Hallo zusammen,
der Eintrag stammt von mir. Uns ist bewusst, dass der Eintrag der Veranstaltungsorte diskutabel ist - ich habe deshalb versucht, die vorhandenen Methoden zu Öffnungszeiten und Startdatum so genau wie möglich in den Daten abzubilden.
Ziel des Eintrags ist es, die Navigation zu den Veranstaltungsorten möglich zu machen - für OSM-Nutzende mit allen Verkehrsmitteln, weil wir davon ausgehen, dass Menschen die Stadt noch nicht so gut kennen. Der VBN bietet die Flächen als POIs in unserem Auskunftssystem FahrPlaner als Zielorte an.
Ich würde mich freuen, wenn die Edition bis zum 4.10. in den Daten bleiben kann, danach werde ich sie entweder zurücknehmen oder, falls nicht konfliktfrei möglich - manuell löschen.
Danke für deine Antwort. Ich kann die Beweggründe gut nachvollziehen, bin jedoch mit der Lösung nicht ganz glücklich.
Zum Auffinden über euer System - für mich ließt sich das als primärer Zweck - würde ich mich über eine Lösung in eurem System freuen.
Nutzt ihr für die Suche in eurem System die OSM Daten oder habt ihr die POIs intern gespeichert? Insbesondere wenn letzteres der Fall sein sollte, würde ich mich dafür aussprechen, das bei euch intern abzulegen - das hätte auch den Vorteil, dass man bei sehr großen Flächen (Ländermeile) auch eine Unterscheidung in West/Mitte/Ost treffen könnte - das sind ja immerhin ~2km bzw. 6 Straßenbahnstationen.
MIr ist aber auch bewusst, dass es nicht mehr viel Zeit ist. Ich könnte in diesem Fall damit leben, die Flächen bis nach dem 3.10. drin zu lassen - mit der Bitte, dass beim nächsten Mal besser zu machen.
VG
Es sollte halt alles im temporary Namensraum eingetragen sein. Dann sehe ich wenig Probleme damit das drin zu lassen bis zum Ende der Veranstaltung. Es sollte aber jetzt nix dauerhaftes in OSM drin sein, was man nur 2 Tage in der Zukunft nutzen kann.
Ich danke für das Verständnis. Falls die Community überwiegend der Meinung ist, dass der Schaden (langfristige, schon ausgelaufene Daten bei selten synchronisierten Nutzungen) größer ist als der Nutzen (Möglichkeit zur Navigation in ÖPNV, Rad, zu Fuß) würden wir das natürlich auch akzeptieren. Wir haben den aktuellen Export und würden in unserem System die Aktualisierung für zwei Wochen aussetzen.
Auf eine genauere Abbildung der Flächen wie der Ländermeile habe ich bewusst verzichtet, um das Zurücknehmen möglichst einfach umsetzen zu können. Ich erlebe die Diskussion hier als sehr zielgerichtet und werde bei vergleichbaren Fällen in Zukunft vorab den Austausch suchen.
Wir nutzen OSM als Datenquelle für POIs (wie bei diesen Flächen), für das Routing von / zur Haltestelle zu Fuß oder mit Rad und in einigen Diensten als Hintergrundkarte.Wir haben vor ca. zwei Jahren entschieden, unsere eigene Datenhaltung z.B. zu Vorverkaufsstellen und Ticketautomaten aufzugeben und diese stattdessen in OSM abzubilden und zu pflegen. Bei größeren Änderungen im Verkehrsnetz (z.B. der Brückensperrung Changeset: 158706326 | OpenStreetMap ) editieren Mitarbeitende auch selbst, um möglichst schnell eine korrekte Abbildung der Situation in den Daten und den darauf aufbauenden Systemen zu erhalten.
Danke für die ausführliche Antwort. Ich finde es beachtlich, dass ihr mit eurem System so sehr auf OSM vertraut/baut.
Ich persönlich fände hier (oder in einem neuen Thread) noch (internes) Feedback wichtig, wie wir damit in Zukunft am besten umgehen. Zum einen ist es toll, wenn große Unternehmen unsere Daten nutzen und aktiv dazu beitragen. Andererseits ist das hier eher ein best-case (start_date und opening_hours und dann hoffentlich das Löschen nach dem 3.10.). Wie gehen wir damit um, wenn sowas häufiger vorkommt? Wollen wir diese Informationen in unserer DB oder ist das Risiko für Karteileichen und “Spam” zu große?
VG
Meine Meinug dazu:
Nein, wollen wir nicht, dafür ist OSM nicht gedacht.
bei vergleichbaren Fällen
solltet ihr das also nicht machen. Jetzt, wo es schon drin ist, kann es auch drin bleiben, das sehe ich auch so. Aber für zukünftige Fälle werdet ihr eine andere Lösung finden müssen (also ein System, mit dem ihr bei euch OSM-Daten überschreiben könnt, ohne bei uns etwas zu verändern, ist wohl unvermeidbar.)
Das gilt natürlich nur für verübergehende Dinge. Denn: Das ihr Aktualisierungen vornimt, längerfristige Brückensperrungen einträgt und unsere Daten nutzt, freut uns sehr, wie auch die andern schon geschrieben haben. Aber OSM ist eine dauerhafte Welt- und keine Veranstaltungskarte.
Stell Dir vor, jemand erstellt aus den OSM Daten eine Karte für ein Buch.
Da steht dann Euer ThemePark für alle Ewigkeit drinne.
Also ich hoffe einmal, dass wenn jemand ein Buch schreibt, er:sie sich auch alle generierten Grafiken genau ansieht und händisch überprüft. Und wenn die Orte trotzdem im Buch landen, ist dies wohl ein lustiges Kuriosum und steigert vielleicht sogar den Wert des Buches.
Wie gesagt, es gibt das Proposal:Temporary (conditional) - OpenStreetMap Wiki. Danach kann man sowas erfassen und jeder der will kann es entsprechend auswerten. Aber alles, was nur temporär ist, sollte nicht als normales Objekt mit den normalen Tags erstellt werden.
Also statt tourism=theme_park ein temporary:tourism=theme_park@(2026 Oct 02 16:00 - 2026 Oct 04 20:00)
Wäre das nicht etwas, was man mit umap gestalten kann?
Es geht den Verantwortlichen darum, dass es auch in ihrem Router funktioniert.
Der Vorschlag auf den temporary Bereich zu gehen ist nicht schlecht. Muss nur der Router entsprechend angepasst werden
Grundsätzlich wäre der temporary-Bereich eine Option gewesen - mich hat jedoch abgeschreckt, dass der letzte Beitrag im wiki neun Jahre alt und keine Nutzung mit taginfo ausgewiesen wird.
Gibt es Beispiele, wo der Namensraum genutzt wird / wurde?
Also der temporary Bereich wäre derzeit eine schöne Option, um es derzeit auszublenden, aber zB im Laufe des 1.10./2.10. wieder reinzunehmen (und am 4.10. rauszunehmen.) Vorteil: die Daten wären schon vorbereitet drin und würden zum akuten Termin wieder hervorgebracht werden (aber dazu schicke ich Dir gleich noch eine Direktnachricht hier).
Wenn ich derzeit den Fahrplaner der BSAG verwende, würde der mich heute schon zB zur Ländermeile bringen und da stände ich dann und würde gähnende Leere sehen (und mich höchstens am Weserstadion erfreuen).
Daher mein Vorschlag: entweder setzt Ihr den Export für zwei Wochen aus (da ihr die Daten schon drin habt) und wir setzen hier temporary:tourism=theme_park@(2026 Oct 02 16:00 - 2026 Oct 04 20:00) und haben dann ggf. die Möglichkeit (falls ihr den Export doch nicht aussetzt), durch Änderung von temporary:tourism=theme_park@(2026 Oct 02 16:00 - 2026 Oct 04 20:00) in tourism=theme_park am 1./2.10. es doch wieder reinzusetzen (d.h. die mühsame Arbeit der Erstellung der Welten und Meilen geht nicht verloren, es müssen nur die temporary-prefixes rausgenommen werden).
und perspektivisch gedacht (für den TdDE bestimmt nicht mehr technisch umsetzbar): wenn irgendwann Euer Router-OSM-Daten-Import mit dem temporary-prefix umgehen könnte, könnte er zum Freimarkt jenen als Ziel ausweisen, solange der Freimarkt läuft, genauso Osterwiese, Maritime Woche, Schlachtezauber etc. pp.
D.h. das Ziel Freimarkt wäre nur zu finden für Daten, zu denen gilt: Ischa Freimaak (also dieses Jahr 16.10. bis 1.11.) aber nicht für Straßenbahn- oder Busfahrten am 10.10. oder 11.11. …
Ich würde sagen das liegt in der Natur der Sache, dass davon nicht vieles in OSM drin ist. Zum einen ist das Mappen von temporären Dingen in OSM nicht unbedingt willkommen (wie du ja hier in der Diskussion festgestellt hast) und zum andern sollten diese temporären Objekte ja auch wieder entfernt werden, wenn sie nicht mehr existieren.
Zu guter Letzt braucht es dann auch noch einen Auswerter. Daher hält sich die Verbreitung in Grenzen. Aber für euch scheint das Ideal zu sein. Ihr könnt die Daten in OSM pflegen und habt einen eigenen Auswerter, dem ihr das beibringen könnt. Evtl. einfacher als das separat zu pflegen.
Ich sehe, dass das für die OSM-Karte nicht schön ist - für eine Fahrplan-Auskunft ist dies aber gewünscht: Ich kann schon jetzt meine Reise am 4.10. planen. Wir nehmen ja auch nicht das Weserstadion aus der Auskunft, nur weil da gerade niemand spielt.
Das Weserstadion ist aber kein so gutes Beispiel, weil es ja immer da ist (auch wenn gerade kein Spiel läuft).
Von den Meilen und Welten zum TdDE sehe ich derzeit hier in Bremen maximal die teils schon (neben den Straßen) bereitliegenden Absperrungen, mehr noch nicht.
Allerdings verstehe ich bzgl. Usability vom Eurem ÖPNV Router, dass da eventuell Nutzer ja nicht direkt das passende Datum eingeben, sondern einfach Start- und Ziel und dann vll. jetzt schon sehen will: ach,ok, so komme ich da hin (auch wenn das Ziel heute eigentlich gar nicht existiert sondern erst in 8 Tagen).