Temporäre Gebäude. Jedes Jahr wieder an ungefähr gleichem Ort.

Ich zeichne temporäre Gebilde gar nicht ein (analog zur professionellen Kartographie).

Wenn man sie unbedingt einzeichnen will, sollten sie auf jeden Fall ein neues Haupttag oder ein Prefix am Haupttag bekommen. Wenn die besonderen Umstände lediglich in Zusatztags untergebracht werden, erscheinen sie in allen existierenden Karten und Anwendungen falsch als dauerhafte Gebäude.

Ich würde sie auch nicht eintragen. Jedenfalls nicht als Gebäude.

Nop wrote:

Ich zeichne temporäre Gebilde gar nicht ein

Das sind nicht einmalig temporäre Gebilde. Die sind in jedem Jahr wieder da. Manche dort vorhandenen POIs sogar mit Website, z.B.https://www.bistro-laguna-buesum.de/. Ob diese Container auf Luftbildern sind hängt davon ab wann die aufgenommen wurden. Sie einfach zu ignorieren bring da nichts, die sind schnell wieder eingezeichnet. Wie bringt man das temporäre zum Ausdruck? Für die Container vielleicht sowas wie temporary:building=yes in Anlehnung an die Lifecycle-Prefix.Für die POIs darin?Keine Ahnung.

Du schreibst im Betreff, dass die Container nicht mal am gleichen Ort stehen ("ungefähr"). amenity=fast_food etc. könnte man mit Öffnungszeiten entsprechend eintragen. Aber nicht die "Gebäude".

OSM_RogerWilco wrote:

Du schreibst im Betreff, dass die Container nicht mal am gleichen Ort stehen ("ungefähr"). amenity=fast_food etc. könnte man mit Öffnungszeiten entsprechend eintragen. Aber nicht die "Gebäude".

Auch `amenity` halte ich bei nicht fest-installierten Objekten für inkorrekt. Auch wenn ein Restaurant geschlossen hat, ist es vor Ort sichtbar und dient als Orientierungshilfe.

Habe ein ähnliches Problem mit Food-Trucks und mobilen Cafés. Ein anderes Beispiel sind Marktstände. Wir brauchen einen eigenen Schlüssel oder Präfix für so was, nur einen Zusatztag oder gar nur Öffnungszeiten funktioniert mMn. hier nicht.

Erinnerte mich jetzt stark an dieses Thema https://forum.openstreetmap.org/viewtopic.php?id=73656 (war ja auch von dir) und da wurde dann schon https://wiki.openstreetmap.org/wiki/Key:seasonal vorgeschlagen. Unterschied zu dem anderen ist diesmal wohl, dass es keinen "Winterstandort" gibt, also ist seasonal noch passender. Bei dem anderen war's ja eher so, dass es woanders weiterhin anschaubar ist, sich eher der Node verschieben müsste.

OSM_RogerWilco wrote:

Du schreibst im Betreff, dass die Container nicht mal am gleichen Ort stehen ("ungefähr"). amenity=fast_food etc. könnte man mit Öffnungszeiten entsprechend eintragen. Aber nicht die "Gebäude".

Selbst wenn die Gebäude/Container jedesmal ein wenig anders dastehen, finde ich es besser wenn sie dennoch überhaupt erfasst sind als gar nicht, oder?

Immer wieder das gleiche Thema und leider (glaube ich) immer noch keine Lösung.

Man könnte "sesonal" einfach mal als prefix für die Gebäude nehmen -> sesonal:building=yes
Über sesonal=* wird das dann gesteuert.
Wäre jetzt mal mein Vorschlag...

the-asca wrote:

Selbst wenn die Gebäude/Container jedesmal ein wenig anders dastehen, finde ich es besser wenn sie dennoch überhaupt erfasst sind als gar nicht, oder?

+1
Und sonst kommt wieder jemand und zeichnet diese als reguläre Gebäude ein...

the-asca wrote:

Erinnerte mich jetzt stark an dieses Thema https://forum.openstreetmap.org/viewtopic.php?id=73656 (war ja auch von dir) und da wurde dann schon https://wiki.openstreetmap.org/wiki/Key:seasonal vorgeschlagen. Unterschied zu dem anderen ist diesmal wohl, dass es keinen "Winterstandort" gibt, also ist seasonal noch passender. Bei dem anderen war's ja eher so, dass es woanders weiterhin anschaubar ist, sich eher der Node verschieben müsste.

