Weihnachts-Map Xmas

Hi,

nochmal zum Zeitraum… jetzt hab ich mal bei OSMand geschaut ob dort so was unterstützt wird und welchem Format:

Bei Ziele 2110 kommen die Tests:

Relevate wäre diese mit Jahresangabe:

"2019 Apr 1 - 2020 Apr 1"
"2019 Apr 15 -  2020 Mar 1"
"2019 Jul 23 05:00-24:00; 2019 Jul 24-2019 Jul 26 00:00-24:00; 2019 Jul 27 00:00-18:00"
"2019 Sep 1 - 2022 Apr 1"
"2019 Apr 15 - 2019 Sep 1: Mo-Fr 00:00-24:00"
"2019 Sep 1 - 2020 Apr 1"
"2019 Apr 15 - 2019 Sep 1"

ja finde ich auch… Um vielleicht irgendwann Software Support zu haben. Man kann bis dahin vielleicht noch die Aufteilung in Zeitraum und Zeit lassen

day_date  "2019 Apr 1 - 2020 Apr 1" und opening_hours "Mo-Fr 9:00-18:00"

PS: würde vielleicht den Leute einfacher machen es zu Pflegen…

Hab die Overpass Abfrage mal a bisserl umgemünzt :smile:

Wer mal alle XMAS Daten sehen möchte auf der ganzen Welt: (!!Vorsicht groß und langsam, statisch Stand von gestern Abend!!)

https://greymiche.lima-city.de/xmas/index.html?load=static

Gruß Miche

Zur Pflege von alte XMas-Daten eine Overpass-Abfrage. Es werden nur Daten angezeigt die älter als “2020-01-01T00:00:00Z” sind angezeigt… kann aber nach belieben abgeändert werden.

Gruß Miche

Hi Michael,

hab was gefunden das schon benutzt wird

https://taginfo.openstreetmap.org/tags/?key=recycling%3Achristmas_trees&value=yes

Gruß Miche

:rofl:
Sowas gibt es nur bei OSM.

(fast) nur die Deutschen denken bei so einem tag an echte Bäume :smiley:

Ich finde das ungünstig, weil ich dann in Kiel an jeder zweiten Straßenecke ein amenity=recycling habe, das nur zwei Wochen im Jahr existiert.

1 Like

[nicht ernst gemeint]
… und in anderen Ländern gibt es Sammelstellen für Kunststoffbäume, die recycled werden?
Zumindest bei den in Deutschland liegenden POIs zweifle ich an dem Ansatz: overpass turbo

das kann ich mir a nicht vorstellen… :rofl: :joy:

Dann würde ich an diesen Tagging annähern… xmas:amenity=recycling + recycling:christmas_trees=yes… Dann müsste alles gesagt sein… wenn diese recycling Stelle nur zur Weihnachtszeit ist… bzw. danach für kurze Zeit besteht.

4 Likes

Hey,

eine neue Version mit sidebar und so weiter:

https://greymiche.lima-city.de/xmas/

mfg Miche101

2 Likes

Hi,

ich hab nochmal daran gefeilt :slight_smile: Neu:

  • geo: Links… um z.B. am Handy auf Navi zum springen zu können
  • RawData um das komplette Orginal-Tagging anzusehen… ohne dazu auf die OSM Seite wechseln zu müssen.

Gruß Miche

1 Like

Hi,

jetzt hab ich eine Beschwerde bekommen warum ich einen name= auf xmas:name= geändert habe. Das wäre blöd und tagging für renderer usw.

Da muss ich feststellen das dass unterschiedlich im Wiki dokumentiert ist… bzw. nicht klar ist weil es nicht da steht explizit.

Es geht um xmas:feature=shop + xmas:feature:shop=christmas_tree ob man die restliche Tagging dann auch im Namespace macht also xmas:* oder im normalen Namespace name= , location=, description= usw.

Aus meiner Sicht spräche nichts dagegen…

OSMand taggt auch bei neuen POI name= bei xmas shops

Gruß Miche

Bei den anderen XMas-Objekten ergäben sich ähnliche Dinge… ob da alles im Namespace sein müsste… müsste man einzeln begutachten. Aber eins nach dem anderen

1 Like

bei xmas:tree:height= könnte man auch als height erfassen… nur ein Objekt wo man eine eigenständige Node erfassen müsste… bei Alstertanne . Aber da ist es auch nicht das selbe Ding… was eine Node rechtfertigen würde

Ja, die zusätzlichen Tags müsste man bei der Frage, ob mit oder ohne namespace wirklich einzeln begutachten. Im Zweifel gilt wahrscheinlich: “so wenig neues namespace wie möglich, aber so viel wie nötig”.

Bei den trees habe ich lit, location und level bisher auch immer ohne namespace benutzt (allerdings insgesamt auch nur ein paar Mal).

Eventuell sollte man diese Tatsache dann auch im Wiki dokumentieren, dass man sich bei den Tags Gedanken gemacht hat, welche mit und welche ohne namespace auskommen können.

ja bei den meisten Dinge die gemappt werden braucht man überhaupt keinen Namespace weil die Dinge sowieso als eigene Note, Way gemappt werden oder ganzjährig stehen oder offen haben und sie deshalb auch nicht unterscheiden…

xmas:feature = tree
da gibt es viele die einfach einfach ein natürlicher Baum sind an dem zu Weihnachten nur Lichter angebraucht werden z.B. XMAS-Map

xmas:feature = shop
Macht gar keinen Sinn wenn das z.B. ein Baumarkt ist das ganze tagging doppelt zu machen z.B. XMAS-Map

xmas:feature = pyramid
Gibt es einige die das ganze Jahr stehen… Way: ‪Großpyramide‬ (‪313307448‬) | OpenStreetMap

xmas:feature = crib, schwibbogen
Gibts auch Objekte die das ganz Jahr stehen… wir aber wird fast immer als eigene Note gemappt

xmas:feature = crib_museum
wird als tourism = museum erfasst, braucht keinen xmas: mehr zusätzlich.

xmas:feature = ice_rink
gibt Plätze die ganzjährig bestehen und als leisure = ice_rink erfasst sind.

usw.

Nur market, event und lighting… ist man besser im Namespace aufgehoben…

Aber ich hab auch schon Objekte gesehen die einen xmas:feature =* haben und mit seasonal = winter, chrismas markiert sind… da verwerte ich dann auch die normalen Tags… name=, website= usw. und überschreibe sie wenn ein XMas:* vorhanden ist.

1 Like

Also könnte man einen market auch komplett ohne xmas: nur mit xmas:feature=market erfassen… wenn man seasonal=christmas dran hängt. Würde jetzt funktionieren… wie es gerade programmiert ist. seasonal Werte ist auch egal was da steht Hauptsache nicht “no”