OK, das halte ich auch für sinnvoll. Ich hadere nur etwas damit Gebäudegeometrien bzw. deren Position und Ausrichtung zu erfassen, die sich jedes Jahr ändern. Sinnvoll erscheint es mir den Ort an sich, wie ein Wochenmarkt zu erfassen.
Da stimme ich Dir zu. In Deinem Fall ist auch ganzjährig etwas vom “Gebäude” vorhanden und vor Ort sichtbar: das Fundament. Da ist das weniger strittig, als wenn die Hälfte des Jahres vor Ort gar nichts zu sehen ist und die Lage zudem variiert.
OSM mal eben neu definieren? Ich mach mir die Welt wie sie mir gefällt…? Oder wie? 
Deshalb bleiben dann ab jetzt die Buden vom Weihnachstmarkt auch das ganze Jahr dort stehen oder wie? building=* ist falsch weil für Immobliles. Alternatives wurde bereits genannt.
Das war so eine Idee. Skyper hatte unter Beitrag #9 Einwände die berechtig sind. Befindet sich auf einem building noch eine amenity dann ist auch nicht mehr klar für wen oder was das gilt. Ich würde dringend anraten für Gebäude was separates zu nehmen.
Es mach m. E. schon einen deutlichen Unterschied, ob etwas 3-4 Wochen im Jahr oder 6 Monate an einem festen Standort steht. Ich persönlich würde da auch zusätzlich nach Nutzung differenzieren: Baustellen-Bürocontainer mappe ich eher nicht, auch wenn die gut und gerne mal 2 Jahre oder länger am gleichen Ort stehen. Ein aus Bürocontainern errichtetes temporäres Schulgebäude mappe ich dagegen sehr wohl, auch wenn das nach 2 Jahren wieder abgebaut werden wird.
den Einwand von skyper kann ich nicht nachvollziehen. Ist das Gebäude nur saisonal vorhanden, dann ist auch die darin befindliche Nutzung nur saisonal möglich. Mit prefixen müsste also ‘seaonal:’ sowohl vor das building als auch vor das amenity. Umgekehrt ist es nicht klar, also wenn das Gebäude da ist, das amenity aber nur saisonal genutzt wird. Dann müsste man aber nur beides getrennt anlegen, also das amenity als poi innerhalb des Gebäudeumrisses.
Die existierenden Anwendungen werten die existierenden Tags richtig aus. Ein vernünftiges Tagging-Schema bewegt sich innerhalb der bereits existierenden Welt.
Wenn Du wider besseren Wissens ein neues, inkompatibles Schema erfindest, hat das nichts damit zu tun daß der Rest der Welt “nicht richtig auswertet”. Du betreibst schlichtweg Sabotage.
Bitte was?
Ok, dann mach doch bitte einmal einen Vorschlag, innerhalb der von dir akzeptierten, bereits existierenden OSM-Welt, wie man entsprechende Objekte nun einträgt.
Und dass sie OTG-überprüfbar jedes Jahr wiederholt da sind, wurde ja hier nun mehrfach erklärt und auch die Sinnhaftigkeit/Wichtigkeit beispielsweise der Wasserwachttürme (wobei mir “Relevanz” als Kriterium ja echt neu wäre) ist bekannt.
Wenn du das nicht kannst/tust, sonder nur das
aussagst, frage ich mich, wer hier gerade Sabotage betreibt.
Oder wir haben jetzt hier irgendwie deine Aussage stark missverstanden, das will ich jetzt nicht ausschließen, dann vl. bitte anders erklären.
Gruß,
asca
Vorschläge wurde bereits oben gemacht. temporary:building=* seasonal:building=* Wobei ich nicht weiß ob das hier einige überhaupt interessiert…
Das bisherige Datenmodell… Ach pfeif drauf! 
Ich mach mir die Welt wie sie mir gefällt… Außerdem ich darf alles… und erst recht wenn es nicht dokumentiert ist…
Exakt. Da steht “invent new tags”. Da steht nicht “mess with established tagging scheme and break it”.
Einige Postings bei Facebook zum Auf- und Abbau des Hüttendorfes
https://www.facebook.com/nordseeurlaub.buesum/posts/2132724540141409/
Ja und? seasonal=* gibt es und ist genau für solche Objekte dokumentiert und wird bereits 1.256 zusammen mit building verwendet.
Mammi71 hier mutwillige Sabotage vorzuwerfen ist nicht die nette Art. Solltest Du eigentlich wissen.
So wie ich seasonal=* sehe, kommt der Tag vor allem von Wasserläufen. Ich habe auch kein Problem damit wenn er für Straßen und Gleise oder sonstige Objekte verwendet wird, solange diese Objekte weiterhin dort vorhanden sind. Anders sieht es aber aus, wenn die Objekte komplett abgebaut oder bewegt werden. Hier brauche ich eine klare Trennung.
So wie seasonal=* definiert ist, habe ich ja gar keine Möglichkeit die exakten Zeiten einzutragen.
Im Zusammenhang mit building=* und amenity=* wurde ich leicht falsch verstanden. Ich ging immer von separaten Objekten aus. Ich kann jetzt aber eine Kneipe haben, die nur im Sommer auf hat oder auch nur zweimal pro Monat. Solange nicht die komplette Einrichtung umzieht/entfernt wird, kein Problem. Schwierig wird es, wenn die Kneipe mobil ist und entweder mehrere Lokalitäten im Wechsel nutzt oder komplett umzieht (z.B als ehemaliger Speisewagen). Zusätzlich kann natürlich auch noch das gesamte Gebäude (Blockhütte) komplett zweimal im Monat von A nach B und wieder zurück transportiert werden.
Ein einfaches seasonal=yes an die Blockhütte halte ich da für unpassend. Auch müsste ich die Hütte und die Kneipe darin, ja an beiden Orten eintragen was wieder gegen das Prinzip von “one feature one object” verstößt.
Ich würde mich auf jeden Fall wundern, wenn ich die Kneipe und das Gebäude vor Ort nicht vorfinde.
Zugegeben ich habe hier übertrieben, aber den Weihnachtsmarkt und -baumverkauf, kann ich gerade noch mit seasonal=christmas abbilden, bei einem Café auf Rädern ist das bestimmt nicht mehr möglich.
+1 Das ist ja genau das was hier von einigen wehement verneint wird… 
Und seasonal kommt eben aus einer anderen Ecke und könnte zu Konflikten zwischen Gebäude und einer amenity führen so daß das alleine schon ein Grund ist es nicht zu nehmen.
Und was das Rendering betrifft: Was soll denn osm.org und all die anderen Renderer machen? Die Kacheln werden einmalig gerendert und fertig. Entweder mit Gebäude oder halt ohne.
Anders sieht das ganze bei Vector-Rendering aus. Da können solche Infos berücksichtigt werden. Da wird eh alles dynamisch erzeugt.
“Wir mappen nicht für den Renderer” ist an der Stelle ganz schön leichtfüßig und zeugt nicht gerade von viel technischer Ahnung oder Fingerspitzengefühl.
Ich habe jetzt mal nur die in OSM eingetragenen Wasserrettungsstationen im Raum Büsum (eine davon im betrachtetem Gebiet) aufgesucht.
http://overpass-turbo.eu/s/1chM
Die sind wie erwartet zur Zeit nicht vorhanden. Was machen wir für OSM daraus?
Ich tendiere zur Ergänzung von seasonal=* auch an anderen Objekten.Allerdings würde Gebäude und POI getrennt eintragen und seasonal=* ergänzen um klarzustellen um welches Objekt hier geht.
Meinungen?
Nein, weil es eben zu emergency=lifeguard seasonal=* gibt. Das scheint für mich so auch korrekt zu sein. Würdest du einen anderen tag dafür benutzen hast du ein nutzloses Objekt in der Datenbank das nicht mehr ausgewertet wird. Und dann kann es passieren, daß jemand kommt und das Ding nochmals, und zwar unter dem richtigen tag einträgt.
Der Titel zielt ja auf Gebäude ab, und da ist seasonal=* ungeeignet.
Für OSM sind Gebäude und andere Einrichtungen (ob nun Imbiss, Supermarkt, Wasserrettung, … ) verschiedene Dinge. Der Wasserrettungsstützpunkt (mit oder ohne seasonal=) hat eine Berechtigung ganz unabhängig vom Gebäude.
Es gibt gibt die Möglichkeit mehrere Features ob ein Objekt zu mappen. Das macht die Sache häufig einfacher. Manchmal wie in dem Fall wäre es aber unpassend weil temporäre Gebäude völlig anders in OSM zu handhaben sind wie temporäre Wasserrettungsstützpunkte bei denen ein seasonal= wohl (laut Wiki) passend ist.
Wird aber bereits über 1.000 mal verwendet und man könnte die Doku entsprechend erweitern. Ich sehe kein Problem damit, dass Karten das wie Gewässer mit intermittent=yes z.B. schraffiert darstellen.
Aha. Und was ist der Unterschied zu den ganzen Pois die trotz seasonal=* auf der Standdardkarte gerendert und angezeigt werden, egal ob gerade Saison ist oder nicht? Da stört es komischerweise auch niemanden.
Das habe ich so oder ähnlich nun schon häufiger argumentiert gelesen. Aber wo ist das dokumentiert? Oder basiert diese Ansicht lediglich darauf, dass nach allgemeiner Ansicht (und in der Realität in der überwiegenden Anzahl) Gebäude massiv und unverrückbar sind (Immobilien halt)? Eine solche Ansicht ist in OSM nicht haltbar. Im engl. Wiki steht bereits im ersten Satz zu buildings geschrieben:
Darunter habe ich auch folgenden Abschnitt gefunden:
Und da gibt es noch ein paar buildings mehr, die nicht absolut ortsfest sind …
Zu den Begrifflichkeiten:
temporary - vorübergehend: ist nach meinem Verständnis sehr ungenau, zu irgendeinem Zeitpunkt/Zeitraum, nach meinem Dafürhalten tendenziell eher einmalig. Um hier bei den buildings zu bleiben: typische Beispiele wären hier Baucontainer (die ich eher nicht mappen würde) oder das Container-Schulgebäude als temporäres Ausweichquartier während einer Sanierung/Neubau der Schule (was ich eher mappen würde). Das ist temporär, einmalig und wird nach Beendigung der Bauarbeiten abgebaut und kommt auch nicht wieder hin.
seasonal - saisonal: ist nach meinem Verständnis zwar immer noch mit deutlicher zeitlicher Unschärfe, aber genauer als temporär. Vorallem lässt sich dies auf immer wiederkehrende Zeiträume eingrenzen. Also eher nicht einmalig. In der Regel jedes Jahr wieder in nahezu gleichem Zeitraum und jeweils auch für einen durchaus längeren Zeitraum von mehreren Monaten. Damit bereits auf Dauer angelegt.
Typische Beispiele sind gerade diese Container und Imbisswägen, die an der Küste nur deshalb regelmäßig entfernt werden, um sie vor den Winterstürmen zu schützen. Hier ist in meinen Augen ein seasonal am building gerechtfertigt. Weder die wiki-Artikel zu buildings noch zu seasonal sagen etwas gegenteiliges dazu aus.
Verwendungen genau in diesem Sinne gibt es schon einige. Beispiele:
DLRG-Station Mittelbrücke Wyk hier
Strandsauna Rantum hier
Surfschule Windloop hier
oder bei unseren holländischen Nachbarn:
Wadwachterspost Richel hier
Elements Beach hier
+1
Man kann es ja gern auf building=static_caravan/container/ger/tent/houseboat … einschränken
Zu Konflikten führt es dann, wenn an einem (!) OSM-Objekt gleich mehrere Haupt-tags hängen, wie eben ein building=* zusammen mit einem amenity=* und dann ein Untertag hinzukommt, der ein Haupttag näher beschreiben soll - nun aber nicht klar ist, welches von beiden oder gar beide gleichzeitig. Solche Konflikte haben wir auch an anderen Stellen in OSM. Typisches Beispiel sind die Eishallen, die als Gebäude bestehen bleiben, die Eisbahn aber nur im Winter betrieben wird. Oder etliche (Eis-)Cafés, die nur im Sommer betrieben werden. Das kann man lösen, indem man das amenity (oder was auch immer) getrennt als Poi einträgt. Das ist ganz einfach! keep it simple, stupid!
Doch, finde ich auch nicht überall passend und hängt von unterschiedlichen Faktoren ab. Ein Festival-Gelände mit all den Installationen für nur ein paar Tage bis 2-3 Wochen, mag zwar schön Aussehen ist aber wohl die meiste Zeit nicht vorhanden.
Zumindest seasonal sollte dann auch überall mit dargestellt werden.
Mein Problem fängt spätestens da an, wo Gebäude mehr als einen festen Standort haben. Habe ich dann mehrere Objekte für ein reales Gebäude?
Gut temporary ist zu ungenau. Was haltet Ihr von periodical:*=*? Syntax kann die gleiche sein wie temporary.
Ich halte seasonal nicht für passend bei periodisch wiederkehrenden Einrichtungen, wenn es sich um einmal die Woche oder einmal im Monat dreht. Das hat nichts mit “Saison” zu tun.
Weiterhin bin ich nicht davon überzeugt, dass es richtig ist, einen Container, der mehrmals die Woche seinen Standort wechselt, an allen Standorten mit building=container + seasonal=yes einzutagen. Gleiches gilt auch für eine Jurte.
Ein Festival ist zeitlich zu kurz und hat auch wenig mit “Saison” zu tun. Das ließe sich vmtl. mit conditional und konkreten Datumsangaben besser abbilden. Meiner Meinung nach gehört das aber gar nicht in OSM, sondern umap und Co wären hier die geeigneten Mittel.
Wenn gewisse Voraussetzungen erfüllt sind würde ich persönlich das in Kauf nehmen. Aber:
meine volle Zustimmung!
Um diese Konstellation ging es weder im Eingangsbeitrag noch bei meinen Beispielen. Für Deine Beispiele ist seasonal ungeeignet. Eine Saisonabhängigkeit muss real als Voraussetzung gegeben sein, um seasonal=* richtig zu verwenden.
Meine Argumentation war auch nicht dahingehend, dass alle nur zeitweilig aufgestellten building=* ein seasonal=* bekommen sollten. Mir ging es nur darum zu widerlegen, dass seasonal=* im Zusammenhang mit building=* gar nicht möglich sein soll. Deine Beispiele widerlegen diese Auffassung ebenfalls nicht, da seasonal offensichtlich nicht zutreffend ist.
So oft wird der Standort einer Jurte auch nicht verlegt …
PS: einige Gebäude, die in den Niederlanden nur von Mai bis Oktober aufgebaut werden, haben sogar Eingang in das niederländische Kataster gefunden … Also selbst da werden Gebäude erfasst, die nicht permanent da stehen.
@Mammi71:
Mir ist die Diskussion auch irgenwie zu (“sesonal”) säsonal-fixiert.
Wenn also das Gebäude in die säsonale Schublade paßt dann ist es OK wenn mit dem OSM-Grundsatz örtlich/zeitlich unveränderlicher Gebäude gebrochen wird.
Und für die Weihnachtsmarkt-Buden die da 4-5 Wochen im Jahr stehen brauchen wir also keine Lösung. Für die Festival oder Freilichtbauten wohl auch nicht.
Wie sieht es mit den “Bauten” für einen Markt aus, der einmal die Woche für 3-4 Tage stattfindet? Die würden da ja dann ca. 50% der Zeit stehen…
Einfach nur ein sesonal an das Objekt pappen und gut ist! Das ist also die Lösung!? Nur für was denn genau?
Und das soll dann beim Rendern von Karten berücksichtigt werden!?!?!
Das einzige was vielleicht passieren wird ist, das gar nichts mehr dargestellt wird wenn der Schlüssel seasonal gefunden wird.
Ich würde daher dringend anraten das konzeptionell nochmals zu überdenken. Vorschläge für Prefixe wie “seasonal”, “temporary” gab es ja bereits… Und zumindestens sind Prefixe bei Gebäuden Gang&Gebe!
… und auch beim frohen Mappen darüber nachdenkt, ob das was man mappt, für die Auswerter (Router und Renderer) praxistauglich ist.