Halte `seasonal=*` hier für ungeeignet, weil ja das gesamte "Gebäude" und die Einrichtung/Restaurant komplett verschwinden. Wenn das Gebäude stehen bleibt und das Restaurant nur saisonal geöffnet ist, würde es passen.

the-asca wrote:

OSM_RogerWilco wrote:

Du schreibst im Betreff, dass die Container nicht mal am gleichen Ort stehen ("ungefähr"). amenity=fast_food etc. könnte man mit Öffnungszeiten entsprechend eintragen. Aber nicht die "Gebäude".

Selbst wenn die Gebäude/Container jedesmal ein wenig anders dastehen, finde ich es besser wenn sie dennoch überhaupt erfasst sind als gar nicht, oder?

Ja, aber wie? Das mit nur einem Zusätztag einzutragen, halte ich für unpassend.
`seasonal:building=*` + `seasonal:amenity=restaurant` oder allgemeiner `temporary:building` + `temporary:amenity`?
Bei letzterem bekomme ich auch meine Marktstände und Food-Trucks unter.

skyper wrote:

`seasonal:building=*` + `seasonal:amenity=restaurant` oder allgemeiner `temporary:building` + `temporary:amenity`?
Bei letzterem bekomme ich auch meine Marktstände und Food-Trucks unter.

temporary:building und temporary:amenity gibt es schon, aber sehr selten.

temporary:building
https://taginfo.openstreetmap.org/keys/ … g#overview

temporary:amenity
https://taginfo.openstreetmap.org/keys/ … y#overview

Danke dann werde ich wohl `temporary:amenity=cafe @ (We,Sa 08:00-; PH off)` verwenden für mein mobiles Café zu Marktzeiten.

Fischkopp0815 wrote:

skyper wrote:

`seasonal:building=*` + `seasonal:amenity=restaurant` oder allgemeiner `temporary:building` + `temporary:amenity`?
Bei letzterem bekomme ich auch meine Marktstände und Food-Trucks unter.

temporary:building und temporary:amenity gibt es schon, aber sehr selten.

temporary:building
https://taginfo.openstreetmap.org/keys/ … g#overview

temporary:amenity
https://taginfo.openstreetmap.org/keys/ … y#overview

Auch gut! 🙂
Löschen... und dann kommt der nächste und zeichnet sie wieder als reguläre Gebäude ein ist halt auch dauer keine Lösung.

Fischkopp0815 wrote:

Das sind Container die da in jedem Jahr von ca. Mai-Okt in etwa gleicher Anordnung stehen. Im Augenblick werden sie mal wieder für den Winter abgebaut.

Ich habe auch so ein Beispiel, wo ich seit geraumer Zeit überlege, wie ich das sinnvoll tagge. In meinem Lieblingsurlaubsort werden für die DRK Wasserwacht jedes Jahr an den gleichen Standorten auf der Düne Container als Wasserwachttürme aufgestellt.
Für Container als Gebäude gibt es https://wiki.openstreetmap.org/wiki/Tag … Dcontainer

Nop wrote:

Wenn man sie unbedingt einzeichnen will, sollten sie auf jeden Fall ein neues Haupttag oder ein Prefix am Haupttag bekommen.

Warum immer neue Tags erfinden, wenn sich das mit bestehenden datenbanktechnisch hinreichend genau abbilden lässt?

Nop wrote:

Wenn die besonderen Umstände lediglich in Zusatztags untergebracht werden, erscheinen sie in allen existierenden Karten und Anwendungen falsch als dauerhafte Gebäude.

Der Grundsatz 'Wir taggen nicht für den Renderer' gilt auch umgekehrt: wir lassen nicht etwas weg, nur weil Renderer oder Anwender das nicht oder nicht richtig auswerten.

the-asca wrote:

und da wurde dann schon https://wiki.openstreetmap.org/wiki/Key:seasonal vorgeschlagen.

+1 genau für solche Anwendungen ist seasonal=* da.

the-asca wrote:

Unterschied zu dem anderen ist diesmal wohl, dass es keinen "Winterstandort" gibt, also ist seasonal noch passender.

Genaugenommen stehen die Container auch im Winter irgendwo abgestellt und warten auf ihren nächsten Einsatz.

the-asca wrote:

