Standardwerte

Immer wieder stolpere ich im Wiki über folgenden oder ähnlichen Text dies ist der Standardwert und braucht nicht kartiert zu werden
Aus meiner Sicht kann es keine Standardwerte geben. Wie soll Mensch oder Software feststellen, ob der fehlende Wert vergessen wurde oder der Standardfall vorliegt und nicht gemappt werden braucht? Ich glaube, dass gerade unerfahrende Mapper hier schnell etwas falsch machen können. Zumal in den Tools i.d.R. nicht ersichtlich ist, welcher TAG ist denn Standard.
Und wer definiert denn, was ein Standardwert ist?

Ich vermute, dass dieses Thema hier nicht neu ist. Ich habe bei der Suche im Forum aber nichts gefunden :frowning:

Gegenbeispiel: bräuchte es wirklich an jedem Straßenstück ein “dies ist keine Einbahnstraße”, also “oneway=no”?

Ich denke in solchen Fällen kann man sich durchaus darauf einlassen, dass “keine Angabe” mit “no” gleichzusetzen ist.

Immer noch besser als wenn ein “no” als Preset-Wert vorgegeben und dann nicht geändert wird, auch wenn man sich eigentlich nicht sicher ist (weil Weg aus Luftbild übernommen zB).

Und dann hätten wir da möglicherweise ein klares, aber falsches “nein” statt “keine Angabe, also vermutlich nein, mit kleiner Unsicherheit” …

Das Thema ist ein Hornissennest. Diejenigen die dem “radikal-minimalismus” verfallen sind halten jedes tag was man auf irgendeine weise als default erahnen könnte für absoluten “Bloat” und die verdammnis soll dich sofort ereilen.

Defakto ist es so das “doppelte tag/values” perfekt im PBF wegkomprimiert werden also kaum ins Gewicht fallen. Dazu kommt das einen “Algorithmus” zu entwerfen der für jede Sonderlocke den richtigen Wert hat zwar im Bereich des Theoretisch machbaren ist, aber sicherlich nicht für JEDEN Hobbyprogrammierer der mit OSM Daten etwas macht.

Daher ja - Es macht Sinn viel “explizit” zu taggen. Es macht auch Sinn Dinge zu taggen wenn man erwarten könnte das sie da sind, in diesem fall aber nicht.

Beispiele:

oneway=no/yes auf einem cycleway. Die StVO sagt das Straßenbegleitende Radwege eben nur der Rechtsseitige genutzt werden dürfen, es sei denn die andere Seite ist freigegeben oder angeordnet. Ohne tagging kann ich nicht wissen was vor Ort angeordnet ist bzw ob jemand es vielleicht einfach nur nicht erfasst hat. (Gerne genommener Fehler - An Kreuzungen verbleibt das oneway=yes)

lit=no/yes - Man könnte denken das man innerhalb geschlossener Ortschaften immer von lit=yes ausgehen könnte. Dem ist aber nicht so. Es gibt keine saubere Regel, also auf jedem weg, parking etc ein explizites lit=no/yes

sidewalk=yes/no/both/left/right - Es gibt keine Regel nachdem man einen Bürgersteig annehmen kann. Also explizit taggen. Auch ausserhalb geschlossener Ortschaften (Deren Dimension ja in OSM auch gar nicht erfasst ist).

source:maxspeed= oder maxspeed:type= ersetzen kein maxspeed= - Das ist nur woher das kommt. Denn ein maxspeed=50 kann durch ein Ortsschild, oder eine anderes Schild angeordnet werden.

Etc etc etc … Es gibt tausend Beispiele.

Und bevor jemand argumentiert “Ja aber man könnte das ja mit einem Algorithmus machen”. Derjenige soll bitte diesen Algorithmus in den Programmiersprachem Python, Ruby, Perl, C, C++, Go vorlegen und entsprechend validieren (Auf dem Planet) so das die ganzen Hobbyprogrammierer das einfach nur inkludieren könne. Diejenigen die dabei gerne mit "Das ist aber ja ganz einfach… " argumentieren haben oft noch NIE mit OSM Daten algorithmisch gearbeitet.

Also - Bleib dabei - Tag die Dinge explizit.

Flo

Ja - mit defaults zu arbeiten halte ich für sehr sinnvoll. Wenn User an einen Waldweg in NRW snowmobile=no kleben hätte ich gerne mal das Schild vor Ort gesehen.

Gruß
tux67

Ich sehe das ähnlich. Man muss nicht an jedes Objekt alles drankleben, was es nicht ist. Ein bridge=no will doch auch keiner haben. Auf der anderen Seite wundere ich mich in letzter Zeit oft, das brouter mir für sehr viele Kilometer Strecke ein “unbekannte” surface anzeigt. Wenn man dann genauer schaut, sind das oft hw=tertiary oder höher, bei denen man in D getrost davon ausgehen kann, dass sie asphaltiert sind, wenn nichts anderes dransteht.

[Ironie ein]
Also an jeder Dorfstraße
name:[List of ISO 639 language codes - Wikipedia]=no , damit klar ist, dass es weder einen abchasischen, noch einen Namen in Zulu gibt?
(d. h. 182 mal = no setzen und einmal in der Landessprache positiv belegen?)
[Ironie aus]

Es hat über 15 Jahre bei OSM funktioniert, dass die meisten highways keine expliziten Access-Werte haben…

Wer nichts verändern will, wird auch das verlieren, was er bewahren möchte.
(Gustav Heinemann)

