Ich bringe hier mal ein Anliegen vor, das ich vor einiger Zeit bereits im CS angesprochen habe.
Rund um das Gelände der Landtage Nord hat @BB-plan (BB-plan | OpenStreetMap) massenweise Parkplatz-Infrastruktur einer Messe erfasst, die immer Ende August für ein verlängertes Wochenende stattfindet. Das DOP20-Bildmaterial vermittelt hier ein realistisches Bild: Die Fahrgassen sind sämtlich an ~362 Tagen im Jahr nicht existent, somit temporäre Objekte, die meiner Ansicht nach nicht in OSM erfasst werden sollten. Vermutlich sind sie von Google Maps abgezeichnet, das dortige Bildmaterial ist zufällig am Messewochenende entstanden. Woher die Benamungen der Fahrgassen kommen, weiß ich nicht – ich vermute, sie sind ein fantasievoller Versuch der Systematisierung, vor Ort gibt es jedenfalls keinerlei Hinweise darauf.
Die vom Ersteller im o.g. CS erklärte Access-Beschränkung ist ein fauler Kompromiss: Die Wege sind ja nicht lediglich an ein paar Tagen im Jahr nutzbar, sondern sie existieren ausschließlich an ein paar Tagen im Jahr, die sich noch dazu von Jahr zu Jahr unterscheiden. Normalerweise sind die Flächen unzerschnittene Wiesen, die als Weide für Schafe oder Kühe sowie zur Futtergrasproduktion genutzt werden. Insofern sind die Fahrgassen meiner Auffassung nach ganz klar temporäre Objekte, die nach good practice Regel #5 nicht erfasst gehören.
Ich schlage daher vor, sie zu löschen und die Lage nach DOP20 und survey präzise zu erfassen. Da ich das Gelände mehrfach die Woche passiere, kann ich problemlos OTG verifizieren.
EDIT: Versuch, Ersteller zu taggen statt auf Profil zu verlinken, klappt nicht.
Ich finde die Daten auch problematisch. So oft ich dort in den letzten Jahren vorbei gefahren bin, habe ich da nie einen Parkplatz wahrgenommen. Wollte das schon selbst mal entfernen, aber man müsste dann genau schauen, welche Objekte nur temporär sind.
Es steht natürlich außer Frage, dass es sinnvoll ist, Besuchern ein Kartenwerk in welcher Form auch immer zur Verfügung zu stellen.
Nur ist OSM dafür nicht das richtige Tool. Wir bilden dauerhafte Geodaten ab, keine fliegenden Bauten. Spätestens wenn es wie beschrieben zu Navigationsfehlern kommt, weil die nicht existierenden Wege einbezogen werden, ist die Sache eindeutig.
Um die Besucherführung muss sich der Veranstalter anderweitig kümmern. Er kann z.B. eine Navi-App anbieten, die auf OSM-Daten basiert und die veranstaltungsspezifischen Daten aus einer eigenen Quelle darüber legt. Damit hat keiner ein Problem, dafür ist OSM da. Aber bitte nicht in die OSM-Datenbank.
Praktisch alle OSM-Navi-Apps haben Aktualisierungsintervalle von ein bis drei Monaten. Bei Straßenbaustellen haben wir uns auf eine Mindestdauer von ungefähr drei Monaten geeinigt, um sie zu mappen. Was kürzer dauert, wird nicht gemappt, weil davon auszugehen ist, dass es bei der Hälfte der Nutzer nur verzögert ankommt und dann zu lange drin bleibt.
Bei einer dreitägigen Veranstaltung wäre das eher nicht sinnvoll. Was du im August umtaggst, ist bei den meisten Nutzern im September drin oder gar nicht (wenns vor Monatsende wieder zurückgetaggt wird).
Die gesamten Wege in OSM zu haben, finde ich ein wenig übertrieben, gemessen daran, dass das nur eine Wiese ist, und sich das Arrangement ggf. sogar von einem zum nächsten Tag ändern könnte, je nachdem, wie eng die Ordner die Autos parken lassen (sofern das nicht Dauerparkplätze sind).
Ich fände es legitim, dass amenity=parking zu behalten, und als Fläche darzustellen, wenn das regelmäßig so verwendet wird, analog zu den xmas: features, und dann mit opening_hours (das finde ich treffender als access:conditional) die Datumsbegrenzung darzustellen. Treffender wäre aber wahrscheinlich so etwas wie amenity:conditional=*, aber das wäre etwas, was ich nicht unter “any tag you like” einfach so verwenden würde, sondern durch einen Proposal process durchsollte.
Und grundsätzlich bin ich der Meinung, das was als name=* getaggt ist, ist eigentlich eine ref=* oder description=*.
Und das access:conditional=* könnte man sicher auch eleganter über n-ter Samstag - n-ter Sonntag o.ä. formulieren, dass es nicht jahresabhängig ist. So ist der ja wirklich access=no für alle Tage in der Zukunft.
Das Beispiel hinkt ein wenig. All den temporären Dingen die wir in den Daten haben, haben in der Regel spezielle tags um sie zu unterscheiden. Dann kann jeder Router/Kartenanbieter damit machen, was er für richtig hält. amenity=parking mit opening_hours oder access:conditional ist da nicht passend. Das würde ja weiterhin aussagen, da ist ein Parkplatz OTG sichtbar.
Ich habe kein Problem damit, temporäre Parkplätze zu mappen. Aber wer das möchte sollte sich erst Gedanken um ein Tagging-Schema machen. Eine spontane Idee wäre ein temporary:highway=service und ein temporary:amenity=parking mit einem temporary:start_date=2026-04-08..2026-04-24 und jeder der eine Karte für heute rechnen will kann das auflösen und wer eine Karte für 26Q2 rechnet, lässt es lieber.
unbedingt. Ich fände, so etwas wie amenity=no + amenity:conditional=parking @ (...) würde besser in den Rest passen, das könnte dann auch auf highway=no + highway:conditional=service @ (...) übertragen werden. Aber das sind Detailfragen deren Diskussion am Thema vorbei geht. Ja, das mit den opening_hours=* oder access=* ist v.a. für die Wege unangebracht, weil solche Wege typischerweise erst durch die eingewiesenen Autos, im besten Fall temporäre Schilder entstehen.
Beim Parkplatz-Objekt wäre ich da entspannter. Auch wenn man es nicht darf (okay, das würde wieder für access und nicht opening_hours spreche), ist es trotzdem noch eine Grasfläche, auf der prinzipiell Fahrzeuge stehen könnten. Nur der name=* oder ref=* ist eine temporäre Eigenschaft…
Es gab schon mal Überlegungen zu einem event- bzw. temporary-Taggingschema. Für Festivalgelände und sowas, aber das ist hier auch ein Beispiel. Auf dem OSM-Samstag letztes Jahr bei der FOSSGIS gabs da auch ne Session zu. Ich glaube in Dokumentation oder Proposal hat sich das bisher aber nicht übersetzt (oder kennt jemand was?). Wäre mal nen schönes Proposal wert.
Allgemeine OSM-Karten (z.B. die Freizeitkarte) werden von den Nutzern typischerweise ein- bis zweimal pro Jahr erneuert. Temporäre Objekte sind somit immer kritisch, weil sie die meiste Zeit in den Karten falsch sind.
Auch nicht den Feinkostwagen, der jeden Donnerstag vor dem Rewe steht
Um mal konkreter an meinem Anliegen zu bleiben: Wiesen, die temporär als Parkfläche genutzt werden, gibt es hier auf dem Land zu Hauf - für Schützenfeste, Zeltfeten und Hermanns 55. Geburtstag. Für alle Anlässe wäre ein “Parkleitsystem per Navi” für ein paar Wenige vielleicht hilfreich, die große Masse interessiert sich aber weder dafür noch für Beschilderungen vor Ort. Ein separates Tagging für solche Anlässe zu entwicklen, würde sicher nicht schaden, aber der Nutzen wäre meiner Meinung nach überschaubar.
In jedem Fall halte ich es aber für falsch, Wiesen als Parkplätze zu mappen, nur weil sie einmal im Jahr dafür zweckentfremdet werden
Ich habe die anderen Beispiele genannt, um zu zeigen, dass man mit so einer Entscheidung - temporäre Objekte mit einem eigenen Schema zu erfassen - ein ganz schön großes Fass aufmacht. Dann kommen viele andere auch auf die Idee ihre temporären Anwendungsfälle einzutragen.
Das Proposal dazu existiert schon. Allerdings nicht mit start/end_date sondern mit der bekannten Syntax aus :conditional. :conditional selbst kann in manchen Fällen problematisch sein, wenn es um ein Objekt geht, dass ohnehin schon conditionals hat, und temporär anders ist.
Das temporäre Zeug kann man doch mit umap auf die Karte malen. So bleibt die echte OSM davon verschont und man hat eine eigene “Spezial-Karte”, in der es drin ist, die man dann für die Dauer der Veranstaltung nutzt. Die offizielle Karte bleibt dabei sauber.
WIr nutzen umap auch für Planungen. Wenn die Planung dann irgendwann realisiert ist, füttert man die eigentliche OSM aber nicht schon, solange nur überlegt wird, wie es werden könnte.
Da diese Parkplätze nur bei den Veranstaltungen LandTageNord und GartenTageNord existieren, gehören sie nicht auf OSM, sondern wenn überhaupt auf Overlays, wie sie z. B. mit uMap möglich sind. Das gilt dann parallel auch für andere Veranstaltungen (z. B. Wacken Open Air, Parookaville/San Hejmo) usw.
