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

Florian Lohoff f at zz.de
So Apr 8 19:15:40 UTC 2018


Hola

On Sun, Apr 08, 2018 at 07:37:59PM +0200, "Christian Müller" wrote:
> 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.

Das liegt daran das das einer der ganz ursprünglichen Maximen
von OSM ist und war:

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer

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

Auch das ist eine maxime der OSM 

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer

	"They are continually improving, don't bend the data to make it
	look prettier, just be patient. "

Und verkleben ist "bend the data" - Ganz einfach.

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

Diese Konstante breite gibt es nicht in OSM - Die fügt Mapnik,
Osmarender, OsmAND, Mapbox  hinzu - Und zwar jeder so wie er will,
meint und je nach Zoomstufe und wie überrepräsentiert er gerne
Autobahnen möchte. OSM hat NIRGENDS eine Vorgabe wie breit ein
highway=unclassified ist.

Ich weiss nicht wie du drauf kommst das in OSM Linien eine Breite haben.

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

https://wiki.openstreetmap.org/wiki/Good_practice#Keep_straight_ways_straight

	"follow the central separation line between lanes in opposite directions
	and add the relevant number of lanes in each forward/backward direction
	for each section where the number of lanes changes"

Es ist alles seit >10 Jahren Dokumentiert das wir der zentralen
Mittellinie der Straße folgen. Das ist nicht MEINE Meinung das ist
Dokumentierte OSM Good Practice -  Kannst du zur Kenntnis nehmen
kannst es aber auch lassen und hier weiter trollen.

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

Auch die Lanes sind keine Breiteninformation - oder steht irgendwo das
eine lane 2,50m Breit ist? Nein - Explizit nicht weil soetwas noch viel
falscher wäre. Das einzige was eine valide Breite wäre wäre ein "width"
tag das aber vernachlässigbare verbreitung findet und auch von
keinem Datenkonsumenten ausgewertet wird.

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

Nein - Man kann keine Tangente an einen Punkt konstruieren.

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

Im Datenobjekt gibt es keine Breite - Wo siehst du die ? Mapnik
schummelt die da dran und das haben dir jetzt schon 3 Leute erklärt
und du weigerst dich dieses zur Kenntnis zu nehmen. Ich frage mich
langsam warum.

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

Du rundest eine absolute Position auf die nächste Straße - Damit ist
die absolute Position kaputt und zusätzlich topologisch falsch.

> > > 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 ist jetzt nen bischen billig die Nummer. Es ist eben kein beliebiger
extrusion algorithmus. Und es geht nicht einfach die Kante zu
verschieben - Das GIS Systeme das können weiss ich - bin genug mit QGis
unterwegs. Die muss ggfs in mehr als einer Dimension verschoben werden
und das in abhängigkeit des taggings und der Geometrie aller beteiligter
Ursprungsobjekte. 

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

Nein - Es prägt was mit den Daten möglich ist Mathematisch und was eben
nicht - Und wenn dann Behauptungen in den Raum gestellt werden so wie
von dir das das  ja "kein problem" sei oder "mathematisch nicht
aufwendig" oder "problemlos" oder "allgemeine praxis" dann weiss ich
daran schon das derjenige es nie selber probiert hat.

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

Ich bin echt müde dir jetzt aus einem OSM XML das auszurechnen das es
günstiger ist weil dann kommt die nächste Schutzbehauptung und die
nächste - Glauben ist halt das Gegenteil von Wissen. Vergleich dazu
Gunkl und die Mondlandung.

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

https://de.wikipedia.org/wiki/OpenStreetMap

	OpenStreetMap (OSM) ist ein freies Projekt, das frei nutzbare Geodaten
	sammelt, strukturiert und für die Nutzung durch jedermann in einer
	Datenbank vorhält (Open Data). Diese Daten stehen unter einer freien
	Lizenz, der Open Database License. Kern des Projekts ist also eine offen
	zugängliche Datenbank aller beigetragenen Geoinformationen.[2] 

talk-de ist vielleicht nicht der richtige Platz die Philosophischen
Aspekte zu diskutieren die dir da jetzt so vorschweben.

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

