Dit topic gaat niet over een specifiek probleem, maar zet ik neer om allerlei - multipolygon gerelateerde - zaken aan te snijden.
Bij het bestuderen van de tagging rondom Wassenaar, kwam ik dit tegen:
Een zandvlakte die duidelijk begroeid is met iets (scrub) van het omringende gebied. [afb. 1]
Op OFM ziet het er als volgt uit.
Waar is al dat zand gebleven? [afb. 2]
In JOSM zie ik dit :
[afb. 3]
Een zandvlakte die doorsneden wordt door de grenzen van een aantal multipolygoon-relaties die daar liggen.
We zien dus dat de standaardkaart (afb. 1) wel de zandvlakte correct toont, maar geen raad weet met de daarop/onder gelegen multi waarvan de scrubsymbooltjes wél, en de kleur niet overkomen.
En OFM (afb. 2) toont de zandvlakte niet correct omdat daar voorrang wordt verleend aan die scrub.
De historie leert dat de zandvlakte later is ingetekend zonder acht te slaan op wat er al lag en omdat de mapper waarschijnlijk ook niet goed begreep wat het gevolg zou zijn.
Omdat zandvlaktes in duinstreken zelden lang op dezelfde plaats liggen, is het heel goed mogelijk dat de oudere multi (met natural=scrub) vroeger correct lag, maar nu kan het rendering probleem simpel worden opgelost door de grenzen van de multis wat beter de huidige werkelijkheid (2015) van die zandvlakte te laten volgen. En misschien nog beter om die zandvlakte toe te voegen aan die multipolygonrelatie.
Ik zal er zelf naar kijken.
Ik zie een grote puinhoop met overlappende landuse.
Daar helpt geen multipolygoon enige mallemoer aan.
Ook die, feitelijk niet bestaande dunne sliertjes ‘vacuüm’ tussen landuses, waar al dan niet een (voet)paadje over loopt; denkelijk het gevolg van oude imports ontsieren.
Mijn advies: wissen en opnieuw intekenen de landuses.
Als iets niet netjes met multipolygonen wordt ingetekend raakt de OFM verward, weet niet wat boven en wat onder moet. Tot nog toe kon ik alleen met tekenvolgorde iets doen (scrub boven duinen, want de bossages zijn meestal kleiner dan het hele duingebied) maar de osm.org kijkt ook naar de oppervlakte van de area (kleiner wordt later gerenderd). Tot voor kort kon ik dat niet maar de laatste mkgmap versie maakt ook dat mogelijk, zie ook https://forum.openstreetmap.org/viewtopic.php?id=56277&p=3 Helaas wordt mijn kaart dan 30% groter wat weer problemen kan geven bij gebruikers met te weinig geheugen en/of oudere GPS, dus vooralsnog ga ik dat niet aanpassen, dan moet men maar beter gaan mappen.
Wel intussen nog iets anders ontdekt, en dat is dat deze complexe tagging waarbij (onnodig) veel over elkaar heen ligt bij Hilverbeek, voor de Duitse rendering geen enkel probleem vormt!
Hier de “deutschen Kartenstil”:
Zo hóórt het eruit te zien…
En hier nog een keer de chaos die Mapnik toont:
Overal bomen waar ze niet horen te staan…
Klaarblijkelijk is het toch heel goed mogelijk om een perfecte rendering te verkrijgen uit een verre van perfect getagde kaart.
Kan iemand verklaren waar die verschillen door komen?
Ik denk dat het gewoon mazzel is dat die Duitse kaart daar de boel toevallig wel rendert zoals jij dat wenst, maar voor hetzelfde geld is het op een andere plek precies andersom. Heeft gewoon met de kleurkeuzes, transparantie en gebruikte symbooltjes te maken.
Hier is de rendering op OFM.
Kun jij bv. verklaren waarom OFM de de grasvlakken aan de rechterzijde wel als gras weergeeft (zonder het boom-icoontje) en waarom dat aan de linkerzijde niet werkt.
Dat is te verklaren. Ten eerste rendert de OFM helemaal geen landuse=grass icm source=3Dshapes ivm ruimtebesparing, de achtergrond van de OFM is sowieso grasgroen dus dit bespaart erg veel diskruimte. Dat rechtervlakje is echter getagd als landuse=meadow, wat wél wordt gerenderd. Verder overlapt dat bos Hilverbeek het hele gebied zonder dat men er een multipolygon van heeft gemaakt. Wordt er netjes een mp van gemaakt dan zie je de open plekken in het bos, óók op de OFM. De Duitse renderer heeft denk ik een regel dat bos eerder wordt gerenderd dan grasland; Mapnik rendert mogelijk ook nog leisure=nature_reserve met die boompjes symbolen?
Vandaag ben ik begonnen aan de klus om de chaos rond Hilverbeek op te lossen. Het is ruim 6 uur werk geweest met veel gepruts en gepriegel en reverts van eigen werk omdat het toch weer fout ging. Het probleem zat erin (en zit er deels nog) dat er enorm veel over elkaar heen ligt en bij een multipolygon hoef je maar één kruisende grens te hebben en het loopt gelijk weer in de soep.
Ik blijf er nog wat aan sleutelen, hier en daar wat grenzen dichter op elkaar leggen en wat schoonheidsfoutjes oplossen.
Het is nu een grote multipolygon geworden waarin alle andere stukken (soms ook weer multis) zijn opgenomen en het rendert in Mapnik nu zoals ik verwacht:
Nu ik weet hoe het moet, kan ik ook de omringende landgoederen opschonen, want dat is net zo erg…
Er zitten nog andere foutmeldingen in het gebied (via Osmose of JOSM), maar die zaten er al in voor ik eraan begon. Die probeer ik ook nog wel weg te krijgen.
Gefeliciteerd, dat was een hele puzzel zo te lezen.
Alle tags op de multi behalve landuse=forest mogen naar de outer lijkt me (of horen al de inners niet bij het natuurgebied?) maar dat is een makkie vergeleken bij de rest van de klus.
Succes met de laatste loodjes.
Volgens mij hoort de landuse=forest inderdaad op de multipolygon-relatie (en niet op de outer); in het bos zitten namelijk gaten waar geen bomen staan maar gras, water enz. is. Daarover verschillen we waarschijnlijk niet van mening.
Ik neem aan dat het natuurgebied alles binnen de outer omvat: het bos, maar ook het gras, water enz.
Dan heeft het natuurgebied dus geen gaten, en is ook geen multipolygon met inners nodig. Het natuurgebied kan dan simpelweg met een vlak met ‘natuurgebied-tags’ beschreven worden. Hiervoor zou je een nieuw vlak kunnen tekenen, maar ook de al aanwezige outer kunnen gebruiken. Het is hier van toepassing dat de outer zelf iets beschrijft (describe something), namelijk de buitengrens van het natuurgebied.
Als er een hek om het hele gebied zou staan, zou je zelfs daarvoor dezelfde outer kunnen gebruiken volgens mij.
Wanneer het natuurgebied wel gaten heeft, wordt het natuurlijk een ander verhaal.
Ah ok, zo zou je het ook kunnen zien. Maar ik denk dat je de multipolygon echter als één geheel moet zien. Dat is een bos met open plekken. Die gaten staan niet los van de outer/buitengrens maar vormen onderdeel van het natuurgebied die de hele relatie omvatten. Daar horen die inners ook bij. Tenzij dat niet het geval is, dus wanneer het grasland als enclave binnen het natuurgebied ligt, dán moet de tag van het park op de outer.
Ik begrijp jouw redenatie, want de outer way omvat ook het hele gebied en zou je ook als grens kunnen zien. Dat is dus een lijnelement, de boundary of barrier die alleen om de buitengrens loopt. Dat mag dan weer wel op de outer. Maar die boundary kan je dus ook zien als een area en dan wordt het lastig waar de tag precies moet, op de relatie of de outer?
JaapK heeft in zijn oorspronkelijk toevoegingen een note toegevoegd:
not 100% sure about the boundaries
En dat geldt ook voor mij. Ik weet bv. niet of boerderij Stofbergen deel uitmaakt van “Hilverbeek” of dat het een zelfstandig bedrijf is. De paden bv. staan daar op access=private.
Ik laat voorlopig even alle tags op de relatie staan en los wat hinderlijke foutmeldingen op.
Gemeente Wijdemeren
Leeuwenlaan (noordzijde; tussen 's-Graveland en Hilversum), 's-Graveland.
Buitenplaats in 's-Graveland.
Landhuis, koetshuis en boerderij Stofbergen.
Eigendom: Vereniging Natuurmonumenten Groot 55 ha
Parkbos, aangelegd in de 17e eeuw, akkers en weilanden.
