[Talk-de] Flächen/Wege // Trolling in changesets

["Christian Müller"]

> Gesendet: Sonntag, 08. April 2018 um 10:00 Uhr
> Von: "Florian Lohoff" <f at zz.de>
> An: "Christian Müller" <cmue81 at gmx.de>
> Cc: talk-de at openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Du scheinst aber hier dem Trugschluss aufzusitzen das OSM eine Karte
> ist. Das ist es nicht OSM ist und war nie eine Karte.

Du konntest unlängst selbst schlussfolgern, dass dieser Schein ein
Trugschluss ist, aber wenn man nur die Hälfte liest..


> OSM ist eine Sammlung von Geografischen Fakten. Die mit Mapnik erzeugte
> Karte ist nur ein Beispiel diese Sammlung an Fakten zu visualisieren.

Genau so, wie ein Routing-Graph /nur/ ein weiteres Beispiel ist, diese
Datensammlung zu benutzen.  Weder das eine noch das andere wird idealer-
weise bevorzugt.

Eigentlich ist es großer Mist, dass nur das credo
"Wir mappen nicht für Renderer."
so weit verbreitet ist, denn in gleicher Weise müsste sich
"Wir mappen nicht für Routing-Engines."
dazugesellen.

Und in beiden Statements müsste es lauten "nicht nur für".


> Wenn wir die Straße mit einer korrekten Breite erfassen
> dann gibt es für den Straßenabschnitt 2 Objekte. Die Mittellinie als
> geometrische Mitte der Straße mit allen Attributen wie
> Geschwindigkeitsbeschränkung etc und eine Objekt mit der Ausdehnung -
> Eine Highway Area.

Ja, das ist /jetzt/ so, /und/ es ist immer noch experimentell.  Es hat
sich noch nicht überall durchgesetzt, dass die Erfassung der highway
area sinnvoll ist; da gibt es noch viele Zweifelnde.

Historisch gesehen wurde eine Straße eigentlich nur dort mit Flächen-
umriss (also highway area) benutzt, wo eine konstante Breite des zu
erfassenden Objekts fehlte.


> Korrekt - Die Mitellinie ist die Geometrische Mitte der Straße - Und die
> erfassen wir. Dazu noch attribute der Straße - Mehr nicht.  

Sorry, aber das ist /deine/ Auffassung und vielleicht die ein paar anderer.
Es ist so /nirgends/ dokumentiert und es ist auch nicht intuitiv (zumindest
nicht, so lange der Flächenumriss nicht auch eingetragen ist - das ist noch
lange nicht überall der Fall, auch wenn es in die Richtung geht, auf jeden
Fall ist das ein Paradigmenwechsel).


> wievielten Mail zu sagen das wir bei Straßen ja eine Breite erfassen und
> das es schon okay ist Flächen damit zu verbinden weil man das ja "einfach raus
> rechnen kann". Und das ist halt in meinen Augen an so vielen Stellen 
> falsch das ich manchmal echt Baff bin. 

Es lässt sich rausrechnen mit abstraktionsbedingtem Fehler (Straßenweitungen
o.ä., Abschnitte nicht konstanter Breite über die Länge werden halt begradigt).
Dass es einfach ist habe ich nicht gesagt, denn das liegt im Auge des Be-
trachters, bzw. bei denjenigem, der es umsetzt.

Wir schrieben, dass eine Straße erfasst wird und die hat nunmal naturgemäß
eine /Breite/, ob die nun explizit durch das width-Tag erfasst wird, oder
mit größerem Fehler implizit durch lanes-Tags oder Klassifikationsattribute
spielt weniger eine Rolle.

Wir erfassen nicht die /Mittellinie der Straße/, sondern die Straße als
Linie.  Das ist nunmal ein Unterschied.

-------------------------------------------------------
Das geographische Faktum, das erfasst wird, ist die Straße und /nicht/
deren Mittellinie, wie von dir oben behauptet.  Man hat sich entschieden,
dieses Faktum in der Datenbank als Linienzug zu /repräsentieren/.  Das
Faktum hingegen besitzt eine räumliche Ausdehnung in /Länge/, /Breite/
und /Höhe/, wie die eigentliche Mittellinie der Straße vor Ort im Übrigen
auch (aber die ist eben /nicht/ das modellierte Faktum!).
-------------------------------------------------------

Es ist eine Frage der Datenverwendung, ob der Linienzug und die assozi-
ierten Attribute zur Rekonstruktion der räumlichen Ausdehnung in 1, 2
oder 3 Dimensionen verwendet werden.