Es sind keine Momentaufnahmen sondern bezogen auf die Technischen Mittel
des Eintragen möglichst genau zu erfassende Verifizierbare Daten.

Siehe hierzu auch:

http://wiki.openstreetmap.org/wiki/Good_practice 

Stichwort Nachvollziehbarkeit und Map whats on the ground.

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

Völlig irrelevant - Es geht nicht darum eine Fläche zu validieren 
sondern es źu unterlassen absichtlich und aus purer Bequemlichkeit oder
für den Renderer einen Fehler hinzuzufügen. 

Dieses ist explizit in den Good Practices von OSM erwähnt

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer

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

Nein - Grenzen sind explizit so definiert das die in der Mitte eines
Weges verlaufen können. Das steht typischerweise im entsprechenden
Gesetz das die Mitte eine Flusses die Grenze darstellt. Bzw noch
schlimmer. Die Mitte des Flusses mit dem Stand von 1943.

Das hat mit der aktuellen Lage des Flusses typischerweise nichts mehr zu
tun so das heute das verbinden von Flussmitte und Grenze auch falsch
ist.

Somit ist eine Grenze etwas ganz anderes als ein Landuse. Die Straße ist
kein Acker - auch nicht die Hälfte bis zur Mitte.

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

Doch  - Genau das sagen die Daten. Ein Node hat eine absolute Position
und eine Fläche hat den von den Nodes beschriebe absolute Lage und
Größe. Wenn ich einen Node der die Mitte der Straße markiert (Sieht hier
erneut Good Practice) dann beschreibt die Fläche eben eine Fläche die
bis zur Mitte der Straße geht denn das sagt genau OSM aus und das war
auch immer schon so.

Wie ich dir schon mind. 3 mal schrieb sind Node Positionen kein
verhandelbares gut bei OSM.
Das sind auch keine Konstruktionshilfen oder nett gemeinte Ratschläge.
Das sind absolute vom Mapper vorgegeben Positionen - Die verändert kein
Algorithmus oder Renderer. 

Sie besagen so dinge wie:
- Hier exakt steht das Schild
- Hier exakt ist die Ecke des Ackers
- Hier exakt ist eine Straßenlaterne

Und nicht:

	"Hier ist in etwa die Ecke des Ackers aber zieh mal so eine
	breite der Straße ab wie du meinst - aber natürlich nur die hälfte und
	wenn das zufällig noch an einer Kreuzung ist dann musst du das in der
	2ten Dimension auch noch machen - wenn nicht dann mach nur so einen Keil
	da rein wie 2 kleine Rundungen mit dem Biegeradius in Abhängigkeit der
	Straßenbreite die wir aus der Mondphase raten - Wenn auf der Kreuzung
	dann noch eine Ampel ist dann verdoppel den Biegeradius. Wenn aber da
	ein surface Sand drauf ist dann ignorier alles was ich gesagt habe -
	Wenn die Fläche an beiden Straßen der Kreuzung ist - und dann müssen die
	Abstände unterschiedlich sein wenn da lanes drauf sind und mache es
	bitte noch Bunt und in Einhornglitzer."

Wir raten oder konstruieren nicht bei OSM - Wir erfassen fakten. Und das
so genau es uns unsere aktuellen Technischen Möglichkeiten erlauben.

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

In der Realität hat die Straße eine Breite - In welchem Faktum steckt
diese Breite wenn du eine Linie bei OSM einträgst die dann bei Mapnik,
OSMAnd etc ausgewertet wird.

> > 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:

Linienobjekte sind bei OSM Eindimensional und das waren sie immer.
Deshalb wird in allen Wissenschaftlichen Publikationen zu OSM immer
von einem Mixed Model gesprochen und das ist genau das was OSM 
von klassischen GIS Anwendungen unterscheidet.

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

Als die Mitte der Straße - Richtig. Siehe auch Good Practice.

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

War und ist es nie gewesen.

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

Genau - Deshalb gibt es überhaupt die Ansätze Straßen als Flächen zu
erfassen.

Flo
-- 
Florian Lohoff                                                 f at zz.de
             UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20180408/5bfa7b1f/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de