Vollständigkeit eines Ways beim Datenextrakt

Hat keiner von den Tekkies hier eine Meinung bzw. Einwände dazu? Also klar freue ich mich auch über eine Bestätigung, wenn meine Ausführungen richtig sind. Aber noch mehr würde ich mich freuen, wenn mich jemand berichtigt, für den Fall, dass ich falsch liegen sollte. Ich lerne ja auch gerne noch etwas dazu.

Ich kenne das Problem bei komplexen MP, von denen nur einige Wege in einer BBox liegen. Wenn so ein MP zum Beispiel mehrmals die Grenzen der BBox "verläßt", womöglich auch noch an mehreren Seiten, dann kann man nicht so ohne weiteres ermittlen, wie die Wege zu verbinden sind.
Falls jemand auf die Idee kommt, dass man von einem Weg nur die Punkte braucht, die innerhalb einer BBox liegen, dann wird er natürlich jede Menge Probleme haben. Auch wenn man nur den nächsten Punkt ausserhalb hat, kann es wieder zu Problemen beim Zusammensetzen kommen.

Harald Hartmann wrote:

Hat keiner von den Tekkies hier eine Meinung bzw. Einwände dazu? Also klar freue ich mich auch über eine Bestätigung, wenn meine Ausführungen richtig sind. Aber noch mehr würde ich mich freuen, wenn mich jemand berichtigt, für den Fall, dass ich falsch liegen sollte. Ich lerne ja auch gerne noch etwas dazu.

Mir ist nicht klar, was Du meinst. Ein Extrakttool, das auf OSM-Basis arbeitet, muss ja immer Nodes mit extrahieren, und es ist nicht möglich, "nur das -" zu extrahieren ohne mindestens links und rechts davon einen Node zu haben.

Bye
Frederik

Wie geschrieben, es gibt ja jemanden mit einer anderen Meinung .. und ich bin nicht allwissend und könnte hier in der Tat ja etwas übersehen haben, an was ich noch nicht gedacht habe.

woodpeck wrote:

Ein Extrakttool, das auf OSM-Basis arbeitet, muss ja immer Nodes mit extrahieren,

Und damit ist doch dann immer noch die "Richtung" (also Vektor) gesichert und es gibt keinen Fall, in dem es wie eine "unendliche Gerade" verhält, oder?

Harald Hartmann wrote:

Und da man ja mindestens zwei Punkte (zumindest in diesem System) braucht, um eine Gerade zu bilden, wäre es ja in der Tat Käse, wenn ein Extrakttool nur den Teil zwischen C und D also das - liefern würde, oder liege ich da falsch?!

Es gibt Extraktoren, die einfach nichts liefern, wenn zwar der Weg den gewünschten Ausschnitt schneidet, aber keiner seiner Punkte im Ausschnitt liegt. Einfachstes Beispiel ist der Datenlayer auf osm.org: Mal eine Gegend suchen mit einem Weg, der weit auseinander liegende Punkte verbindet (weiter als ein Browserfenster gross ist), ganz weit reinzoomen und ein bisschen rumscrollen. Sobald keiner der Punkte im Fenster liegt, verschwindet der blaue Strich im Datenlayer.
Abgesehn von solchen exotischen Fällen... auch die Autoren von Extraktionsprogrammen kennen das Problem und bieten dem Anwender passende Optionen an, was mit angebissenen Flächen passieren soll.

Grüße,
Max (der noch grübelt, wie aus einem Vektor eine Gerade wird und was man mit der Information anfangen sollte, dass das mal die Grenze einer Fläche war mit innen und aussen)

maxbe wrote:

Max (der noch grübelt, wie aus einem Vektor eine Gerade wird und was man mit der Information anfangen sollte, dass das mal die Grenze einer Fläche war mit innen und aussen)

sorry, dass ich dich angesteckt habe ... aber mir geht's eben genauso ... und ich frage mich immer noch, ob ich etwas übersehe ... oder wie man dann zu so einer aussage kommt

maxbe wrote:

Mal eine Gegend suchen mit einem Weg, der weit auseinander liegende Punkte verbindet (weiter als ein Browserfenster gross ist), ganz weit reinzoomen und ein bisschen rumscrollen. Sobald keiner der Punkte im Fenster liegt, verschwindet der blaue Strich im Datenlayer.