Das Routing-Engines nur die Ausdehnung in der Länge betrachten ist kein
Grund zur Annahme, dass das Datenobjekt die Ausdehnung des geographisch-
en Faktums in der Breite vernachlässigt.

Ginge es nur darum, einen Routing-Graphen zu erstellen, könnte man sich
noch viel mehr Details sparen:  Dazu musst du die Straße eigentlich nur
mit Anfang- und Endpunkt und evtl. durch Punkte bei Geschwindigkeits-
wechseln erfassen und die Abschnitte dann mit der Distanz versehen bzw.
gewichten.  Dieser Anwendungsfall benötigt viel weniger geographische
Fakten, als in OSM erfasst werden / sind.


> Ein 1 Dimensionales Objekt kann nie eine reale Breite haben.

Was gleichzeitig bedeutet, dass ein 1-dimensionales Objekt nicht real
sein kann!?  Es ist eben eine Idealisierung, dass der Darstellung und
Speicherung von /Abbildern/ geographischer Fakten dient, die immer
eine räumliche Ausdehnung haben (und oft eine zeitliche noch dazu).

Selbst die Mittellinie der Straße hat im übrigen eine räumliche Aus-
dehnung in drei Dimensionen, aber dieser geographische Fakt wird in
der DB /nicht/ beschrieben (zumindest nicht von DB-Objekten mit
assoziierten highway=* Werten).


> ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei
> egal welcher Genauigkeit einfach topologisch falsch ist und bleibt.

Ist es nicht.  Es ist maximal geometrisch ungenau, genau so ungenau, wie
es eben ungenau ist, einen Weg als Linie und nicht als Fläche zu begreifen.


> > Natürlich kann man das und es ist auch nicht so, dass das noch niemand getan
> > hätte oder die Algorithmen dazu nicht zur Verfügung stünden.  Ich habe auch
> 
> Link? Referenz? 

Du kannst dich da beliebiger Extrusions-Algorithmen bedienen, also Algorithmen,
die durch Parallelverschiebung der Kanten eines geometrischen Objekts ein neues
erzeugen, dass in Relation zu dem alten steht.

Das findet z.B. bei allen 3D-Anwendungen, welche OSM-Daten als Grundlage einbe-
ziehen ebenso Anwendung - nur halt in höherer Dimension.  Dort extrudiert man
die Grundfläche von Gebäuden, um zu einem Körper zu gelangen.  Gleiches gelingt,
um von Weglinien bzw. -zügen, zu (Weg-)Flächen zu gelangen.

Die Wissenschaft bietet mittlerweile dimensions-unabhängige Extrusionsalgorithmen
an.  Man füttere Google mit "dimension-independent extrusion algorithm" falls
einen das näher interessiert.

Ich behaupte nicht, dass sich damit /in jedem Fall/ Flächenumrisse von Wegen er-
setzen oder perfekt rekonstruieren lassen, aber es ist oft gut genug und nie topo-
logisch falsch.


> Also bisher hatte ich immer (>10 Jahre) die Möglichkeit auf Rechnern zu
> Arbeiten die die OSM Daten verarbeiten konnten. Ich habe lange für QA
> Zwecke OSRM Instanzen laufen gehabt die den ganzen Tag routen getestet
> haben etc. Ich habe mal ein auf PostgreSQL/PostGIS basierendes Datenbankend für 
> osmarender gebaut. So abwegig ist das mit den OSM Daten zu arbeiten nicht.

Ok, aber prägt das nicht auch eine bestimmte Sichtweise auf die Daten, bzw.
eine bestimmte Art, sie zu interpretieren?


> Es hat nichts mit der absoluten Genauigkeit der Lage eines Knotens zu
> tun ob man Fehler der Topologie noch hinzufügt. Das ist dann einfach
> nur eine Summe von Fehlern.

Topologie beschäftigt sich mit den Lagebeziehungen!  Grob gesprochen, ob
etwas links oder rechts von etwas anderem liegt, nicht /wie weit/.  Ob
du ein Feld rechts neben einer Straße, das an die Straße grenzt nun mit
obskurer Lücke zeichnest oder nicht, ändert die Lagebeziehung nicht.

Das Feld liegt auch dann noch /an/ der Straße, wenn ein Straßengraben
dazwischen liegt, weil der ja nicht für sich allein steht, sondern
funktional entweder zur Straße oder zum Feld zugehörig und damit je
nach Sichtweise vernachlässigbar ist (Frage des Anwendungsfalls).

