Hola, On Sat, Apr 07, 2018 at 11:51:2O8PM +0200, "Christian Müller" wrote: > > Nein - Wir behaupten das ein Knoten an der Absoluten Position 51.434 > > 8.123 ist - Und nicht - An dieser Stelle -8m/2 rechtwinkelig zu einem > > der Wegen die diesen Knoten enthält. Das machen wir NIRGENDS bei OSM. > > > > OSM ist eine Sammlung von Geografischen Fakten - Und das ist dann eben > > kein Faktum sondern evtl. eine Konstruktionshilfe. > > Das ist nett gedacht, aber diese Argumentation funktioniert hinten und > vorne nicht, weil die Mittellinie /nicht als Faktum/, sondern selbst > als Konstruktionshilfe eingetragen wird.
Nein - die Mittellinie ist die Orientierung für die Erfassung eines Graphen zwecks Routing. Zusätzlich die Angabe für den Renderer wo in eine möglicherweise auszugebenden Karte die Mitte der zu Rendernden Linie ist. > Wir erfassen ja mit der Mittellinie eben /nicht/ die Mittellinie sondern > ein geographisches Objekt mit einer Breite. Das man das auch als Linie > in einem Routing-Graphen /verwenden/ kann, ist ein anderer Aspekt, aber > sowohl das Datenmodell, als auch die width-Tags sprechen eine klare, > andere Sprache: Das Faktum ist die Wegfläche, ihre Kodierung die /ange- > näherte/ Mittellinie. Das genau steht wo? Ein "width=" ist eine "useful combination" auf einem Weg und mitnichten verpflichtend oder auch nur häufig angewendet. Und ein Objekt mit nur 1ner Dimension kann schlecht eine Breite haben. Das tag width= findet sich 1.5Mio mal in der OSM Datenbank. Stand Ende 2017 hatten wir 430Mio Ways. D.h. auf gerade mal 0.25% der Wegen ist eine Breitenangabe. Da halte ich die Aussage "wir erfasssen ... Objekt mit einer Breite" für geradezu abenteuerlich. Die Zahlen sagen das wir das genau nicht machen. > Das weicht eben, wie gesagt, erst neuzeitlich auf, weil die Außenlinie > der Fläche zusätzlich nochmal separat erfasst wird und die Bedeutung > des linearen Objekts auch als Fläche /deshalb/ in den Hintergrund > rückt. Als reines Graphenobjekt wurde diese Mittellinie nie be- > schrieben, sondern immer als die Repräsentation einer Fläche mit > (relativ) konstanter Breite, Verwendung, Zustand und Klassifikation. Aeh - Diese Erkenntnis entnimmst du genau welcher Tatsache? Ich kenne OSM eigentlich genau anders herum. Wir haben nie Breiten erfasst sondern immer nur Mittellinien. Ausschliesslich der Renderer hat "angenommene Breiten" nach Typenklassen und Zoomlevel dazugeschummelt. Explizit erfasst haben wir Breiten nie und die Renderer haben das auch nie ausgewertet. > Und nochmal: Es ist nicht "falsch", wenn eine Grenzlinie einen Offset > besitzt, sondern bestenfalls "ungenau". Andernfalls stellst du das > gesamte Projekt in Frage. Es gibt unzählige Koordinaten in OSM, die > ab irgend einer Kommastelle falsch sind. Jede Messung kennt ihren > Messfehler. Selbst Galileo wird daran nichts ändern, aber viel- > leicht verschieben sich diese Diskussionen sinnfreierweise dann > tatsächlich in den qcm-Bereich, wer weiß.. Der Messfehler von Galileo hat absolut gar nichts mit dem Runden der Position der Ecke eines Ackers auf die nächste Straße zu tun. Der wird noch oben drauf gerechnet auf den absoluten Lagefehler. Diesen Fehler den du Propagierst ist ein Vielfaches (30-50 Fach) der Ortophoto Auflösung die uns in D zur Verfügung steht und auch ein vielfaches der aktuellen GNSS möglichkeiten. Dazu kommt das der Fehler sich ja summiert. D.h. ich runde die Ecke des Ackers auf die Mitte einer Straße deren absolute Lage ja schon den Messfehlern der GNSS oder Ortophotos unterliegt. Du willst VORSÄTZLICH einen Fehler hinzufügen und hast mehrfach behauptet den könne "man" ja herausrechnen - Eine Anwendung oder Algorithmus der dieses schafft bist du schuldig geblieben. Ich habe mehrfach das Gegenteil behauptet und dafür auch klare Grundlagen genannt - Ich sehe einfach nicht den Vorteil für eine Minderheit (Nachweis siehe vorangegangene Mail) die kein "Nichts" in der Karte sehen will, allen Flächen absichtlich Fehler Geographischer und Topologischer Natur hinzuzufügen und es dazu für Neumapper nahezu unmöglich zu machen korrekte Daten zu erfassen. Man kann das eben genau nicht raus rechnen oder "Mal eben Algorithmisch Lösen" - Diesen Beweis sind bisher alle die das behauptet haben schuldig geblieben. Wenn ich alle Beträge eines Kassensystems auf volle € runde kann ich hinterher nicht mehr die Cent Beträge ausgeben. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
signature.asc
Description: PGP signature
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de