+1
Bin auch sehr dafür. Nach reiflicher Überlegung soll es OK sein. Das hilft jetzt nicht bei der Durchsetzung, weil sich Hardcore-MP-ler dann immer mit “natürlich habe ich reiflich überlegt, und ihr seid alle doof!!!” rausreden können, aber so eine Richtlinie hat ja auch normative Wirkung, nicht nur tatsächliche.
Danke, das hatte ich, wenn ich mich recht erinnere, mal irgendwo in einem anderen Diskussionsthema mitbekommen.
Dies hatte ich wohl vergessen in die Frage zu packen, dass das bereits bekannt… , daher was ist der ganz einfache Grund, warum die API so programmiert wurde? Könnten dann eventuell bei einer höheren Anzahl von Punkten pro Weg etwa verschiedene Editoren zu langsam werden? Falls ja, gibt es dazu “on-the-ground” Messungen?
+10 auch von mir 
Wenn ich das richtig sehe, gab es ursprünglich kein Limit, was üble Performanceprobleme in der API verursacht hat. Seit API 0.6 gibt es daher ein Limit von 2000 Nodes pro Way. Von API-Seite wäre das heute wahrscheinlich handlbar, aber einzelne Editoren sind schon arg langsam mit langen Ways.
Dann gibt’s noch das Thema, dass Versionen immer komplett abgelegt werden, was vor allem beim Hinzufügen oder Löschen von Knoten zu recht viel Redundanz führt, sowohl auf der Datenbank, als auch beim Hochladen.
Mein Senf dazu (betrifft ausschließlich Landschafts-Flächen-MPs):
Die meisten Riesen Mp’s (Flächen) auf die ich in meiner weiteren Umgebung treffe, sind ca. 10 Jahre alt, wurden von einer Handvoll Kartierern damals erstellt, und sind meist recht ungenau. Es ging wohl damals darum, möglichst viele “weiße Flächen” erstmal irgendwie zu füllen. Aus heutiger Sicht vllt. nicht so schlau.
Habe gerade ein grosses Wald - MP zerlegt mit weit über 60 innern. Auf der betroffenen Fläche gibt es nun wieder neue 5 bis 6 MP. Die Anzahl der inner hat, über alle neuen MP betrachtet, sogar deutlich zu genommen, denn da waren noch etliche Lichtungen (z. B. Äcker, Wiesen) noch nicht erfasst. Mangels genügend querender Straßen konnte ich die MP nicht kleiner machen. Ergebnis also irgendwie ernüchternd, aber die Karte ist natürlich auch viel detaillierter geworden. Nur, wer denkt, man könnte weitgehend OHNE MP auskommen, das wird nix!
Andererseits habe ich in der letzten Zeit auch eine Vielzahl von Sinnlos-MP, welche nur aus aneinander gereihten outer bestanden, entsorgt (durch Umwandlung in einfache Relationen). Was ich an solchen MP in meiner Region finde, stammt weitgehend aus der Frühzeit von OSM.
Nein, das sicher nicht. Aber deinen neuen, kleineren MPs sind doch viel besser zu handhaben als das bisherige Groß-MP. Und das ist, neben der genaueren Erfassung, doch ein großer Gewinn!
Ich werfe hier nochmal zwei Overpass-Abfragen hinein 
Einmal eine die nach Outer-Ways sucht die wenig Punkte haben (<20), aber trotzdem eine Relation “multipolygon” erstellt wurde.
http://overpass-turbo.eu/s/E7Q
Und noch eine… Sinnlose Relationen… nur einen outer-Way und ohne inner-Ways
http://overpass-turbo.eu/s/E7R
…gibt ganz schön viele 
… teilweise hatten sie mal inner-Ways
Gruß Miche
Wohl weil diese ‘inner’ mal landuse=construction waren - was ja temporäre Dinge sind.
Gruß
Toni
Hab ich bei dene die ich angesehen hab noch nicht gehabt… aber jetzt wird schon langsam Sinnlos… landuse=construction auch noch auszuschneiden ist ein Blödsinn… soll ma vielleicht noch Schule/Bäcker/Friseur/Hotel/Gasthof/Tankstelle/Metzger/Kirche aus landuse=residential ausschneiden… nur weils sooo und nur so ganz richtig ist??
so wie hier teilweise:
https://www.openstreetmap.org/relation/6946674
landuse aus landuse mittels MP rausschneiden? Ja, so habe ich das MP-Konzept verstanden.
Hat wenig mit dem Konzept MP zu tun. Sondern einfach damit was man unter landuse=residential vs. construction (zB) versteht.
Wenn man darunter ein fertiges Wohngebiet (residential) versteht, und eines welches gerade hochgezogen wird (construction), dann sind dies zwei disjunkte Flächeneigenschaften und man muss die Flächen halt trennen (keine Überlagerung).
Klar, sobald die Baustelle fertig ist, kann man die landuses verschmelzen.
Mir geht es dabei mehr um Baustellen mitten im Wohngebiet, nicht am Rande.
Da beide ‘landuse’ sind und das eine inerhalb des anderen liegt verwende ich ein MP mit outer und inner.
Wenn die Baustelle weg ist wird das zugehörige ‘landuse’ gelöscht, zurück bleibt ein MP mit nur einem outer - so what?
Da kann das MP mit dem einen ‘outer’-Member doch “noch eine Weile” existieren, oder?
Denn zwei Wochen später wird die nächste Baustelle mitten im Wohngebiet gemapped und bumms hat’s MP wieder ein ‘inner’.
muss man das? Eine Baustelle für ein Wohnhaus in einem Wohngebiet ist für mich immer noch Wohngebiet. Mit MP arbeite ich nur, wenn das eine das andere explizit ausschließt.
nach diesem Argument bräuchten wir dann kein landuse=construction, kein landuse=brownfield und kein landuse=greenfield, wenn …
Ja wenn? Wenn die Baustelle nur ‘klein genug’ ist? Wenn’s eh ‘nur’ ein Haus ist? Wenn’s eh nur ‘ein’ Haus ist?
In der Regel wohnt dort während der Bauzeit niemand, wenn und weil das alte Haus nicht mehr und das neue Haus noch nicht existiert.
Wirklich schön 
Aus meiner Sicht ein Beispiel für ein komplexes MP, bei dem man Probleme hat, es sinnvoll zu zerlegen. Wenn doch, dann mit geraden Linien, z.B. von https://www.openstreetmap.org/node/5854811243 nach Osten.
Ich würde es tortenartig entlang imaginärer und realer Waterway-Verläufe auftrennen … aber es wird trotzdem eine Schweinearbeit sein.
Haben die “Seeteile” nicht auch Namen oder lokale Bezeichnungen - ähnlich Bay, Bucht?
Es wäre deutlich leichter, wenn in JOSM Alt-X (Split Object) für MP funktionieren würde. Oder kennt jemand etwas anderes dafür?
Könnte sonst mal versuchen, das zu ermöglichen, wenn die Auswahl zwei gültige MP ergibt.
Ergebnis wären dann zwei MP, in denen jeweils die richtigen inner sind. Habe sowas schon selbst vermisst.
Doppelpost gelöscht