Selbst wenn die Gebäude/Container jedesmal ein wenig anders dastehen, finde ich es besser wenn sie dennoch überhaupt erfasst sind als gar nicht, oder?

In meinem Beispiel der Wasserwachttürme finde ich es nicht nur besser sondern wichtig, dass die überhaupt erfasst werden. Das sind lebensrettende Informationen. In meinem Fall stehen sie auch jedes Jahr exakt an der gleichen Stelle, die Fundamente bleiben ja an Ort und Stelle, wenn sie nicht von Winterstürmen beschädigt werden.

EinKonstanzer wrote:

Man könnte "sesonal" einfach mal als prefix für die Gebäude nehmen -> sesonal:building=yes
Über sesonal=* wird das dann gesteuert.

seasonal als prefix hätte aktuell nur den effekt, dass auf der Standardkarte kein Rendern erfolgen würde. Einen Mehrwert sehe ich darin auch nicht. Das etablierte seasonal=* reicht vollkommen aus und hätte den Vorteil, dass dies gleich für alles gelten würde, was an den Gebäudeumriss getaggt ist. Und es ist kiss.

Mammi71 wrote:

the-asca wrote:

und da wurde dann schon https://wiki.openstreetmap.org/wiki/Key:seasonal vorgeschlagen.

+1 genau für solche Anwendungen ist seasonal=* da.

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.

Mammi71 wrote:

In meinem Beispiel der Wasserwachttürme finde ich es nicht nur besser sondern wichtig, dass die überhaupt erfasst werden. Das sind lebensrettende Informationen. In meinem Fall stehen sie auch jedes Jahr exakt an der gleichen Stelle, die Fundamente bleiben ja an Ort und Stelle, wenn sie nicht von Winterstürmen beschädigt werden.

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.

Mammi71 wrote:

Nop wrote:

Wenn die besonderen Umstände lediglich in Zusatztags untergebracht werden, erscheinen sie in allen existierenden Karten und Anwendungen falsch als dauerhafte Gebäude.

Der Grundsatz 'Wir taggen nicht für den Renderer' gilt auch umgekehrt: wir lassen nicht etwas weg, nur weil Renderer oder Anwender das nicht oder nicht richtig auswerten.

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.

Mammi71 wrote:

EinKonstanzer wrote:

Man könnte "sesonal" einfach mal als prefix für die Gebäude nehmen -> sesonal:building=yes
Über sesonal=* wird das dann gesteuert.

seasonal als prefix hätte aktuell nur den effekt, dass auf der Standardkarte kein Rendern erfolgen würde. Einen Mehrwert sehe ich darin auch nicht. Das etablierte seasonal=* reicht vollkommen aus und hätte den Vorteil, dass dies gleich für alles gelten würde, was an den Gebäudeumriss getaggt ist. Und es ist kiss.

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.

EinKonstanzer wrote:

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?

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.

EinKonstanzer wrote:

Befindet sich auf einem *building* noch eine *amenity* dann ist auch nicht mehr klar für wen oder was das gilt.

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.

Mammi71 wrote:

Nop wrote:

Wenn die besonderen Umstände lediglich in Zusatztags untergebracht werden, erscheinen sie in allen existierenden Karten und Anwendungen falsch als dauerhafte Gebäude.

Der Grundsatz 'Wir taggen nicht für den Renderer' gilt auch umgekehrt: wir lassen nicht etwas weg, nur weil Renderer oder Anwender das nicht oder nicht richtig auswerten.

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.

Nop wrote:

Du betreibst schlichtweg Sabotage.

Feel free to invent new tags! If you want to mark something that is verifiable and mappable in OpenStreetMap but there is no existing tagging scheme for that - then you can invent and use new tags

https://wiki.openstreetmap.org/wiki/Any_tags_you_like

Nop wrote:

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?

Nop wrote:

Mammi71 wrote:

Nop wrote:

Wenn die besonderen Umstände lediglich in Zusatztags untergebracht werden, erscheinen sie in allen existierenden Karten und Anwendungen falsch als dauerhafte Gebäude.

Der Grundsatz 'Wir taggen nicht für den Renderer' gilt auch umgekehrt: wir lassen nicht etwas weg, nur weil Renderer oder Anwender das nicht oder nicht richtig auswerten.

Die existierenden Anwendungen werten die existierenden Tags richtig aus. Ein vernünftiges Tagging-Schema bewegt sich innerhalb der bereits existierenden Welt.

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

Nop wrote:

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.

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

