Bos in openfietsmap verdwenen

Volgens mij zijn sinds kort de stukjes bos verdwenen in OFM als ik ze gewoon over het gras of farmland heb getekend. In mapnik rendert het wel… in OFM niet meer. Alleen als ik multypolygonen gebruik krijg ik m’n bossages weer terug denk ik bij de volgende update van OFM.

http://www.openstreetmap.org/#map=18/51.76927/4.68202 … hier en voorbeeld uit de Louisa- en Cannemanspolder. Nu kom ik eigenlijk steeds bij toeval weer een stuk bos tegen dat verdwenen is in OFM.

edit: beetje verkeerd voorbeeld, want het zijn 3d-shapes. Hier het Herdenkingsbos http://www.openstreetmap.org/#map=19/51.76386/4.68389 Over het “grass” heengetekend. http://www.openstreetmap.org/#map=19/51.76386/4.68389 Nu als multipolygon forest ( role inner) Op de OFM van 21/12 niet te zien, als multipolygon denk ik dadelijk wel.

Met heide en bos heb ik ook ruzie. De combinatie heath (Multipolygon outer) en forest (multipolygon inner) resulteert in één groot bosgebied… Ook de heide wordt dan weer bos.
Van de Cartierheide bij Eersel heb ik de multipolygonen maar weer even afgegooid. De ingebedde bossages zie je dan in OFM niet. http://www.openstreetmap.org/#map=16/51.3350/5.2732
Wel in Mapnik.
Wie weet de oplossing? Is er wat veranderd in OFM of heb ik het altijd fout gedaan en is het mij niet opgevallen? Gewoon een stukje bos tekenen over Farmland of grass gaat dus niet meer.
Eggie

Deze vraag is gisteren al beantwoord:

10 Mappingtipps für Fortgeschrittene (oder: Wie ärgere ich meine Mitmapper)

7. Benutze Multipolygone III
Fordere den Renderer heraus und trage die Tags nicht in das MP ein, sondern nur an die outer-ways; gerne auch unterschiedlich. Wozu haben wir denn so tolle Programme und teure Hardware?

Eén van de meest misbruikte OSM dogma’s is: “don’t map for the renderer/router.”

Maar er is een meer basaal dogma, dat wél altijd geldt: Garbage In, Garbage Out (GIGO)!

Je hebt stukjes bos “gewoon” over het gras of farmland getekend…

Probeer je eens de discussie voor te stellen tussen mapper en renderer.

Renderer: “ik zie farmland, dat zet ik op de kaart en klaar.”
Mapper: “fout, want er zit nog een stukje forest in.”
Renderer: “o, ok, dus als ik landuse zie moet ik nog even verder kijken of er nog iets andere bovenop ligt? Zoals ik al doe bij buildings, swimming_pools en parkings?”
Mapper: “Ja, natuurlijk! Logisch toch?”
Renderer: “ok, maar wat teken ik dan bovenop? Forest of farmland?”
Mapper: “domme vraag. Heb je wel eens farmland bovenop een forest zien liggen?”
Renderer: “ok, maar kun je dat dan aangeven met [layer=-1] of [layer=1]?”
Mapper: “dat is mappen voor de renderer en dat mag ik niet. Bovendien is dat niet overeenkomstig de werkelijkheid.”
Renderer: “o, maar ik ken wel mappers die dat wel doen.”
Renderer: "dus er bestaat een logisch hierarchie van objecten? Zoiets:

  • Forest > grass
  • Scrup > grass
  • Scrup > meadow
  • Farmland > grass
  • Water > grass, forest (O, water ligt ook altijd bovenop? Net als forest?)."
    Mapper: “ja precies.”
    Renderer: “Maar dus wel water > forest?”
    Renderer: “ok, maak maar een tabel met Meta Data waarin dit vastligt.”
    Mapper: “Meta Data???”
    Renderer: “trouwens als je zegt dat scrup > grass, wat doe ik dan als er een stukje grass in een groter gebied met scrup ligt?”
    Mapper: “weer een domme vraag…”

