Studie zum Datenmodel von OSM

[Mammi71]

@SimonPoole

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.

Kannst Du das mal näher erläutern? ich bin da eher bei Tordanik.

[SimonPoole]

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).

[kumakyoo]

@SimonPoole

Speziell bei landuse ist es eher der Normalfall, dass die Ringe aus mehreren Wegen bestehen.

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.

@SimonPoole

@Tordanik

… dass fast jeder Mapper mit ihnen in Berührung kommt.

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.

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.

@SimonPoole

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 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.

@SimonPoole

Von mir aus könnte man auch einen “area” Elementtyp einführen, der 1-1 Relationen mit Typ multipolygon entspricht

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.)

[miche101]

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

[kumakyoo]

@miche101

Aber das ist nur für Leute relevant die ganze planet-Dateien verarbeiten…

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…

[kumakyoo]

@SimonPoole

Von mir aus könnte man auch einen “area” Elementtyp einführen, der 1-1 Relationen mit Typ multipolygon entspricht,

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.

[pyram]

@kumakyoo

Multipolygone (mindestens ein Weg nicht geschlossen) 43.203 14.548 ? 2.247 1.792

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.