Wenn ich osmfilter und Co nutze, wird doch meistens/immer ein darin befindlicher Way trotzdem komplett und vollständig im Extrakt enthalten sein, auch wenn der Way über die Grenze geht, oder? Bei Members einer Relation und geschlossenen Polygonen ist das ja anders, da gibt es ja meist genug Optionsmöglichkeiten dazu, wie damit umgegangen wird.
Aber auch wenn jetzt ein Extrakttool einen Way (kann auch ein geschlossenens Polygon sein) mit den Nodes A-B-C-D-E-(A) holt und den tatsächlich teilen sollte, z.B. C-D, dann bleibt doch damit die “Richtung” erhalten, oder irre ich mich da? 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?!
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.
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.
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.
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?
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)
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
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.
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.
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. …
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.
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.
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.
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.
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.
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.