Enz. enz. want de discussie is nog lang niet afgerond. En dit is een discussie (stappen in het script van een renderer en in de onderliggende software) die bij iedere landuse, iedere multipolygon weer opnieuw moet worden gevoerd.

In het voorbeeld van OFM. Ik weet het uiteraard ook niet zeker, maar wat zou kunnen…
Jaren geleden heeft OFM een grote winst geboekt door gras niet meer te renderen. Dankzij deze beslissing is OFM nu nog steeds (iets) kleiner dan 1 GB.
Maar stel nu dat de onderliggende software (is dat mkgmap?) heeft bedacht dat er een keer een grens wordt bereikt bij de tijdrovende activiteiten om van garbage nog iets redelijks te maken?
Dan wordt het grass nu niet meer gerenderd (keuze van OFM) en “dus…” ook niet meer het landuse dat hier weer bovenop ligt.
Probleem voor de Renderer? Of voor de Mapper?

In het voorbeeld van multipolygonen.
Kijk hier eens: http://wiki.openstreetmap.org/wiki/Relation:multipolygon
Soms durf ik er niet eens aan te beginnen. Een bos op een eiland dat gedeeltelijk samenvalt met de oever van het eiland. Pfft… want Inner en Outer mogen elkaar wel raken, maar niet overlappen.

Ander voorbeeld:
Vijver in een weiland. Vaak is de vijver een duplicate shape: Inner van de multipolygon én [natural=water].
Binnen JOSM kun je dan het probleem van de renderer goed zien: het water is groen, de transparante som van water + grass.
Pas op het moment dat ik de de huidige Inner verwijder en de [natural=water] toevoeg als nieuwe Inner is het water blauw!

Ander voorbeeld:
Enige tijd geleden waren wij water-dingen verkeerd aan het mappen. Hele gebieden stonden onder water. Gelukkig voor ons: de renderer is niet te beroerd om te renderen voor de mapper. Onwaarschijnlijke overstromingen werden door de renderer letterlijk ingedamd.

Ander voorbeeld:
Sommige mappers breiden een [natural=water] niet uit. Te veel werk? Ze tekenen er gewoon nog een nieuwe [natural=water] overheen die ook gewoon over het grass heen wordt getekend.
Potlatch en ID vinden dat allemaal prima en die JOSM jongens een meisjes vinden het leuk om vervolgens te corrigeren. Toch?
Niet dus (wat mij betreft): Wie ärgere ich meine Mitmapper.

Ha Eric,

De spagaat die de mapper en/of de renderer moet maken begrijp ik. Die discussie volg ik. Als beginnende mapper jaren geleden alweer (en die zijn er toch meer?) ben ik optimistisch begonnen om die stukje bos heel simpel over gras-, bouwland te mappen. En ja… een week later te zien op de ofm. Van multipolygonen of relaties had ik nog nooit gehoord. Je hebt er dan geen idee van. Ik tekende braaf de vijvertjes en het bos over het onderliggende grondgebruik heen. Daarna werd alles weer ingehaald door de 3d-shapes. Mijn eerste simpele stukjes bos waren niet eens meer nodig. Ja… soms wordt er weer een stuk bos aangeplant. Uit gemakzucht tekende ik dan het bos over het grondgebruik heen. Dat gaat dus niet meer. :slight_smile:
Nu los ik het op met de multipolygonen. 'k Denk niet dat een beginnende mapper, uitzonderingen daargelaten, daar aan denkt.
Nu zit ik met de erfenis uit het prille verleden. Als ik iets weer tegenkom verander ik het. Das Ärgern war selbstverständlich ohne Absicht. :sunglasses:

Overigens uit die combinatie heide / bos kom ik nog niet uit. … en dat waren al 3dshapes. Overal ontbreekt de heide. In Brabant ben ik van tijd tot tijd bezig die hei weer tevoorschijn te toveren… maar nu die stukjes bos weer terug.

Selbstverständlich…! :wink:

