Hola, On Sun, Apr 08, 2018 at 02:57:34AM +0200, "Christian Müller" wrote: > > Gesendet: Sonntag, 08. April 2018 um 00:43 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 > > > > 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. > > Irgendwie liest du auch nur das, was du lesen willst, oder? Da > brauchst du dich dann auch nicht wundern, wenn niemand die von dir > verschickten Dokus liest. Wenn das width-tag fehlt, wird je nach > Straßenklasse und evtl. dem lanes-Attribut eine Breite errechnet.
Nur und ausschliesslich im Renderer und das auch nur Renderer Spezifisch und das auch in Pixeln je nach Auflösung - Mit der realen Breite hat und hatte das nie zu tun. Du scheinst aber hier dem Trugschluss aufzusitzen das OSM eine Karte ist. Das ist es nicht OSM ist und war nie eine Karte. OSM ist eine Sammlung von Geografischen Fakten. Die mit Mapnik erzeugte Karte ist nur ein Beispiel diese Sammlung an Fakten zu visualisieren. > Das eine genaue Angabe oft fehlt, ist ein Missstand, rechtfertigt > aber nicht die Annahme, dass wir nur die Mittellinie von Straßen > erfassen. Das geographische Objekt, dass von einem mit highway=* "Nur" habe ich nie behauptet - Du hast behauptet das wir die Mittellinie nicht erfassen sondern ein Objekt mit Breite - Bei einem 1 Dimensionalen Objekt ist diese Annahme - aehm - schwer nachzuvollziehen. Das stimmt so einfach nicht. 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. > getaggten Datenbankobjekt repräsentiert wird, ist eine Straße, > mit Straßenfläche und ggf. weiteren Eigenschaften, nicht diese > Mittellinie. Wir erfassen die Straße als Mittellinie, nicht umge- Wir nennen es Straße - Geometrisch ist es die Mittellinie - und wir erfassen viel - Aber die Breite eben nur auf einem verschwindend geringen teil der Wege. > kehrt. Nach deiner Argumentation müssten ja die Seitenstreifen, > Trennlinien, Standstreifen nochmals als Idealisierung in den Daten- > bestand, weil die Mittellinie nur für sich steht, steht sie aber > nicht. Es wurde sowohl im Wiki als auch in der Mailingliste > mehrmals darauf hingewiesen, dass Spuren und Standstreifen /nicht/ > separat erfasst werden, /weil/ die Mittellinie die baulich nicht > getrennte Straßen/fläche/ repräsentiert. Korrekt - Die Mitellinie ist die Geometrische Mitte der Straße - Und die erfassen wir. Dazu noch attribute der Straße - Mehr nicht. > Ich verstehe auch nicht, wieso du dich von einer Erklärung zur Situation > der Bestandsdaten angegriffen fühlst. Ich habe auch nie behauptet, dass > ich irgendeinen Fehler hinzufügen will, in der Art, wie du ihn beschreibst. > Es ging darum aufzuzeigen /warum/ diese Daten so in der DB zu finden sind, > wie sie es sind. Umgekehrt wird ein Schuh draus - Du versuchst mir in der ich weiss nicht wievielten Mail zu sagen das wir bei Straßen ja eine Breite erfassen und das es schon okay ist Flächen damit zu verbinden weil man das ja "einfach raus rechnen kann". Und das ist halt in meinen Augen an so vielen Stellen falsch das ich manchmal echt Baff bin. Ein 1 Dimensionales Objekt kann nie eine reale Breite haben. Die wird an den Stellen wo die Straße angezeigt wird nur dazu geschummelt. Mit Real erfasster Breite hat und hatte das nie zu tun und wird es auch nie zu tun haben. Wenn du eine Reale Fläche/Breite haben willst musst du das als Fläche separat erfassen. > Vielleicht war das ja bei dir schon immer so, dass du mit 2cm genauen Luft- > bildern gemappt hast. Ich hingegen kenne OSM noch aus einer Zeit, wo für > das hiesige Gebiet keine sonderlich gute Auflösung mit den Quellen zur Ver- > fügung stand, die zur Nutzung mit OSM erlaubt waren. Ich komme aus NRW und ja - wir hatten früh und lange Zugriff auf 40cm Luftbilder - Erst über das LVermA jetzt über ESRI. Und ich kenne OSM noch aus Zeiten da ich mit einem Feldbuchrahmen rum gerannt bin und zu meinen GPS Tracks noch Zeichnungen gemacht habe. Hat aber auch alles nichts mit der Genauigkeit zu tun. Auch damals habe ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei egal welcher Genauigkeit einfach topologisch falsch ist und bleibt. > > 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. > > 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? > nie behauptet, dass das fehlerfrei möglich sei, und ich wiederhole mich, wenn > ich dir erkläre, dass Speicherplatz und Verarbeitungsbreite für geographische > Daten in der Breite noch nicht seit Ewigkeiten zur Verfügung stehen. (OSM war > /ist ein Hobbyprojekt, ein Projekt von und für die crowd nicht wahr?) Also bisher hatte ich immer (>10 Jahre) die Möglichkeit auf Rechnern zu Arbeiten die die OSM Daten verarbeiten konnten. Ich habe lange für QA Zwecke OSRM Instanzen laufen gehabt die den ganzen Tag routen getestet haben etc. Ich habe mal ein auf PostgreSQL/PostGIS basierendes Datenbankend für osmarender gebaut. So abwegig ist das mit den OSM Daten zu arbeiten nicht. > M.M.n. differenzierst Du Vergangenheit/Gegenwart nicht genügend, und nutzt > heute gültige Argumente, um dein Unverständnis gegenüber einer Datenlage > auszudrücken, die unter anderen Paradigmen entstanden ist. Paradigmenwechsel > und teilweise auch die offene Paradigmensuche, die das Projekt durchgangen > hat und die der Grund dafür sind, dass es ein Großteil der Mapper heute > bevorzugt, luftbildgenau abzuzeichnen, anstatt mit Papier oder GPS vor Ort > Daten zu erfahren, zu erfassen und später in der DB abzubilden, blendest > du in diesem Thread warum auch immer aus. Es hat nichts mit der absoluten Genauigkeit der Lage eines Knotens zu tun ob man Fehler der Topologie noch hinzufügt. Das ist dann einfach nur eine Summe von Fehlern. > Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten, > heute scheinbar nicht mehr so wichtig. Vor zehn Jahren gab es schon noch > ein paar mehr Leute, denen es wichtig war, dass die Gesamtdaten auch auf > kleine Geräte passten und dort verarbeitbar waren. In dieser Zeit ist die > Erklärung für manche Bestandsdaten viel einfacher zu suchen und zu finden. 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. Ein Größenargument war das nie. Ich behaupte das selbst ohne zusätzliches auswertungen/konstruktion das verkleben mehr CPU Zeit bei allen Anwendungen braucht weil es die Anzahl der notwendigen Knoten bei den Highways massiv nach oben treibt. Ich tippe mal so auf Faktor 5. > Ein geometrischer Fehler von auch 3 - 5 Metern ist/war für viele Anwend- > ungsfälle völlig unerheblich, ob du das nun wahrhaben willst oder nicht. Du Es geht nicht um die Anwendung - Das versuche ich dir doch die ganze Zeit mal zu sagen. Es geht darum das OSM eine Faktensammlung ist und da geht man nicht hin und fügt absichtlich Fehler hinzu. Ich schreibe auch bei Wikipedia dem Karl Theodor zu Guttenberg keine Vornamen dabei nur weil ich das witzig finde. Als Faktensammlung, gerade so technischer Natur wie OSM versuche ich doch von vorneherein den Fehler möglichst klein zu halten. Wenn ich das nicht mache kann ich auch gleich sagen - pah - Dezimalstellen an der Latitude - die schneide ich einfach weg. Bielefeld ist auf der Karte jetzt nen Vorort von London. Entweder man versucht Fehler zu minimieren oder man kann doch gleich aufgeben. Und dieses Verkleben ist halt ein Fehler den die Protagonisten der Verklebung bewusst und absichtlich hinzufügen. > schriebst, nach meiner Erfahrung zutreffend, dass Gemeinden z.B. früher nur > als Node eingetragen waren. Gehst du die Minderheiten, die das heute noch > tun auch an, nur weil du der Meinung bist, dass sie die Gemeinde ja gleich > umrisshaft hätten einzeichnen können? Bist du der Meinung, dass die un- > genauen Siedlungsgrenzen wertlos sind? - Deren Fehler ist auch mit modernen > Luftbildern erheblich und er wird dennoch akzeptiert, weil eine ungefähre > Siedlungsgrenze in vielen Fällen besser ist, als gar keine Information zu > haben. Hab ich nicht geschrieben - aber ich gehe mal auf das Argument ein. Der Knoten mit dem Gemeindenamen hat mehr/andere Funktionen als die Fläche. (Das war im überigen eine meine ersten Softwareentwicklungsversuche bei OSM vor 10 jahren. Ich habe die is_in tags in allen place nodes in Deutschland auf korrekte hierarchische Einordnung überwacht.) Hier habe ich das vor fast 10 Jahren schonmal ausgeführt. Damals hatten wir noch keine admin boundarys - aber ich habe die angekündigt das wir die haben werden. https://lists.openstreetmap.org/pipermail/talk-de/2008-December/032251.html "D.h. is_in/place nodes, landuse=residential und administrative boundary werden irgendwann parallel existieren, aber unterschiedliche dinge meinen." Bitte auch nicht landuse=residential mit Gemeindenamen versorgen - Halte ich auch für falsch und gibt auch den falschen Anreiz die landuses so riesig zu machen. Diese Ungenauigkeit von Boundarys liegt darin das dieses als einziges Objekt bei OSM geduldet sind obwohl sie vor Ort nicht verifizierbar sind. Siehe auch Mapping Good Practices. Und wenn du in die Historie von den admin_level=8 in NRW guckst dann wirst du mich bei vermutlich ~60% in der version 1 finden. ICH habe die u.a. so ungenau eingetragen weil ich Admin boundarys wollte und brauchte, die aber nicht existierten. Ich habe die gebraucht um Adressvollständigkeitsauswertungen zu machen. 2009 habe ich für alle Wahlbezirke in NRW die jeweiligen Straßenlisten mit der Wahlbezirkszuordnung auf den Webseiten der Kommunen gesucht und in ein Wiki gepackt. Teilweise Kopiert, teilweise abgeschrieben weil Bilder, teilweise OCR. https://wiki.openstreetmap.org/wiki/DE:Stra%C3%9Fenverzeichnis#Fr.C3.BChere_Auswertungen_von_Sven_Anders_und_Florian_Lohoff Mit dem offiziellen Zugriff auf die Kataster/ALKIS in NRW konnten wir die dann präzisieren. Boundarys sind also ein denkbar schlechtes argument für ungenaue Daten bei OSM - Weil sie eine große Ausnahme Bilden. > Sowohl eine schlechte Datengrundlage, technische Limitierungen oder > begrenzte Ressourcen/Manpower rechtfertigen die Technik des Verklebens, > wenn es darum geht (ging!) oder gehen wird, Daten kurz zu fassen. In > ärmeren Regionen oder solchen mit schlechterer Infrastruktur ist das > immer noch ein Thema, hierzulande und derzeit offenbar nicht. Verkleben ist topologisch IMMER falsch. Der Acker endet nicht und wird auch nie in der Mitte der Straße enden. Das jedoch sagt beim verkleben die Absolute position des Nodes. OSM hat beim auswerten/rendern _nie_ Node Positionen als Konstruktionshilfsmittel benutzt sondern es gilt immer die absolute Position des Nodes. Und die Summe des absoluten Lagefehlers wird durch verkleben einfach größer, das hat mit ungenauer Datenlage nichts zu tun. Verkleben macht einfach kaputte Daten noch kaputter. > > Wenn ich alle Beträge eines Kassensystems auf volle € runde kann ich > > hinterher nicht mehr die Cent Beträge ausgeben. > > Der Vergleich ist unzutreffend. Nein ist er nicht. Du rundest die Flächenkante auf die nächstgelegene Straße - genau das ist verkleben. 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