Das betrifft ganz allgemein den "/map" API-Call, d.h. diese Sachen kann man gar nicht mehr sinnvoll in iD editieren: zoom man zu weit rein, sind keinerlei Punkte in der BBox und werden damit auch nicht von /map zurückgeliefert. Zoom man weiter raus, so hört iD recht schnell damit auf, überhaupt irgendwelche Daten abzurufen.

Noch ein ergänzendes Zitat:

addresshistory*org wrote:

Wenn das MP Schema nicht passt, müssen wir eben das MP System verbessern. Zum Beispiel wo bei einer unendlichen Gerade, das Innere, und wo das Äußere ist. Es kann doch nicht sein dass sich dies lediglich mittels geschlossenem Ring erschließt

Ich vermute es geht hier nicht um die Vollständigkeit eines Ways, sondern um ein unvollständig geladenes/extrahiertes Multipolygon mit mehreren äußeren (outer) Ways und was es bräuchte, um damit trotzdem noch was anfangen zu können.

Der Ausdruck "unendlichen Gerade" ist vielleicht etwas unglücklich und irreführend, ich verstehe das so:

␣␣␣␣␣␣␣␣x
+----|----+
|␣␣␣␣|␣␣␣␣|
|␣␣␣␣x␣␣␣␣|
|␣␣␣␣|␣␣␣␣|
+----|----+␣bbox
x
^␣way

Ein Way als Teil eines multi-outer MPs schneidet das umgebende Rechteck (Bounding Box, bbox) eines geladenen/extrahierten Kartenauschnitts in zwei Teile. Ohne die fehlenden Ways ist aber nicht klar, ob das Polygon die rechte oder linke Hälfte umschließt (oder sich der Way in gerader Richtung quasi unendlich fortsetzt).

Mit einer zusätzlichen Information am Way, dass die Innenseite des Polyons rechts des Ways liegt, könnte man die rechte bbox-Hälfte entsprechend füllen.

So was Ähnliches gibt es beim natural=coastline Tag:

Definitionsgemäss liegt dann das Land (weiss) links von der Linienrichtung, das Meer (blau) rechts davon.

Dadurch kann man z.B. das Meer in einem Kartenausschnitt an der Küste rendern, ohne das komplette Ozean-Polygon laden zu müssen.

ikonor wrote:

Der Ausdruck "unendlichen Gerade" ist vielleicht etwas unglücklich und irreführend, ich verstehe das so:

␣␣␣␣␣␣␣␣x
+----|----+
|␣␣␣␣|␣␣␣␣|
|␣␣␣␣X␣␣␣␣|
|␣␣␣␣|␣␣␣␣|
+----|----+␣bbox
x
^␣way

Und man kann Pech haben, dass der Way überhaupt keinen Node innerhalb der BBOX hat:

␣␣␣␣␣␣␣␣x
+----|----+
|␣␣␣␣|␣␣␣␣|
|␣␣␣␣|␣␣␣␣|
|␣␣␣␣|␣␣␣␣|
+----|----+␣bbox
x
^␣way

Was dann?

Ok, ein konstruiertes Beispiel, aber in Amiland theoretisch möglich, wo sich manche Highways endlos geradeaus durch die Prärie ziehen. Oder bei deren linearen Grenzstücke der Bundesstaaten. Oder bei den bei uns so unbeliebten Richtfunkstrecken. ...

Gruss
walter

Tatsächlich passiert das ziemlich oft mit Wegen, die in der Nähe der Ecke der BBox verlaufen. Da kann dann schon leicht mal kein Knoten in der BBox sein, wohl aber der Weg selbst.

wambacher wrote:

Ok, ein konstruiertes Beispiel, aber in Amiland theoretisch möglich, wo sich manche Highways endlos geradeaus durch die Prärie ziehen

Nein, ist nicht theoretisch, kommt gar nicht mal selten vor: https://tools.geofabrik.de/osmi/?view=g … g_segments

wambacher wrote:

Und man kann Pech haben, dass der Way überhaupt keinen Node innerhalb der BBOX hat: [...] Was dann?

Dann hilft aber auch keine "--complete-multipolygons" Option, wenn ein Extrakt-Tool solche Ways nicht erkennen kann? Das heißt man hat generell Pech und der Ansatz wäre nur deswegen nicht schlechter.

Für das tool splitter (1) habe ich einiges an Code gebraucht, um solche Wege zu erkennen. Im Prinzip kann man sich die echte BBox als Mitte in einem 3x3 Raster vorstellen, wobei die anderen 8 Boxen den Rest des Planeten abdecken. Dann ermittelt man zu jedem Weg in planet.osm, in welchen Boxen er Punkte hat. Der Großteil aller Wege wird nur in einer Box auftauchen, die wenigen anderen müssen dann genauer untersucht werden. Deutlich einfacher, aber nicht vollkommen ist die Variante, die bbox auf allen Seiten um ein paar hundert Meter zu vergrößern in der Hoffnung, dann die gewünschten Punkte zu finden.