Eggie, klopt, ik heb inderdaad onlangs wat veranderd in de tekenvolgorde van bossen en graslanden omdat men in Oostenrijk gigantische bosgebieden op OSM heeft geimporteerd, daarbij alles bedekkend wat er bovenop is getekend (oa grasland). Fout in OSM want eigenlijk moet je zoiets netjes oplossen met multipolygonen. Snappen ze niet, vinden ze te ingewikkeld. In Frankrijk plempt men gigantische landbouwgronden in OSM, zelfde probleem.

Jouw probleem is dus net andersom, stukje bos bovenop een grasland. De renderer weet dan niet meer wat nou bovenop wat ligt. Layer-1 of +1 zou mooi zijn als die dat snapte maar dat is helaas niet het geval. Voor domme renderers als bv Garmin heeft men de multipolgoon methode ingevoerd en dat werkt prima, mits men zich daar aan houdt. De Oostenrijkse en Franse mappers vinden dat echter teveel werk, te ingewikkeld en doen dat dus niet altijd. Een kleine aanpassing in de tekenvolgorde van de OFM (eerst bos, dan gras of akkers) lijkt daar dus te werken maar bij jou heeft het dus een averechts effect gehad, maar als je dat oplost met mp’s (waar je denk ik al mee bezig bent?) komt dat wel goed.

Ha Ligfietser,

Layer +1 had ik uiteraard ook al geprobeerd. … en het park in "grass omgezet… "Wie ärgere ich uzw… :smiley:
Ben nu aan de multipolygonen verslingerd… Hier kom ik wel uit.

Zelf denk ik dat m’n multipolygonenprobleem met het heide / bosgebied ontstaat doordat de outer-mp’s meer relaties hebben op de perceelgrenzen.
Maak ik een boseiland role=“inner”… dan wordt het heidegebied(met gedeelde buitengrens) role= outer weer bos, terwijl de tag natural=heath is.
http://www.openstreetmap.org/#map=19/51.33710/5.27016

Eggie

edit: Veel bos zal ik niet bijvoegen… Dat doet er immers jaren over om wat te worden. Wat nu aangeplant wordt haal ik niet meer in mijn leven. :slight_smile: 'k Heb zelfs in de Louisapolder een heel stuk beginnend bos weer weg moeten halen omdat het door de reeën was kaal gevreten. Nu is hier een begin gemaakt met een “herdenkingsbos”. (Vrees dus ook voor dit bos) Als ik dat niet gecheckt had na mapping was het “niet-renderen” me niet eens opgevallen.

Als ik even deze als voorbeeld neem: http://www.openstreetmap.org/relation/3391188
Beste manier om een mp te taggen, is de relatie taggen met landuse=grass en leisure=park en niet op de outer way.

Zie http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Valid_Multipolygon_conditions
Tags describing the multipolygon (e.g., landuse=forest) should go on the relation. The outer way(s) should be left untagged, unless they describe something in their own right. For example, a forest could be delineated by four fences, in which case the four ways would be tagged with the barrier tag, but could still be used as “outer” members of the forest relation.

Hoe dat precies met die andere relatie (heide / bos) weet ik niet, om welke relatie gaat het precies?

http://www.openstreetmap.org/way/86053782#map=19/51.33671/5.27537&layers=D

De multipolygonen heb ik er af gegooid, want het effect was negatief. (alles bos) . Dit boseilandje (en de eilandjes links) in de heide is zelfs in de mapnik niet te zien. In de vorige versie was ook de heide één groot bosgebied. Nu is het wel heide, maar de losse boseilanden ontbreken. Wanneer ik ze in een relatie zet wordt de heide weer als bos gezien in de mapnik. Renderen gaat uiteraard traag bij zo’n groot gebied. Het resultaat laat dan op zich wachten.
Het is in ieder geval al beter dan op vorige ofm versie. Nu is er in ieder geval heide.

edit: en met “eraf gegooid” bedoel ik de relatie.

hier http://www.openstreetmap.org/way/86052791#map=16/51.3331/5.2731&layers=D het hele gebied.

Soms duurt het héél lang voordat zoiets goed wordt gerenderd op Mapnik, een eilandje ergens in Zeeland duurde weken.
Hou daar dus rekening mee en geef de moed niet te snel op :wink:

Ik snap niet dat als je weg 86052791 in een relatie stopt als outer way (geen tags), en de kleine stukjes bos als inner way (met landuse=forest), dat dat niet goed gaat?
De relatie krijgt dan natural=heath en type=multipolygon. Werk je met JOSM? Is wel aan te raden want niet te doen in Potlatch.
Selecteer gewoon alle leden en klik op Gereedschappen>Multipolygon aanmaken, en Josm doet de rest, kiest keurig de outer en inner ways zelf.
Zie https://www.dropbox.com/s/r905i2ao2rb42sg/heide.jpg

Als je het goed vind zal ik 'm uploaden (doe ik nu niet want misschien ben je er al mee bezig)

Ben een potlatcher… Zal het nog eens op mijn manier proberen. Zal een seintje geven als het af is. Doe het eigenwijs toch even met potlatch.

Wat bedoel je met 86052791… Daar zou dan toch de tag natural=heath op moeten?

Ligfietser,

'k Heb met potlatch2 alles in de relatie gezet multipolygon 3393792. Het meest rechtsgelegen boseilandje van de reeks van vijf had plots een ander relatienummer, maar daar heb ik weer 3393792 van gemaakt.
Ben benieuwd of de heide heide blijft.
Zou jij eens kunnen kijken?

http://www.openstreetmap.org/#map=18/51.33577/5.27413

Van weg http://www.openstreetmap.org/way/86051143 ontbreek de inner role.
De outer way heb je nog steeds als natural=heath maar die moet op de relatie, daar ontbreekt natural=heath
Verder zou ik toch echt Josm willen aanraden voor dit soort werk, is een stuk eenvoudiger.

Ik geef het even op met potlatch. Daar kan ik nergens vinden de relatie (de selectie? ) waar ik de tag natural=heath op kan zetten. Kan natuurlijk wel op de outerway de tag heath weghalen, maar waar is dan de relatie te vinden waar die op moet. Ongetwijfeld zal ik iets over het hoofd zien. :roll_eyes:

Dubbelklikken op de relatie (zie je linksonder in het advanced scherm)

Vervolgens krijg je een edit box, met onderin weer een advanced menu, waarin je wat tags kwijt kan.

'k Ga 't proberen.

in (box) advanced toegevoegd natural = heath… ben benieuwd. bedankt zover! (Als het lukt doe ik de rest van de heide ook)

edit: De Louise = en Cannemanspolder ook zo gedaan. Leisure=park van de outerway gehaald en nu op relatie gezet.

Die krijgt nu alle kleuren, want ik had grass per abuis laten staan naast Leisure = park. Zie nu alle kleuren groen verschijnen en zelfs wit.
http://www.openstreetmap.org/#map=16/51.7680/4.6864 Ziet het er niet uit dan corrigeer ik wel.

Nog niet helemaal goed, je hebt nu de relatie toegevoegd als member aan de relatie kijk maar op http://www.openstreetmap.org/relation/3393792
Hoe je dat doet is me een raadsel, misschien een bug in Potlatch en ik krijg die met Potlatch ook niet meer weg.
Ik zal 'm met Josm eruit halen ok?

Graag… ik had eerst de relatie in de box bijgevoegd. Fout dus. Daarna verdween die input vanzelf, maar kennelijk niet in potlatch zelf. De hei wordt al weer groen. Dat zal ik ook wel hebben gedaan met de louise en cannemanspolder., http://www.openstreetmap.org/#map=18/51.76652/4.68433 want die wordt al weer wit.

Ik heb even alle stukjes heide daar in josm bewerkt en in mp’s gezet.
In een paar minuten gebeurt (maar niet geupload). En toen een OFM kaartje van gemaakt.
Zoek de verschillen (links de BNL van gisteren, rechts het resultaat in Josm, let even niet op de ontbrekende hoogtelijnen in het kaartje rechts)