Vollständigkeit eines Ways beim Datenextrakt

Communities Deutschland (Germany)
21

Stimmt, danke. Da war ich wohl wirklich auf dem Holzweg und habe mir das wohl zu einfach vorgestellt.

Dann bleibt aber noch der Punkt: wenn dieser Abschnitt eines Ways ein Member einer MP ist, dann kann man aber trotzdem entsprechende Dinge (inner/outer) ableiten bzw. in einem zweiten Schritt nachermitteln, oder?

Bzw. muss man dann aber eigentlich generell immer solche Strukturen “nachladen” ob man will oder nicht. Und damit könnte ich die andere Aussage von addresshistory*org nicht nachvollziehen, dass das OSM Datenmodell “kaputt” wäre.

22

Ja. Sobald man einen Node hat muss man sich sowieso raufhangeln zum Way und dann wieder dessen nodes suchen. Selbst in diesem einfachen Fall hat man schon das Problem, dass man irgendwie seine Informationen vervollständigen muss. Da ist das Weiterhangeln zur Relation und deren ways auch nur ein Schritt mehr.

Grüße,
Max

PS: Ein Negativbeispiel, was passiert, wenn man sich nicht um Dinge ausserhalb des Ausschnitts kümmert ist meine Karte hier. Da werden Changesets ausserhalb des Gebietes beim Update nicht berücksichtigt, wodurch immer mal Dinge am Rand kaputtgehen. Das heilt dann oft wieder, wenn die Flächen wieder in Bereichen geändert werden, die innerhalb des Ausschnitts liegen. Das ist auch kein spezielles Problem von MP-Relationen, sondern betrifft alle Objekte. Es fällt nur bei MP-Relationen auf, weil die in der Regel grösser sind. Könnte man sicher beheben, hab aber keine Lust und meine Lieblingsgebiete liegen natürlich nicht am Rand :wink:

23

Um zu ermitteln auf welcher Seite der Linie das “blau” sein muss, braucht man alle Nodes aller Linien des betreffenden Rings im Multipolygon. Das können durchaus hunderte Ways sein. Um die “Blau-Seite” in so einem worst-case zu ermitteln muss man entweder das ganze MP und alle seine Elemente laden oder sich durch den Ring hangeln und dabei massenweise einzelne Abfragen starten.

Nur die Coastlines haben dieses Problem mit den Ausschnitten nicht, da hier das Meer immer rechts von der Linie liegt.

Deshalb finde ich, dass das Coastline-Konzept ein gutes Vorbild für einen künftigen Flächentyp in OSM wäre. Sanderd17 hat da einen interessanten Vorschlag gemacht (https://wiki.openstreetmap.org/wiki/User:Sanderd17/Areas) in dem ich allerdings noch die Ringzuordnung streichen würde um eine sehr einfache Umstellung zu erreichen.

24

Inner/outer ja (hilft aber bei dem Problem nicht), sonst aber nichts.

Hier mal als Beispiel ein Ausschnitt aus dem Wald-MP Beispiel von Wulf4096 zum Laden in JOSM.

Der API “map” Aufruf dazu liefert diese Daten (gekürzt mit “…”):


<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="CGImap 0.6.1 (2515 thorn-01.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
 <bounds minlat="51.5431391" minlon="12.4093707" maxlat="51.5445418" maxlon="12.4128913"/>
 <node id="1393737328" ... lat="51.5420512" lon="12.4130913"/>
 <node id="1393737331" ... lat="51.5427865" lon="12.4115812"/>
 <node id="1393737333" ... lat="51.5428638" lon="12.4128149"/>
 <node id="1393737344" ... lat="51.5441064" lon="12.4111493"/>
 <node id="1393737347" ... lat="51.5446081" lon="12.4103899"/>
 <node id="5967994823" ... lat="51.5421207" lon="12.4140474"/>
 <node id="5967994824" ... lat="51.5442200" lon="12.4110233"/>
 <node id="5967994825" ... lat="51.5448483" lon="12.4098900"/>
 <way id="126558573" ...>
  <nd ref="5967994825"/>
  <nd ref="1393737347"/>
  <nd ref="5967994824"/>
  <nd ref="1393737344"/>
  <nd ref="1393737331"/>
  <nd ref="1393737333"/>
  <nd ref="1393737328"/>
  <nd ref="5967994823"/>
 </way>
 <relation id="8791274" ...>
  <member type="way" ref="632044723" role="outer"/>
  ...
  <member type="way" ref="632044725" role="outer"/>
  <member type="way" ref="125496335" role="inner"/>
  <member type="way" ref="125496331" role="inner"/>
  <tag k="landuse" v="farmland"/>
  <tag k="type" v="multipolygon"/>
 </relation>
 <relation id="8791300" ...>
  <member type="way" ref="632044729" role="outer"/>
  <member type="way" ref="126558573" role="outer"/>
  <member type="way" ref="632044702" role="outer"/>
  <member type="way" ref="632044774" role="outer"/>
  <member type="way" ref="632044776" role="outer"/>
  <tag k="landuse" v="forest"/>
  <tag k="type" v="multipolygon"/>
 </relation>
</osm>

Der eine selektierte Way ist Mitglied in zwei Multipolygon (MP) Relationen, die ebenfalls mitgeliefert werden. Daher deutet JOSM die Polygon-Mitgliedschaft am Way mit einem Innenrand an. Da aber nicht klar ist, wo die Polygone liegen, zeichnet JOSM den Innenrand mal auf der linken, mal auf der rechten Seite, vermutlich nach der Krümmung des Ways.

Das erfordert aber unter Umständen zusätzlichen Verarbeitungsaufwand bzw. manuelles Nachladen durch den Benutzer im Editor.

Deshalb die Überlegung, dass man die Information, auf welcher Seite des Ways das Polygon liegt, zusätzlich am Way haben müsste, um auch ohne Nachladen des kompletten Polygons auszukommen.

In unserem Beispiel könnte man dem Way hinzufügen, dass die Waldfläche in Wegrichtung links und die Ackerfläche rechts liegt. Hier mal zur Veranschaulichung in willkürlicher Notation von mir eingefügt:


 <way id="126558573" ...>
  ...
  <rel ref="8791274" side="right">
  <rel ref="8791300" side="left">
 </way>

Damit könnte JOSM den Innenrand auf beiden Seiten richtig zeichnen und theoretisch bei Auswahl eines MPs auch den Rand auf der entsprechenden Seite hervorheben. Oder beim Rendern einer Karte könnte man die Flächen entsprechend bis zur BBox füllen.

Abgesehen von der vagen Überlegung mit zusätzlicher Information am Way, driftet die Kritik in Verschwörungstheorien und Phrasen ab, das kann man nicht ernst nehmen.