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