Semikolen bei verschiedenen Quellenangaben im Source-Tag erforderlich

?

Hallo,
ein Mapper hat mich darauf hingewiesen, daß meine Eingaben für Source nicht korrekt seien, weil ich für die Trennung der verschiedener Quellenangaben kein Seminkolen verwende.
Beispiel:

Bei meiner Antwort,

habe ich ihm auch Angeboten, im OSM-Forum noch die Meinung anderer Mapper einzuholen, worum er mich nun gebeten hat.

Meine Frage ist also:
Werden Quellenangaben im Source-Tag oder in den CS-Kommentaren irgendwo maschinell weiter verarbeitet, wozu das Semikolen erforderlich ist, oder können die Quellenangaben in beliebigem Syntax erfolgen ?

Grüße

Edith: Beitragstitel berichtigt

Spricht denn etwas gegen den Semikolon? Was auf jeden Fall dafür spricht, wäre Einheitlichkeit. Wenn Mehrfacheinträge generell per Semikolon getrennt werden, warum hier eine Ausnahme machen?

name sollte gar keinen Trenner erhalten, der stört nur beim Suchen.

ref_name wird als Referenz in fremder Datenbank verwendet und erhält die dort genutzte Schreibweise mit Komma. Beispiel Bushaltestelle “Klinikum, Solingen”

description ist freier Text, Trenner zur Lesbarkeit teils sinnvoll.

note und fixme sollte in erster Linie kurz sein, i.A. Komma bei Aufzählung oder Satzbau.

source am Objekt ist eigentlich entbehrlich, da in changesets die Grundlagen angegeben werden.
source im changeset trenne ich mit Semikolon, da es eindeutiger ist.
In deinem Beispiel würde ich “Maps4BW;Mapbox Satellitenbild” verstehen, den Rest müsste ich nachschlagen.

Da die Source Einträge nicht standardisiert sind, kann man sie eh nur auswerten, indem man bspw nach Mapbox in einem String sucht. Und da ist es vollkommen egal, wie man die Einträge trennt. Irgendwann, wenn es mal eine feste Liste der Source Tags gibt und nicht Mapbox Aerial, Mapbox Satellite Image, Mapbox Luftbild, Mapbox Satellitenbild,… genutzt wird, wäre auch ein definiertes Trennzeichen hilfreich. Das passiert vermutlich kurz nach einer Einigung über footway vs path.

Dann dürfte man bei den Quellenangaben auch keine Leerzeichen verwenden ?

Grüße

Was ist mit dem Leerzeichen bei “Mapbox Satellitenbild” ?
Das wäre dann - wegen der Einheitlichkeit - auch nicht zulässig, oder ?

Grüße

Das ist auch meine Meinung.

Also nie. :smiley:

Grüße

Laut heiliger Schrift soll ein ; als Trennzeichen verwendet werden:
https://wiki.openstreetmap.org/wiki/Key:source

Oh, du Häretiker. Sieh, was offenbart wurde:
https://wiki.openstreetmap.org/wiki/Key:source#Specific_values

Als Auswerter würde ich im ganzen String nach “survey” suchen und mir ein Semikolon-Splitting sparen.

hi,

JOSM macht source=source1; source2; source3, wobei sourceN der Name des Hintergrundes ist. Mit Leerzeichen nach den Kommata.

Gruss
walter, der von source=survey+esri jetzt Abstand nehmen will.

Verwendest Du eine Vorlage ?
Bei mir macht JOSM das, was ich reinschreibe.

Grüße

Nö, obwohl es eine gibt.
nee, ich klicke auf “von den aktuellen Ebenen abrufen” vor dem Hochladen.

Gruss
walter

Also nie.
:smiley: :smiley: :smiley:

Dafür sehe ich keinen Grund. Es gibt ja auch Angaben wir ref=B xxx;B yyy. Auf der Karte werden die dann als getrennte Zeilen angezeigt. Ist ja auch zulässig.

