i.O. passt schon. Also so ähnlich nach dem Konzept von OSMcarto, bei dem beim letzten grossen Update, die grelleren Landuse Farben harmonisiert wurden :- )
Danke für die Karte!
i.O. passt schon. Also so ähnlich nach dem Konzept von OSMcarto, bei dem beim letzten grossen Update, die grelleren Landuse Farben harmonisiert wurden :- )
Danke für die Karte!
Hi,
jetzt ist der Josm-Editor auch integriert
Gruß Miche
Vielen Dank
Gibt wieder neues
Neue Tags an der XMAS Tagging Zeit. Hab auf taginfo: santas-grotto und santas-letterbox gefunden. Diese sind sogar im Wiki vorhanden aber nicht auf der Deutschen Seite sondern auf der Englischen Seite.
Santa’s_Grotto
Santa’s_Letterbox
In OSM sind diese auch schon zu finden:
Letterbox
santas-grotto
Gruß Miche
Hi Jan,
ich hab mir mal erlaubt die JOSM Vorlage für XMAS zu erweitern Hoffe ich hab alles richtig gemacht
https://josm.openstreetmap.de/wiki/Presets/Xmas
Gruß Miche
Hi,
was meint ihr was bei xmas:day_date richtig ist? Da findet man so alle Varianten… den Zeitraum bzw. die Tage anzugeben. Im Wiki stehen auch mehrere Varianten je nach Sprache
DE => 2016-11-28/2016-12-23
EN => 2009.11.23-2009.12.30
FR => 2016-11-21…2016-12-23
2016-12-21;2016-12-23;2016-12-24)
NL => 23.11.2009-30.12.2009
RU =>23.11.2009-30.12.2009
Bin da bisserl verwirrt… die letzten beiden Varianten finde ich am schönsten. Hab mir nie den Kopf gemacht… aber mit der JOSM Vorlage fällt mir das jetzt auf.
gruß Miche
Ich würde hier, identisch zu anderen Daten, wie z.B. start_date
immer ISO-8601-01 nehmen: YYYY-MM-DD. Das hat diverse Vorteile und ist eines der wenigen eindeutigen Formate.
ok… und dann bei einem Zeitraum… YYYY-MM-DD “/” oder " - " oder “…” YYYY-MM-DD
YYYY-MM-DD/YYYY-MM-DD
YYYY-MM-DD - YYYY-MM-DD
YYYY-MM-DD…YYYY-MM-DD
am Menschenfreundlichsten wäre vielleicht die zweite Variante
Hi hab mit dem " opening_hours Auswertewerkzeug" probiert…
der möchte sowas:
2023 Nov 25-2023 Dec 24 10:00-20:00, PH
Zeiträume werden normalerweise in einem der folgenden 4 Formate angegeben
YYYY-MM-DD-
-YYYY-MM-DD
YYYY-MM-DD-YYYY-MM-DD
YYYY-MM-DD--YYYY-MM-DD
Dabei kann man immer auch das -DD
oder -MM-DD
weglassen (also wäre 1948-1960
ebenso korrekt wie 1978-06-1980-11
oder 1992-2011-01-01
), falls nicht bekannt. Da jeder Zeitabschnitt mit 4 Ziffern beginnt, kann es nicht zu Missverständnissen kommen. Offiziell sagt ISO-8601, dass man mit einem /
trennen soll, aber da in OSM bestimmt auch der ein oder andere kein ISO-Datumsformat nimmt, könnte das /
dort zu mehr Verwirrung führen. Ich kenne das vor allem von den Date namespaces und es ist prinzipiell gut lesbar und nicht zu verwechseln. Der letzte Punkt ist hier bei OSM natürlich sehr wichtig aufgrund der verschiedenen Datumsformate.
ISO-8601 ist übrigens seit 1996 auch in Deutschland offizieller Standard für Datumsschreibweise (als Teil der DIN 5008), die D.M.YYYY
-Schreibweise ist nur im Inlandsschriftverkehr geduldet und nur, solange es unmissverständlich ist. Alternativ ist auch D. Monat YYYY
erlaubt. Aber das alles gilt natürlich nicht im Privatsektor, ist nur gut zu wissen.
Im von Dir verlinkten Preset sieht das aber wie folgt aus:
<combo
key="xmas:day_date"
text="time-window"
de.text="Zeitraum"
values="2022-11-25-2022-12-23,2023-12-01-2023-12-23,2024-11-29-2024-12-23,2025-11-28-2025-12-23,"
/>
Da sind das ISO-Zeiträume und kein opening_hours-Schema. Warum das im Beispiel im Wiki dann xmas:day_date=2009.11.23-2009.12.30
als Beispiel hat, weiß ich auch nicht. Prinzipiell sollte aber ein Auswerter beides verstehen.
ja das Preset hab ich ja gemacht… und darum auch die Frage ob das so richtig ist… weil es im Wiki auf jeder Seite anders steht…
Nun ist der Groschen gefallen, Entschuldigung. Ich habe vermutlich nur halbherzig gelesen
Keines der Beispiele nutzt das opening_hours-Schema, ich sehe allerdings Von-Bis und Von/Bis, wobei auf einer Seite ein Deutsches DD.MM.YYYY
steht, welches ich als falsch erachten würde. So ziemlich alle Systems verlassen sich auf das ISO-Format, nur dass in OSM jemand als Trennzeichen -
und --
vorschlägt und offiziell eigentlich /
der Standard wäre.
Als Software-Entwickler würde ich das entspannter parsen und sowohl /
, -
als auch --
als Trennsymbol der einzelnen Daten zulassen, da das Wiki -
und --
vorsieht, offiziell aber /
zu benutzen ist. Da wohl vergessen wurde zu erwähnen, in welchem Format es sein soll, würde ich mich im Zweifel strikt an das ISO-Format halten, weil das so ziemlich jede Bibliothek korrekt verarbeiten wird.
Also langer Rede, kurzer Sinn: Ich würde YYYY-MM-DD/YYYY-MM-DD
nehmen, aber das ist meine rein persönliche Einschätzung, die sich nicht durchs Wiki belegen lässt.
ok… ich hab mal im Wikipedia zum suchen begonnen:
hier wären Beispiele, diese zwei würde ich bevorzugen: (trenner "“slash” oder “zweimal Minus”
Ich halte es am sinnvollsten, sich an das Schema von conditional/openening_hours zu halten.
Also YYYY MMM TT-YYYY MMM TT (z.B. 2005 Aug 9-2005 Aug 30).
Ich frage mich allerdings auch, ob es den Schlüssel day_date überhaupt braucht. Die gleiche Aussage sollte doch auch in openenig_hours passen.
Ja, viellect xmas:feature=santas-letterbox
kommt von der irische Community: Christmas 2022 Challenge – OpenStreetMap Ireland
Würde ein Tag xmas:feature=tree_dump
Sinn machen für die Stellen, an denen man in Großstädten nach Weihnachten seine Weihnachtsbäume ablegen darf?
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