Hola,

On Sat, Apr 07, 2018 at 09:06:09PM +0200, "Christian Müller" wrote:
> > Sent: Thu, 5 Apr 2018 16:38:49 +0200 
> > From: "Florian Lohoff" <f...@zz.de>
> > To: "Christian Müller" <cmu...@gmx.de>
> > Cc: talk-de@openstreetmap.org
> > Subject: Re: [Talk-de] Flächen/Wege // Trolling in changesets
> >
> > Sobald du eine Fläche mit dem Weg verbindest behauptest du das diese
> > Seite Geometrisch zu dem landuse daneben gehörst. Das sagst du dadurch
> > das die neue Grenze des landuses die Knoten in der Straßenmitte sind.
> 
> Das ist nicht wahr, weil das eine Interpretationsfrage ist.  Ob die Knoten
> in der Straßenmitte zur Fläche gehören, oder eine (zu berechnende Grenze),
> die sich aus dem Versatz der Knoten in der Straßenmitte um die Hälfte der
> getaggten Breite (oder einer Standardbreite, wenn wir einen Fehler durch
> Abstraktion akzeptieren) ergibt, ist Frage der Gestaltung.

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.

> Wir bearbeiten hier aber zum Teil Geschichte, weil sich die Mappenden bei
> OSM i.d.R. sehr stark am Luftbild orientieren (lies: es abzeichnen), als
> damit, welche alternativen Möglichkeiten es gibt, das Datenmodell wartungs-
> arm zu fortzuentwickeln.  Die detaillierten Luftbilder abzuzeichnen dürfte
> zu den intuitiveren Methoden zählen, aber auch zu den aufwendigsten.  Es
> ist keine sparsame, sondern eher eine gründliche Methode, die aber für
> abstraktere Datenmodelle evtl. eine -grundlage liefert.

s.o. Fakten - nicht Konstruktionshilfen.

> > Wir zeichnen eine Linie in der Mitte um einen routingfähigen Graphen zu
> > bekommen. Wenn du das geometrisch richtig machen willst musst du den Weg
> > auch zusätzlich als Fläche erfassen. Da gibt es ja reichlich versuche
> > zu.
> 
> Da stimme ich mit dir überein.  Die Gefahr die besteht ist, dass Mapper
> beginnen, Mittellinien (also die Wegabstraktion) zu entfernen, wo Wege
> als Flächen gemappt wurden.  Die Argumentation wird (korrekterweise)
> sein, dass es auch Routingalgorithmen gibt, die Flächen verarbeiten
> können.

Ich kenne nur versuche Routing über Flächen zu machen - Ich kenne niemanden
der sowas in Produktion oder Nutzbar hat. Mal ganz davon abgesehen das
es computational ein Desaster ist.

> Je mehr Mittellinien dann aus dem Bestand verschwinden, desto nutzloser
> wird es, sich diese für ein Nicht-Flächen-Routing herauszufiltern.  Bei
> vielen gepflasterten Plätzen habe ich das schon beobachtet - es werden
> keine ergänzenden highway=* Linien für Legacy-Router eingetragen.

Legacy = Alles was heute irgendwo in Benutzung ist. Als Hilfskonstrukt
Routen aktuell die Routingalgorithmen über die Aussenkante der Flächen. Was
halt kaputt ist.

> M.M.n. fährt OSM mit dem Hybrid-Modell eigentlich ganz gut (also beides
> einzutragen, obwohl es redundant ist).  Ich verstehe aber auch die Gegner,
> die häufig mit dem Argument der Redundanzvermeidung um sich werfen, aber
> keine Lösung haben, ob die Redundanz durch das Behalten der Fläche, oder
> das Behalten der abstrakteren Mittellinie aufzulösen sei.  Der maximal-
> kooperative Ansatz ist also, beide Varianten zu behalten, imho.

Graphen und Flächen sind eben keine Redundanten Informationen. Das sieht
man schon an der Verklebediskussion. Ein Graph/Mittellinie KANN und WIRD
niemals die Fläche ersetzen können.

> > Verkleben bedeutet Abstraktion und Informationsverlust - Genauer
> > eigentlich sogar nicht Verlust sondern Verfälschung. Die Begrenzung
> > der Fläche sind absichtlich falsch um eine Lücke zwischen Straße und
> > Fläche zu vermeiden. Ein anderes Argument kenne ich nicht.
> 
> Das ist sehr total, aber für viele Anwendungen ist diese Totale völlig
> irrelevant, weil der Detailgrad, den du anstrebst für viele Anwendungen
> nicht relevant ist (tatsächlich ist er eigentlich nur für eine genaue
> Flächenberechnung relevant).  Für topologische Aussagen, etwa "neben
> der Straße liegt das Feld, es zählt zu folgender Größen/ordnung/" ist
> das nicht wichtig.  Und wenn es einen Standard gibt, dass z.B. jede
> Straße einen Straßengraben bestimmter Breite haben muss, dann ist der
> Fehler, den du wegen des Informationsverlustes bei der Berechnung mit
> Standardwerten erleidest, eben nicht die Regel, sondern eine vernach-
> lässigbare Ausnahme.

s.o. OSM ist eine Sammlung von Fakten. Das was du vorschlägst ist
absichtlich inkorrekte Fakten einzutragen.

> Aber wie gesagt, die meisten Leute sind, was OSM betrifft, nicht an
> einer abstrakten, topologisch richtigen Karte interessiert, sondern
> an einer, die möglichst nahe an die Vogelperspektive herankommt, so
> dass auch die hohen Zoomstufen nicht Nichts enthalten.

Das ist so wie meine Aussage zu den "Gelegenheitsmappern". Hast du da
irgendwelche Belegbaren informationen zu? Ich halte die oben genannte
Aussage für Falsch. Ich und die mit denen ich die Diskussion haben haben 
ein Interesse daran eine möglichst genaue Karte zu machen die vom
Detailierungsgrad weit über das von Google oder den anderen 
gelieferte Hinaus geht. Eine Karte ohne "Nichts" zu erzeugen ist mapping
für den Renderer und wird seit bestehen von OSM von weiten teilen
der Community nach meiner Beobachtung abgelehnt.

> > "man" oder "Du" - Ich kenne derzeit keine Anwendung die das macht. Wir
> > haben seit 10 Jahren das Thema das Straßen und Flußbreiten nichtmal
> > gerendert werden. Wenn das alles so einfach ist warum hat es dann noch
> > keiner gemacht?
> 
> Das ist eine Frage der Muse.  Offensichtlich macht es mehr Spaß, die
> Daten zu bearbeiten, als ein Stylesheet zu schreiben.  Grundsätzlich
> aber ist es nicht schwer, den Regelsatz von CartoCSS oder ähnlichem
> zu verstehen.  (Es ist aber anspruchsvoll den Stil so hinzubekommen,
> dass das Kartenbild gut lesbar ist, und zwar für viele Nutzer und
> Nutzer verschiedener Altersgruppen).  Ich habe das Rendern der Stras-
> senbreite in Kendzi3d (code auf github) umgesetzt und auch die als
> area:highway=* gemappten Flächen durch diesen Code zeichnen lassen.
> Wenn das in einem 3D-Renderer klappt, lässt sich das auch für 2D-
> Tiles umsetzen.

Nochmal: "man" oder "Du"? Deine Behauptung ist das das ja ganz einfach
ist und man das kann. Ich kenne das gerade niemanden der das macht daher
meine provokante Frage. Ich habe mich selber zu Zeiten von Osmarender
mal ein paar Wochen damit beschäftigt und habe anschliessend das Thema
als zu aufwendig verworfen. Das Thema ist eben nicht so trivial wie du
das versuchst zu verkaufen.

> > Warum? Die Böschung des Grabens - Stand heute machen die leute das zum
> > farmland. Defakto gehört das zum Graben. Jetzt kann man da natürlich
> > eine Riverbank einzeichnen für einen 30cm breiten graben. Das wiederum
> > halte ich für Mumpitz. Defakto ist da aber was was nicht zum farmland
> > gehört.
> 
> Das zeigt nur, dass du mit der Ackerwirtschaft nicht viel am Hut hast.

Ich wohne zufällig im Aussenbereich und ich glaube ich habe mehr mit
Landwirtschaft zu tun als 99% der OSM Mitglieder :) Siehe auch meine 
langen Diskussionen zum Thema "Track vs. Service" auf talk-de in den
letzten 10 Jahren.

> Die Gräben erfüllen sehr oft eine Doppelfunktion und entwässern auch
> den Acker - du willst ja nicht, dass deine Ernte oder das Wurzelwerk
> vergammelt, weil das Wasser nicht abfließen kann.  Ich würde ihn auch
> extra eintragen, aber de facto ist es gar nicht so einfach Acker und
> Ackergräben funktional voneinander zu trennen (optisch schon).

Der Straßenbegleitende Graben gehört aber zur Straße und gehört auch
Pflegetechnisch zumeist zur Straßenunterhaltungspflicht. Das er der
Entwässerung dient sagt ja ggfs. das Tagging aus.

> Mapping für den Renderer ist, kleine Strukturen, oder z.B. Untergrund-
> Infrastruktur nicht in die DB aufzunehmen ("denn die Erscheinen ja eh
> nicht auf der Karte").

Aeh ? Dinge die nicht gerendert werden ist "mapping für den renderer"? 

> Der Renderer ist eine Abstraktion der Abstraktion.  Wenn Du dir beim

Das sehe ich anders:  OSM ist eine Faktensammlung von Geodaten. Der Renderer 
macht
durch Abstraktion daraus eine visuelle Karte.

> Eintragen Gedanken darüber machst, wie das von einer Software namens
> Mapnik oder ähnlich gezeichnet wird, dann filterst Du deine Wahr-
> nehmung der Realität schon dahingehend, dass du nur Objekte in die
> DB einträgst, die diese Software /kennt/  (die DB liegt aber eine
> Abstraktionsschicht /unter/ dem Renderer, nicht drüber;  genau ge-
> nommen ist es schon eine Vorfilterung für die Bearbeitung der Daten
> einen grafischen Editor zu verwenden, denn ihr Inhalt ist nicht
> grafisch, es werden lediglich Strukturen, die auf einer Koordinate
> als Grundlage basieren mit abstrakteren Begriffen der natürlichen
> Sprache verknüpft).

Nach deiner definition nichtmal das. Nach deiner Definition gibt es in
der OSM Datenbank keine absoluten Koordinaten denn du möchtest diese
beliebig anhand der angeschlossenen Wege noch interpretieren.

> Es soll nicht der Eindruck stehen bleiben, dass diese Methode des
> Verklebens irgendwie schlecht oder gar falsch war, denn es gibt
> nunmal wie so oft /mehrere/ Möglichkeiten ein Datenabbild dieser
> Welt zu schaffen und keines davon ist perfekt.  Alle haben ihre
> Vor- und Nachteile.  OSM stellt ja nicht nur eine Karte bereit,
> es ist ein Ökosystem, dass von der Vielfalt der Beitragenden und
> ihrem Einsatz für das Projekt zehrt.

Die Methode war immer schon was "Geografische Fakten" angeht falsch.
Deshalb habe ICH das nie Praktiziert. Und viele die lange dabei sind
und viel Mappen machen das auch nicht weil es was die Pflege der Daten
angeht bei der heuten Editorunterstützung einfach absolut nervig ist.

Wenn ich mir Ostwestalen-Lippe (Regierungsbezirk Detmold) ansehe
ist das verkleben auch eine absolute Randerscheidung. Ich hatte
die Zahlen hier ja mal geschrieben. Bei 1.4Mio Wegen und ~9 Mio Nodes
haben wir 24000 verklebte "Segmente" also Wege zwischen 2 Nodes.

> Konkret hier:  Ist ein Verkleben geometrischer Objekte, die unter-
> schiedlich stark abstrahieren, wirklich nie sinnvoll?  Welche Aus-
> sagen werden durch eine Veränderung der Daten wie verändert?  Wie
> wirkt sich die veränderte Repräsentation der Daten auf ihre Aus-
> sagekraft aus, usw.?

Ich halte das verkleben von Objekten unterschiedlicher Klasse immer für
falsch. Ich mache das nicht alleine aus "Hygenegründen" - Und was
die anschliessende Pflege der Daten angeht gibt mir das Ergebnis
auch Recht. Es ist Sonnenklar welches Objekt was ist weil sie eben 
alle mehr oder minder solitär existieren. Verkleben von dingen wie
landuse miteinander mache ich. Der Acker kann u.a. "nahtlos" in
Dauergrünland übergehen oder auch in einen Wald.

> Wenn verklebte Objekte ausgewertet werden, sind topologisch Aus-
> sagen z.B. mit viel weniger Rechenaufwand ableitbar, als wenn
> eine aufwendige geometriche Umgebungssuche gestartet werden muss
> (und z.B. nicht bekannt ist, welche Maximalbreite von Gräben anzu-
> nehmen ist, um bei jeder Konfiguration dann die "irgendwo" neben-
> liegende Flächengrenze eines Ackerpolygons o.ä. zu "finden").

Den "wenig Rechenaufwand" möchte ich mal sehen. Das halte ich für eine
maximal hypothetische Aussage. Und die "aufwendige geometrische
Umgebungssuche" lässt sich mit dingen wie einem RTree ja beliebig
erledigen. Alles was mit OSM Rohdaten zu tun hat ist massiv Speicher
und CPU intensiv. Das liegt einfach am schieren Volumen der Daten.

> Das heißt wie gesagt nicht, dass entklebte Objekte keine Vorteile
> bei der Auswertung besäßen.  Es soll nur verdeutlichen, dass weder
> die eine, noch die andere Variante der Datenrepräsentation in allen
> Belangen der anderen vorzuziehen ist.

Das sehe ich entschieden anders. Verkleben enthält einen Geometrischen
Fehler der sich nicht raus rechnen lässt weil das Faktum der absoluten 
Position nicht mehr enthalten ist. Das ist wie mit einer JPEG
Kompression. Das Original Bild lässt sich daraus nie wieder Berechnen.

> Naja, höchstens ungenau.  Wenn du mit dem Begriff "falsch" arbeitest,
> dann ist ALLES in OSM falsch, denn wenn eine phys. Forschungsgruppe die
> Linsen für die Aufnahme von Orthofotos überarbeitet hat, oder sich die
> Kontinentaldrift bemerkbar macht, stimmt keine einzige Koordinate in
> ihrer Lage.

Wie groß ist denn der Fehler? Wenn ich mit Ortophotos mit 20cm
Bodenauflösung Arbeite dann aber den Knoten 10m daneben an die Straße
klebe ist der Fehler durch das Verkleben im Zweifelsfalle 50 mal so
groß. Und der Fehler summiert sich ja das ja der Fehler des Ortophotos
noch auf die Straßenmitte auch noch zutrifft.

> Wichtiger ist imho, dass topologische Aussagen stimmen, über jene
> Objekte, die eingetragen sind und werden.  Der Rest lässt sich nach
> und nach präzisieren und evtl. mit Robots auch algorithmisieren,
> wo unstrittig.

Du kannst einmal gelöschte Präzision nicht mehr Mathematisch hinzufügen.
Die ist weg - Und bleibt auch weg. Natürlich kann man vermeintlich da
was dran schummeln. Falsch bleibt es aber. Nur anders.

Flo
-- 
Florian Lohoff                                                 f...@zz.de
             UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Antwort per Email an