Semikolen bei verschiedenen Quellenangaben im Source-Tag erforderlich

PT-53 · 2018-01-09T09:32:37.000Z

?

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:

Maps4BW ( LGL, www.lgl-bw.de) / Mapbox Satellitenbild
https://www.openstreetmap.org/way/407365300
https://www.openstreetmap.org/changeset/55193974

Bei meiner Antwort,

Auszug:
Du hast natürlich recht was Mehrfach-Schlüsselwerte bei Schlüsseln angeht, die maschinell für Karten etc. aufbereitet werden. Source-Angaben werden aber nicht von Programmen “verarbeitet”, sie werden nur von Menschen gelesen und dazu ist kein besonderer Syntax erforderlich. Das gilt zum Beispiel auch für die Schlüssel name, note, description und fixme.

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

glglgl · 2018-01-09T10:12:03.000Z

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?

axelr · 2018-01-09T10:20:44.000Z

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.

SunCobalt · 2018-01-09T10:26:33.000Z

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.

PT-53 · 2018-01-09T10:33:15.000Z

glglgl:

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?

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

Grüße

PT-53 · 2018-01-09T10:36:14.000Z

axelr:

In deinem Beispiel würde ich “Maps4BW;Mapbox Satellitenbild” verstehen, den Rest müsste ich nachschlagen.

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

Grüße

PT-53 · 2018-01-09T10:40:00.000Z

SunCobalt:

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.

Das ist auch meine Meinung.

SunCobalt:

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.

Also nie.

Grüße

wilmaed · 2018-01-09T10:49:27.000Z

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

just use the standard OSM multivalue convention of separating them with a “;” (semicolon) e.g. source=survey;local knowledge

SunCobalt:

Da die Source Einträge nicht standardisiert sind

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.

wambacher · 2018-01-09T11:28:07.000Z

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.

PT-53 · 2018-01-09T11:45:34.000Z

wambacher:

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

wambacher · 2018-01-09T12:09:30.000Z

PT-53:

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

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

Gruss
walter

chris66 · 2018-01-09T12:10:49.000Z

SunCobalt:

Das passiert vermutlich kurz nach einer Einigung über footway vs path.

Also nie.

Änderungssatz #55141333:

Seitenwege des Kanals zu “Weg” geändert, damit Apps wie MAPS.ME Fahrrad-Routen darüber anlegen. Der Kanaldamm ist hervorragend dafür geeignet. … Bitte den Rest ebenfalls ändern. Bei Fragen bitte .@gmail.com oder hier. Lg

glglgl · 2018-01-09T12:25:39.000Z

PT-53:

axelr:

In deinem Beispiel würde ich “Maps4BW;Mapbox Satellitenbild” verstehen, den Rest müsste ich nachschlagen.

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

Grüße

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.

ghostrider44 · 2018-01-11T10:42:36.000Z

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

whb · 2018-01-11T23:09:26.000Z

ghostrider44:

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

ghostrider44:

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.

ghostrider44 · 2018-01-12T09:39:22.000Z

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?

kreuzschnabel · 2018-01-12T10:05:01.000Z

ghostrider44:

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

PT-53 · 2018-01-13T16:17:38.000Z

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

MKnight · 2018-01-13T16:36:28.000Z

ghostrider44:

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?

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.

Bananensaft · 2018-04-04T18:01:58.000Z

Ich würde diesen Thread gerne nochmal aufleben lassen:

PT-53:

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

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