Den Vorschlag von Frederik (#398) finde ich sehr gut. Gratulation an Frederik für diese Idee!
Nur ein kleines „Bedenken“ dazu: Bei Punkt 4 (
) muss möglicherweise erklärt werden (vielleicht in einer Anmerkung?), dass es noch nicht als „gemeinsame identifizierende Eigenschaft“ zählt, wenn die Teile einfach irgendwelche Eigenschaften bzw. Tags teilen (wie es z.B. bei mehreren Wiesenflächen der Fall wäre – auch so etwas wird ja manchmal als MP zusammengefasst). Es geht wirklich um identifizierende Eigenschaften, insbesondere Eigennamen.
Allerdings würde ich die Reihenfolge umdrehen. Also mit den einfachen Fällen anfangen, in denen keinesfalls ein MP erforderlich ist, und dann zu den komplizierteren kommen.
Mit Checklisten habe ich immer gern gearbeitet. Weil man das Rad da nicht jedes Mal neu erfinden muss und die Gefahr, dass man was nicht beachtet, minimiert wird.
Mann könnte das evtl. auch wie einen Entscheidungsbaum (Programmablaufplan) aufbauen, an dessen Endzweig jeweils der entsprechende Link zu dem zutreffenden WIKI hängt.
Mann muss es noch nicht mal mit den Symbolen eines Programmablaufplanes erstellen. In Zeiten, wo Computer noch nicht so richtig grafikfähig waren, ging das auch ganz gut mit ASCII Zeichen.
bei den meisten in diesem Faden erwähnten Negativ-Beispielen, z.B. diesem, endet der Check schon bei Punkt 2, weil die Fläche ein Loch hat, oder läuft durch bis Punkt 7, weil der Umriss mehr als 50 Punkte oder mehr als 10 qkm hat. Ich würde daher “Multipolygon ist erforderlich”, außer bei Punkt 4, ersetzen durch “Prüfe, ob die Fläche so aufgeteilt werden kann dass diese Bedingung nicht mehr erfüllt ist”, also z.B.
Ist es eine Fläche mit Loch → Prüfe, ob die Fläche so aufgeteilt werden kann, dass die Teilflächen keine Löcher mehr aufweisen.
Es braucht dann natürlich eine Anleitung zum Aufteilen. Über die sollte vielleicht separat diskutiert werden.
Es geht hier auch gar nicht um Multipolygone, sondern darum dass das Verkaufs Produkt, der Polygon Vermarkter, auf die Wiedergabe von uns gezeichneter “Löcher” weitgehend verzichtet.
Wir arbeiten für die Branche der Tilevermarkter bereits viel zu sehr in der Tiefe, und für Berufs Geografen -welche selbst an amtlichen Karten arbeiten- bereits viel zu detailliert.
Daher nun deren aktuelle Initiaitive, uns im Einsatz von Multipolygonen durch beschönigend genannten Empfehlungen, welche in Realität natürlich verbindliche Regeln sind, einzuschränken.
Dazu ein passendes Zitat: Nur die dümmsten Kälber wählen ihre Schlächter selber.
Bertolt Brecht
Die Frage ist doch, wem nützt die hier vorligende Initiative von Michael.
Michael befindet sich schon sehr lange auf einem Kreuzzug gegen die Verwendung von Multipolygonen https://www.openstreetmap.org/changeset/56911458 ,was hat ein Deutscher User, mit solchen Wünschen in Österreich verloren. Es geht hier um eine Agenda der Firma für die Michael arbeitet. Uns wird hier hingegen vermittelt, es gehe um eine Agenda für eine leichtere Bearbeitbarkeit für OpenStreetMap Anfänger.
Fehlen die Argumente kommt der Hamme Verschwärungstheorie zum Einsatz.
Ich Mappe in meinen primären Regionen https://www.openstreetmap.org/#map=19/47.52595/12.39868 in großer Detailtiefe. ICh erkläre klar, dass die Verwendung von Multipolygonen vorteile bringt. Auch die Anwendung sogenannter Polygonteppiche liefert klare Vorteile. Aus Technischer Sicht spricht nichts gegen die gemeinsame Nutzung einer Flächenbegrenzung. Klar ablehnend sehe ich das zerstückel von Straßen. Aber das ist hier auch nicht die Frage.
Warum arbeitest Du hier mit Andeutungen. Die Arbeitsverhältnisse sind hier kein Geheimnis.
Und wenn Frederik ein berufliches Interesse daran hätte, die Multipoligonitis einzuschränken, schätze ich ihn so ein, dass er genug E… … … . Hose hat, um so etwas selbst anzuschieben.
Es ist einfach so, dass es mittlerweile in OSM Konstrukte gibt und damit meine ich nicht nur Multipoligone, die die spätere Bearbeitung dieser Elemente auf Grund ihre Komplexität fast unmöglich machen bzw. man die Lust verliert sich soviel Arbeit zu machen. Um dieses Thema umfassend zu behandeln, müsste man aber einen eigenen Faden aufmachen.
Ich kann Dich nur bitten, Deine Provokationen und unterschwelligen Verdächtigungen gegen andere Mapper zu unterlassen.
Und wenn Dir was nicht passt, dann nenne die Dinge oder die Personen beim Namen.
Bei der Empfehlung geht es doch gar nicht darum, auf Details zu verzichten.
Ziel ist es auf MP zu verzichten, wenn dies ohne Informationsverlust möglich ist, um Mappern die Bearbeitung etwas einfacher zu machen.
Welche Vorteile hier irgendwelche Vermarkter haben sollten, ist mir nicht klar.
Hauptsächlich den Mappern, welche sich nicht mit unnötig komplizierten MP herumschlagen wollen.
Ich bin vor einigen Wochen, das war glaube ich irgendwo in der Nähe von Neckargerach oder Zwingenberg (https://www.openstreetmap.org/#map=15/49.3977/9.0744) beim Mappen über MPs gestolpert und habe dann irgendwann das Bearbeiten abgebrochen, da es einfach sehr zeitaufwendig ist, solche MPs zu bearbeiten und trotz aller Bemühungen habe ich den Wald bei Zwingenberg kaputt gemacht (obwohl ich diesen gar nicht bearbeiten wollte, sondern nur die angrenzende Wiese, welche eine gemeinsame Linie mit dem Wald teilte) und JOSM hat mich nicht gewarnt, da das entsprechende MP nicht vollständig geladen war.
Deswegen bin ich sehr dankbar, dass hier versucht wird, eine entsprechende Empfehlung zu beschließen.
Ich bin der Meinung, dass man alles einfach halten sollte, solange dies möglich ist, ohne die Realität falsch darzustellen oder an Details zu verlieren.
Ich arbeite nun sehr viel und gerne mit Multipolygonen, und habe persönlich in meiner Laufbahn auch sämtliche hierzu genannten Fehler selbst begangen, und anschließend wieder mühsam selbst ausgebessert. Letztlich sind MP´s kein Problem sofern man sich an wenige Regeln hält.
Eine Straße besteht aus drei Details,
dem Straßen Way, dieser dient als Träger der Straßen Eigenschaften, dieser zeigt auch den Straßenverlauf an.
dem Leer Raum (Vorbereitung für spätere Straßen Flächen Elemente)
dem Straßenrand Way, Träger der angrenzenden Flächen- Eigenschaft.
Multipolygon Teppiche verwende ich gerne und ausgiebig, achte bei solchen aber sehr darauf, dass hierbei nur kleine Strukturen entstehen. Groß- MP Strukturen löst man hierbei unbedingt auf. Diese Relikte sind wirklich problematisch, und werden sehr gerne als Ausrede der MP Gegner genannt, dabei ist das auflösen solcher Strukturen heute absolut keine Hexerei.
Ich möchte also abgesehen von Grenz Relationen nie die Ausrede hören, mein MP wurde nicht vollständig geladen, daher habe ich ein MP zerstört, das ist doch nur eine faule Ausrede.
Grenz- Relationen gehören von allen anderen Details getrennt, sauber in einem eigenen Polygon geführt. Diese Vorsichtsmaßnahme senkt auch das Risiko einer versehentlichen Zerstörung solcher Strukturen beträchtlich.
… soll ich noch mehr liefern, z.B. ein paar Forst-MP’s noch?
In meinen Augen sind MP-Teppiche, die aus Liniensegmenten zusammengesetzt sind und solche o.g. Beispiele ein Verstoß gegen https://wiki.openstreetmap.org/wiki/DE:Ein_Objekt,_ein_OSM-Element. Sie stellen eine unnötige Verkomplizierung des Datenbestandes dar und behindern im extremsten die Anpassung/ Änderung der Daten durch Dritte… Ich habe öfters Kontakt zu Mappern, die nicht JOSM nutzen und die beschweren sich regelmäßig über MP’s und bitten mich mal drüberzuschauen, daß kein Fehler entstanden ist…
Ich habe mir das Beispiel angeschaut. Ich finde es - sagen wir mal - suboptimal. Wieso werden von Dir die gepflasterten Flächen der privaten Grundstückseinfahrten aus landuse=residential ausgelassen? Das entspricht keiner der in https://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dresidential aufgeführten Verwendungen (bei der einen werden die gesamten Siedlungsflächen inkl. der dazu gehörigen Straßen als landuse=residential eingezeichnet, bei der anderen die tatsächlichen Siedlungsgrundstücke unter Auslassung der Straßen). Grundstückseinfahrten sind aber Teil des Siedlungsgrundstücks und somit gehören sie eindeutig in die landuse=residential-Fläche.
Die von Dir genutzten Aussparungen für Zufahrten gaukeln auch eine Detailtreue vor, die aber tatsächlich nicht vorhanden ist. Was ist Zufahrt, was ist Fußweg zur Haustür, was ist Terrasse? Das gibt kein Luftbild so eindeutig her und ein exaktes Einzeichnen nach Besichtung vor Ort ist weder möglich (Betreten von Privatgrundstücken) noch ist es erwünscht, dass diese Details auf Wohngrundstücken ohne Einverständnis des Besitzer so detailliert eingezeichnet werden. Also: Wenn man Deinen Ansatz umsetzen wollte, müsste sich das Aussparen von Straßen auf tatsächliche Straßen beschränken. Die privaten Zufahrten auf den angrenzenden Grundstücken sind dagegen eindeutig landuse=residential.
Ein_Objekt,_ein_OSM-Element. Ein Beispiel hierfür: Ein ausgedehntes Waldgebiet genannt Finsterwald, ist durch mehrere Wiesen durchbrochen. Den Regeln entsprechend Ein_Objekt,_ein_OSM-Element, sind demnach die verteilten Waldflächen in einem gemeinsamen Multipolygon mit name=Finsterwald zusammenzufassen. Du beschreibst hier aber das genaue Gegenteil. Ich finde Ein_Objekt,_ein_OSM-Element, ist sogar ein hervorragendes Beispiel für den sinnvollen Einsatz von Multipolygonen. Beispiel: Wald/ Unterberghorn https://www.openstreetmap.org/relation/1914793
Deine Angriffe sind nun ein excellentes Beispiel, was den kleinen Mappern blüht, sobald die aktuelle Proposal “Empfehlung” in Abstimmung abgeschlossen ist.
Inquisition
Anstatt über kleine Mapper herzuziehen, sollten wir diese dazu motivieren, seit Jahren unerledigte Baustellen aufzuräumen.
Zu Deiner Behauptung, Kontakt zu Usern welche per ID Probleme mit Multipolygonen haben, habe ich bereits ausgeführt, dass der Editor ID Defekt ist. Das kümmert Dich und andere aber nicht, ID User regelmäßig als Kronzeugen zu instrumentalisieren.
Nun gut, nenne uns einen solchen. Dieser bekommt hier Gehör. Einstweilen würde ich dich Bitten, Deine Energie auf die Reparatur des Editos ID zu lenken.
Uns stehen in dieser Region sehr hochwertige Luftbilder von geoimage.at zur Verfügung, und ich wohne und lebe in dieser Gemeinde. In Österreich gibt es Panoramafreiheit. Zu den frei gehaltenen Straßenflächen. Diese halte ich in Vorbereitung für Flächenmerkmalen von Straßenflächen frei. Ich hoffe ich habe Deine Frage zur Detailtreue hiermit bentworten können.
Noch eine Anmerkung. Auch in der sogenennten Basemap, also unserem amtlichen Mitbewerber Produkt, werden Straßenflächen von anderen Flächenmerkmalen freigehalten. Warum ausgerechnet soll OSM das nicht dürfen, gibt es hierzu ein stilles Abkommen?. Nachdem das von Dir genannte Argument OSM Residential fließt über die Straßenfläche, geradezu gebetsmühelartig immer wieder kommt, bin ich geneigt in Verbindung mit der in Karto unterirdischen Rendering Breite von highway=residential genau solches anzunehmen.
In der weiteren Konsequenz bitte nicht nur die Flächen für Grundstückszufahrten, sondern auch die Flächen für Terrassen, Rasenfläche, Gemüsebeete, Swimmingpool etc. frei halten. Eigentlich gehört ein landuse=residential ausschließlich an die Flächen, wo das Wohngebäude drauf steht. Das ist zwar identisch mit building=*, aber egal. Alles andere ist dann nicht mehr residential. Auch nicht der Gartengeräte-Schuppen und auch nicht die Garage.
Das ist doch absurd!
