Multipolygonrelationen

Hi,

da stellt sich mir die Frage, warum dieses Landuse residential überhaupt ein MP sein muß? Ich hätt', es komplett ohne MP gemacht,
denn wenn z. B. eine Schule _nicht_ "residential" sein soll, was bleibt dann noch übrig (für den landuse residential?)
Wenn man z. B. alle Straßen (und Parkplätze) als
landuse "traffic" rausnimmt, hätte man auch konsequenterweise auch die L 251 ausklammern müssen, was aber nicht geschehen ist.

Just my 2c.

Ciao,
Frank

Hi,
ist aus meiner Sicht eindeutig falsch gemappt. Gebäude gehören natürlich zum Wohngebiet
und müssen nicht ausgestanzt werden....

Manche Leute sind halt MP Fans...... 😉

die Relationen selbst als 'inner' einzubinden?

Hier verstehe ich nicht was Du damit meinst.

Chris

kellerma wrote:

Hi,

da stellt sich mir die Frage, warum dieses Landuse residential überhaupt ein MP sein muß? Ich hätt', es komplett ohne MP gemacht,
denn wenn z. B. eine Schule _nicht_ "residential" sein soll, was bleibt dann noch übrig (für den landuse residential?)
Wenn man z. B. alle Straßen (und Parkplätze) als
landuse "traffic" rausnimmt, hätte man auch konsequenterweise auch die L 251 ausklammern müssen, was aber nicht geschehen ist.

Just my 2c.

Es ist halt nun mal so. Halte auch nichts von dem Wahn, jede kleine Fläche usw. per MP zu erfassen. Der Genauigkeit ist es bestimmt nicht zuträglich, wenn Grenzen von Flächen und Gebäuden mit einer Straße (Straßenmitte) identisch sind.
Und bei 'highways=pedestrian + area=yes' führt dies dazu, daß beide ways übereinander angezigt werden (QLandkarteGT). Laut englischem Wiki sollte dies vermieden werden. Im deutschen fehlt dieser Hinweis.

Beantwortet aber meine Frage nicht.

Vielleicht sollte man sich einmal darauf einigen was mit landuse eigentlich bezweckt werden soll. Denn es ist nicht als schöner Hintergrund gedacht. Eigentlich soll es doch in Zoomstufen angezeigt werden in denen noch keine Gebäude zu sehen sind, um eine grobe Orientierung zu bekommen. Ein Shop in einem Wohnhaus macht ja auch noch kein Einkaufszentrum draus. Genauso sollte es sich mit landuse verhalten. Einzelne Handwerksbetrieb können durchaus in Wohngebieten stehen. Genauso wie einzelne Wohnhäuser sich auch in Gewerbegebiete verirren.

viw wrote:

Vielleicht sollte man sich einmal darauf einigen was mit landuse eigentlich bezweckt werden soll. Denn es ist nicht als schöner Hintergrund gedacht. Eigentlich soll es doch in Zoomstufen angezeigt werden in denen noch keine Gebäude zu sehen sind, um eine grobe Orientierung zu bekommen. Ein Shop in einem Wohnhaus macht ja auch noch kein Einkaufszentrum draus. Genauso sollte es sich mit landuse verhalten. Einzelne Handwerksbetrieb können durchaus in Wohngebieten stehen. Genauso wie einzelne Wohnhäuser sich auch in Gewerbegebiete verirren.

Kann man doch im Stylefile/Typfile vorgeben, oder nicht?
Hat aber auch nichts mit meiner Frage zu tun!

Radeln wrote:

viw wrote:

Vielleicht sollte man sich einmal darauf einigen was mit landuse eigentlich bezweckt werden soll. Denn es ist nicht als schöner Hintergrund gedacht. Eigentlich soll es doch in Zoomstufen angezeigt werden in denen noch keine Gebäude zu sehen sind, um eine grobe Orientierung zu bekommen. Ein Shop in einem Wohnhaus macht ja auch noch kein Einkaufszentrum draus. Genauso sollte es sich mit landuse verhalten. Einzelne Handwerksbetrieb können durchaus in Wohngebieten stehen. Genauso wie einzelne Wohnhäuser sich auch in Gewerbegebiete verirren.

Kann man doch im Stylefile/Typfile vorgeben, oder nicht?
Hat aber auch nichts mit meiner Frage zu tun!