Im Wiki
https://wiki.openstreetmap.org/wiki/DE:Key:opening_hours
entnehme ich den Beispielen, dass die Zeiten innerhalb eines Tages mit Komma ohne Leerzeichen getrennt werden. Wird dann ein anderer Tag zugefügt mit anderen Zeiten, erfolgt zwischen den einzelnen Tagen die Trennung mit Semikolon, z.B.:
Mo 10:00-12:00,12:30-15:00; Tu-Fr 08:00-12:00
Wenn das so richtig und gewollt ist, dass also nach Komma ohne Leerzeichen und nach Semikolon mit Leerzeichen weitergeschrieben werden soll, sollte so auch grundsätzlich verfahren werden. Dann müsste m.E. allerdings auch die folgende Zeile im Wiki geändert werden, da hier die Wochentage mit Komma getrennt sind:
Su-Tu 11:00-01:00, We-Th 11:00-03:00, Fr 11:00-06:00, Sa 11:00-07:00

Komma und Semikolon haben bei opening_hours verschiedene Bedeutungen.
Mit Komma abgetrennte Regeln wirken additiv, mit Semikolon überschreibend.

Bei deinen beiden obigen Bespielen macht das keinen Unterschied, hier aber schon:
“Mo-Fr 09:00-13:00**;** We 15:00-18:00” bedeutet, dass montags, dienstags, donnerstags und freitags von 9 bis 13 Uhr geöffnet ist und mittwochs ausschließlich von 15 bis 18 Uhr.
“Mo-Fr 09:00-13:00**,** We 15:00-18:00” hingegen bedeutet, dass montags, dienstags, mittwochs, donnerstags und freitags von 9 bis 13 Uhr geöffnet ist und mittwochs zusätzlich von 15 bis 18 Uhr.

Danke für die Erklärung. Man lernt halt nie aus.
Zusatzfrage:
Bleibt es dabei, dass innerhalb eines Tages oder einer Gruppe (z.B. Mo-Fr) die Uhrzeiten nach einer Zwischenpause durch Komma ohne Leerzeichen, beim Wechsel auf einen anderen Tag jedoch durch Komma (bei additiver Wirkung) oder Semikolon mit Leerzeichen zu trennen sind? Oder spielt das Leerzeichen keine besondere Rolle?

Kennst du http://openingh.openstreetmap.de/evaluation_tool/ ? Da kannst du es ausprobieren.

–ks

Ich faße dann mal zusammen:

Ob bei den Quellenangaben im Source-Tag verschiedene Werte durch Semmikolen oder ein anderes Zeichen getrennt werden, hat keinerlei Auswirkungen, weder positiv noch negativ (Siehe Beitrag # 4 von SunCobalt und Beitrag # 8 von wilmaed).

Das Argument Einheitlichkeit für eine Trennung mit Semmikolen zieht für mich nicht, solange keine einheitlichen Quellenangaben vorgegeben sind / verwendet werden.

Vielen Dank für Eure Beiträge.

Grüße aus Oberschwaben

Zumindest ist das Usus.
Und ja, das Leerzeichen spielt, soweit ich weiss “eigentlich” keine besondere Rolle. Meine Meinung dazu: Man sollte nicht nur alles einheitlich taggen, weil das Wiki uns das so sagt, sondern auch, damit sich Neumapper oder Wiki-verweigerer nicht die Eigenheiten von anderen Mappern abschauen. Huch, da bin ich ja wieder beim Thema. Hinzu kommt, dass es auch lesbarer ist.

Tip: statt des evaluation-tools kann man auch gleich den Validator von Josm verwenden. Der verwendet meines Wissens den selben Renderer (ja, nich so schön aufgehybscht). Hierzu muss für Leerzeichen"fehler" “andere Warnungen” aktiv gesetzt sein.

Ich würde diesen Thread gerne nochmal aufleben lassen:

Dem muss ich leider wie bereits wilmaed in Post #4 widersprechen.

Soweit ich das hier sehe spricht mehr für eine Standardisierung als gegen eine solche.

Liebe Grüße