You are not logged in.

#1 2022-05-17 17:09:02

Wetterauer
Member
From: Wetterau
Registered: 2021-07-10
Posts: 381

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 sad


Änderungen werden von mir i.d.R. nicht gelöscht, sondern durchgestrichen

Offline

#2 2022-05-17 17:20:54

Hartmut Holzgraefe
Member
Registered: 2015-04-13
Posts: 257

Re: Standardwerte

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" ...

Offline

#3 2022-05-17 17:28:54

flohoff
Member
Registered: 2018-08-09
Posts: 491
Website

Re: Standardwerte

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=<nummer> - 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

Offline

#4 2022-05-17 17:31:30

tux67
Member
From: Wegberg
Registered: 2014-08-19
Posts: 502

Re: Standardwerte

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

Offline

#5 2022-05-17 18:03:20

GerdP
Member
Registered: 2015-12-18
Posts: 1,816

Re: Standardwerte

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.

Offline

#6 2022-05-17 18:28:30

pyram
Member
Registered: 2012-06-16
Posts: 1,449

Re: Standardwerte

Wetterauer wrote:

...Aus meiner Sicht kann es keine Standardwerte geben...

[Ironie ein]
  Also an jeder Dorfstraße
  name:[https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes]=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...

Offline

#7 2022-05-17 18:45:05

Wetterauer
Member
From: Wetterau
Registered: 2021-07-10
Posts: 381

Re: Standardwerte

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


Änderungen werden von mir i.d.R. nicht gelöscht, sondern durchgestrichen

Offline

#8 2022-05-17 19:31:27

GerdP
Member
Registered: 2015-12-18
Posts: 1,816

Re: Standardwerte

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.

Offline

#9 2022-05-17 20:01:46

SimonPoole
Member
Registered: 2010-03-14
Posts: 2,174

Re: Standardwerte

@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.

Offline

#10 2022-05-18 08:28:23

Wetterauer
Member
From: Wetterau
Registered: 2021-07-10
Posts: 381

Re: Standardwerte

Schönes Beispiel, aber

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

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. sad


Änderungen werden von mir i.d.R. nicht gelöscht, sondern durchgestrichen

Offline

#11 2022-05-18 08:51:36

pebogufi
Member
Registered: 2010-04-11
Posts: 323

Re: Standardwerte

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.

Offline

#12 2022-05-18 09:04:07

GerdP
Member
Registered: 2015-12-18
Posts: 1,816

Re: Standardwerte

Wetterauer wrote:

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

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.

Offline

#13 2022-05-18 10:20:26

Wetterauer
Member
From: Wetterau
Registered: 2021-07-10
Posts: 381

Re: Standardwerte

GerdP wrote:

Ich denke nicht, das es einen weltweiten Standard gibt.

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


Änderungen werden von mir i.d.R. nicht gelöscht, sondern durchgestrichen

Offline

#14 2022-05-18 10:34:08

SimonPoole
Member
Registered: 2010-03-14
Posts: 2,174

Re: Standardwerte

Wetterauer wrote:
GerdP wrote:

Ich denke nicht, das es einen weltweiten Standard gibt.

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

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

Last edited by SimonPoole (2022-05-18 10:34:39)

Offline

#15 2022-05-18 11:11:20

Wetterauer
Member
From: Wetterau
Registered: 2021-07-10
Posts: 381

Re: Standardwerte

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


Änderungen werden von mir i.d.R. nicht gelöscht, sondern durchgestrichen

Offline

#16 2022-05-18 11:41:07

GerdP
Member
Registered: 2015-12-18
Posts: 1,816

Re: Standardwerte

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

Offline

#17 2022-05-18 12:11:22

Wetterauer
Member
From: Wetterau
Registered: 2021-07-10
Posts: 381

Re: Standardwerte

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.


Änderungen werden von mir i.d.R. nicht gelöscht, sondern durchgestrichen

Offline

#18 2022-05-18 12:53:24

SafetyIng
Member
Registered: 2021-01-22
Posts: 396

Re: Standardwerte

Wetterauer wrote:

Genau darauf will ich hinaus. In OSM gelten keine nationalen Gesetze.

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:

Wetterauer wrote:

Und somit dürften Sätze wie dies ist der Standardwert und braucht nicht kartiert zu werden in OSM nicht geben.

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

Offline

#19 2022-05-18 13:05:11

