Hola, On Mon, Oct 22, 2018 at 01:57:03PM +0200, "Christian Müller" wrote: > Mit Fehler behaftete bzw. ungenaue Fakten sind nunmal auch Fakten, > da kannst du dich noch so sehr bemühen, deine Definition derer als > die alleinige Wahrheit anzupreisen ;-). Es gilt: > "Wer misst, misst Mist." > und diese Ingenieursweisheit verschwindet auch im cm-Bereich nicht.
Aber dinge eintragen von denen ich nicht einmal gesichert sagen kann ob sie wirklich existieren ist halt unwissenschaftlich. Das hat mit messen nichts zu tun sondern mit Raten und das sind dann die Paper die irgendwann zurückgezogen werden. > Du hast recht, das schlechte Luftbilder sehr viel Raum für Fehl- > interpretationen liefern, aber das war in OSM noch nie Kriterium > dafür, gar nichts einzutragen. Die Arbeitsweise ist eine, die Doch - Das ist ein Kriterium. Das steht in den Best Mapping Practices. "We map whats on the ground" - Nicht mehr oder weniger. Etwas reinraten und als Entschuldigung schlechte Luftbilder angeben ist halt quatsch. Wie es Linus Torvalds mal sinngemäß gesagt hat: Ich kann pi in einer Sekunde bis zur 1000000sten Stelle berechnen solange das nicht richtig sein muss. Wenn schlechte Luftbilder als Entschuldigung für kaputte Daten herhalten dann male ich heute einfach noch so 2-3 Mio Gebäude bei OSM rein!?? Ernsthaft? > inkrementell die Daten überarbeitet, je nach Kenntnisstand. Das > wird auch dann so sein, wenn die hoch aufgelösten Luftbilder dem > Projekt ggf. nicht mehr zur Verfügung stehen. Die Abweichung der > Geometrien zur Realität würde dann wieder größer, aber etwas, > das ungefähr die Realität wiedergibt, ist eben besser, als hoch- > präzise, aber inaktuelle Daten: Du kannst dann ja alle Gebäude von meinen 2-3 Mio die ich reinmale Löschen die wirklich nicht existieren. Aber schön manuell kontrollieren und jedes das du löscht frage ich nach wie du drauf kommst. > Das kannst du auch überall dort sehen, wo gebaut wird. I.d.R. > erfolgt die Anpassung der Daten an eine präzisere Fassung erst, > wenn die Objekte später auf Luftbildern zu sehen und dann ab- > zeichenbar sind - die Erfassung findet aber oft weit vorher > statt und zu diesem Zeitpunkt ist es für OSM und viele seiner > Anwendungen oft egal, ob z.B. die Mittellinie einer neuen > Straße exakt an der geographisch korrekten Position liegt. Ja - Aber da sieht man eine Baugrube - Ein Erdgeschoss - Das kann ich einzeichnen - Da weiss ich das was da ist. Die Geometrie ist vielleicht ein bisschen zu groß oder zu klein. Aber die Ackerfläche bis an die Straße zu ziehen obwohl im Luftbild erkennbar noch was dazwischen ist ist halt das faken von Daten. Und wenn deine Luftbilder so schlecht sind das du nichts siehst solltest du besser nichts davon einzeichnen. > Die Diskussion um das Verkleben des Landuses hatten wir schon > und es ist sinnlos, die immer gleichen Argumente immer wieder > vorzutragen. Das Hauptproblem ist, dass "falsch" und "rich- > tig" nur in einem Kontext benutzbar sind, in dem definitorisch > zunächst einmal genau geklärt ist, was wie im Datenmodell abge- > bildet wird. Dieses Modell als Grundlage von OSM war und ist > aber nicht (komplett) interpretationsfrei. Ein Großteil der > Diskussionen und Konsensfindungsbemühungen beschäftigt(e) sich > ja gerade damit, dieses Modell zu entwickeln. Das hat mit dem Modell nichts zu tun. Nodesharing zwischen Flächen und Wegen führt zu Fehlern - Faktischen, Semantischen - You name it. Um das mal an einem Beispiel zu machen: https://silicon-verl.de/home/flo/tmp/nodesharing.jpg Hier mal eine beliebige Kreuzung auf dem Lande. Es gibt die Nodes 1,2,3,4 und die Ackerflächen A/B/C Nach dem "Verklebeprinzip" wird nur der Node 1 benutzt. Denn die Straßen treffen sich dort und die 3 Angrenzenden Ackerflächen benutzen als Ecknode jeweils Node 1. Fehler die mir sofort ins Auge springen. - Die Ackerflächen teilen sich einen Node und Kanten obwohl sie nicht aneinander Grenzen - Er werden Bankette, Straßengraben und Alleebäume unterschlagen die nicht zur Ackerfläche gehören. - Die Knoten liegen jeweils zur Kreuzungsmitte verlagert - Die jeweiligen Ackerflächen (Angenommen Quadratisch a*b) werden bei nur 5m Lagefehler um 10*a + 10*b größer. - Durch das teilen von Kanten wird dargestellt das ein Wechsel von Fahrbahn auf den Acker jederzeit möglich ist - Dank Graben geht das aber nicht. - Es ist durch Lagebetrachtung von Nodes nicht mehr möglich zu entscheiden ob ein Acker links oder rechts der Straße liegt. Dazu kommen Nachbearbeitungsprobleme: - Im Knoten 1 sind 3 Flächen und 2 Straßen verbunden. Sind sie das wirklich oder sieht das nur so aus? Mit den derzeitigen Editoren ist nicht ersichtlich ob ALLE übereinanderliegenden Wege in einem Knoten verbunden sind. Es ist nur sichtbar das mehr als ein Weg verbunden ist. Hier habe ich schon viele Routingprobleme behoben weil mal irgendjemand zwar eine Straße da angeschlossen hat - Aber eben nicht an die Straße sondern die nur an einem Landuse war - der Knoten aber über den Weg geschoben. - Ich kann nie nur einen Weg, ein Landuse anfassen sondern wenn ich was anfasse sind im Changeset gleich alle beteiligten Flächen und Wege obwohl sie sich typischerweise nicht geändert haben. D.h. History Bloat. - Typischerweise haben landuses deutlich mehr nodes wenn sie diese mit Straßen teilen. > Und so kann eben überall dort, wo es keine mathematisch exakte > Beschreibung der Features, aber stattdessen einen Spielraum > für Interpretation gibt, je nach Verständnis und ggf. auch > Anwendungsfall "richtig" sein, was nach anderem Verständnis > eben falsch ist. Für eine absolute geografische Lage gibt es ein Richtig und ein Falsch. Und zwar ist es falsch wenn ich um Größenordnungen aus meinem Messfehler bewusst rauswandere. Im Beispiel von oben ist meine Bodenauflösung vielleicht 20cm - Wenn ich dann 10m da bewusst und absichtlich daneben einen Knoten lege dann ist das Falsch. Dann ist das das bewusste und absichtliche fälschen von Lageinformationen um der Generalisierung willen. Und DAS ist absolut inakzeptabel - Siehe auch Best Mapping Practices. > In Gebieten, wo auf Luftbildern im Pixelbereich gerade so zu er- > kennen ist, dass eine Straße links und rechts von Acker gesäumt > wird, reicht die Information (Acker | Straße | Acker) für viele > Anwendungszwecke nunmal aus, egal wie gut oder schlecht/ungenau > die Landuse-Grenze in der DB repräsentiert wird und auch egal > ob sie verklebt ist, oder nicht. Man muss vor allem in D nicht mit Landsat mappen. Und man kann trotzdem wenn man eine Kreisstraße hat einfach mal 10m Platz lassen. Das ist ein leichtes. Josm hat da einen View für - Kostet einen klick. > Woher kommt eigentlich der Zwang, dieses Problem "per Dekret" > von oben herab lösen zu müssen? Nach meiner Beobachtung löst > sich das Verkleben in Regionen mit gut aufgelösten Luftbildern > mittelfristig von selbst - denn dort konvergieren die einge- > tragenen Landuse-Grenzen gegen das, was auf dem Luftbild zu > erkennen ist. Wenn Alt-Daten nicht mehr oder sehr schlecht Nein - Siehe auch die Diskussion mit OF0 - In dem Bereich gibt es 20cm Luftbilder wie in meinem Beispiel. Ein neumapper verklebt, ein alter mapper sagt das das doof ist. OF0 schreibt das das aber anerkannte Praxis ist. Ich sage - Ja - Aber laut Praxis gibt es genauere Möglichkeiten die bevorzugt werden sollen. > zum Status-Quo eines guten, aktuellen Luftbildes passen, dann > wird bei der Überarbeitung dieser Daten häufig intuitiv "ent- > klebt". Und auch in solchen Fällen, in denen weiterhin ver- > klebt wird, rückt die Flächengrenze (etwa als Neueintrag) an > eine Position mit kleinerem Fehler (sofern die Georeferen- > zierung mitspielt). Entkleben kostet ~10x so viel Zeit wie es neu einzuzeichnen. Wenn ich einen schlechten Tag habe dann lösche ich verklebtes Zeugs und mache es neu weil ich keinen Bock habe die Historie eines Nodes/Ways zu erhalten die von jemandem eingezeichnet wurde dem das Nachbearbeiten egal war. > (Wenn bei Google automatisiert mit Laser-Ranging vermessen > wird, stellt sich die Frage nicht, denn die identifizieren > die Objekte (zunächst) nicht, sondern kümmern sich nur um > die Wiedergabe eine (gigantisch großen) Punktmenge, die so > ge-shaded wird, dass die Farbgebung der entspricht, die man > auch vor Ort wahrnehmen würde. Was welches Objekt ist, liegt > dann im Auge des Betrachters. Das bezieht sich nicht auf > die "normale" Google Maps Darstellung, sondern auf die Web- > GL Darstellung bei hoher Zoomstufe in fotorealistischem 3D.) Google maps hat einen völlig anderen Scope als OSM. Da geht es drum ihre Dienste zu verkaufen aka Yellow Pages und das soll ansprechend hinterlegt werden. Google Maps ist voll von Fehlern und denen ist das auch egal. In der Stadt in der ich wohne ist der Stadtpark laut Google Maps voll mit Gebäuden die nicht da sind. Ist aber egal - Die Karte sieht hübsch Bunt aus. OSM hat einen völlig anderen Scope und Anspruch. Siehe auch hier wieder Best Mapping Practices. 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