Natürlich kannst du das im Stylefile vorgeben. Aber wenn jedes Haus ein anderes Landuse bekommt, dann hast du den gleichen Flickenteppich, welchen man eigentlich vermeiden wollte. Daher sollte ein landuse=garage auch nicht für die einzelne Garage sondern nur für Garagenhöfe benutzt werden.

viw wrote:

Radeln wrote:

viw wrote:

Vielleicht sollte man sich einmal darauf einigen was mit landuse eigentlich bezweckt werden soll. Denn es ist nicht als schöner Hintergrund gedacht. Eigentlich soll es doch in Zoomstufen angezeigt werden in denen noch keine Gebäude zu sehen sind, um eine grobe Orientierung zu bekommen. Ein Shop in einem Wohnhaus macht ja auch noch kein Einkaufszentrum draus. Genauso sollte es sich mit landuse verhalten. Einzelne Handwerksbetrieb können durchaus in Wohngebieten stehen. Genauso wie einzelne Wohnhäuser sich auch in Gewerbegebiete verirren.

Kann man doch im Stylefile/Typfile vorgeben, oder nicht?
Hat aber auch nichts mit meiner Frage zu tun!

Natürlich kannst du das im Stylefile vorgeben. Aber wenn jedes Haus ein anderes Landuse bekommt, dann hast du den gleichen Flickenteppich, welchen man eigentlich vermeiden wollte. Daher sollte ein landuse=garage auch nicht für die einzelne Garage sondern nur für Garagenhöfe benutzt werden.

Es ist schon interessant, was aus einer einfachen Frage werden kann. Ein ausufernder Thread, ohne daß das eigentliche Problem geklärt wird.
In der Schule hieß das: Thema verfehlt, setzen 6.

BTW, Garage bzw Garagenhöfe erklärt sich von selbst. Der Schlüssel/Wert lautet ja schließlich landuse=garages.

chris66 wrote:

Hi,
ist aus meiner Sicht eindeutig falsch gemappt. Gebäude gehören natürlich zum Wohngebiet
und müssen nicht ausgestanzt werden....

Manche Leute sind halt MP Fans...... 😉

die Relationen selbst als 'inner' einzubinden?

Hier verstehe ich nicht was Du damit meinst.

Chris

Wenn Du angeführte Relation anschaust, findest Du einige Multipolygonrelationen deren einzelne Wege Bestandteil der Relation 1535811 sind. Anstatt die Einzelteile hinzuzufügen, sollte man doch auch die Relationen als solche hinzufügen können.
Verständlicher?

Hi,

multipolygon in multipolygone zu stecken geht. Im Wiki nicht direkt unter der "MP-Seite" aber dann auf "Multipolygon_Examples" erklärt.
Wird dann auch (in Deinem Fall) etwas übersichtlicher.

Ciao,
Frank

Radeln wrote:

Wenn Du angeführte Relation anschaust, findest Du einige Multipolygonrelationen deren einzelne Wege Bestandteil der Relation 1535811 sind. Anstatt die Einzelteile hinzuzufügen, sollte man doch auch die Relationen als solche hinzufügen können.

Eine multipolygon-Relation beschriebt eine Flaeche mit innenliegenden Ausschnitten. Die inner-Mitglieder der Relation definieren den Rand der Ausschnittsflaechen.

Soweit klar?

Und nun fragst du, ob anstelle von Wegen nicht ein anderes Objekt als inner-Mitglied genutzt werden kann, das selber aber gar keinen Weg sondern eine Flaeche definiert.

Scheint dir die Idee wirklich so sinnvoll, dass du drei mal nachfragst, warum keiner darauf antwortet?

Oder andersrum das Pferd aufgezaeumt: Welchen Vorteil haette man davon, wenn man da weitere Verschachtelungsebenen einbaut? Um die urspruengliche Relation auszuwerten, muss man dann vorher erstmal eine weitere Relation auswerten, die vielleicht dann wieder eine Relation als Mitglied hat, die ...

Gruss
Torsten

kellerma wrote:

multipolygon in multipolygone zu stecken geht.

Ja, aber indem der inner-Weg der einen Relation gleichzeitig ein outer-Weg einer anderen Relation ist. Was Radeln gefragt hatte, war, ob man nicht die eine Relation als inner-Mitglied einer anderen Relation nutzen koenne.