GerdP
Member
Registered: 2015-12-18
Posts: 1,816

Re: Standardwerte

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

Last edited by GerdP (2022-05-18 13:22:24)

Offline

#20 2022-05-18 13:31:27

SafetyIng
Member
Registered: 2021-01-22
Posts: 396

Re: Standardwerte

GerdP wrote:

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?!? big_smile

Offline

#21 2022-05-18 13:33:43

GerdP
Member
Registered: 2015-12-18
Posts: 1,816

Re: Standardwerte

Scheint wohl eher ein Fehler in "Go Map!" zu sein. Der Mapper war sich wohl eher nicht bewusst, was da hochgeladen wurde.

Offline

#22 2022-05-18 14:08:07

Wetterauer
Member
From: Wetterau
Registered: 2021-07-10
Posts: 381

Re: Standardwerte

SafetyIng wrote:

Gerade für eine sinnvolle Datenstruktur sind Standardwerte immer sinnvoll und notwendig.

Stimmt. In der OSM-Datenbank gibt es aber keine Strukturen. Es gibt nur einen "Anker" an den jeder beliebige Daten kleben kann. Innerhald der Datenbank gibt keine automatische Validierung oder sonstige Checks.

SafetyIng wrote:

Diese Standardwerte müssen aber entsprechend dokumentiert sein.

Wo werden diese Werte heute dokumentiert, und wer legt fest, was "Standardwerte" sind?

GerdP wrote:

Du willst also bridge=no an fast alle Strassen kleben?

Warum nicht? Es ist dann Aufgabe der benutzten Software diese "Standardtags" nur dann anzuzeigen, wenn sie nicht Standard sind, oder der Nutzer expliziet wünscht auch diese Daten zu sehen.

Aber mal ein anderes Beispiel als solche Totschläger wie Brücken an Straßen....

Jeder weiß, dass an Bahnübergängen Andreaskreuze stehen. Also wird das Andreaskreuz als Standard definiert. Nun gibt es auch Bahnübergänge an denen es  tatsächlich keine Andreaskreuze gibt. Vergißt nun der Mapper an diesen BÜs das expliziet anzugeben, sind die Daten invalide und keiner merkt es.

Last edited by Wetterauer (2022-05-18 14:11:09)


Änderungen werden von mir i.d.R. nicht gelöscht, sondern durchgestrichen

Offline

#23 2022-05-18 14:34:51

GerdP
Member
Registered: 2015-12-18
Posts: 1,816

Re: Standardwerte

Die Daten sind ja immer mit einer gewissen Wahrscheinlichkeit falsch. Egal, ob durch fehlerhafte Eingabe, nicht vorhandene Eingabe, nicht aktualisierte Daten oder was auch immer. Wenn man den Mapper zwingt oder auch nur bittet, Dinge anzugeben, auf die er nicht geachtet hat, dann wird er entweder raten oder gar nichts mappen, oder? Nur ganz fleissige schauen noch mal nach.

Offline

#24 2022-05-18 14:44:10

Wetterauer
Member
From: Wetterau
Registered: 2021-07-10
Posts: 381

Re: Standardwerte

GerdP wrote:

Wenn man den Mapper zwingt oder auch nur bittet, Dinge anzugeben, auf die er nicht geachtet hat, dann wird er entweder raten oder gar nichts mappen, oder? Nur ganz fleissige schauen noch mal nach.

sad Da ist leider einiges dran  sad


Änderungen werden von mir i.d.R. nicht gelöscht, sondern durchgestrichen

Offline

#25 2022-05-18 14:45:27

GerdP
Member
Registered: 2015-12-18
Posts: 1,816

Re: Standardwerte

SafetyIng wrote:

Diese Standardwerte müssen aber entsprechend dokumentiert sein.

Ich finde nicht, dass das so sein muss. Wenn die große Mehrzahl der Objekte in einer Region eine bestimmte Eigenschaft haben, dann IST das der Standard für diese Region. Wenn sich irgendwann rausstellt, dass diese Region die totale Ausnahme gegenüber den umliegenden (oder den meisten) Regionen ist, dann kann man eine Aktion starten, die explizite Tags vergibt.
OSM macht es schon immer den Mappern leicht, nicht den Datenauswertern. Das ist aus meiner Sicht auch eine gute Idee.

Offline

Board footer

Powered by FluxBB