Na het herstellen van wat vandalisme heb ik een park in Enschede hersteld:
http://www.openstreetmap.org/#map=17/52.22821/6.88243
Volgens mij volgens de regels der kunst: landuse eronder en leisure=park zwevend eroverheen.
Toch heeft het forest in het park een rare afwijkende kleur. Wat kan hiervan de oorzaak zijn? MPR?
http://www.openstreetmap.org/relation/7274602
Vaak is het als je alleen bomen ziet, dat er een groot gebied landuse=forest heeft hier de relatie
De forest kleur en bomen icoontjes worden apart gerenderd.
Dan zie je vaak ook bomen in het water.
Kan de zin niet geheel volgen, maar bedoel je dat een multipolygoonrelatie (MPR) de oorzaak is?
Dat zou dan een systeemfout zijn?
Probeer forest eens buiten de relatie te zetten
Een trial and error methode; ik zal eens kijken…
de forest groen relatie ligt onder de leisure park en boven op de forest bomen van de relatie.
teken eens een polygon landuse=forest, kijken of er verschil is tussen polygon en multipolygon
Ik heb de MPR forest gesplitst in non-MPR’s en het renderingprobleem is opgelost!
Maar: is dit een issue dat we, waar, moeten melden?
In het VAn Lochemsbleekpark zitten vier inner polygonen en nu puur voor de rendering de outer te splitsen?
Ik heb het hier gemeld.
https://github.com/gravitystorm/openstreetmap-carto/issues/2641
De opmerking die werd gemaakt.
Volgens mij wordt er ‘domweg’ van groot naar klein gerenderd: eerst de grote vlakken met de juiste kleur vullen, daarna stapsgewijs steeds kleinere.
Bijvoorbeeld eerst een grote residential: vlak krijgt helemaal de kleur lichtgrijs. Daarna een gebouw in dat gebied: gebouw wordt donkergrijs ingekleurd, de al bestaande lichtgrijze kleur wordt voor dit gebiedje vervangen door donkergrijs.
Bij parken met stukken bos erin is vrijwel altijd het park het grootst, dus worden de bosgedeeltes in het renderproces eerst lichtgroen ingevuld (door het aanwezige park) maar daarna donkergroen, doordat het bos eroverheen gerenderd wordt (omdat het kleiner is).
In Enschede was het park echter kleiner dan het bos, zodat het precies andersom ging. Eerst een groot donkergroen vlak (bos), daaroverheen het (kleinere) park.
Volgens mij maakt het niet uit of het om een polygon of multipolygon gaat, alleen de grootte is van belang. Doordat Martin het bos in kleinere stukken heeft opgedeeld, komen ze weer (zoals meestal) later aan de beurt in het renderproces, met het resultaat wat we gewend zijn. We zien op de kaart donkergroene stukken bos, met soms nog wat lichtgroen park waar geen kleiner vlak bos, gras o.i.d in de data aanwezig is.
Hoe dat met de boompjes zit weet ik ook niet precies. Miscchien dat die als laatste aan de beurt zijn, per boomsymboooltje zijn ze natuurlijk als ‘erg klein’ op te vatten. Dan zouden ze dus altijd ‘bovenop’ eindigen.
De tag layer=* wordt volgens mij door de rendering genegeerd, dus daarmee kun je geen andere rendervolgorde afdwingen.
Om deze ‘park-renderfout’ te voorkomen, zou bos altijd na park ingekleurd moeten worden. Je zou in het renderproces de volgorde moeten vaststellen waarin bos, park, water, enz. gerenderd worden. Maar misschien loop je dan weer tegen andere problemen aan.
Ik ben blij dat ik nooit tag voor de renderer, dan hoef ik niet druk te maken om dit soort fouten. 
Ik vind dat lichtgroen voor de parken spuuglelijk, maar dat zal me er niet van weerhouden om een gebied als park te taggen als ik dat de beste tag vind.
Kijk, dat probeerde ik dus te zeggen: eerst grote vlakken, dan kleinere, dan de boompjes. Iemand op Github is het met me eens. 
Het antwoord van Github werkt enig licht op de zaak, maar:
Waarom werken we dan in dergelijke simpele gevallen (eiland in landuse) überhaupt nog met MPR’s?
Leisure=park is niet als landuse ingevoerd, maar blijkbaar doet de renderer wel alsof
Hoe om te gaan met ‘onvolledige eilanden’: een kleiner eiland ligt niet geheel in de omsluitende maar kruist deze
De reden waarom de ‘boompjes’ van het bos zonder gebruikt te maken van een MPR wel gerenderd blijven in een grasstuk, parkeerplaats of park is mij volgens de principes genoemd door Github volledig onduidelijk.
Omdat we de werkelijkheid mappen. Als er een eiland in een meer wordt opgespoten, kun je niet langer zeggen dat het hele oppervlak ‘water’ is. Dat doe je wel als je de tag natural=water op het hele vlak laat staan, en alleen het nieuwe eiland intekend en tagt met natural=sand o.i.d. Dat één renderer per toeval deze fout voor je corrigeert, is leuk voor het plaatje, maar er blijft een fout in de data staan.
De renderer kleurt allerlei vlakken in, niet alleen landuse: parkeerplaatsen, gebouwen, water, schoolterreinen enz. Dat lijkt me ook wel logisch voor een algemene kaart. Een speciale kaart met de nadruk op ‘landuse’ is misschien ook wel te vinden/te ontwikkelen.
Dan is er toch geen eiland en omsluitende? Er zijn dan toch gewoon twee vlakken die aan elkaar grenzen? Ik weet niet of ik je goed begrijp. Je bedoelt zoiets als een klein meertje aan de rand van een bos, dat deels buiten het bos ligt?
Volgens mij vallen de boompjes onder pattern in Github termen. Die worden blijkbaar als laatste gerenderd, en komen dus altijd bovenop andere ingekleurde vlakken te liggen.
Het lijkt me duidelijk dat de render-regels van Carto niet altijd ideaal zijn, maar een concreet voorstel hoe ze verbeterd kunnen worden lever ik ook niet een-twee-drie.
Betreffende het onderhavige geval is het nog niet helemaal goedgekomen. Nog steeds leisure=park bovenop gerenderd, zoals het Kozakkenpark en Abraham Ledeboerpark http://osm.org/go/0GS4SMxm
Een ander deel is dat bij het Roessingh de parkeerplaatsen (onderdeel van relatie) niet meer zichtbaar zijn. Kan er zelf (trial and error) mee gaan knoeien maar als iemand anders bereid is dit even te bekijken vind ik dat ook prima. Zolang er a.u.b. geen details worden verwijderd, het is al tamelijk teruggesnoeid sinds de laatste reparaties.
Bij het Ledeboerpark zag ik op het eerste gezicht een aantal onjuiste inners in een relatie. Ze komen namelijk twee keer voor, een keer los met landuse=xxx en keer als inner zonder landuse.
Kan er nu niet verder mee stoeien, aangezien OSM momenteel onbereikbaar is.
Wordt gewaardeerd Henk, vriendelijk dank voor de moeite.
Heb de inners van Ledeboerpark aangepast plus enkele toegevoegd die nog ontbraken (waaronder een hele grote). Waarmee het netto oppervlak van het bosgebied waarschijnlijk net onder die van het park is gekomen, want het rendert nu goed (waarschijnlijk toevallig, zie volgende alinea).
Kozakkenpark kon ik enkel goed krijgen door het grasveld te splitsen. Dus de eerdere opmerkingen in deze draad kloppen: een park mag niet kleiner zijn dan een onderliggende landuse, anders wordt het park (de kleur ervan) bovenop de landuse afgebeeld.
Parkeerplaatsen bij Roessingh: is het niet zo dat de standaard renderer simpelweg niets doet met parking_space?
Yep, gezien dat het nu goed rendert, mooi.
ook weer geleerd, heb ik dan toevallig zelf wel goed gedaan die enkele keren dat ik leisure=park heb gebruikt.
Ik weet dat voorheen de parkeerplaatsen wel zichtbaar waren, hoe dat weet ik niet. JJJWegdam heeft het ooit gemaakt.
In feite is het heel simpel: map wat de werkelijkheid is, de rendering zou dat moeten volgen.
Heb je een vijver met een eiland erin? Multipolygon, want het eiland id geen onderdeel van de vijver. Bosgebied met een stuk gras in het midden? Multipolygon, want het gras is geen bos.
Hebben jullie het idee dat er situaties zijn die wel goed getagd maar niet goed gerrndered zijn?
Nee omgekeerd, niet goed gerenderd omdat er niet goed is/was getagd. Ik neem aan dat fouten in de renderer weinig voorkomen, de oorzaak zal dus meestal bij de mapper liggen.
Het is goed dat Math even reageert, hij zit dicht bij het vuur als er werkelijk render problemen zijn op de OSM carto standaard.