Gruss
Torsten

de_muur wrote:

Radeln wrote:

Wenn Du angeführte Relation anschaust, findest Du einige Multipolygonrelationen deren einzelne Wege Bestandteil der Relation 1535811 sind. Anstatt die Einzelteile hinzuzufügen, sollte man doch auch die Relationen als solche hinzufügen können.

Eine multipolygon-Relation beschriebt eine Flaeche mit innenliegenden Ausschnitten. Die inner-Mitglieder der Relation definieren den Rand der Ausschnittsflaechen.

Soweit klar?

Und nun fragst du, ob anstelle von Wegen nicht ein anderes Objekt als inner-Mitglied genutzt werden kann, das selber aber gar keinen Weg sondern eine Flaeche definiert.

Scheint dir die Idee wirklich so sinnvoll, dass du drei mal nachfragst, warum keiner darauf antwortet?

Oder andersrum das Pferd aufgezaeumt: Welchen Vorteil haette man davon, wenn man da weitere Verschachtelungsebenen einbaut? Um die urspruengliche Relation auszuwerten, muss man dann vorher erstmal eine weitere Relation auswerten, die vielleicht dann wieder eine Relation als Mitglied hat, die ...

So tief stecke ich da auch nicht drin.
Was mich eben in diesem Bereich stört, ist die Anzahl an MP (einfache Gebäude, Flächen - IMHO unnötig), die dann per Einzelwege in eine Relation gepackt werden. Meine Ansinnen war, wenn sie schon als MP vorhanden sind, diese auch so in die Relation zu übernehmen.
Weshalb geht denn niemand gegen diesen IMHO MP-Irrsinn an?

Radeln wrote:

Weshalb geht denn niemand gegen diesen IMHO MP-Irrsinn an?

Da es bei OSM per Definition kein richtig oder falsch gibt, sollte man mit solchen Aufraeumaktionen betont zurueckhaltend sein. Der Ersteller gibt sich damit ja richtig Muehe, mit welchem Recht soll man ihm seine Arbeit dann wieder kaputt machen? (So zumindest wuerde er es wahrscheinlich sehen.)

Solange es auf der Karte noch genug weisse Flecken gibt, ist man m.E. besser beschaeftigt, wenn man einem Mapper mit einem anderen Tagging-Ansatz soweit moeglich aus dem Weg geht und man lieber nebeneinander als gegeneinander mapped.

Die Idee bei OSM ist, dass so ein Mapper mit der Zeit merkt, dass sich sein Ansatz nicht durchsetzt und er ihn deshalb mit der Zeit selber wieder einstellt.

Gruss
Torsten

de_muur wrote:

Radeln wrote:

Weshalb geht denn niemand gegen diesen IMHO MP-Irrsinn an?

Da es bei OSM per Definition kein richtig oder falsch gibt, sollte man mit solchen Aufraeumaktionen betont zurueckhaltend sein. Der Ersteller gibt sich damit ja richtig Muehe, mit welchem Recht soll man ihm seine Arbeit dann wieder kaputt machen? (So zumindest wuerde er es wahrscheinlich sehen.)

Weshalb es bei OSM kein richtig oder falsch geben kann, verstehe ich ganz und gar nicht .
Auch ein OPEN-Projekt braucht eindeutige Regeln/Vorgaben, was nicht heißt, daß diese zementiert sind/bleiben. Das Wiki trägt dazu leider nicht unbedingt bei (teilweise mehrdeutig und zerfleddert).
Dazu gehört auch dies (wiederhole mich) :
Bei einer Relation mit 'highways=pedestrian + area=yes' mit 'highway' als Grenze werden beide ways übereinander angezeigt (QLandkarteGT). Laut englischem Wiki sollte dies vermieden werden. Im deutschen fehlt dieser Hinweis.

Ich will keine Aufräumaktionen zu starten, wäre auch zu aufwendig. In besagtem Fall wurde das ein oder andere geändert, nachdem ich den Mapper angeschrieben habe. Allerdings nicht das unsinnige Mappen von Gebäuden/einfachen Flächen als Relation. Leider hat er auf weitere Anschreiben nicht mehr reagiert.

de_muur wrote:

Die Idee bei OSM ist, dass so ein Mapper mit der Zeit merkt, dass sich sein Ansatz nicht durchsetzt und er ihn deshalb mit der Zeit selber wieder einstellt.

Soll das ein Witz sein? Man läßt da jemand 'rumwurschteln', bis er einsieht, daß das doch nicht so ganz richtig war. Nimmt man dann an, daß er dies alles wieder rückgängig macht? IMHO eher nein.

Diese Art des Mappens hat auf meiner Karte Auswirkungen. Residential Flächen haben damit, wenn ich keine Gebäude anzeigen lasse, an deren Stelle Lücken, was ansonsten nicht der Fall ist. Ob man dies verhindern kann, weiß ich nicht. Habe deshalb die Anzeige von Flächen bis auf einige wenige reduziert.

Gruß
Josef

Radeln wrote:

Diese Art des Mappens hat auf meiner Karte Auswirkungen. Residential Flächen haben damit, wenn ich keine Gebäude anzeigen lasse, an deren Stelle Lücken, was ansonsten nicht der Fall ist. Ob man dies verhindern kann, weiß ich nicht. Habe deshalb die Anzeige von Flächen bis auf einige wenige reduziert.

Gruß
Josef

Ich sehe du hast ganz persönliche Interessen. Da wundert es mich nicht wenn du an anderer Stelle jegliche Diskussion über das Thema landuse an sich mit Thema verfehlt abbrichst. Aber irgendwie hätte der Mapper ja recht, wenn in dem Gebäude nicht nur gewohnt sondern auch gearbeitet wird. Aber genau diese Diskussion wolltest du nicht. Gleiches gilt auch für Garagen und Schuppen.

Einfach den Quatsch löschen und gut ist. Die meisten erkennen hier schon dass das Unsinn ist nur was willst du jetzt noch machen, bissl von anderen getrollt werden? Traust dich nicht das selbst zu löschen? Go delete.

damit keine Missverständnisse aufkommen: natürlich die inner-Rollen löschen.

viw wrote:

Radeln wrote:

Diese Art des Mappens hat auf meiner Karte Auswirkungen. Residential Flächen haben damit, wenn ich keine Gebäude anzeigen lasse, an deren Stelle Lücken, was ansonsten nicht der Fall ist. Ob man dies verhindern kann, weiß ich nicht. Habe deshalb die Anzeige von Flächen bis auf einige wenige reduziert.

Gruß
Josef

Ich sehe du hast ganz persönliche Interessen. Da wundert es mich nicht wenn du an anderer Stelle jegliche Diskussion über das Thema landuse an sich mit Thema verfehlt abbrichst. Aber irgendwie hätte der Mapper ja recht, wenn in dem Gebäude nicht nur gewohnt sondern auch gearbeitet wird. Aber genau diese Diskussion wolltest du nicht. Gleiches gilt auch für Garagen und Schuppen.

Was willst Du damit eigentlich sagen? Wenn in dem Gebäude gewohnt und gearbeitet wird, ist es als Relation zu mappen. 😉
Was hat dies eigentlich mit dem ursprünglichen Problem zu tun?
Es sind auch weniger persönliche Interessen, bis auf die pedestrian Geschichte. Da ich wie geschrieben, das Meiste in meiner Karte ausblende, könnte mir dies alles ja am A... vorbeigehen.

monotar wrote:

Einfach den Quatsch löschen und gut ist. Die meisten erkennen hier schon dass das Unsinn ist nur was willst du jetzt noch machen, bissl von anderen getrollt werden? Traust dich nicht das selbst zu löschen? Go delete.

damit keine Missverständnisse aufkommen: natürlich die inner-Rollen löschen.

Der große Guru bin ich nicht. Geht das so einfach ohne irgendwelche negativen Folgen?

Radeln wrote:

monotar wrote:

Einfach den Quatsch löschen und gut ist. Die meisten erkennen hier schon dass das Unsinn ist nur was willst du jetzt noch machen, bissl von anderen getrollt werden? Traust dich nicht das selbst zu löschen? Go delete.

damit keine Missverständnisse aufkommen: natürlich die inner-Rollen löschen.

Der große Guru bin ich nicht. Geht das so einfach ohne irgendwelche negativen Folgen?

Wo du dich grade selber outest:

Kannst du das MP hier mal in Ordnung bringen:
http://www.openstreetmap.org/browse/relation/1424400

da fehlt es den inneren wohl an der inner-role.

Ansonsten bitte in Ahrweiler Schwimmwesten verteilen ;-)

gruß,
ajoessen

Schön, endlich wieder eine MP-Diskussion...
...ich erinnere mich an meine als P.S. hier vorgebrachte Idee:
http://forum.openstreetmap.org/viewtopi … 82#p139582

Und da war doch noch der Ausspruch:
"Viele Köpfe, viele Unsinne."
...oder habe ich das falsch in Erinnerung?

Spaß beiseite. Macht mal weiter. Vielleicht kommt ja hier was bei raus 😉

ajoessen wrote:

Radeln wrote:

monotar wrote:

Einfach den Quatsch löschen und gut ist. Die meisten erkennen hier schon dass das Unsinn ist nur was willst du jetzt noch machen, bissl von anderen getrollt werden? Traust dich nicht das selbst zu löschen? Go delete.

damit keine Missverständnisse aufkommen: natürlich die inner-Rollen löschen.

Der große Guru bin ich nicht. Geht das so einfach ohne irgendwelche negativen Folgen?

Wo du dich grade selber outest:

Kannst du das MP hier mal in Ordnung bringen:
http://www.openstreetmap.org/browse/relation/1424400

da fehlt es den inneren wohl an der inner-role.

Wohl schon erledigt.
Danke an grenzdebil_bonn.

Wenn dies allerdings so elementar ist, dürfte dieser Wikitext nicht ganz richtig sein, oder?

'In den meisten Fällen kann eine Relation auch ohne Angabe der Rollen "innen" und "außen" richtig interpretiert werden. Es wird dennoch empfohlen, die Rollen anzugeben um anderen Kartografen das Verständnis zu erleichtern.'

BTW, es gibt in der Ecke noch so einige Waldflächen mit vor allem Wiesen darin. Diese müßten dann ebenfalls als MP mit den Wiesen usw. als inner getaggt werden, oder gibts da eine Alternative?

Gruß
Josef

Radeln wrote:

...
Wenn dies allerdings so elementar ist, dürfte dieser Wikitext nicht ganz richtig sein, oder?

'In den meisten Fällen kann eine Relation auch ohne Angabe der Rollen "innen" und "außen" richtig interpretiert werden. Es wird dennoch empfohlen, die Rollen anzugeben um anderen Kartografen das Verständnis zu erleichtern.'

BTW, es gibt in der Ecke noch so einige Waldflächen mit vor allem Wiesen darin. Diese müßten dann ebenfalls als MP mit den Wiesen usw. als inner getaggt werden, oder gibts da eine Alternative?

Gruß
Josef

Wenn das wirklich nur Wiese und nix anderes ist, macht inner Sinn. Sollten da aber noch weitere landuse-Möglichkeiten im "Loch" bestehen, oder ein zukünftiger Mapper diese finden, schlage ich vor, das inner ohne tag als Loch zu lassen und die vorhandenen landuse ohne Bezug zum forest-MP einzuzeichnen. Siehe auch:
http://forum.openstreetmap.org/viewtopi … 57#p165657

hurdygurdyman wrote:

Wenn das wirklich nur Wiese und nix anderes ist, macht inner Sinn. Sollten da aber noch weitere landuse-Möglichkeiten im "Loch" bestehen, oder ein zukünftiger Mapper diese finden, schlage ich vor, das inner ohne tag als Loch zu lassen und die vorhandenen landuse ohne Bezug zum forest-MP einzuzeichnen. Siehe auch:
http://forum.openstreetmap.org/viewtopi … 57#p165657

Nee Wambacher hat im zitierten Post eine völlig andere Situation beschrieben. Ihm ging es darum, zwei "touching inner ring" zu vermeiden. Aufwändig aber durchaus korrekt. Allerdings entspricht das wohl kaum noch dem in deiner Signatur erwähnten KISS-Prinzip.

Edbert (EvanE)

EvanE wrote:

...
Nee Wambacher hat im zitierten Post eine völlig andere Situation beschrieben. Ihm ging es darum, zwei "touching inner ring" zu vermeiden. Aufwändig aber durchaus korrekt. Allerdings entspricht das wohl kaum noch dem in deiner Signatur erwähnten KISS-Prinzip.

Edbert (EvanE)

Wambacher beschreibt ein inner, in dem zwei verschiedenen landuse-Flächen liegen, die dieses inner vollständig ausfüllen. Mein Vorschlag analog wiki bezieht sich auf den zweiten Satz hier:
Zitat:
"Das Beispiel zeigt einen Wald mit einer Lichtung, die je zur Hälfte See und Farmland ist. Der Kartograf zeichnet einfach nur die Ränder der drei Objekte Wald, See und Farmland. In "OGC Simple Feature Standard" ist diese einfache Möglichkeit nicht vorgesehen, es gibt keine sich berührenden inneren Ringe. Stattdessen wäre zunächst in den Wald ein Loch zu zeichnen und in dieses dann die einzelnen Polygone für See und Farmland."

Ist doch passend und einfacher, oder? Und verhinderte Verschachtelungen bzw. komplexe MP's entsprechen m.E. dem KISS-Prinzip unter Beachtung der simple features, wenn man bedenkt, dass keine überlagernden Flächen entstehen sollen, weil forest auf der Lichtung nicht gilt. So wollen das doch einige Puristen. Als ich vorschlug, kleine Flächen einfach über große malen zu lassen, wurde ich fast erschlagen... 🙄
http://forum.openstreetmap.org/viewtopic.php?id=12284

hurdygurdyman wrote:

EvanE wrote:

...
Nee Wambacher hat im zitierten Post eine völlig andere Situation beschrieben. Ihm ging es darum, zwei "touching inner ring" zu vermeiden. Aufwändig aber durchaus korrekt. Allerdings entspricht das wohl kaum noch dem in deiner Signatur erwähnten KISS-Prinzip.

Wambacher beschreibt ein inner, in dem zwei verschiedenen landuse-Flächen liegen, die dieses inner vollständig ausfüllen. Mein Vorschlag analog wiki bezieht sich auf den zweiten Satz hier:
"Das Beispiel zeigt einen Wald mit einer Lichtung, die je zur Hälfte See und Farmland ist. Der Kartograf zeichnet einfach nur die Ränder der drei Objekte Wald, See und Farmland. In "OGC Simple Feature Standard" ist diese einfache Möglichkeit nicht vorgesehen, es gibt keine sich berührenden inneren Ringe. Stattdessen wäre zunächst in den Wald ein Loch zu zeichnen und in dieses dann die einzelnen Polygone für See und Farmland."

Ist doch passend und einfacher, oder? ...

Für Wambachers Beispiel ist das durchaus passend. Ob das aber einfacher ist, darüber kann man durchaus streiten.

So ein Konstrukt für eine einzelne Inner-Fläche zu empfehlen, schießt meines Erachtens aber deutlich über Ziel hinaus. Wir mappen schliesslich nicht, um irgendwelche Fehlertools (hier JOSM-Validator) zufrieden zu stellen.

Edbert (EvanE)

EvanE wrote:

...
So ein Konstrukt für eine einzelne Inner-Fläche zu empfehlen, schießt meines Erachtens aber deutlich über Ziel hinaus. Wir mappen schliesslich nicht, um irgendwelche Fehlertools (hier JOSM-Validator) zufrieden zu stellen.

Edbert (EvanE)

Nochmal ganz langsam:
eine einzelne inner-Fläche mit homogener (topologisch zusammenhängender) Flächeneigenschaft ist i.d.R. nicht identisch mit der umschließenden Flächeneigenschaft, daher wird diese über inner ausgeschlossen. Dann ist im inner-Loch erst mal nichts.
Um diesen inner-Nichts nun zu füllen kann ich dem inner eine Flächeneigenschaft zuordnen, wenn diese für die gesamte inner zutrifft. Dann benötige ich kein neues Polygon für die inner-Fläche.
Sollte sich jedoch herausstellen, dass später durch mehr Liebe zum Detail oder Veränderungen der Flächennutzung Teile dieser bisher homogenen inner andere Nutzungen/Oberflächen zuzuordnen sind, sollte ich das alte inner-tag entfernen und dann in den inner-Bereich die verschiedenen Flächennutzungen neu anlegen. Dies Vorgehensweise hat den Vorteil, dass sie etablierten Regeln für GIS außerhalb OSM und der Wirklichkeit entspricht, denn die Flächeninhalte überlagern sich nicht.