Wenn wir die Straße nicht nur mit einem width-Tag assoziieren, sondern
auch mit einem Attribut, das die Gesamtbreite der Straßenanlage (also
inkl. Entwässerungsgräben) wiedergibt, dann lässt sich auch der geo-
metrische Fehler minimieren, der durch die Abstraktion des geograph-
ischen Faktums /Straße/ als Linie entstanden ist.


> > Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten,
> > heute scheinbar nicht mehr so wichtig.
> 
> Das hat die Datenbank nie kleiner gemacht. Wenn du verklebst haben ALLE
> Wege die zusätzlichen Knoten. Tausche Anzahl Knoten gegen Anzahl Knoten
> je Weg. Vorher hatte ich 10 Knoten in 3 Wegen. Jetzt habe ich 30 Knoten,
> 10 je Weg.

Oh, das ist eine Milchmädchenrechnung:  Wenn verklebt wird, dann wird x
mal auf /die identen/ Knoten verwiesen, der Knoten (die Koordinate) aber
nur exakt einmal gespeichert.  Geometrisch parallel geführte Linien
erhöhen das Datenaufkommen (und den node-count in der DB) hingegen
drastisch.

Außerdem sind Wiederholungen bei den Verweislisten gut komprimierbar.
Geometrisch ungefähr parallel geführte Linien, die alle ihren eigenen
Knotensatz haben, sind für einen Kompressor schwer bis gar nicht zu
packen, denn es gibt dann keine gleichen Folgen von Knotenverweis-
listen mehr.

Ein anderer Aspekt ist, dass das Verkleben auf mehrere Arten geschehen
kann.  Wenn etwa Wege in MP wiederverwendet werden, anstatt sie über-
einander zu legen, entfallen selbst die Wiederholungen der /Verweis/-
listen.


> > Ein geometrischer Fehler von auch 3 - 5 Metern ist/war für viele Anwend-
> > ungsfälle völlig unerheblich, ob du das nun wahrhaben willst oder nicht. Du
> 
> Es geht nicht um die Anwendung - Das versuche ich dir doch die ganze
> Zeit mal zu sagen. Es geht darum das OSM eine Faktensammlung ist und da
> geht man nicht hin und fügt absichtlich Fehler hinzu.

Das ist wieder Unterstellung oder Unverständnis, weiß nicht.
Irgendwie scheinst du zu glauben, dass deine Sicht der Dinge die einzig
richtige ist.  De facto ist OSM keine Faktensammlung, sondern die Suche
danach.  Und da kann man nicht einfach kommen und sagen, dass Leute die
diese Fakten anders abbilden, absichtlich Fehler hinzufügen würden.

