Im Moment habe ich ein wenig das Gefühl, dass hier “the best is the
worst enemy of the better” zutrifft: Es ist klar, dass man nicht all zu
oft an der API rumschrauben will und so möchte man möglichst alles in so
eine Änderung reinpacken und es perfekt machen.
Ja, das geht in die richtige Richtung; es ist einfach so: Eine Änderung
an der OSM-API / am Datenmodell verursacht im ganzen OSM-Ökosystem
immense Kosten, selbst wenn die Änderung nicht so groß ist. Hunderte
Leute müssen ihre Software anfassen und ändern, damit sie weiterhin
funktioniert; tausende von Personen-Stunden müssen aufgewendet werden.
Zeit, die anderenfalls für andere Dinge sinnvoll eingesetzt werden kann.
Deswegen sollte man so eine Änderung nur machen, wenn sich das auch
wirklich lohnt, wenn man also durch diese einmalige Investition dann
auch viel Arbeit spart, viele Sachen besser und einfacher werden.
Mein Ansatz wäre jedenfalls, zuerst mal nur den Area-Datentyp
einzuführen. So etwa:
In meinen Augen verursacht Dein Ansatz alle Kosten, die ich oben erwähnt
habe, ohne wirklich einen Nutzen zu bringen. Dein Area-Datentyp löst
nicht das Problem, dass jedes Gebäude in OSM derzeit fünf Objekte
braucht, macht es nicht einfacher, Flächen zu bearbeiten, macht es nicht
einfacher, sie zu speichern, macht es nicht einfacher, sie in einem
Programm zu verarbeiten. Das wäre für mich also kein ausreichend großer
Nutzen, um zu rechtfertigen, dass wir Hunderte von Leuten zwingen, ihre
Software umzustellen.
nur ist der halt so strukturiert dass es relativ aufwendig ist ihn zu parsen, weil es 2 Rekursionslevel sind.
Einfach alle Flächen als Multipolygone anlegen wäre auch teuer, der Vorteil ist dass man die dann eindeutig und einfach in einen neuen Area-Datentyp umwandeln könnte, während es bei geschlossenen ways mit entsprechenden tags trotzdem immer ein bisschen Raten ist
Flächen: In der Realität gibt es keine Linien, sondern nur Flächen
ein paar Linien gibt es schon, z.B. ein Berggrat, oder der Thalweg eines Fließgewässers, Cliff-Kanten oder die Kanten von Stützmauern, etc.
Eigentlich sind nur Straßen, Eisenbahnen und Landebahnen Flächenobjekte die wir zu einer Linie reduzieren. Und Mauern und Hecken. Vielleicht auch Baumreihen?
Was du dabei, glaube ich, übersiehst, ist, dass größere Änderungen auch größeren Aufwand bedeuten. Das kennt man vom Refaktorisieren: Früher tendierte man bei der Softwareentwicklung dazu, viel zu große Änderungen auf einmal durchzuführen, gar das Programm komplett neu zu schreiben. Heute weiß man, dass viele kleine Änderungen effektiver sind.
Natürlich kann man das nicht 1:1 auf OSM übertragen. Wenn man jeden Tag 'ne neue API rausbringt, werden sich die User bedanken… Aus meiner Erfahrung heraus würde ich sagen, dass drei einfache Änderungen im Abstand von drei Jahren (für das ganze Umfeld, wie auch die Leute, die die Änderung durchführen) einfacher zu händeln sind, als eine große, bei der man alles neu machen muss, und dass in der Summe dabei Aufwand eingespart wird.
das soll er auch nicht.
Doch, das tut es. Der Nutzen der Änderung ist der, dass man nicht mehr aufwendig zwischen Weg und Fläche unterscheiden muss. Ich hatte es ja oben schon geschrieben: 181 Regeln muss man laut Jochen im schlechtesten Fall auswerten, alles Stringvergleiche. Das ist ein immenser Aufwand, auch wenn die Anzahl der Vergleiche im Mittel vermutlich deutlich geringer sein wird.
Ich vermute, dass ein Großteil der verarbeitenden Software diese Trennung derzeit regelmäßig durchführt, meist vermutlich in Form einer vorgelagerten Datenaufbereitung. Dieser Schritt würde wegfallen, die Software einfacher. Den Änderungsaufwand halte ich für relativ gering, weil man im Wesentlichen einfach nur komplizierten Code wegwerfen muss.
Dann gibt es Software (wie beispielsweise Routingsoftware), die Flächen meist gar nicht nutzt. Da ändert sich dann auch nichts (allenfalls fällt die eben erwähnte Datenaufbereitung weg).
Anders sieht es bei Editoren und allgemeiner Software (wie Osmium und Co) aus. Da wird der Aufwand etwas größer sein. Aber gerade da wäre ich, wenn ich die Software anpassen müsste, froh, wenn ich in kleineren Schritten vorgehen könnte.
Und nachdem ich das alles gesagt habe: Wie oben schon geschrieben, völlig sicher bin ich mir bei all dem nicht. Ich hab’ halt den Vorteil, dass ich gar nicht entscheiden kann und damit geht natürlich eine gewisse Narrenfreiheit einher. Meine Erfahrung mit Softwareänderung beschränkt sich auf etwa 2000 User (das aber immerhin über fast 20 Jahre). OSM mit Millionen oder gar Milliarden Usern ist da eine ganz andere Hausnummer. Aber trotzdem: Mein Eindruck ist, dass es sich lohnen würde, kleine Schritte zu machen.
Frag’ mal eine Ameise, ob die das auch so sieht. Ich glaube, es ist eine Frage der Perspektive, was man als Linie und was als langgezogene Fläche wahrnimmt. Oder andersrum: Für jemanden, der das ganze Universum kartiert, kann man die Erde als einzelnen Punkt mappen. Würde dann wahrscheinlich sogar als Micromapping durchgehen…
Die Einführung des Flächen-Datentyps bringt alleine vermutlich nicht viel, denn die Mapper müssten diesen dann auch richtig verwenden und nicht flächige Objekte versehentlich als Wege erfassen oder umgekehrt. Es wird somit eine gute Editor-Unterstützung notwendig (gibt es teilweise schon). Deshalb ist es aber auch gar nicht so wichtig, wie das in der Datenbank abgebildet wird? Also könnte der erste Schritt sein, dass Editoren anfangen zwischen Flächen und Wegen zu unterscheiden und hierfür etwa das area-Tag verwenden. Damit würden noch nicht angepasste Programme erstmal weiter funktionieren und es gäbe keine “harte” Umstellung. Wenn das dann breit unterstützt wird, könnte man überlegen das Datenbankschema um den Flächen-Datentyp zu erweitern und dann die Objekte mit area-Tags in Flächen-Datentypen umzuwandeln. Wobei dann der Flächen-Datentyp eigentlich überflüssig geworden und das area-Tag schon den Zweck erfüllen würde?
Es gibt da auch die Idee, stattdessen ein Attribut, oder wie man das nennt, zu verwenden, also sowas wie id und version. Das ginge wohl auch ziemlich einfach (und wäre wahrscheinlich sauberer als das area-Tag, weil das ja schon benutzt wird). Beides hat aber den Nachteil, dass nach wie vor Multipolygone und einfache Flächen getrennt sind.
Das ist kein Nachteil. So bleiben einfache Flächen einfach (und von denen haben wir weitais am meisten) und die Vorteile der bestehenden Lösung für kompliziertere Flächen bleiben erhalten (wir haben des weiteren ja noch einen 3. Flächentyp).
Doch, das ist ein Nachteil. Die Programme werden komplexer, da sie zwei unterschiedliche Algorithmen für Flächen benötigen. Insbesondere kann es passieren, dass (unabsichtlich) die beiden Algorithmen unterschiedliche Ergebnisse liefern und damit die Anwendung inkonsistentes Verhalten an den Tag legt.
Du meinst die Küstenlinien (und dergleichen)? Das ist ein eigenes Kapitel, was ich absichtlich in meiner Untersuchung ausgeklammert habe. Da sind ja dann auch noch so Fragen offen, wo ein Ozean endet und ein anderer beginnt und so Zeugs…
Du kommst nicht darum einfache (egal ob automatisch schliessend oder nicht) und zusammengesetzte Ringe verschieden zu behandeln, sprich der Aufwand fällt nicht weg.
Ein zusätzliches Flag/Attribut an Wegen um anzuzeigen ob sie als Fläche oder geschlossen Weg zu behandeln sind, behebt die Probleme mit Objekten die beides sein können (natürlich behebt das Unschärfen in der Kategorisierung nicht, die es auch gibt), und das ist was schlussendlich bei der Auswertung am meisten stört.
Eine Lösung für “komplizierte” Flächen sollte dann aber auch wirklich nur für komplizierte Flächen nötig sein. Ein Gebäude mit Innenhof zum Beispiel ist eigentlich ziemlich einfach (wenn man es nicht wie eben unser aktuelles Datenmodell unnötig verkompliziert) und ich finde, ein Area-Datentyp sollte auch das leisten können. D.h. der aus meiner Sicht naheliegende Kandidat für einen Area-Datentyp ist das, was die GIS-Leute als “Polygon” bezeichnen: Ein äußerer Ring, beliebig viele innere Ringe.
Ein Attribut zur Unterscheidung zwischen Linien und Flächen wäre schon mal sehr hilfreich, ja. (Und erst einmal area=yes an alle Flächen zu hängen wäre womöglich ein guter erster Schritt in einer Migrationsstrategie.) Aber eine ordentliche API-Unterstützung würde mehr leisten, u.a.:
Garantieren, dass Ringe sich nicht überschneiden und dass innere Ringe in äußeren liegen
Drehrichtung definieren, so dass man Flächen am Rand eines Kartenausschnitts abschneiden kann, ohne dass es Mehrdeutigkeiten gibt.
Die Nachteile von Relationslösungen zumindest für den einfachen Gebäude-mit-Innenhof-Fall vermeiden, z.B. das Verteilen der History auf etliche verschiedene Elemente oder die Möglichkeit, beliebige weitere Member und Rollen mit komplett unklarer Semantik einzuhängen
Du musst bei den Ringen unterscheiden on sie aus einem “Teil” oder aus mehreren bestehen. Sprich für den 2. Fall musst du einen “Zusammensetzalgorithmus” implementieren, dass kannst du höchstens umgehen in dem du beliebig lange Wege erlaubst (und keine gemeinsamen Geometrien mehr, denke mal an Grenzen), was aber einen ganzen anderen Rattenschwanz an Problemen nach sich zieht.
Dazu kommt noch, dass wie schon gesagt, Polygone aus einfachen geschlossen Wege bei weitem die am häufigsten vorkommenden “Flächen” sind (>99%), dein Vorschlag macht die Verarbeitung von diesen 99% ohne Not deutlich teurerer.
Das Problem ist das du versuchst für einen Fall zu optimieren, der im grossen ganzen praktisch nicht vorkommt.
Und eine vereinfachte Verarbeitung und Validierung hast du auch nur dann wenn du “unendlich” grosse Ringe/Wege zulässt, was beliebig Probleme bei der Bearbeitung und Erstellung der Ringe gibt (von Sachen wie keine gemeinsamen Geometrien bei Grenzen und ähnlichem mal gar nicht zu reden).
Ich glaube, da haben wir aneinander vorbeigesprochen. Ich wollte nie die Ringe, die aus mehreren Teilen bestehen (typischerweise boundary, coastline etc.), im Area-Datentyp haben. Dort sollen alle Ringe aus einem geschlossenen Linienzug bestehen. Meinetwegen auch nur einem äußeren (und beliebig vielen inneren), wie es Tordanik angedeutet hat. Das wäre wohl sogar konsistenter.
Speziell bei landuse ist es eher der Normalfall, dass die Ringe aus mehreren Wegen bestehen. Einerseits well Wege zwischen 2 angrenzenden Flächen mitbenutzt werden, anderseits weil OSM Wege eine maximale Anzahl Knoten haben (2000). Jetzt kann man das alles abschaffen, aber es macht das Editieren deutlich umständlicher bis zu unmöglich ohne Spezial-Tools.
Es ist nicht einfach Renitenz, dass keine der vielen Vorschläge für einen Flächentyp über die Jahre Erfolg hatten, sondern es liegt einfach daran, dass sie über alles gar keine Verbesserung zur Folge gehabt hätten.
PS: Grenzen, sprich “boundaries” verwenden die gleiche Modellierung wie multi-polygone, verwenden also nicht das “Küstenlinien” Modell.
Wir scheinen hier eine unterschiedliche Realitätswahrnehmung zu haben. Gebäude mit Innenhof, Teiche mit Insel, Wäldchen mit Lichtung etc. sind zwar prozentual sicher nur ein kleiner Teil der Flächen, aber sie sind häufig genug, dass fast jeder Mapper mit ihnen in Berührung kommt. Das ist etwas, das bei der Modellierung der physischen Realität vor Ort alltäglich auftritt, nicht nur bei abstrakten Gebilden wie z.B. Grenzen.
Ich finde es daher wesentlich sinnvoller, wenn diese Fälle von der gleichen Lösung abgedeckt werden, mit der das Nachbarhaus auch erfasst ist, und nicht die komplexe Sonderlösung für Riesengebilde brauchen.
Eine definierte Drehrichtung von Ringen würde es erlauben, Flächen teilweise herunterzuladen (und zumindest im Prinzip sogar konflikfrei gleichzeitig an verschiedenen Abschnitten einer großen Fläche zu editieren). Damit könnte ein Hauptgrund für das 2000-Node-Limit wegfallen.
Wenn es nur der Flächentyp wäre, wäre das vielleicht plausibel. Aber es haben ja seit 15 Jahren auch sonst keine Weiterentwicklungen am Kern des OSM-Datenmodells mehr stattgefunden. Entweder sind wir also mit Version 0.6 zufällig über das unübertreffbar perfekte Datenmodell gestolpert oder es ist eben doch ein soziales Problem.
Z.B. keine Mapper die iD/RapiD verwenden. Sprich das ist nicht nur der seltene Fall, sondern auch noch der, der von 80% der Mapper nicht einmal wahrgenommen wird, wenn sie mal darüber stolpern würden.
Ja, aber gleichzeitig können dann keine Abschnitte mit anderen Flächen geteilt werden (oder mit Wegen mit einer definierten Richtungsbedeutung), dass ist gerade dann wenn es um grosse Flächen geht eine wesentliche Arbeitserleichterung (die ihrerseits natürlich nicht “kostenlos” ist).
.
Das behautet niemand, aber es gibt relativ wenig Gebiete die durch eine “sanfte” Renovation verbessert werden könnten, und für eine grosse Renovation hat niemand Zeit und/oder das Geld.
Das Einführen eines Flags für geschlossene Wege der anzeigt ob das eine Fläche ist oder nicht, wäre eine kleine Verbesserung mit absehbaren Umfang an Nachteilen. Von mir aus könnte man auch einen “area” Elementtyp einführen, der 1-1 Relationen mit Typ multipolygon entspricht, denn auch das Drängen auf Änderungen des Datenmodells ist hauptsächlich ein soziales Problem, und dass wäre dadurch schlagartig erledigt.