Das Argument, dass ein Hobbyprogrammierer nicht für jeden Wert einen sinnvollen default setzten kann erschliesst sich mir nicht. Zunächst mal muss ich auf die Idee kommen, dass ich eine Information in OSM finden kann, wenn ich den Schlüssel xyz auswerte. Dann schaue ich mir an, welche Werte im wiki dokumentiert sind und welche laut Taginfo tatsächlich in dem für mich relevanten Teil der Welt vorkommen. Dann bastel ich mir eine Regel, die etwas damit anfängt, wenn der Schlüssel vorhanden ist, und eine weitere als “sonst vermute dies oder das”. Diese “sonst” Behandlung brauche ich eigentlich immer, egal, ob das Tag fast immer oder fast nie gesetzt ist. Im einfachsten Fall passiert sonst nichts, aber auf keinen Fall darf “irgendwas zufälliges” passieren.
Umgekehrt habe ich oft erlebt, dass Objekte mit mehr als 10 Tags gerne mal widersprüchliche Tags haben. Meine Vermutung ist dann immer, dass der Mapper es einfach nicht schafft, die Bedeutung von vielen Tags zu erfassen bzw. gar nicht auf die Idee kommt, dass irgendwo in der Liste ein abc=no stehen könnte.
Sprich: Die Auswertung von fehlender Information durch Maschinen ist aus meiner Sicht einfacher zu handhaben als die Überforderung des Mappers mit zu vielen Infos.
Schön wäre es allerdings, wenn Defaults maschinenlesbar hinterlegt wären. Ich kenne das praktisch nur für Rechts-/Linksverkehr.

@Wetterauer und @flohoff dann macht doch eine -vollständiges- Beispiel mit -allen- Tags für eine normale Anliegerstrasse (highway=residential), dass ist ja vermutlich der einfachster Fall.

Schönes Beispiel, aber

Frei nach Bömmel aus der Feuerzangenbowle: Da stelle ma uns mal janz dumm :smiley:

Nehmen wir an, heute erfasst jemand eine Straße wie folgt:

highway=residential

Mehr nicht. Was gilt dann als standardmäßig gesetzt? Und wo kann ich das erfahren?
Wenn ich das weiß, kann ich auch den unterschiedlichen Code darstellen.

Ich weiß übrigens z.Z. wirklich nicht was der Standard ist. :frowning:

1 Like

Es sollte nun aber niemand auf die Idee kommen, diverse no-Werte als nicht sinnvolle Details zu sehen und zu löschen.
Ich habe gerade einen Wohnmobil-Stellplatz mit Werten erweitert, unter anderem
drinking_water no
internet_access no
power_supply no
sanitary_dump_station no
tents no
water_supply no
WEIL der Platz wirklich sehr puristisch ausgestattet ist, d.h. weil Austattungen, die man oft oder üblicherweise findet, hier eben NICHT anzutreffen sind.
Das soll ausgedrückt werden. Die Werte für tents und internet hätte ich auch weglassen können, aber für tents gab es einen Hinweis im Hinweisschild, also explizit verboten.

Was ich sagen will: sogenannte default-Werte machen manchmal auch Sinn, wenn man sie explzit angibt.

Ich denke nicht, das es einen weltweiten Standard gibt. In D darf man wohl annehmen, dass die Straße asphaltiert ist und von allen Fahrzeugarten mit max. 50 km/h befahren werden darf und kann (smoothness=good oder besser).
Ich würde alles, was davon abweicht, mappen.
Straßenbeleuchtung ist wohl nie klar, also immer erwähnenswert, wenn man es denn weiss. Für das Vorhandensein von Bürgersteigen gibt es nach meiner Erfahrung auch keine klare Regel, geschweigedenn deren Oberfläche oder Eignung für Radfahrer oder andere Fahrzeuge.

Gibt es denn für Deutschland definierte Standards? Wenn JA, wo.

Zum grössten Teil im StVG (und diversen Normen).

Innerhalb von OSM gelten nationale Gesetze und auch noch untergeordnete Normen???
Wie ist das mit dem O in OSM vereinbar?

Worauf willst Du hinaus? OSM ist open und hat fast überhaupt keine Regeln. Die wenigen Reglen, die es gibt, sind im API hinterlegt, also z.B. max. 2000 Knoten für einen Weg. Alles andere funzt doch eher nach dem Prinzip: Wenn keiner meckert oder ändert, ist es OK oder egal

Genau darauf will ich hinaus. In OSM gelten keine nationalen Gesetze. Und damit kann man auch nicht annehmen, dass irgendeine Regel von außen Gültigkeit in OSM hat.
Wenn es also innerhalb von OSM keine Regelung über die Verwendung von Standards gibt, kann es auch keine anzunehmenden Standartwerte für TAGs geben. Und somit dürften Sätze wie dies ist der Standardwert und braucht nicht kartiert zu werden in OSM nicht geben.

Das Open bedeutet dass OSM eine offene Datenbank (frei für jeden) ist.
Nicht, dass parallel noch andere Gesetze gelten…

Gerade für eine sinnvolle Datenstruktur sind Standardwerte immer sinnvoll und notwendig.
Standardwerte kann man zusammen fassen in

  • zueinander sinnvolle Keys: Ein Highway braucht idR keine Bauwerksangaben.
  • zueinander sinnvolle Values: Je nach dem. V.a. sind diese notwendig, damit man als Datennutzer damit umgehen kann.

Somit ist die Aussage:

aus meiner Sicht falsch. Diese Standardwerte müssen aber entsprechend dokumentiert sein.

Du willst also bridge=no an fast alle Strassen kleben? Und tunnel=no, layer=0, embankment=no, oneway=no and was weiss ich noch alles?
Edit: Scheint zumindest Menschen zu geben, die das für klug halten: https://www.osm.org/way/12172819

^

Können wir das bitte als Negativbeispiel einrahmen?!? :smiley: