"landuse" ist kaputt

Sehr interessante Anschauung - kann ich beim besten Willen nicht nachvollziehen.
Hört sich aber irgendwie nach "Neuerfindung des Fahrrads" an. 🤣

mfG Michael

r-michael wrote:

Sehr interessante Anschauung - kann ich beim besten Willen nicht nachvollziehen.
Hört sich aber irgendwie nach "Neuerfindung des Fahrrads" an. 🤣

mfG Michael

Wieso? So dumm ist die Denkweise gar nicht.
Wenn ich z.B. ein Wohngebiet landuse=residential habe, in dem ein Schrebergarten liegt,
muss ich diesen wiederum als landuse=allotments definieren. Da beiden den gleichen Key haben sorgt dies für einen Konflikt.
Einfach drüberlegen oder als Multipolygon ausschneiden?
Hier spalten sich die Geister. Die einen sagen grundsätzlich, dass niemals 2 Landuses übereinander liegen dürfen,
andere meinen wiederum, dass der Schrebergarten ein Teil des Wohngebiets sei und daher die Berechtigung zum Übereinanderzeichnen gegeben sei.

Allerdings sollte an dieser Stelle dann endgültig festgelegt werden, was denn nun richtig ist.
Das Einführen eines neuen Keys halte ich auch nicht für sinnvoll.

KaChing_Cacher wrote:

Hier spalten sich die Geister. Die einen sagen grundsätzlich, dass niemals 2 Landuses übereinander liegen dürfen,
andere meinen wiederum, dass der Schrebergarten ein Teil des Wohngebiets sei und daher die Berechtigung zum Übereinanderzeichnen gegeben sei.

Allerdings sollte an dieser Stelle dann endgültig festgelegt werden, was denn nun richtig ist.
Das Einführen eines neuen Keys halte ich auch nicht für sinnvoll.

Bei manchen überlagernden Flächen klappt das ja schon seit Jahren prima:

amenity=school, amenity=parking, leisure=nature_reserve

Grober, nicht voll durchdachter Vorschlag:
landuse definiert die Oberfläche und darf sich nicht überlappen (hic: MP); amenity/leisure als Fläche ersetzt ein darunter liegendes landuse nicht, sondern definiert nur deren Nutzung.

mit landuse=military sehe ich da wirklich ein Problem. könnte eigentlich amenity/leisure sein?
blöd: landuse bedeutet ja Land-Nutzung und nicht Erd-Oberfläche.
noch schlimmer: ist residential dann immer noch landuse oder doch amenity/leisure?

ym2c
Walter

wambacher wrote:

mit landuse=military sehe ich da wirklich ein Problem.

Welches in gängigen Renderern schon lange entschärft wurde (Schraffur für landuse=military).

chris66 wrote:

wambacher wrote:

mit landuse=military sehe ich da wirklich ein Problem.

Welches in gängigen Renderern schon lange entschärft wurde (Schraffur für landuse=military).

ja, gerade deshalb. nur weil es hübsch aussieht, wäre es dennoch bei diesem Ansatz (landuse versus amenity/leisure) nicht korrekt.
Ist aber sowieso dunkelgraue Theorie - ändert sich eh nix. oder mal wieder auf api 0.7 warten?

Gruss
Walter

KaChing_Cacher wrote:

r-michael wrote:

Sehr interessante Anschauung - kann ich beim besten Willen nicht nachvollziehen.
Hört sich aber irgendwie nach "Neuerfindung des Fahrrads" an. 🤣

mfG Michael

Wieso? So dumm ist die Denkweise gar nicht.
Wenn ich z.B. ein Wohngebiet landuse=residential habe, in dem ein Schrebergarten liegt,
muss ich diesen wiederum als landuse=allotments definieren. Da beiden den gleichen Key haben sorgt dies für einen Konflikt.
Einfach drüberlegen oder als Multipolygon ausschneiden?
Hier spalten sich die Geister. Die einen sagen grundsätzlich, dass niemals 2 Landuses übereinander liegen dürfen,
andere meinen wiederum, dass der Schrebergarten ein Teil des Wohngebiets sei und daher die Berechtigung zum Übereinanderzeichnen gegeben sei.

Allerdings sollte an dieser Stelle dann endgültig festgelegt werden, was denn nun richtig ist.
Das Einführen eines neuen Keys halte ich auch nicht für sinnvoll.

Vielleicht kann ich es daran deutlicher machen: Beide "Geister" haben völlig recht.

Es gibt eine Fläche "usage_district=residential".
Es gibt eine Fläche "area_kind=allotments".

Diese Schrebergärten liegen im Wohngebiet und daher wird auch nichts irgendwo rausgenommen.

Es dürfen aber niemals zwei "usage_district" übereinanderliegen. Das kann auch nicht passieren, weil "überwiegend Wohngebiet", "überwiegend Industriegebiet" und "überwiegend Landwirtschaftsgebiet" sich auch rein sachlich schon gegenseitig ausschließen.

Alle drei Meinungen sind richtig:
1. Man muss einen Acker im Industriegebiet mappen dürfen
2. Das Industriegebiet ändert sich nicht durch einen dort vorhandenen Acker
3. "überwiegende Nutzung" kann nicht mehrere Werte haben. Überschneidungen sind Unsinn.

Der Fehler liegt darin, das wir sozusagen ein Tag "Tiersorte" haben und dafür sowohl "Säugetier" als auch "Reh" zulassen wollen. Als nur von "Säugetier", "Vogel" und "Insekt" die Rede war wurde die Regel aufgestellt, dass es immer nur eins davon sein kann. Dann kam durchaus berechtigtes Detailmapping und es tauchte "Reh" und "Kaninchen" auf. Und jetzt wird darüber getritten, ob "Reh" und "Säugetier" miteinander unvereinbar sind...

Weide

Also wo ein Acker ist, kann schlecht ein Industriegebiet sein, schließt sich ja irgendwie aus.

aighes wrote:

Also wo ein Acker ist, kann schlecht ein Industriegebiet sein, schließt sich ja irgendwie aus.

Keinesfalls.
Wo überwiegend Industriegebiet ist, kann durchaus mal ein Acker dazwischen sein.

Wie Weide schon geschrieben hat, ist es eine Frage der räumlichen Dimension der Edits. Das gleiche wie mit residential und Schrebergarten. Solange ein landuse im wesentlichen deutlich kleinere Areas umfasst als ein anderes, kann es Konflikte geben.

Hier ist im landuse=forest ein landuse=meadow, ein natural=water und ein natural=scrub.

Unterschiede gibt es bei den Kartenersteller. Die meisten zeigen es. Es kommt auf den Render an, wie er diese Daten nutzt.

Und warum soll ich nicht landuse=residential an landuse=residential mit einem landuse=allotments teilweise an beide =residential angrenzend nutzen?

EDIT:
Und meistens haben die Wohngebiete einen Namen und dann gibt es mehrer Wohngebiete in einer Stadt. Hier im Gebirge zum Beispiel Oberdorf und Unterdorf und manchmal Mitteldorf.

@Zecke:

Wenn eine Stadt zu 51% aus Wohngebiet besteht und 24% aus Industriegebiet und 25% Gerwerbegebiet soll ich dann also die gesamte Stadt als Wohngebiet eintragen, weil das überwiegt? Wie schaut es dann aus, wenn ich noch den Nachbarort mit dazu nehme...soll ich dann den Zwischenraum auch noch als Wohngebiet erfassen, weil der Feldstreifen ist ja nur sehr gering im Gewicht.

Laut deinem überwiegend wäre das ok. Detailierter wäre aber doch schöner. Das das Wohngebiet auch da endet, wo die Bebauung endet etc.

KaChing_Cacher wrote:

Wenn ich z.B. ein Wohngebiet landuse=residential habe, in dem ein Schrebergarten liegt,
muss ich diesen wiederum als landuse=allotments definieren. Da beiden den gleichen Key haben sorgt dies für einen Konflikt.
Einfach drüberlegen oder als Multipolygon ausschneiden?

Meine Sicht als Kartenbauer: Bitte keine Flächen übereinander legen !
Grund: Über Prioritätsregeln ist zu entscheiden, welche der Flächen auf der Karte erscheinen soll - das klappt einfach nicht für alle Konstellationen.

Gruß Klaus

toc-rox wrote:

KaChing_Cacher wrote:

Wenn ich z.B. ein Wohngebiet landuse=residential habe, in dem ein Schrebergarten liegt,
muss ich diesen wiederum als landuse=allotments definieren. Da beiden den gleichen Key haben sorgt dies für einen Konflikt.
Einfach drüberlegen oder als Multipolygon ausschneiden?

Meine Sicht als Kartenbauer: Bitte keine Flächen übereinander legen !
Grund: Über Prioritätsregeln ist zu entscheiden, welche der Flächen auf der Karte erscheinen soll - das klappt einfach nicht für alle Konstellationen.

Gruß Klaus

Und meine Sicht als Kartenbauer ist: das mit den Übereinanderlegen von landuse würde ich sehr begrüssen, wenn deutlich zwischen "hauptsächlich", wie residential, industrial, etc. sowie auf der anderenseite "allotments", etc. Unterschieden wird und die "hauptsächlichen" sich nicht überschneiden dürfen. Das würde es gerade mit den Prioritäten sehr viel einfacher machen.

Das mit den "Austanzen" ist jedenfalls eine unsägliche Sitte, hatte erst gerade wieder 2 Fälle, wo Leute die Häuser aus dem Landuse rausgestanzt haben, und dabei natürlich damit durcheinander gekommen sind, in welches Multipolygon es jetzt raus soll. Sprich im Mulitpolygon waren viele Häuser als Inner ausserhalb des Outer ...

Thorsten

Es ist schon intressant was man mit landuse versucht zu definieren und dabei verschiednes vermischt.

Beispiel landuse= military und landuse=residential ...

das sind rein virtuelle laduse und nicht reale (wie landuse=allotments).

Strassen stanz ihr ja auch nicht aus landuse=residential raus (und ich will sicher nicht auf dieser Wohnen!)

aighes wrote:

Wenn eine Stadt zu 51% aus Wohngebiet besteht und 24% aus Industriegebiet und 25% Gerwerbegebiet soll ich dann also die gesamte Stadt als Wohngebiet eintragen, weil das überwiegt? Wie schaut es dann aus, wenn ich noch den Nachbarort mit dazu nehme...soll ich dann den Zwischenraum auch noch als Wohngebiet erfassen, weil der Feldstreifen ist ja nur sehr gering im Gewicht.

Laut deinem überwiegend wäre das ok. Detailierter wäre aber doch schöner. Das das Wohngebiet auch da endet, wo die Bebauung endet etc.

Überwiegend ist die offizielle Definition (soweit es sowas gibt).
Überwiegend heißt für mich nicht automatisch "alles größer 50%" sondern "dominant", d.h. die anderen landuses treten in einem deutlich kleineren Prozentsatz auf. Wie z.B. in dem Industriegebiet mit einem kleinen Acker zwischendrin. In deinem Beispiel liegen alle landuses in der gleichen Größenordnung und sollten daher auch separat getaggt werden. Natürlich sind die Grenzen hier nicht scharf.

Ein Problem mit landuse ist meiner Meinung nach, daß es nicht wirklich sauber definiert ist. Der Key wird für kleine Objekte wie einen Swimmingpool (basin) genauso verwendet wie für die Umrisse des Bebauungsgebiets einer Großstadt (residential) oder ganze Regionen (Farmland-Monster). Daß es keine zwei gleiche Landuses an einer Stelle geben kann, stimmt aber nur, wenn man sich auf landuses vergleichbarer Größenordnung bezieht. Von daher plädiere ich für die Möglichkeit, entweder Landuses übereinender legen zu können, oder aber eine Art layer einzuführen, der die Dimension des Landuses wiedergibt. Der Renderer kann dann immer noch entscheiden, bis zu welchem Layer er noch darstellt.

aighes wrote:

Also wo ein Acker ist, kann schlecht ein Industriegebiet sein, schließt sich ja irgendwie aus.

Wo Ackerboden ist, da kann kein Industrieboden sein. Aber es gibt auch noch das "Industriegebiet Ost", in dem dieser Acker liegt. Das muss man auch irgendwie mappen können.

"Dieses Stück Boden wird industriell genutzt" und "Dieses Stück Boden gehört zu einem Industriegebiet" sind ganz verschiedene Aussagen.

Weide

geri-oc wrote:

Hier ist im landuse=forest ein landuse=meadow, ein natural=water und ein natural=scrub.

Unterschiede gibt es bei den Kartenersteller. Die meisten zeigen es. Es kommt auf den Render an, wie er diese Daten nutzt.

toc-rox wrote:

[Meine Sicht als Kartenbauer: Bitte keine Flächen übereinander legen !
Grund: Über Prioritätsregeln ist zu entscheiden, welche der Flächen auf der Karte erscheinen soll - das klappt einfach nicht für alle Konstellationen.

Meine volle Zustimmung. Und wenn ich mir schon die Mühe mache, etwas zu Kartieren, dann verwende ich Multipolygone um dem Renderer zu sagen was ich gezeichnet sehen will und überlasse es nicht dem Programm. Und schon gleich gar nicht probiere und trickse ich so lange rum bis es passt.

Was ohne Multipolygone rauskommen kann zeigt ein Beispiel im oben genannten Gebiet. Im Gießereisportpark (leisure = stadium) liegt eine Grasfläche (natural = grass), die jedoch von Mapnik nicht dargestellt wird. In dieser Grasfläche liegen zwei Tennisplätze (leisure = pitch), die mit "layer = 1" markiert sind. Vermutlich damit sie sichtbar sind. Das heißt also hier ist eine Grasfläche auf Höhe der Erdoberfläche (layer = 0, wenn nicht angegeben). Direkt auf oder irgendwo über der Grasfläche sind die beiden Tennisplätze. Sicherlich nicht. Somit für mich klassisches Tagging for the renderer:

Der Redewendung „Taggen für den Renderer“ hat bei OSM eine lange Geschichte und bedeutet: Tags vergeben, um eine bestimmte Darstellung zu erzielen.

Einer der wichtigsten Regeln bei OSM lautet: Nicht absichtlich falsche Tags vergeben, nur weil diese zur gewünschten Darstellung führen.

kukuk wrote:

Das mit den "Austanzen" ist jedenfalls eine unsägliche Sitte, hatte erst gerade wieder 2 Fälle, wo Leute die Häuser aus dem Landuse rausgestanzt haben, und dabei natürlich damit durcheinander gekommen sind, in welches Multipolygon es jetzt raus soll. Sprich im Mulitpolygon waren viele Häuser als Inner ausserhalb des Outer ...

Das ist vollkommen unnötig. Oberirdische Gebäude stehen wie das Eigenschaftswort schon sagt über der Erdoberfläche und werden deshalb automatisch über "landuse" gezeichnet. Unterirdische Gebäude erhalten "layer = -1" oder niedriger.

Willi2006 wrote:

Das ist vollkommen unnötig. Oberirdische Gebäude stehen wie das Eigenschaftswort schon sagt über der Erdoberfläche und werden deshalb automatisch über "landuse" gezeichnet. Unterirdische Gebäude erhalten "layer = -1" oder niedriger.

Dem ist leider nicht so. Es liegt allein an der Reihenfolge in dem bestimmte Objekte gerendert werden. Ein highway=footway + area=yes hat (früher?) bei Mapnik eine darauf stehendes Gebäude überdeckt. Erst mit einem Multipolygon (dort wo das Gebäude steht, ist ein Loch in der Fußgängerzone) hat das Rendern wie gewünscht/erwartet geklappt.

Bei 'normalen' Landuse klappt das mit den Gebäuden und Straßen/Wegen, weil Landuse und Natural sehr früh nach dem Hintergrund und vor Straßen/Wegen und Gebäuden gerendert wird.

Edbert (EvanE)

quasilotte wrote:

Es ist schon intressant was man mit landuse versucht zu definieren und dabei verschiednes vermischt.

Beispiel landuse= military und landuse=residential ...

das sind rein virtuelle laduse und nicht reale (wie landuse=allotments).

Strassen stanz ihr ja auch nicht aus landuse=residential raus (und ich will sicher nicht auf dieser Wohnen!)

80% der Diskussionen übers Tagging sind hier sinnlos.
Die restlichen 20% würden auch wegfallen wenn es Taggingregeln gibt die verbindlich sind - weil man endlich auch das WIKI passend schreiben kann und nicht nach GUSTO !!

Fürs erste würde schon mal genügen wenn die "Taggingregeln" klarer und eindeutiger wären. Dem ist nicht so und wird meines Erachtens auch nie so sein, da sie, wie OSM insgesamt auch, evolutionär gewachsen sind. "Böse Zungen" nennen dies auch Methode Kaninchenstall oder Wildwuchs.

Es gab hier durchaus schon Diskussionen ob landuse = residential an Straßen, beziehungsweise in entsprechendem Abstand dazu, zu enden habe.

Eigentlich gibt es natural (= wood, water, scrub, ...) um die Bodenbedeckung zu beschreiben und landuse (= farm, military, industrial, reservoir, ...) um die Nutzung zu beschreiben. Würde das so konsquent wie möglich durchgehalten, so könnte eine Fläche zum Beispiel sowohl mit natural = water als auch mit landuse = military markiert sein. Die Fläche könnte blau und darüber rote Schraffur oder kleine Panzersymbolen gezeichnet werden. Jedoch es geht kunterbunt durcheinander. Die Renderer versuchen "das Beste" aus diesem Durcheinander zu machen. Und es gibt immer wieder wackere Versuche zu einer Trennung zu kommen, zum Beispiel durch Einführen neuer "tags" wie landcover 😉

Willi2006 wrote:

Das ist vollkommen unnötig. Oberirdische Gebäude stehen wie das Eigenschaftswort schon sagt über der Erdoberfläche und werden deshalb automatisch über "landuse" gezeichnet. Unterirdische Gebäude erhalten "layer = -1" oder niedriger.

EvanE wrote:

Dem ist leider nicht so. Es liegt allein an der Reihenfolge in dem bestimmte Objekte gerendert werden. Ein highway=footway + area=yes hat (früher?) bei Mapnik eine darauf stehendes Gebäude überdeckt. Erst mit einem Multipolygon (dort wo das Gebäude steht, ist ein Loch in der Fußgängerzone) hat das Rendern wie gewünscht/erwartet geklappt.

Meines Erachtens ist das kein Gegenbeispiel sondern speziell und eher eine Bestätigung. "highway = footway" ist das primäre Merkmal und "area = yes" das "sekundäre", das unabhängig von landuse ist. Also wird die Fußgängerzone nicht mit landuse sondern mit highway gezeichnet. Allerdings hätte ich erwartet, dass Gebäude nach und somit über Straßen gezeichnet werden. Gebäude stehen eher über Straßen und nicht Straßen über Gebäuden.

EvanE wrote:

Willi2006 wrote:

Das ist vollkommen unnötig. Oberirdische Gebäude stehen wie das Eigenschaftswort schon sagt über der Erdoberfläche und werden deshalb automatisch über "landuse" gezeichnet. Unterirdische Gebäude erhalten "layer = -1" oder niedriger.

Dem ist leider nicht so. Es liegt allein an der Reihenfolge in dem bestimmte Objekte gerendert werden. Ein highway=footway + area=yes hat (früher?) bei Mapnik eine darauf stehendes Gebäude überdeckt. Erst mit einem Multipolygon (dort wo das Gebäude steht, ist ein Loch in der Fußgängerzone) hat das Rendern wie gewünscht/erwartet geklappt.

Bei 'normalen' Landuse klappt das mit den Gebäuden und Straßen/Wegen, weil Landuse und Natural sehr früh nach dem Hintergrund und vor Straßen/Wegen und Gebäuden gerendert wird.

Edbert (EvanE)

Das ein Weg über ein Gebäude gezeichnet ist doch auch so gewollt! Wo ist da der Fehler?
Falls er durch das Gebäude geht gehört z.B noch tunnel=yes an den Way , da er dann ja auch gezeichnet werden könnte bzw. als anderst als der offene Wag.

Und wenn da kein Gebäude ist gehört da auch keins hin, wahrscheinlich ging da auch mit 2 geschlossenen Ways ohne MP (ich denke doch das der Weg die 2 Gebüde dann auch trennt).

@Willi2006

Ja Wildwuchs und egoistische Selbstdefinition (auch bekannt als Besserwisserei) trifft es sehr gut! Dabei spielt es keine Rolle ob man für Renderer oder für die Datenbank mappt - beide könne mit den jetzigen Daten in Wirklichkeit nicht viel Anfangen (es macht nur den Anschein).

Willi2006 wrote:

EvanE wrote:

Dem ist leider nicht so. Es liegt allein an der Reihenfolge in dem bestimmte Objekte gerendert werden. Ein highway=footway + area=yes hat (früher?) bei Mapnik eine darauf stehendes Gebäude überdeckt. Erst mit einem Multipolygon (dort wo das Gebäude steht, ist ein Loch in der Fußgängerzone) hat das Rendern wie gewünscht/erwartet geklappt.

... Allerdings hätte ich erwartet, dass Gebäude nach und somit über Straßen gezeichnet werden. Gebäude stehen eher über Straßen und nicht Straßen über Gebäuden.

Es gibt auch noch Tunnel. Um die korrekt zu zeichnen, werden Straßen und Wege in Mapnik erst nach den Gebäuden gezeichnet.

Edbert (EvanE)

Weide wrote:

"Dieses Stück Boden wird industriell genutzt" und "Dieses Stück Boden gehört zu einem Industriegebiet" sind ganz verschiedene Aussagen.

Was ist das Ziel: Wortklauberei zu betreiben oder eine Karte erstellen?

Sprache ist nun mal ihrem Wesen nach nicht immer eindeutig, und eine Karte ist nun mal ihrem Wesen nach eine Vereinfachung und Interpretation, bei der Details weggelassen werden müssen die manche für wichtig halten. Das ist für manche Menschen mit einem überwiegend technischen Fokus schwerverständlich.

Deswegen gab und gibt es für die Erstellung klassischer Karten Kartierungsregeln die von einer höheren Stelle gesetzt sind, die die Zwecke der Karte im Blick hat.

Bei OSM gibt es eine solche Stelle leider nicht und viele machen sich gern ihre Regeln selber, weil sie davon überzeugt sind alles besser zu wissen. Das ist das Problem. Dafür ist die Karte an vielen Stellen trotzdem erstaunlich gut. Aber eher wegen der vielen stillen fleissigen Arbeiter als der ständigen Tagneuerfinder und -definierer.

Taunide wrote:

Bei OSM gibt es eine solche Stelle leider nicht und viele machen sich gern ihre Regeln selber, weil sie davon überzeugt sind alles besser zu wissen. Das ist das Problem. Dafür ist die Karte an vielen Stellen trotzdem erstaunlich gut. Aber eher wegen der vielen stillen fleissigen Arbeiter als der ständigen Tagneuerfinder und -definierer.

Danke.

Weide

Willi2006 wrote:

...
Was ohne Multipolygone rauskommen kann zeigt ein Beispiel im oben genannten Gebiet. Im Gießereisportpark (leisure = stadium) liegt eine Grasfläche (natural = grass), die jedoch von Mapnik nicht dargestellt wird. In dieser Grasfläche liegen zwei Tennisplätze (leisure = pitch), die mit "layer = 1" markiert sind. Vermutlich damit sie sichtbar sind. Das heißt also hier ist eine Grasfläche auf Höhe der Erdoberfläche (layer = 0, wenn nicht angegeben). Direkt auf oder irgendwo über der Grasfläche sind die beiden Tennisplätze. Sicherlich nicht. Somit für mich klassisches Tagging for the renderer...

Ich hatte hier ein halbes Jahr nach meinem Beginn (Lernphase?) bei OSM den Sportpark nach Fotos und BING erfasst.

Dank Willi habe ich mal nachgeschaut:
- natural=grass ist natürlich falsch, aber es wurde weder von JOSM-Datenprüfer, OSMI oder keep_right angemeckert.
- In diesem landuse=grass lagen zwei Tennisplätze (Kurzrasen) - mittlerweile sind sie als rote Sandplätze umgebaut.
- Der Biathlonstart ist jetzt schon überdacht - es wird weitergebaut ...

Nun␣muss␣ich␣noch␣mal␣hin␣-␣es␣fehlt␣ja␣noch:␣Hochsprunganlage,␣Weitsprunganlage,␣Tribüne,␣...

🙁

Nochmals "Tagging_for_the_renderer" -> ich möchte auch die Daten als Karte nutzen.

Erst mit einem Multipolygon (dort wo das Gebäude steht, ist ein Loch in der Fußgängerzone) hat das Rendern wie gewünscht/erwartet geklappt.

Der Fußweg geht hier bestimmt um das Gebäude - und wurde nur vereinfacht als area=yes eingetragen. Entspricht das MP dem "tatsächlichen" oder einen "Tagging for the renderer" oder einem Taggingfehler?

geri-oc wrote:

Erst mit einem Multipolygon (dort wo das Gebäude steht, ist ein Loch in der Fußgängerzone) hat das Rendern wie gewünscht/erwartet geklappt.

Der Fußweg geht hier bestimmt um das Gebäude - und wurde nur vereinfacht als area=yes eingetragen. Entspricht das MP dem "tatsächlichen" oder einen "Tagging for the renderer" oder einem Taggingfehler?

Nee, in dem Beispiel war das eine (größere) Kirche auf einem großen Platz (auf allen Seiten mehr als 10 Meter Fläche).
Das Multipolygon entspricht schon der Realität, da dort wo die Kirche steht, ja keine Fußgängerzone ist. Es handelt sich daher um eine Fläche in einer Fläche. Wir sind nur irritiert, weil Gebäude auf Landuse & Co beim Rendern auch ohne MP funktioniert.
Wie bereits gesagt, ist das eine Frage der Reihenfolge beim Rendern.

Das als Fußweg einzutragen wäre einfacher gewesen, wenn die Situation das hergegeben hätte.

Edbert (EvanE)