> 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.
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.
> Das sehe ich als Fehler. Der Weg an der "Waldgrenze" gehört ja nicht zum
> Wald und auch nicht zum Acker daneben. Er ist eigenständig.
Ja, das ist (d)eine Sichtweise, aber der nächste kommt und sagt, der Weg /ist/
die Waldgrenze und dann gehört er sowohl zum Acker als auch zum Wald. Er
ist Bindeglied (oder Trennglied) und kann als solches eigenständig betrachtet
werden, oder eben nicht. Diese Sichtweise(n) wird(werden) ja gerade dann
modelliert, wenn der Weg (die Weglinie in den Daten) als Grenze wiederver-
wendet wird.
> 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.
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.
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.
> 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.
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.
> > Wie bereits gesagt, entsteht dadurch ein Fehler (abstraktions-
> > bedingt), der bei der Flächenberechnung aber z.B. dadurch min-
> > imiert werden kann, dass (Länge*getaggte Breite)/2 von der Be-
> > rechnung der Flächengröße der geklebten Fläche abgezogen werden
> > kann. /Wenn/ alle Flächen so gemappt würden, dann ist das auch
> > programmatisch einfachst umzusetzen, dann programmiert man das
> > einmal und gut ist.
>
> "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.
ABER: Das ist evtl. gar nicht gewünscht, denn es geht durch Abstraktion
(und teilweise bewusst in Kauf genommenen Informationsverlust) darum,
den Lesern der Karte eine zugänglichere Quelle zu topographischen Daten
an die Hand zu geben, die einem Luftbild ungleich schwerer entnommen
werden könnten (ansonsten reichte das schließlich, ein paar Labels
in ein Luftfoto zu zeichnen das kann auch Google Maps - die Daten
auch unterschiedlichen Zoomstufen so zur Verfügung zu stellen, dass
man auf jeder Zoomstufe als Mensch noch eine Übersicht behalten kann,
schafft Google Maps imho weniger gut)
> 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.
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).
> Es gibt keine Notwendigkeit das jeder quadratcentimeter zu einem landuse
> gehören muss. Das ist mapping für den Renderer.
Das sehe ich anders. Gerade irgendwelche Ventilanlagen im Pipeline-Netz,
die für den Katastrophenschutz schon von Interesse sind, sind klein, aber
nicht unbedeutend - vielleicht nicht im qcm-Bereich, aber grundsätzlich,
gerade in Ballungsräumen, ist man schon daran interessiert, auch kleine
Strukturen in der Karte wiederzufinden.
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").
Der Renderer ist eine Abstraktion der Abstraktion. Wenn Du dir beim
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).
> > Und auch das Phänomen, dass eine Fläche an eine andere an-
> > schließt, wird sich durch Lückenbildung (egal aus welcher
>
> Wir sind aber nicht beim verkleben von Flächen untereinander
> sondern von Flächen mit Wegen.
I.O. - es ging (mir) wie gesagt in diesem Thread auch nicht darum,
hier irgendjemanden vom Entkleben (und dem Vervielfachen paralleler
Linienzüge) aufzuhalten, sondern darum, die geschichtliche Ent-
wicklung der Bestandsdaten in Erinnerung zu rufen und das diese
an einem bestimmten Punkt in OSMs Vergangenheit sowohl Sinn und
Richtigkeit besassen, wenn bestimmte Faktoren in der Auswertung
berücksichtigt wurden.
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.
Auch im Bezug auf solche vermeintlich einfach zu lösenden Probleme,
muss man sich fragen, wieviel Schaden entsteht, wenn man einen
Diversifikationsfaktor durch Verbot/Dekret/Konsens eliminiert.
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.?
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").
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.
> Dann lassen wir das mit dem verkleben. Das ist eine Vereinfachung
> die die Geometrie falsch abbildet.
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.
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.
> Es ist wichtig eine gewisse Disziplin anzuwenden. Nicht alles weil
> es einfach ist mal eben übereinanderklatschen und auch nicht drauf
> achten ob dinge verbunden sind oder nicht.
Jein, gut gemeint ist ja bekanntlich nicht immer gut. Grundsätzlich
gebe ich dir schon recht, dass eine gewisse Struktur in Daten und
Edits erkennbar sein sollte, aber OSM war und ist auch immer ein
Experimentierkasten.
Und es wurde mehr als einmal betont, dass die Community Vorrang
gegenüber der (Daten-)Qualität haben soll. Oder wurde das nur
als Wunsch einzelner formuliert? Ich bin mir nicht sicher, ob
darüber abgestimmt wurde, aber als Projekt wo einer den Frei-
willigen gegenüber sagt, wo es lang geht, ist OSM nie angetreten.
Gruß
cmuelle8
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
