Muss das sein?
https://www.openstreetmap.org/#map=19/51.14021/7.21350
???
Ist doch nicht schwer zu erkennen, dass jede Menge Gebäude per MP erfasst sind. Overkill/Wahnsinn.
Ja vor allem teilen sich die Gebäude und die Fussgängerzone schön artig die Linien:
https://www.openstreetmap.org/relation/2177226
(z.B. https://www.openstreetmap.org/way/178062446))
was sicher inhaltlich vollkommen korrekt gemappt ist, aber wieder die Wartbarkeitsfrage aufwirft.
Christoph
Hallo,
ich persönlich bin ja kein Multipolygon-Hasser (eher ein Freund, wenn es um Landuse geht), aber das genannte Beispiel ist wirklich Overkill. Bei Gebäuden hat es sich eingebürgert, dass sie nur dann als Multipolygon erfasst werden, wenn das Gebäude einen Innenhof (also ein Loch) hat.
Kann es sein, dass der Mapper, der diese Gebäude eingetragen hat, auf dem Vermessungsamt oder bei einem Öffentlich bestellten Vermessungsingenieur arbeitet? Im ALKIS (Amtliches Liegenschaftskataster-Informationssystem) gibt es nämlich einen Datentyp der unseren MPs sehr ähnlich ist. Gebäude, Flurstücke und Landnutzung werden dort (zumindest in Baden-Württemberg) als Multipolygon erfasst. Deren Erstellung ist übrigens eine noch schlimmere Klick-Orgie als in JOSM. 
Fußgängerzonen und Gebäude sind etwas, wo es, anders als bei Landnutzung, fast keinen Interpretationsspielraum gibt (maximal Dachkante vs. aufsteigendes Mauerwerk). Um Neulingen das Leben nicht allzu schwer zu machen, sollte man Gebäude nur wenn nötig als Multipolygon erfassen. Multipolygone erhöhen für Datennutzer nämlich den Verabeitungsaufwand und wenn alle Gebäude in Deutschland Multipolygone wären, dann …
Solange du kein inhaltlichen Fehler in diesem Gebiet findest (z.B. Neubauten/Abrisse), würde ich nichts ändern und mich an deiner Stelle mit “produktivem” Mappen beschäftigen. Wenn du jedoch in diesem Gebiet etwas ändern möchtest, dann steht es dir IMHO frei, das Mapping auf klassisches Gebäudemapping umzustellen. [3]
Das intensive Verwenden von MPs wie im obigen Fall hat den Nachteil, dass Newbies, die mit Primitveditoren (iD & Co.) [1] arbeiten, unabsichtlich kaputte MPs verursachen. Gebäude sind nämlich etwas, was Newbies und Nicht-JOSM-Nutzer, meiner Erfahrung nach, besonders gerne editieren. [2]
Viele Grüße
Michael
[1] Sorry, aber Editoren ohne Qualitätssicherungsmechanismen sind einfach primitiv.
[2] eigene Erfahrung diverser Nachmittage mit dem OSMI-Multipolygonview
[3] Aus selbigen Grund trenne ich gerade entlang von Bahnstrecken in Mecklenburg-Vorpommern die Landnutzungsflächen von Verkehrswegen, weil ich die ÖPNV-Routen aktualisiere und auf Public Transport 2 “upgrade”.
Für dich und andere semi-professionelle Insider ist es sicher kein Problem, mit einer hingeworfenen Abkürzung und einem Link sofort das Corpus Delicti zu erkennen. Für all die anderen, unbedarften Forenteilnehmer wären ein weniger aufgeregter, dafür mehr aussagekräftiger Betreff und/oder eine kurze Erläuterung im Beitrag sicher hilfreich. Es sei denn, diese Leute sind nicht die Zielgruppe deines Beitrages.
wenn man über seinen Tellerrand blickt, ist das garnicht so unüblich. Siehe Salamanca in Spanien: https://www.openstreetmap.org/#map=14/40.9629/-5.6668
@Nakaner: Ob die da wohl auch ALKIS haben?
Ich würde das auch so entfernen. Relationen belasten die OSM-Server und andere Auswerter unserer Daten massiv; unnütze Beispiele wie die hier sollten demnach weg.
Dann mach mal. Die Freude der spanischen Kollegen wird riesengroß sein.
Nur so nebenbei: Wird sauber gerendert und Nominatim und andere vernünftige Software hat auch keine Probleme damit.
(hab ich die Ironie-Tags übersehen?)
Diese Theorie kannst du sicher an Hand von Daten, Fakten und Beispielen untermauern.
Ich spiele jeden Tag den aktuellen Planet ein und werfe mal einen Blick ins gestrige Logfile:
Phase 1:
00:01:33 [0000] startNodes()
00:02:09 [0000] 10,000,000 nodes, max id: 35,292,019, usage: 28%, 278,636 nodes/sec.
00:02:45 [0001] 20,000,000 nodes, max id: 48,049,640, usage: 42%, 275,759 nodes/sec.
[...]
02:39:42 [0158] 2,630,000,000 nodes, max id: 3,216,297,812, usage: 82%, 277,164 nodes/sec.
02:40:19 [0158] 2,640,000,000 nodes, max id: 3,227,938,386, usage: 82%, 277,134 nodes/sec.
02:40:39 [0159] 2,646,251,183 nodes, max id: 3,235,210,462, usage: 82%, 277,220 nodes/sec.
02:40:39 [0159] endNodes()
02:40:39 [0159] startWays()
02:40:54 [0159] 1,000,000 ways, max id: 5,544,800, usage: 18%, 62,727 ways/sec.
02:41:08 [0159] 2,000,000 ways, max id: 6,737,502, usage: 30%, 67,315 ways/sec.
02:41:23 [0159] 3,000,000 ways, max id: 8,031,732, usage: 37%, 67,474 ways/sec.
[...]
03:37:46 [0216] 263,000,000 ways, max id: 315,810,333, usage: 83%, 76,732 ways/sec.
03:37:54 [0216] 264,000,000 ways, max id: 316,895,310, usage: 83%, 76,848 ways/sec.
03:37:57 [0216] 264,353,272 ways, max id: 317,272,397, usage: 83%, 76,884 ways/sec.
03:38:02 [0216] endWays()
03:38:02 [0216] startRelations()
03:38:10 [0216] 100,000 relations, max id: 160,433, usage: 62%, 12,870 relations/sec.
03:38:13 [0216] 200,000 relations, max id: 290,287, usage: 69%, 17,739 relations/sec.
03:38:15 [0216] 300,000 relations, max id: 429,953, usage: 70%, 22,278 relations/sec.
[...]
03:38:57 [0217] 2,700,000 relations, max id: 3,949,418, usage: 68%, 49,262 relations/sec.
03:38:58 [0217] 2,800,000 relations, max id: 4,065,870, usage: 69%, 49,807 relations/sec.
03:40:00 [0218] 2,988,511 relations, max id: 4,276,307, usage: 70%, 25,182 relations/sec.
03:40:04 [0218] endRelations()
0 changesets, max id: 0, usage 0%.
2,646,251,183 nodes, max id: 3,235,210,462, usage 82%.
264,353,272 ways, max id: 317,272,397, usage 83%.
2,988,511 relations, max id: 4,276,307, usage 70%.
1,134,693,014 attributes.
0 attributes in changesets, max 0 at id 0.
332,932,480 attributes in nodes, max 430 at id 424,298,167.
770,670,290 attributes in ways, max 330 at id 69,367,224.
13,982,355 attributes in relations, max 433 at id 87,565.
3,136,283,726 nodes in ways, max 2,000 at id 5,302,607.
5,198,694 nodes in relations, max 9,330 at id 3,227,491.
28,979,397 ways in relations, max 8,971 at id 1,834,172.
253,337 rels in relations, max 1,669 at id 1,666,469.
34,431,428 members in relations, max 9,330 at id 3,227,491.
Phase 2:
03:40:17 [0000] 1,000,000 nodes upto 15,851,738 @ 120,423 n/s, mem: 277,696,880/635,109,376/3,817,799,680.
03:40:25 [0000] 2,000,000 nodes upto 21,700,896 @ 127,656 n/s, mem: 563,507,408/1,055,195,136/3,817,799,680.
03:40:31 [0000] 3,000,000 nodes upto 23,667,031 @ 138,869 n/s, mem: 834,687,240/1,695,416,320/3,817,799,680.
[...]
07:48:49 [0248] 2,644,000,000 nodes upto 3,232,629,135 @ 177,215 n/s, mem: 2,234,114,696/3,800,039,424/3,817,799,680.
07:48:54 [0248] 2,645,000,000 nodes upto 3,233,806,066 @ 177,218 n/s, mem: 2,052,310,328/3,800,039,424/3,817,799,680.
07:48:57 [0248] 2,646,000,000 nodes upto 3,234,923,903 @ 177,249 n/s, mem: 1,844,505,776/3,800,039,424/3,817,799,680.
07:49:30 [0000] 100,000 ways processed, max id: 4,119,351 at 10,909 ways/sec.
07:49:38 [0000] 200,000 ways processed, max id: 4,286,880 at 11,888 ways/sec.
07:49:42 [0000] 300,000 ways processed, max id: 4,443,381 at 14,584 ways/sec.
[...]
10:43:35 [0174] 264,100,000 ways processed, max id: 316,997,974 at 25,261 ways/sec.
10:43:37 [0174] 264,200,000 ways processed, max id: 317,114,776 at 25,267 ways/sec.
10:43:44 [0174] 264,300,000 ways processed, max id: 317,218,116 at 25,260 ways/sec.
10:44:58 [0000] 100,000 rels processed, max id: 160,434 at 3,414 rels/sec.
10:45:19 [0000] 200,000 rels processed, max id: 290,288 at 3,983 rels/sec.
10:45:43 [0001] 300,000 rels processed, max id: 429,954 at 4,045 rels/sec.
[...]
10:54:10 [0009] 2,700,000 rels processed, max id: 3,949,419 at 4,645 rels/sec.
10:54:24 [0009] 2,800,000 rels processed, max id: 4,065,871 at 4,703 rels/sec.
10:54:55 [0010] 2,900,000 rels processed, max id: 4,176,170 at 4,630 rels/sec.
Nach meiner Beobachtung ist der auf Relationen entfallende Aufwand vernachlässigbar.
Gruß Wolf
Diese Tatsache kann auch theoretisch Überlegungen untermauert werden:
Fläche gemappt als einfacher geschlossener way:
Abfrage: Join über 3 Tabellen: ways - way_nodes - nodes
Ergebnis: Der erhaltene Way kann ohne weiter Verarbeitung als Fläche bentz werden.
Fläche gemappt als MP aus way-Schnipseln:
Abfrage: Join über 5 Tabellen: relations - relation_members - ways - way_nodes - nodes
Ergebnis: Ein geschlossener way muss erst aus den erhaltenen way-Schnipseln zusammengesetzt werden. Dazu müssen diese erst sortiert werden, da deren Reihenfolge in der Relation nicht festgelegt ist. Bei der Sortierung und bei Zusammenbau muss zudem noch die Richtung der beteiligten ways berücksichtigt und ggf. umgekehrt werden.
Dass die zweite Variante sowohl für die Abfrage als auch für die Weiterverarbeitung mehr Ressourcen in Anspruch nimmt, steht wohl ausser Frage. Wie massiv die zusätzlichen Belastung sind lässt sich nur durch Vergleichsmessungen feststellen. Nach einer Erfahrung mit Datenbanken können aber Joins mit zunehmender Anzahl von Tabellen den DB-Server massiv ausbremsen. Und der Unterschied der Verwendung eines fertigen ways oder ihn erst vorher jedesmal zusammenbauen zu müssen, dürfte auch nicht unerheblich sein.
Das bedeutet, die benutzten Verfahren sind effektiv, ich glaube aber nicht, dass die angesprochene MP-Praxis effizient ist.
MPs belasten die OSM Server nicht, da diese sie nur “dumm” speichern und nicht versuchen, irgendetwas mit ihnen anzustellen.
Aber komplexe MPs belasten alle Bearbeiter und Auswerter von OSM-Daten, die versuchen müssen
- alle relevanten Objekte zu ermitteln. Dafür sind entweder eine Datebank oder mehrere Verarbeitungsdurchgänge und viel Speicher nötig
- die komplizierten Zusammenhänge zu verstehen/richtig zu rekonstruieren
- ggf. eine Änderung vorzunehmen ohne etwas zu beschädigen
Effektiv verhindern solche Strukturen
- daß ein normaler Mapper oder gar ein neuer Interessent eine eigentlich einfache Änderung durchführt
- daß ein Interessent die OSM Daten schnell und einfach auswertet. Entweder er verwendet eines der wenigen Standardtools, die die aufwändige Aufbereitung bereits enthalten, oder er darf erst mal mehrere Wochen (keine Übertreibung) in seine eigene Software investieren.
bye, Nop
+1
Jede Art des Mappens die dem “So einfach wie möglich” widerspricht, und insbesondere überflüssige Multipolyone (auch bei Landschaften) sollten geächtet werden weil sie anderen Usern den Zugang zum Mappen erschweren. Die WIKI sollte das entsprechend klar ausdrücken anstelle “Spielfreudige” noch zum Experimentieren zu animieren was alles technisch geht.
Bei manchen Strukturen über die ich so stolpere (und um die zu korrigieren mir die Zeit fehlt; ich beschäftige mich lieber mit “produktiver” Arbeit in noch rudimentär gemappten Gebieten) beschleicht mich der Verdacht dass dahinter nicht Unvermögen sondern Absicht steckt.
Bezgl. der Verlinkung im 1. Post bin ich allerdings der Meinung dass man für solche Diskussionen Objekte verlinken sollte, keine Karten. Denn nach der Karte sieht ja alles prima aus.
Das die Karte vieles beschönigt, dürfte Dir wohl bekannt sein.
Muss wohl schwierig sein den Ausschnitt in einem Editor zu öffnen. 
Wenn ich vor einem HTML-Browser sitze (und manche mappen auch mithilfe von Tools in einem Browserfenster, dürfte vielleicht auch *Dir *bekannt sein), ist das nicht schwierig, aber ein Aufwand wo man sich als Leser eines Threads fragt, ob sich die Mühe wohl lohnt. Von daher ist **“??” ** eine verständliche Reaktion auf die man als TE mitnichten gereizt zu reagieren braucht. 