the-asca wrote:

Nop wrote:

Mammi71 wrote:

Der Grundsatz 'Wir taggen nicht für den Renderer' gilt auch umgekehrt: wir lassen nicht etwas weg, nur weil Renderer oder Anwender das nicht oder nicht richtig auswerten.

Die existierenden Anwendungen werten die existierenden Tags richtig aus. Ein vernünftiges Tagging-Schema bewegt sich innerhalb der bereits existierenden Welt.

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.

Vorschläge wurde bereits oben gemacht. temporary:building=* seasonal:building=* Wobei ich nicht weiß ob das hier einige überhaupt interessiert...

the-asca wrote:

Wenn du das nicht kannst/tust, sonder nur das

Nop wrote:

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.

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

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... 🙂

OSM_RogerWilco wrote:

Feel free to invent new tags! If you want to mark something that is verifiable and mappable in OpenStreetMap but there is no existing tagging scheme for that - then you can invent and use new tags

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. … 540141409/

Nop wrote:

Exakt. Da steht "invent new tags". Da steht nicht "mess with established tagging scheme and break it". :-)

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.

skyper wrote:

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.

+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?
- Nicht eintragen weil nur temporär vorhanden? Das kann wohl zumindest für etwas wichtiges nicht die Lösung sein.
- eintragen z.B. als temporary:emergency=lifeguard ? Ich finde das von der Systematik am besten.Aber das wird wohl von keinem Renderer und auch von sonst keinem Auswerter betrachtet. Auch das halte ich zumindest bei wichtigen Objekten für ungünstig.Ich würde es darum eher nicht verwenden.
- seasonal=* ergänzen? Das ist für emergency=lifeguard im Wiki so dokumentiert https://wiki.openstreetmap.org/wiki/DE: … Dlifeguard

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?

Fischkopp0815 wrote:

- Nicht eintragen weil nur temporär vorhanden? Das kann wohl zumindest für etwas wichtiges nicht die Lösung sein.
- eintragen z.B. als temporary:emergency=lifeguard ? Ich finde das von der Systematik am besten.Aber das wird wohl von

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.

Fischkopp0815 wrote:

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?

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.

EinKonstanzer wrote:

Der Titel zielt ja auf Gebäude ab, und da ist seasonal=* ungeeignet.

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.

EinKonstanzer wrote:

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.

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.

EinKonstanzer wrote:

Der Titel zielt ja auf Gebäude ab, und da ist seasonal=* ungeeignet.

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:

wiki:en wrote:

The definition of "building" is not straightforward. The OpenStreetMap definition is quite wide and includes not only objects considered as buildings by strict definitions but also building=static_caravan, building=houseboat and may include at least some building=storage_tank.

Darunter habe ich auch folgenden Abschnitt gefunden:

wiki:en wrote:

building ger A permanent or seasonal round yurt or ger used as dwelling.

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

Fischkopp0815 wrote:

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?

+1
Man kann es ja gern auf building=static_caravan/container/ger/tent/houseboat ... einschränken

EinKonstanzer wrote:

könnte zu Konflikten zwischen Gebäude und einer *amenity* führen so daß das alleine schon ein Grund ist es nicht zu nehmen.

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!

Mammi71 wrote:

EinKonstanzer wrote:

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.

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.

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.

Mammi71 wrote:

EinKonstanzer wrote:

Der Titel zielt ja auf Gebäude ab, und da ist seasonal=* ungeeignet.

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:

wiki:en wrote:

The definition of "building" is not straightforward. The OpenStreetMap definition is quite wide and includes not only objects considered as buildings by strict definitions but also building=static_caravan, building=houseboat and may include at least some building=storage_tank.

Darunter habe ich auch folgenden Abschnitt gefunden:

wiki:en wrote:

building ger A permanent or seasonal round yurt or ger used as dwelling.

Und da gibt es noch ein paar buildings mehr, die nicht absolut ortsfest sind ....

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?

Mammi71 wrote:

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.

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.

skyper wrote:

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.

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.

skyper wrote:

Habe ich dann mehrere Objekte für ein reales Gebäude?

Wenn gewisse Voraussetzungen erfüllt sind würde ich persönlich das in Kauf nehmen. Aber:

skyper wrote:

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.

meine volle Zustimmung!

skyper wrote:

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.

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.

skyper wrote:

Gleiches gilt auch für eine Jurte.

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.