Wir mappen nicht für Fehlertools, aber diese helfen uns Fehler zu bereinigen. Wenn deren "Meckerei" unsinnig sein sollte, möge man sich an die Entwickler wenden.

Sollte es dich noch interessieren, verweise ich auf die recht konkreten Meinungen der Kollegen aiges und de_muur im link zwei Antworten über dieser, welche mich u.a. bewogen haben, meine frühere Ansicht in die hier vorgestellte zu ändern.

hurdygurdyman wrote:

Nochmal ganz langsam:
eine einzelne inner-Fläche mit homogener (topologisch zusammenhängender) Flächeneigenschaft ist i.d.R. nicht identisch mit der umschließenden Flächeneigenschaft, daher wird diese über inner ausgeschlossen. Dann ist im inner-Loch erst mal nichts.
Um diesen inner-Nichts nun zu füllen kann ich dem inner eine Flächeneigenschaft zuordnen, wenn diese für die gesamte inner zutrifft. Dann benötige ich kein neues Polygon für die inner-Fläche.
Sollte sich jedoch herausstellen, dass später durch mehr Liebe zum Detail oder Veränderungen der Flächennutzung Teile dieser bisher homogenen inner andere Nutzungen/Oberflächen zuzuordnen sind, sollte ich das alte inner-tag entfernen und dann in den inner-Bereich die verschiedenen Flächennutzungen neu anlegen. Dies Vorgehensweise hat den Vorteil, dass sie etablierten Regeln für GIS außerhalb OSM und der Wirklichkeit entspricht, denn die Flächeninhalte überlagern sich nicht.

deckt sich 100% mit meiner Auffassung. "Einfache" Innenbereiche als stink-normale Polygone (ways), komplexere nach Befarf als weitere unabhängige Relation.

Wenn deren "Meckerei" unsinnig sein sollte, möge man sich an die Entwickler wenden.

Diese Fehlertoos "meckern" nicht, sonder beanstanden Fehler in der Topologie von MP-Relationen, die zur Zeit von "unseren" Renderen toleriert werden - es sieht ja trotz Problem auf der Karte meisstens sauber aus.
Die Tools "meckern", weil die MPs einfach falsch sind und somit anderen Programmen die Arbeit schwer bis unmöglich machen.
Wie beim Programmieren: manche Compiler sind geduldig, andere peniebel. Mir sind die penieblen lieber.

Gruss
Walter

p.s. eine uralte Frage: "was ist ein Loch?" - "Ein Nichts mit etwas drum" 😉

wambacher wrote:

Die Tools "meckern", weil die MPs einfach falsch sind und somit anderen Programmen die Arbeit schwer bis unmöglich machen.
Wie beim Programmieren: manche Compiler sind geduldig, andere peniebel. Mir sind die penieblen lieber.

Nö, die meckern manchmal einfach nur so...wie ich auch
http://josm.openstreetmap.de/ticket/6363

SunCobalt wrote:

...
Nö, die meckern manchmal einfach nur so...wie ich auch
http://josm.openstreetmap.de/ticket/6363

Sag ich doch:
"Wenn deren "Meckerei" unsinnig sein sollte, möge man sich an die Entwickler wenden."
Und somit hast du gutes getan, auch wenn du manchmal einfach nur so meckerst 😉

@wambacher:
1. Danke für deine Bestätigung
2. Auch mir geht es darum, es allen Beteiligten vom Mapper bis zum Renderer einfacher zu machen. Wobei unsinnige bzw. nicht nachvollziehbare Fehlerprüfungen in den Validatoren leider den Mapper verunsichern und die Akzeptanz der Tools verringern. Aber auch deren Entwickler sind nur Menschen, jedoch lern- und kompromissbereit, wie SunCobalt's Ticket zeigt.

Aber jetzt zum Ausgangspunkt dieser Diskussion; dem Freibad-Loch im residential:
Derartige MP sind unsinnig und könnten verhindert werden, wenn wir bestimmte landuse als abstrakte überwiegende Nutzungen definieren, die einen Transparent-Charakter haben sollten, weil sie ein Sammelbegriff sind, der mit dem Bewuchs und der Bebauung nichts zu tun hat, sich aber daraus ableitet. Und das sind primär alle, die in der deutschen Übersetzung mit -gebiet enden und diese Bereiche in niedrigen Zoomstufen erkennbar machen sollen.