(1) http://www.mkgmap.org.uk/doc/splitter.html

GerdP wrote:

Da kann dann schon leicht mal kein Knoten in der BBox sein, wohl aber der Weg selbst.

Ah ok. Macht aber für die Visualisierung (Rendering) keinen Sinn und somit braucht man auch nicht über "Geraden" reden.
Für statistische Zwecke mag es aber noch reichen, wenn einfach nur die Tags vom Way kommen.

Harald Hartmann wrote:

[...] braucht man auch nicht über "Geraden" reden.

Ich denke, Du machst das zu sehr am Begriff der "Geraden" fest, was nach meiner Interpretation nur ein vereinfachtes Bild für ein unvollständiges Polygon sein soll.

Ja, dass ist mir schon klar .. ich will ja auch darauf hinaus, dass es aber ja nicht einmal das ist.

Wenn ich keine Knoten habe, habe ich letztendlich nicht mal mehr irgendeine "Geometrie" und somit auch kein "unvollständiges Polygon", sondern einfach nur irgendwelche beschreibende Metadaten von etwas. Und somit finde ich damit auch keinen Anwendungsfall von Innen/Außen, links/rechts, oder sonst irgendwas zu sprechen.

Wenn ich aber in der Tat ein "unvollständiges Polygon" habe, also mit wenigsten ein paar Knoten usw., dann habe ich auch eine Geometrie und somit auch wieder die Information zumindest darüber, was links/rechts ist, da man die Richtung dieses Polygons kennt.

Harald Hartmann wrote:

GerdP wrote:

Da kann dann schon leicht mal kein Knoten in der BBox sein, wohl aber der Weg selbst.

Ah ok. Macht aber für die Visualisierung (Rendering) keinen Sinn und somit braucht man auch nicht über "Geraden" reden.

Ich finde, es gerade für das Rendering relevant. Wenn die BBox relativ klein ist, kann auch mal ein natural=water Weg drum herum verlaufen.
Dessen Blau möchte ich dann schon haben, wenn ich eine kleine Insel in einem großen See anschaue.

In diesem Fall muss aber dann das Extraktool oder der Renderer "über" die BBox hinausschauen und sich die zwei nötigen Knoten (Nodes) holen/ermitteln. Und ich wiederhole mich ja ungern, aber in diesem Fall wäre dann auch wiederrum die Fliessrichtung des Wasser sofort und unmittelbar darstellbar. Sorry, bin irgendwie gerade von einem Fluss ausgegangen und nicht von einem See, habe ich irgendwie überlesen

Nachtrag: aber trotzdem weiß man dann die Richtung, was links und rechts ist und kann somit die entsprechende Ecke "blau" füllen. Und ich sag/behaupte ja nicht, dass das dann trivial ist.

Harald Hartmann wrote:

Wenn ich keine Knoten habe

Das ist hier - glaube ich - nicht der Punkt.

Harald Hartmann wrote:

Wenn ich aber in der Tat ein "unvollständiges Polygon" habe, also mit wenigsten ein paar Knoten usw., dann habe ich auch eine Geometrie und somit auch wieder die Information zumindest darüber, was links/rechts ist, da man die Richtung dieses Polygons kennt.

Nein, die Richtung eines Polygons kann man aus einem Teilstück nicht zwingend ableiten, oder wie meinst Du das? Angenommen der gerade Way mit drei Knoten (von unten nach oben) in meinem Beispiel aus #9 ist eine Kante einer rechteckigen Fläche. Da kann man nicht sagen, ob das Rechteck nach links oder rechts geht.

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.

Harald Hartmann wrote:

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?

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 😉

Harald Hartmann wrote:

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?

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/Use … rd17/Areas) in dem ich allerdings noch die Ringzuordnung streichen würde um eine sehr einfache Umstellung zu erreichen.

Harald Hartmann wrote:

wenn dieser Abschnitt eines Ways ein Member einer MP ist, dann kann man aber trotzdem entsprechende Dinge (inner/outer) ableiten [...]

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.

Harald Hartmann wrote:

[...] bzw. in einem zweiten Schritt nachermitteln, oder?

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.

Harald Hartmann wrote:

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.

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.