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.
Doch, natürlich. Ein einzelner Ring ist einfach nur ein Spezialfall eines Multipolygons, der ganz genau gleich behandelt wird.
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.
Kannst Du das mal näher erläutern? ich bin da eher bei Tordanik.
iD/RapiD hat einen (synthetischen) Flächentyp der Flächen für den Nutzer transparent entweder als einfaches Polygon/geschlossener Way oder als MP modelliert (seit mehr als ein Jahrzehnt).
Ich hab’ das mal für Deutschland (Stand 1.1.2024) gezählt (auch noch ein paar andere Tags, wobei bei building der Speicher für die MPs nicht reichte):
| Element | Anzahl landuse |
Anzahl natural |
Anzahl building |
Anzahl leisure |
Anzahl amenity |
|---|---|---|---|---|---|
| Wege (nicht geschlossen) | 135 | 337.811 | 7 | 3.594 | 5.368 |
| Wege (geschlossen) | 4.454.975 | 1.717.808 | 36.945.832 | 502.309 | 1.203.418 |
| Multipolygone (alle Wege geschlossen) | 95.662 | 39.943 | ? | 6.945 | 4.101 |
| Multipolygone (mindestens ein Weg nicht geschlossen) | 43.203 | 14.548 | ? | 2.247 | 1.792 |
Mein Vorschlag von oben wäre, dass man die Elemente der zweiten und der dritten Zeile zusammenfassen und als Area mappen würde.
Für den Umgang mit den Multipolygonen aus der letzten Zeile gibt es mehrere Optionen, im Detail wäre das eine Diskussion für sich und meiner Meinung nach erst der zweite Schritt, den man meines Erachtens, wenn erst mal Areas da sind, auch ohne Änderung an der API machen kann.
Ich denke, die Mapper sind nicht das Problem. Da können die Editoren viel auffangen. Eure Diskussion zeigt ja, dass das bereits gemacht wird. 
Die Probleme kommen, wenn man die Daten nutzen will: Also Karten zeichnen, Routen berechnen, Daten wissenschaftlich auswerten, Geolokalisation betreiben, etc.
Das wäre ein weiterer Punkt, an dem man das Datenmodell verbessern kann. Ich hab’ das in meinem Vorschlag erst einmal ausgeklammert, weil ich, wie oben geschrieben, kleinere Schritte sinnvoller finde. Jochen hat es in seinem Vorschlag mit aufgenommen. Und was die “Arbeitserleichterung” anbelangt: Das bezieht sich wieder nur auf die Mapper, und erneut können das die Editoren abfedern.
Da wäre ich dabei. 
(Wobei ich halt die Multipolygone mit zerteilten Ringen ausschließen und derzeit als Way gemappte Flächen mit einschließen würde, aber das kann man auch später noch machen, die dafür benötigten Änderungen sind minimal und möglicherweise wäre der Wechsel so auch deutlich einfacher.)
Was ich noch beitragen möchte 
was immer wieder kommt ist das es sehr viel Arbeit (Rechenleistung) kostet… den Way die gänzlich ohne Geographischen informationen kommen die lat und lon zu ermitteln.
Wenn ein Way nur wenig information hätte über seine Lage und Größe dann könnte man wesentlich effizienter zuordnen.
Aber so ist ja klar wenn ich aus 12 Milliarden Nodes immer erst die richtige raussuchen muss geht das wesentlich langsamer… Alleine wenn man den Speicherbedarf dieser Nodes überschlägt:
11800100027;48.3493193;11.9235668
bei ~35 Byte pro ID wäre das bei 12 Mrd. Nodes schon bei 384GB an Daten. Sich alle Nodes mal in den Arbeitsspeicher zu lande … wird dann schon schwierig mit meinen z.B. 16 GB Arbeitsspeicher.
Hier müsste man die Api nur erweitern aber nicht alles umwerfen… ein zusätzliches bbox=“AABBCC” … zwei Byte für Lat, Lon, BOX also 6 Byte könnte man schon einiges erreichen um die Daten effizienter zu verarbeiten zu können. Aber das ist nur für Leute relevant die ganze planet-Dateien verarbeiten…
Gruß Miche
Würde auch schon bei kleineren Extrakten helfen. Bei germany.osm stoße ich auch regelmäßig an die Arbeitsspeichergrenzen (bei mir 4GB) und muss auf tmp-Dateien ausweichen oder in mehreren Durchläufen arbeiten…
Je mehr ich darüber nachdenke, desto mehr gefällt mir dieser Vorschlag. Einerseits würde diese Änderung das OSM-Ökosystem vergleichsweise gering belasten und andererseits hätte man damit etliche Möglichkeiten. Man könnte type=... bei allen Elementen einführen. Dann hätte man mittelfristig für jedes Objekt nur ein Element. Das wiederum würde bedeuten, dass klar ist, auf was sich area=yes/no genau bezieht. Man könnte damit Flächen und Linien klar trennen. Alles immense Verbesserungen mit geringem Aufwand.
Selbst die Umwandlung, dass man die Punkte eines Elements nicht mehr als Node speichert, sondern in die Elemente übernimmt, würde damit meiner Meinung nach einfacher: Und wenn es nur deswegen ist, weil man sich über Flächen dabei keine Gedanken mehr machen muss (oder zumindest deutlich weniger).
Alles in allem, das wäre für mich ein super erster Schritt.
Bei dieser Zeile dürfte ein nicht unerheblicher Teil der Fälle überflüssig kompliziert erfasst und in die Form Zeile 2 oder 3 umbaubar sein. Stammt meist von Mappern mit “Multipolygonitis”.
Mittlerweile sollten das daher eher weniger als mehr werden, nachdem die gefühlte Mehrheit eingesehen hat, dass das keine gute Idee war.