Es ist auch keine Faktensammlung die Anspruch auf Vollständigkeit er-
hebt.  Weiterhin ist das Datenmodell nicht widerspruchsfrei.  Wieder
andere sehen OSM als Projekt oder Kommunikationsplatform  ("Wikipedia
für Geodaten").


> Als Faktensammlung, gerade so technischer Natur wie OSM versuche ich
> doch von vorneherein den Fehler möglichst klein zu halten. Wenn ich das
> nicht mache kann ich auch gleich sagen - pah - Dezimalstellen an der
> Latitude - die schneide ich einfach weg. Bielefeld ist auf der Karte
> jetzt nen Vorort von London. 

Ja, klar, auf den Versuch kommt es an, aber fehlerfrei wird diese
selektive Sammlung von Fakten nie sein.  Das ist m.E. eine Utopie.

Es setzte insbesondere voraus, dass sich gar nichts ändern darf.
Denn die Daten sind ja immer eine Momentaufnahme und wenn sich
sowohl Datengrundlage als auch die Paradigmen des Datenmodells
wandeln, dann ist es einfach etwas als fehlerhaft darzustellen,
das vorher als fehlerfrei galt.


> Entweder man versucht Fehler zu minimieren oder man kann doch gleich
> aufgeben. Und dieses Verkleben ist halt ein Fehler den die Protagonisten 
> der Verklebung bewusst und absichtlich hinzufügen.

Ich denke, dass es eine Melange aus Unwissenheit, Bequemlichkeit und
tatsächlich einer anderen Art ist, die Realität zu modellieren bzw.
zu verstehen.

Der Fehler lässt sich nur minimieren, wenn du eine Gleichung hast,
mit der du gegenrechnen kannst.  Es gibt für die Flächengeschichte
in OSM m.W. derzeit keinen Validator der Flächen auf ihre korrekte
Lage hin prüft.  Fehler lassen sich ja nur mit Bezugsrahmen fest-
stellen und solange nicht geklärt ist, welcher Bezugsrahmen gültig
sein soll, solange lässt sich auch nicht sagen, dass die Verkleber
falsch liegen.  Die haben einfach nur einen anderen Bezugsrahmen,
der zu dem von dir verwendeten inkompatibel ist.

Irgendwer hatte mal gemeint, dass man Flächen auch nur durch Punkte
und Aussagen darüber, zu welchen Flächen diese Punkte gehören, modellieren
kann  (also nicht nur flächengrenzbezogene Punkte, sondern auch innen
liegende). Man rastert die Fläche also unregelmäßig mit fortschreitend
mehr Samples, die Genauigkeit steigt mit der Anzahl der erfassten Punkte.

Das wird in OSM gar nicht verwendet, aber es ist denkbar, dass auch
das mit der Zeit zu Ergebnissen führt, die mit den derzeit in OSM
verwendeten Methoden konkurrieren können.


> Diese Ungenauigkeit von Boundarys liegt darin das dieses als einziges
> Objekt bei OSM geduldet sind obwohl sie vor Ort nicht verifizierbar
> sind. Siehe auch Mapping Good Practices.

In diese Kategorie fallen noch eine ganze Menge mehr Objekte, die vor
Ort nicht oder nicht mehr verifizierbar sind.  Die Landesgrenzen sind
bsp.-weise ja nun auch nicht gerade über den Acker gemalt..


> Mit dem offiziellen Zugriff auf die Kataster/ALKIS in NRW konnten wir die dann präzisieren.

Ja, wäre wünschenswert, wenn diese Art der Koop überall funktionieren würde.


> Boundarys sind also ein denkbar schlechtes argument für ungenaue Daten
> bei OSM - Weil sie eine große Ausnahme Bilden.

Nein, das ist Unsinn und war schon immer Unsinn.  Flächen und Flächen-
grenzen gehören untrennbar zusammen.  Die Grenze der Republik macht
ohne die Fläche keinen Sinn und umgekehrt.  Die sprachliche Trennung
ist suggestiv aber künstlich.  Geographische Grenzen (politische und
auch naturräumliche) werden nicht um der Grenzen willen gebildet,
sondern um dem Begrenzten/Eingefriedeten/Innliegenden willen.

Das eine existiert nicht ohne das andere, auch wenn es theoretisch
getrennt betrachtbar ist.

Und im Prinzip sind Multipolygone und Boundaries derselbe Wein in
anderen Schläuchen.  Wenn man wöllte und die Auswertung entsprechend
anpasst, könnte man das vereinheitlichen.  (Ein Flächentyp in der API
würde evtl. genau das tun.)


> Verkleben ist topologisch IMMER falsch. Der Acker endet nicht und wird auch
> nie in der Mitte der Straße enden.

Das ist nicht das was die Daten sag(t)en.  Der Acker endet an der Straße,
so wird ein Schuh draus, dazu muss nichtmal eine Breite getaggt sein.

Genauer ist und war die Aussage nie, denn die Linie in der DB hat eben
nicht /genau/ die Mittellinie von Straßen abgebildet, sondern einfach
nur die Straße.  Die genauere Erörterung ist etwas das mit der Zeit
und zunehmender Datendichte dazu gekommen ist.

Das geographische Faktum einer Straße kommt nunmal immer mit räumlicher
Ausdehnung einher, egal ob du das als Linie, Fläche, Punkt oder Text
abbildest.


> > Der Vergleich ist unzutreffend.
> 
> Nein ist er nicht. Du rundest die Flächenkante auf die nächstgelegene
> Straße - genau das ist verkleben.

Nein, verkleben ist einfach nur die topologische Verbindung von zwei
Objekten, die nebeneinander lieben.  Sie haben i.d.R. vor Ort eine
gemeinsame Flächengrenze (sind also auch vor Ort verklebt).  Dass
das in den Daten unrichtig wirkt(e) liegt an der Wahl der Repräsen-
tation der geographischen Fakten und an den damit einhergehenden,
 unterschiedlichen Rückübersetzungsmöglichkeiten:

a) Die Linie in der DB wird (nur) als Mittellinie der Straße rück-
übersetzt

b) Die Linie wird als Repräsentat der Straße mit Straßenfläche und
ggf. weiteren (in den Daten teilweise wegabstrahierten) Features
aufgefasst.

Das wird sich in Zukunft mit der Verbreitung der Flächenumrisse auf-
lösen, aber in anderen Dingen auf einer höheren Zoomstufe wieder-
kehren.  Das Phänomen wiederholt sich fraktalartig und es gibt
eben mehr als einen Lösungsansatz.


Gruß