Hi,
ich möchte gerne die fehlenden Fluss Stücke die per Relation zusammengebaut werden als Polygon zu bilden.
Jetzt habe ich aber das Phänomen wenn ich mir die einzelnen Teilstücke anschaue sehen die erstmal so aus als wären sie geschlossen. Wenn ich mir aber nun jeweils den ersten und letzten Punkt ansehe kann man erkennen das die nicht genau übereinstimmen.
Woran kann das liegen ?
Ich habe die Reihenfolgen kontrolliert das stimmt mit der XML Def. überein.
Das sind Rundungsfehler: In den OSM-Daten sind die Endkoordinaten der Wegstücke jeweils identisch (schau dir das XML dieser Relation an) und passen somit 100%-ig aneinander.
<köttelanspitz>In unserer Toolchain (osmosis → osm2pgsql → PostGis) ist das kein Problem. Irgendwo (osm2pgsql?) wird das ausgebügelt. </köttelanspitz>
Jetzt im Ernst: Ich könnte mir vorstellen, dass solange wie irgendwie möglich, mit Strings für die Koordinaten gearbeitet wird. Es müssen ja nur gleiche Koordinaten gesucht werden, damit die passenden zueinander finden.
Gruss
walter
Hm ok … ich importiere die Koordinaten als Double Datentyp.
Wie macht ihr das denn bei euch ?
Gruß,
Markus
Ich: garnicht. Ich überlasse das den Tools. Und soweit mir bekannt ist, gibt fast niemanden hier, der das selber macht. Die Mehrzahl verwendet die Overpass, die aber “nur” bereits importierte Daten abfragt oder Datenbanken, die mit osm2pgsql erstellt wurden.
User gehrke macht das wohl händisch und ich hab das früher auch so gemacht.
Tip: Stell auf Strings um, bis du die Ways zu einem Polygon/Multipolygon zusammengeklauberst hast, danach geht es mit Double weiter.
Gruss
walter
Ach ja 
ich benutze eine Library für .NET (SpalialLite http://spatial.litesolutions.net/)) um mir das arbeiten mit den PBF Dateien zu erleichtern… die gibt mir die Koordinaten schon so blöd umgerechnet. Da muss ich noch mal ran …
Danke für die Hilfe !
Aber Warmbacher ich habe doch noch mal eine Frage …
unter dem Link http://www.openstreetmap.org/api/0.6/relation/3354679/full
kann man ganz gut sehen das der 2. Weg den selben Startpunkt hat wie Weg 1. Müsste der 2. Weg nicht den Endpunkt von Weg 1 als Startpunkt haben ?
Gruß,
Markus
Nee, du musst alle ways und beide endnodes prüfen. Die sind totsl durcheinander.
Mehr spätrr, bin einkaufen
W.
Oh Ja bitte erkläre es mir…
Ich dachte da im Wiki etwas von einer sortierten Liste stand das ich mich daran halten kann.
“Eine Relation ist eines der grundlegenden Datenelemente, auf denen OpenStreetMap aufgebaut ist. Eine Relation besteht aus einem oder mehreren Attribute und einer sortierten Liste von Datenelementen. Als Datenelement können Punkte, Linien und Relationen in die Relationsliste aufgenommen werden. Jedem Datenelement kann auch eine Rolle (engl. role) zugewiesen werden, die beschreibt, welche Bedeutung das Datenelement in der Relation hat.”
Das müsste eher “sortierbar” heißen.
Sortiert ist sie i.a. erst, wenn man im Relationseditor auf “Sortieren” klickt. Erst dann sieht man z.B. ob die ways geschlossen sind.
Ok, ich versuche das grade mal an dem oben genannten Ralations beispiel aufzuschreiben.
Die Relation fängt an mit
So nachdem ich das jetzt gemacht habe sehe ich das es immer noch nicht passt 
Hilfe … nach welchen Kriterien wird denn wie sortiert ?
Gruß,
Markus
-snip-
muß die ganze Sache nochmals überdenken. Das sollte mit PostGis eigentlich einfacher gehen - und du sagst ja “was PostGis kann, kann MSSQL auch”, oder?
Ich melde mich nochmals.
Gruss
walter
Ja ich bin mir fast zu 100 % sicher 
Cool danke für die mühe !
Ich schwanke noch ein wenig (nee, kein Alk) zwischen der reinen GIS-Lösung und dem Zusammenpfriemeln.
Bei der GIS-Lösung nimmt man “einfach” alle Ways und wirft diese GIS vor mit der Aufgabe “Mach mir bitte ein Polygon daraus”. Das geht prinzipiell sehr gut allerdings haben wir wieder das komische Rundungsproblem - oder auch nicht solange alle Nodes immer die gleiche krumme Koordinate bekommen. Gibt es denn keinen Distanzfaktor, der z.B. sagt: alle Koordinaten im Umkreis von 1 cm oder kleiner sind identisch?
Das Zusammenpfriemeln könnte auch gehen, erscheint mir nur ziemlich unelegant. Ich hab das früher so gemacht., als ich PostGIS noch nicht so gut kannte - und jetzt brauch ich es nicht mehr, da osm2pgsql für mich den Job macht. Daher nur ein Versuch der Beschreibung:
Mein damaliges Verfahren:
Damit müssten alle Ways verbraucht sein, ansonsten ist das MP defekt (Ways zuviel). Es können aber auch Ways fehlen oder nicht miteinander verbunden sein.
Dann knallt es fürchterlich und du muss das irgendwie abfangen.
Gruss
walter
ps: Glaubst du mir langsam, dass das ganze nicht trivial ist? Und von den möglichen Geometriefehlern wie Überschneidungen oder Self Touching Ways haben wir noch garnicht gesprochen.
Es bedeutet, dass die Reihenfolge der Member eine Eigenschaft ist und also mit abgespeichert wird. Bei mathematischen Relationen ist das z.B. anders, es ist also eher eine “sortierte Liste” als eine “Relation”. Erst seit Relationen als sortierte Objekte gelten, kann der Reihenfolge in der Beschreibung des Relationstyps eine Bedeutung gegeben werden. (kann, muss aber nicht)
Bei den neuen ÖPNV-Routen-Relationen hat die Reihenfolge eine Bedeutung. Z.B. wird die Reihenfolge der Haltestellen durch ihre Reihenfolge in der Relation angegeben (und der Sortierknopf macht alles kaputt). Bei den alten ÖPNV-Relationen bedeutet die Sortierung dagegen nichts und man gab die Reihenfolge durch Rollen wie “stop:4” oder “backward_stop:17” an.
Bei Multipolygonen hat die Reihenfolge keine Bedeutung.
Weide
Das ist absolut korrekt. Weil aus “GIS-Sicht” ein OSM-Multipolygon eine Geometrie ist, die aus mehreren Linestrings (Osm-Ways) besteht, die geschlossene Polygone bilden (sollten), kann jedes GIS-System wie PostGis und sicher auch die entsprechende MSSQL-Komponente diese Geometrie ohne weitere Informationen selber zusammenstellen.
Keine Member-Rollen (Inner/Outer) oder gar eine Sortierung ist dafür notwendig. Reine Geometrie.
Gruss
walter
Das mit den falschen Koordinaten habe ich gelöst :-). Diese Problematik habe ich also nicht mehr.
Sollten Ways fehlen würde ich diese Geometry auch nicht anzeigen … richtig ?
Natürlich glaube ich dir das Auch schon beim ersten mal … aber “nicht trivial” bedeutet ja nicht unschaffbar.
Über die Self Touching Ways und Überschneidungen bin ich schon gestolpert … da bietet mir aber der SQL Server eine Funktion an um das zu korrigieren. Das klappt bisher.
Vielleicht noch am Rande: Mir geht´s bei dieser ganzen Problematik mit den Relationen im Moment nur um alle Geometrien die mit Wasser zu tun haben. Das Problem ist das viele der Flüsse die als (M)Polygon gemappt sind halt nur über eine Relation zusammengebaut werden.
Ich würde dann noch ein 3a. einbauen.
Wenn ich das verfahren an unserer Beispiel Relation von oben anwenden würde und mit Way 249450576 beginne würde ich beim 3. Way, nach 208119426 keinen passenden Way finden. Hier drehe ich dann Way 204052147 einmal um und nun passt auch der 4. 249450521 und das Polygon ist nun geschlossen und kann erstellt werden.
Sehe ich das richtig so ? Irgendwelche Einwände.
@Warmbacher: Ich muss natürlich zugeben das der MSSQL Server von seinen GIS Funktionen noch nicht so weit ist wie ein PostGIS :-). Aber ich denke mit einer Userdefined CLR geht das nun.
Viele Grüße,
Markus
WayID StartNode EndNode
Klasse! was war es denn?
Ja, hängt ein wenig davon ab, wie “dein” Gis auf unzulässige oder defekte Geometrien reagiert. PostGis gibt dann ganz einfach für das zu erzeugende Polygon NULL zurück und du kannst dich dann auf die Suche machen 
Stimmt, haben unsere Leute ja auch hinbekommen. Trivial sollte bedeuten: “Nicht mal so eben zusammengezimmert”
Prima. und die wäre?
Schwierig zu schreiben und noch schwieriges zu verstehen: GIS-M(Polygone) sind nicht gleich OSM-M(Polygone). Die heissen zwar ähnlich, werden aber sehr oft durcheinander geworfen. daher muß du in so einer Diskussion eigentlich immer klarstellen, welche Umgebung (GIS oder OSM) du meinst.
Ich muß wohl endlich mal eine Gegenüberstellung der Begriffe erstellen:
sorry, zu komplex für jetzt. Das ist was fürs Wiki - wenn es das so noch nicht geben sollte.
tl;dr: OSM ist nicht OGC-Konform
Gruss
walter
Diese 3. Library Spatiallite hat die Koordinaten so umgerechnet. Wenn ich allerdings X und Y angeschaut habe standen die richtig drin. Mit diesen Koordinaten habe ich dann im Textformat weitergemacht bis ich die endgültige Geometrie zusammengebaut habe. Das hat meine Probleme hier gelöst.
Man kann auf eine Geometrie oder Geografie ein .isValid() feuern und falls nicht mit einem .MakeValid() das ding grade rücken. Hat bis jetzt funktioniert :-).
Ich baue mir nun mal so einen Relation verwurster MElde mich wieder.
Greetz,
Markus
Ok, kann PostGIS auch - MakeValid hab ich nur noch nicht verwendet:
http://postgis.net/docs/ST_IsValid.html und http://postgis.net/docs/ST_MakeValid.html
Gruss
walter