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

[Florian Lohoff]

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 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/16d1f6ea/attachment.sig>