wir haben hier in Österreich wirklich hervorragende Quellen, das ist richtig. Und deshalb stimme ich zu, dass diese Erfahrungen nicht auf D übertragen werden könne. Aber darum geht es hier nicht, es geht um die Eintragungen im Wiki.
Es würde mich interessieren, wie viele von diesen 50 wirklich aktiven Mappern zu den Ring-Zeichnern bzw. zu den gestückelten Zeichnern zählen. Denke mal das Ergebnis würde relativ klar ausfallen, würde mal vermuten, es geht in Richtung Ring-Zeichnern.
Experimenteller Freiraum ist ja OK, aber ich wäre auch dafür, dies wie von Pfad-Finder dann auch im Wiki klar zu erwähnen und nicht das Ganze eher vage zu belassen. Genau wegen diesen vagen Vorgaben entstehen doch solche “Probleme” und Uneinigkeiten und das wollen wir doch alle nicht.
Mich würde auch interessieren, wie weit verbreitet diese speziellen Relations-Polygone sind… Ich kann mir gut vorstellen, daß es nur einige Hotspots sind, die von wenigen oder einzelnen Mappern bearbeitet werden…
Eine Overpass-Abfrage zur Identifizierung von Highway-Abschnitten, die Teil einer Relation type=multipolygon sind hab ich mir mal erarbeitet:
Wenn ich die Diskussion in diesem Thread nochmals überfliege, frage ich mich, ob wir nicht zumindest einen Teil-Konsens haben: nämlich, dass man die Verwendung von Straßenabschnitten, Wasserwegen etc. als MP-outer- oder -inner-Elemente möglichst vermeiden sollte. Denn dafür hat, soweit ich sehe, keiner der Mitdiskutanten plädiert (oder liege ich da falsch?). Sogar wenn wir über gestückelte MPs geteilter Meinung bleiben, könnten wir uns doch zumindest darauf einigen, dass vor allem die aus Straßenabschnitten, Wasserwegen etc. gestückelten MPs große Probleme verursachen (kreuzschnabel hat das mehrfach in verschiedenen Threads sehr anschaulich beschrieben) und man daher von ihnen abraten sollte – auch im Wiki.
Früher war ich ein “Stückler”, d.h. ich habe jeden noch so kleinen Flächenumfang zerlegt, um die Teilstücke dann für die anderen Flächen zu verwenden. Grund dafür war die Regel: “Es darf nur einen (Way) geben”. Das Gebiet um meinen Wohnort sieht immer noch entsprechend aus. (*)
Irgendwan vor ca 2 Jahren ist der Cent gefallen und ich habe die massiven Probleme erkannt, verstanden und was am wichtigsten ist: akzeptiert. Dazu kam noch die Erkenntnis, dass “gestückelte Multipolygone” im OGC-Umfeld die absolute Ausnahme sind und so gut wie nie verwendet werden. Dieses schaffte auch für Nicht-OSMler riesige Probleme, mit “unseren komischen Daten” was vernünftiges anzufangen.
Gruss
walter
*) Ich versuche das nach und nach abzubauen, aber einfach ist das wirklich nicht.
Ich weiss nicht, ich finde solche Benimmregeln im Wiki immer ein bisschen doof. Also ja, man kann sagen: “Allgemein wird versucht, X statt Y zu tun, weil mit Y eine Reihe von Problemen verbunden sind.”, aber alles, was darüber hinausgeht, ist m.E. im Wiki fehl am Platz.
Wasserwege oder Küstenlinien als Teil eines outer Rings von Grenzrelationen sind gang und gäbe, aber ich nehme an, die hattest Du hier nicht mit-gemeint, als Du über Multipolygone sprachst?
osm2pgsql wandelt gestückelte MP natürlich in “richtige” Polygone nach dem OGC-Standard um, damit sie von allen Programmen verarbeitet werden können. Dazu gehören u.A. auch Mapnik, das **kein OSM-Programm **ist. Nur dadurch können diese Dinger überhaupt gerendert werden. Oder man nehme Qgis, OpenJump, GeoServer, Openlayers, Leaflet, … da gilt genau das gleiche.
Für diese Umwandlung muss osm2pgsql oder auch andere DB-Loader/Konverter alle Teile eines MP zusammensuchen, sortieren, danach jeweils Start und Ende der passenden Ways zusammenfügen (Ringe bilden) und das dann als OGC-Objekt abspeichern.
Hier mal ein aktueller Auszug aus dem Log:
[2016-01-22 12:13:02] 2050 pid 1845 still running
Process 6 finished processing 37 relations in 35 sec
Maximum node in persistent node cache: 3959324671
Process 1 finished processing 38 relations in 40 sec
Maximum node in persistent node cache: 3959324671
Process 5 finished processing 37 relations in 41 sec
Maximum node in persistent node cache: 3959324671
Process 0 finished processing 38 relations in 52 sec
Process 3 finished processing 38 relations in 62 sec
Maximum node in persistent node cache: 3959324671
Process 2 finished processing 38 relations in 65 sec
Maximum node in persistent node cache: 3959324671
Process 4 finished processing 38 relations in 68 sec
...
All child processes exited
264 Pending relations took 68s at a rate of 3.88/s
...
Osm2pgsql took 97s overall
[2016-01-22 12:13:41] 1845 updatepl done RC=0
Hier wurden 264 Relationen von 7 Prozessoren parallel verarbeitet. 35-68 Sekunden pro CPU, 1-2 Sekunden pro Rel. Und das für die Daten der letzten 2 Minuten. Der gesamte Block hat 97 Sekunden gebraucht, also zum Glück etwas weniger als die 120 Sekunden der Daten. Oft dauert die Verarbeitung aber länger als das Zeitfenster der Daten und dann hinkt die DB teilweise heftig hinterher.
Gestern Nacht fast 2 Stunden und zur Zeit die normalen 120 Sekunden.
Nein, natürlich nicht. Es geht ja in diesem ganzen Thread nicht um Grenzrelationen, sondern um Otto-Normal-MPs wie Waldflächen etc. (Das dachte jedenfalls ich bisher.)
Ich habe eigentlich nur versucht, wenigstens eine Teil-Teil-Teil-Einigung vorzuschlagen, und diese daher absichtlich sehr schwach formuliert, eben als “Benimmregel” (wenn man es so nennen will; ich hätte “Tip” oder “Empfehlung” gesagt) statt als Vorschrift. Wenn aber auch das schon zuviel ist und ich schon für diesen Vorschlag gleich Haue bekomme, verlässt mich irgendwie langsam der Mut. Immerhin, auch “Allgemein wird versucht …” wäre doch ein Fortschritt; ich schließe mich also auch einer solchen Formulierung gerne an.
Also finde es auch ein wenig doof wenn “Einzelne!” die Karte mit komplexen MPs komplett versiegeln.
Da geht dann keiner mehr rann, aber ist dass ev. das Ziel gewisser Leute…
Ich schließe mich dem an.
In meinem Bereich Bezirk Kitzbühel gibt es in Bezug auf, für MP- Relationen gestückelten Wegen kein Problem. In anderen Regionen lässt sich das relativ leicht beseitigen. http://overpass-turbo.eu/s/dXg
Ich gebe ganz offen zu dass ich früher auch ein Zerstückler von Wegen war. Genauso wie das Ring Zeichnen- ist für mich heute das Zerstückeln von Wegen Vergangenheit.
Als das muss ich vehement verneinen. Für mich ist das Zeichnen von überlagerten Linien (= Ringe Zeichnen) eine unnötige Redundanz.
Speziell wenn es ins Detail geht, wie zum Beispiel wenn Gebäude sich über mehreren Geschssen- erstrecken, führen überlagerte Ringe ins pure Chaos.
MP-Strukturen gehört meiner Meinung nach klar die OSM-3D Zukunft, daher sollten diese aktuell experimentell geduldet werden.
das ein Feldweg in einer Lehmgrube ein service ist -
eine Straße kein permissive ist, weil Wohnhäuser an dieser stehen (Privatstraße)
ein Gebäude nicht aus mehreren Gebäude besteht, die alles aber Einzelhäuser sind (Reihenhaus)
dann mach sich OSM selbst kaputt, weil es dann sinnlos ist Leute für OSM vor Ort zu gewinnen.
Ich dulde 3-D-Relationen (habe sie testweise schon probiert) - aber alle Häuser in 3-D zu verwandeln ist in OSM so nie möglich. Wenn es eine Region gibt (Passau) die so etwas macht ist es für mich gut.
M.E. sollte gerade OSM die Informationen vor Ort besser nutzen und versuchen mehr Mapper für die Aktualisierung (und wenn es nur ihr Gewerbe ist) zu interessieren, dies ist aber nur möglich mit einfachen “Einstiegsmöglichkeiten”. Und wenn jemand seinen kleinen shop als Supermarkt einträgt, kann man ihn Wege zeigen, wie es besser (richtiger) ist und wie er seinen “shop” auf seiner Internetseite darstellen kann. Aber keiner findet es Klasse wenn sein shop auf einmal nicht mehr da ist, weil jemand aus der “Ferne” es (automatisch oder nicht) umtaggt.
Und Redunanzen sind für einen Anfänger einfacher als Relationen …
(Ich weiß OSM ist eine Anarchie - hat man mir gesagt)
Sorry, aber du kennst dich nicht wirklich aus welche Datentypen und Topologien es gibt, die in Geodatenbanken gespeichert werden (können) und was wir mit OGC-Konformität meinen?
Da hast Du leider recht. Wir können das Thema gerne fortführen, aber die Frage ist, wie wir zu konstruktiven (Teil-)Ergebnissen kommen. Hm …
Ich hatte oben ja mal versucht, wenigstens einen Minimal-fast-Konsens zu formulieren. Was haltet ihr denn davon, wenn wir so etwas (meinetwegen rein deskriptiv, damit sich niemand ermahnt vorkommt) ins Wiki schreiben: “Viele deutschsprachige Mapper sind der Meinung, dass Multipolygone zu vermeiden sind, deren Elemente aus Abschnitten von Straßen, Wasserläufen etc. zusammengestückelt sind. Als Gründe dafür werden angeführt: * (hier bitte Liste anfügen; Gründe wurden ja oft genug im Forum genannt).”
Aber wahrscheinlich geht auch das irgendjemandem zu weit?
Ja, frage ich mich auch. Eigentlich würde ich dem Multipolygon-Freak, dessen Wiki-Änderungen der ursprüngliche Gegenstand dieses Threads waren und der in der zitierten Diskussion mit allen Mitteln seine reine Lehre gegen die Angriffe der Realität verteidigt, empfehlen, lieber ein Buch zu schreiben, denn da hat er mehr Platz und es redet ihn keiner mehr drein. Darin kann er dann auch gerne seitenlang über hemisphärenüberspannende Maximal-MPs etc. spekulieren. Titelvorschläge: “The Zen Of OSM Multipolygons” oder “The Bible of Polygones” oder so. Vielleicht nimmt O’Reilly es ins Programm; Cover-Motiv (da O’Reilly-Bücher ja traditionell Tierbilder als Cover haben): der Uroboros. Und wir könnten dann hoffentlich mal das Wiki aufräumen und uns fragen, wie wir verständliche, editierbare und halbwegs OGC-konforme MPs hinbekommen …
+1
Jedoch kann ich mir nicht vorstellen, dass es speziell für MP deusche Extrawürste geben muss. Argumente gegen die Stückelei und das Kleben an highways gibt es ja genug. Und einige Zerstückelungsfanatiker können doch nicht allen anderen die Arbeit erschweren. Bei Grenzen sehe ich das ja noch ein. Schaut euch mal den Kaiserstuhl an und stellt euch vor, dass da mal wieder die Weinbergterrassen umgestaltet werden.
(*)