> Gesendet: Sonntag, 08. April 2018 um 21:15 Uhr > Von: "Florian Lohoff" <f...@zz.de> > An: "Christian Müller" <cmu...@gmx.de> > Cc: talk-de@openstreetmap.org > Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets > > 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.
"Don't bend the data", ja? Just be patient. Wie willst du auf der Grundlage fehlender Daten argumentieren, dass die Linie nur etwas /repräsentiert/, dass in der Realität gar nicht da ist?? Das ist absurd! Und das ist so auch nicht dokumentiert. Und die verschiedenen Anwendungen, die Standardwerte für irgendwelche Breiten ungefähr annehmen gehören genauso zu OSM wie das doku- mentierte width-Tag. OSM besteht nicht nur aus der DB! Es ist ein verteiltes Ökosystem. > > 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. Niemand sprach von Punkten. 1 Dimension: Länge, 2 Dimensionen: Länge plus Breite, 3 Dimensionen: Länge + Breite + Höhe Verläuft der Straßenkörper annähernd gerade, reichen zwei Werte und eine Linie um nach Belieben den ursprünglichen Körper rekonstruieren zu können, je nachdem wieviele seiner Dimensionen für den Anwendungsfall benötigt werden. > Das ist jetzt nen bischen billig die Nummer. Es ist eben kein beliebiger > extrusion algorithmus. Doch ist es. Simple is beautiful. Komplizierter ist es für das 3D- Mapping eigentlich auch nicht und das funktioniert schließlich bestens, ohne die Lohoff'schen Einwände und Sorgen. Es ist genauso nicht perfekt, enthält abstraktionsbedingt Fehler, aber niemand kann und war darauf aus, jeden Punkt der Realität in OSMs Datenbank abzubilden. > 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. Du liest wahrscheinlich immer nur den Anfang meiner mails. Es IST kein Problem eine Fläche mit relativ konstanter Breite, die als Linie idealisiert wurde mit der zugehörigen Breiteninformation unter Verwendung der Extru- sionsmethode geometrisch zu reproduzieren. > 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. Lächerlich, das ist doch selbst eine Schutzbehauptung! Rechne es doch einfach nach und trete damit an. > talk-de ist vielleicht nicht der richtige Platz die Philosophischen > Aspekte zu diskutieren die dir da jetzt so vorschweben. ? > Es sind keine Momentaufnahmen sondern bezogen auf die Technischen Mittel > des Eintragen möglichst genau zu erfassende Verifizierbare Daten. Ja, die Erde ist eine Scheibe. Amen. Bei uns gab es mal einen Kirschbaum, den konnte man recht lange verifizieren. Heute steht da ein Poller. An anderer Stelle war mal eine Gärtnerei, da ist jetzt ne Tankstelle. Alles Momentaufnahmen, verifizierbar für kürzeste Zeit. Die ganze Karte ist eine Momentaufnahme und in bestimmten Details stets inaktuell. Vielen Dank für deine Links, die ich alle sehr gut kenne. Wie du sehen kannst, können die kaum eindeutig sein, hätten wir doch hier sonst keine Meinungsverschiedenheiten und würden im Gleichklang tönen. Momentaufnahmen sind verifizierbare Daten, für den Moment. > 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. Du verstehst es immer noch nicht. Das was du als Fehler ansiehst, ist in einem anderen Kontext kein Fehler. Selbst die Ackergrenze verschiebt sich von Jahr zu Jahr. Willst du den Bauern jetzt auch noch anhauen, dass der gerade fahren soll, damit du bei deiner Ein- Meterdiskussion recht behältst? Ohne Validierungsregel kann hier keiner behaupten, dass etwas falsch ist, weil der (ich wiederhole mich..) /Bezugsrahmen/ nicht geklärt ist und eben auch nicht überprüft wird. Du hast halt deinen Bezugsrahmen in dem das ein Fehler ist, der nächste hat einen anderen, wo deine Linie einen Fehler darstellt. Es ist müßig darüber zu diskutieren. Wenn du hier so deinen Willen durchdrücken willst, dann darfst du die Leute nicht anbetteln, dass so und so einzuhalten, son- dern musst einen Regelsatz aufstellen, der serverseitig /über- prüft/ bzw. validiert was auf den Server drauf darf und was nicht. > > 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. Du verstehst nicht, worauf eine Vereinheitlichung hinaus laufen würde. Wenn eine Flächengrenze in der Wegmitte verläuft, dann überlappt eben diese Fläche die Wegfläche - wo ist das Problem? Wie der Grenzverlauf bestimmter Flächen gesetzmäßig geregelt ist, hat mit der mathematischen Repräsentation eines geographischen Faktums, das ein anderes enthält, überlappt oder von ihm eingeschlossen ist, rein gar nichts zu tun. > Somit ist eine Grenze etwas ganz anderes als ein Landuse. Die Straße ist > kein Acker - auch nicht die Hälfte bis zur Mitte. Nein, ist es eben nicht. Ein "landuse" tag wird mit einer Fläche assozi- iert, die //notwendigerweise// durch eine Flächengrenze begrenzt wird. Wie diese Flächengrenze kodiert wird, ist ein anderes Thema. Wie bei der Flussmitte für Landesgrenzen wiederholt sich das Problem (fraktalartig eben) auch in Innenstädten, etwa wenn es darum geht, Stadtteilbezirks- grenzen zu erfassen. Auch für diese kann es Sinn machen, die Straßen- mitte und nicht die -kante als Flächengrenze zu verwenden und damit eine Überlappung verschiedenartig definierter Flächen zuzulassen. Es ist richtig (oder wünschenswert), dass falls man die Extrusion der Wegfläche aus der Mittellinie heraus zur Fehlerminimierung bei der Rückübersetzung aus einem abstrakteren Modell verwenden will, für die angeklebten Flächen entscheiden können muss, welche wahr- haft Nachbarn sind (also durch den Umriss nach Extrusion begrenzt sind) und welche das physische Objekt per Definition überlappen. Das verdeutlicht dir aber nur noch einmal, das für bestimmte Flächen (die, die so definiert sind/werden) weiterhin die Mittel- linie als Flächengrenze benutzt werden wird, selbst wenn es einen explizit eingezeichneten Straßenumriss gibt und echte Nachbar- flächen damit vernäht werden. D.h. ähnlich wie die Flussmittellinie nicht durch das Erfassen von waterway=riverbank für das Ankleben aller Flächengrenzen freige- stellt wurde, so wird sich auch die Straßenmittellinie mit einem Paradigma, das dem bei Fließgewässern verwendeten gleicht, nicht vollständig der Flächendefinition entziehen. Wenn ein Gesetzestext die Flussmittellinie als Grenze /definiert/, dann ist es eher unschön, wenn die in OSM nicht wiederverwendet wird und stattdessen Lücken und ungenaue Überlappungen einge- tragen sind. Das gleiche ist dann auch auf Stadtteilgrenzen o.ä. übertragbar. > 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. Es ist auch, wie ich dir schon mehrfach schrieb, nicht verhandelbar, dass die Objekte in der DB reale Objekte vor Ort /abbilden/ und dabei abstraktionsbedingt ein Fehler entsteht. Gerade dann, wenn man sich entscheidet, Objekte mit konstanter Ausdehnung in eine Dimension da- durch zu /vereinfachen/, dass etwas flächen- oder körperhaftes als Linie /idealisiert/ wird. Die Node-Positionen der Straße waren schon immer eine /Idealisierung/ eines geographischen Faktums, dass interpretiert werden muss, ob von Mensch oder Algorithmus um Informationen über die Welt rückzugewinnen. Niemand ist je rausgegangen mit der Maxime ein Ein-Dimensionals Objekt zu vermessen, das ist reiner Blödsinn. Wir haben keine unendlich dünne Mittellinie von Mittellinien von Straßen gesucht, sondern ein mathematisches Modell genutzt, um geographische Fakten, die vor Ort beobachtbar sind und waren /abzubilden/. Als die Straßenbreite auf Luftbildern noch nicht erkennbar war, war es i.d.R. auch völlig Wurst, /wo/ genau die Koordinaten liegen, die das GPS gemessen hatte. Es ist auch der Intuition und keineswegs irgendeiner Vorgabe geschuldet, dass bevorzugt die Mittellinie an- genähert wird. Es wurde schon immer die Straße erfasst /mittels/ Abstraktion, die Straße aber /ist/ keine Abstraktion, sie ist das geographische Faktum! > Sie besagen so dinge wie: > - Hier exakt steht das Schild > - Hier exakt ist die Ecke des Ackers > - Hier exakt ist eine Straßenlaterne Streiche "Hier", ergänze "an dieser Position". Das sind alles Ab- bilder, Messwerte.. Sie besagen nicht Dinge wie - An dieser Position exakt verläuft die Mittellinie einer Straße. sondern - Entlang dieser Positionen verläuft eine Straße. (mit allem drum und dran) Um nochmal auf die Momentaufnahme zurückzukommen. Was denkst du, warum so Tags wie "last_checked" eingeführt wurden, die besagen, wann sich eine Messung vor Ort mit einer weiteren (zu einem anderen Moment) nochmals bestätigen ließ. > Wir raten oder konstruieren nicht bei OSM - Wir erfassen fakten. Und das > so genau es uns unsere aktuellen Technischen Möglichkeiten erlauben. OSM erfasst nicht die Fakten, sondern ausgewählte Aspekte dieser Fakten. Es bildet /Modelle/, die diese Fakten /modellieren/. Ein Modell ist nicht der Fakt. Das Stichwort ist evtl. "Vermessung der Fakten", und das ist auch nicht neu, wenn man in alten Schriften liest. Die Modelle, die Fakten der Realität abbilden sind sehr wohl /konstruiert/. Das ganze Geoid ist /konstruiert/, es ist eine mathematische Approximation, die scheinbar und /bisher/ am besten den Körper /abbildet/, den wir im Kleinen weiter vermessen. In der Vergangenheit wurden andere Geoide aus Messdaten /konstruiert/, die sich später als weniger gut approximierend darstellten. Manche sagen heute dazu, dass sie schlicht falsch waren, aber das ist nicht korrekt, denn für die Gebiete aus denen die Mess- daten stammten, die zur Geoidkonstruktion verwendet wurden, passten diese Modelle nämlich seehr gut. > 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. Das sagte ich bereits: Im width-Tag, in der Klassifikation der Straße und ggf. in der Anzahl der lanes. Je weniger davon explizit getaggt wurde, desto ungenauer das Modell, das heißt aber nicht, dass das Modell ein 1-dimensionales geographisches Faktum der Realität /abbildet/. Außerdem ist die Schlussfolgerung, ein width-Tag sei so oft nicht vor- handen, deswegen würde das modellierte geographischen Faktum keine Breite besitzen, nicht schlüssig. Das ist "missing data", nicht mehr und nicht weniger. > Linienobjekte sind bei OSM Eindimensional und das waren sie immer. Ja exakt, aber nicht Straßen oder beliebige andere Features, die damit repräsentiert werden. > > 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 ist eine Behauptung ohne Beleg und entspricht nicht den Tatsachen. Selektive Wahrnehmung? > > 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. Wenn du die Parallele zu den Flussmitten ziehst und feststellst, dass eben nicht /alle/ Flächen am Ufer enden, dann freut man sich hier ob einer Konfliktlösung evtl. zu früh. Insofern war diese Behauptung evtl. voreilig. Gruß _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
