Hmmm, ik ben het wel gedeeltelijk met je eens. Maar het is vrij lastig.
Ik vind dat bomen best individueel in een bos gemapped mogen zijn, ookal is er al een bos als area gemapped. Tot het moment dat de bomen zo dicht op elkaar staan dat ze niet meer individueel op de kaart te onderscheiden zijn (al voelt dit wel een beetje als mappen voor de renderer…). Ik zou dit eventueel kunnen meenemen als dat bomen in de dataset minder dan bv 0,5 m van elkaar staan ze niet worden geïmporteerd. Maar ik vraag me af of dat wenselijk is. Want dan krijg je dat bomen die in het open staan maar wel bv in een rij dicht op elkaar staan niet gemapped/geïmporteerd mogen worden…
Een simpele oplossing waar ik zelf als eerste aandacht is alle bomen die in een bos area staan niet importeren (65.000 van de 270.000). Alleen je hebt heel wat bomen in de stad gemapped als bos area ipv als bomenrij of als individuele bomen. En die bomen moeten gewoon geïmporteerd worden.
Dus alomal zie ik niet hoe dit (semi-)automatisch uitgezocht kan worden. De enige optie die ik zie is elke bos area (8.500) individueel checken. Maar tja… dat gaat vrij lang duren en heeft ook niks meer te maken met deze import.
Dat laatste lijkt me juist wel!
Je kan stellen dat die bomengroepen fout zijn, maar degenen die ze juist vinden en zo mappen hebben net zo veel recht om deze mapping (bv een rij bomen als een langwerpige houtopstand taggen, of een grasveld bedekt met bomen als “bomenplantsoen” mappen)) goed te vinden. Het komt erop neer dat in OSM landuse=forest en natural=wood geen minimum- of maximumoppervlak hebben, ook geen verplichte of verboden gebiedsvormen, en dat beide tags betekenen: dit is een gebied of veldje met voornamelijk bomen.
Dus bij een bomenimport zou mijn voorkeur zijn om ofwel van tevoren kijken wat er met het area-object moet gebeuren, en het geschikt maken voor de import of uitsluiten van de import, of regelen dat met zekerheid alles binnen aanvaardbare tijd achteraf bekeken en zonodig verbeterd wordt.
Dat laatste zou met een maproulette missie kunnen, als je een query of dataset kan verzinnen van de na te kijken objecten. Daar kan je dan met een groep mappers aan werken. Ik denk dat de meeste gevallen niet heel moeilijk zullen zijn en vanaf de sofa afgedaan kunnen worden, en dan alleen de moeilijke gevallen met survey.
Zo’n Maproulette missie kan dan bv ook in de Provincie van de maand komen, of misschien als aparte “extra provincie”.
Aha!
Er zijn zo’n 4.000 “closed ways” met de tag natural=wood, landuse=forest of landcover=trees waarin/waarop bomen geïmporteerd zullen worden. Ik heb hier wel een lijst van. Je kan dit alleen niet opvragen met een query, dus weet niet of dat een probleem is voor maproulette. Maar klinkt goed!
Moeten we dan alleen wel met z’n allen goed gaan nadenken hoe we het willen oplossen. Sommige mensen vinden bomen op bos gemapped namelijk prima en anderen vinden dat niet prima. Ook moeten we dan goed afstemmen wanneer we vinden dat er teveel bomen bij elkaar zijn gemapped en het duidelijker aan te geven is met een bos area.
Vroegâh was een natural=tree een speciale boom, die eruitsprong wegens monumentaal of andere bizonderheid, en dan is het niet gek om midden in een bos een paar speciale bomen te mappen.
Maar inmiddels wordt elke losse boom als een natural=tree gemapt. Dan is het vreemd om van een bomengroep elke boom ook nog apart erop te zetten. Of om een boomgebied te vervangen door elkaar verdringende boomnodes. En dan moet niet de import leidend zijn, maar hoe wij in OSM bomen/bossen/bosjes/boomgroepen/bomenrijen mappen.
Ik denk het dan beter is om uit de import nadere kenmerken te halen om aan het gemapte gebied toe te voegen. Die ontbreken nu meestal; soms is er een bladtype en/of een bladcyclus gemapt, maar wat ik ervan tegenkom is dat NL-breed gezien zeer onvolledig en zeer onbetrouwbaar.
MapRoulette missies kunnen gebouwd worden met een overpass query, als de objecten in OSM zitten. Maar je kan ook een databestand als basis voor een MapRoulette missie nemen. Dan kan je bijvoorbeeld met QGIS allerlei vergelijkingen, bewerkingen, selecties en transformaties doen, en het resulterende bestand als databron voor de MR missie gebruiken.
Als ik zeg “je kan” dan bedoel ik “het is mogelijk”. Zelf kan ik dit niet, maar ik heb wel missies gedaan die op die manier gemaakt waren.
Ik denk dat jullie de Amsterdamse details wel de baas worden. Ik wacht dat rustig af in de wetenschap dat Goirle ook een database met veel bomen heeft. Als je iets over bomen vraagt aan de gemeente krijg je een antwoord dat zo ongeveer begint met: u hebt het over boom nummer xxxxxxxxxx is ons bomen GIS.
Weet iemand of de Amsterdamse software en het onderliggende datamodel ook bij andere gemeentes gebruikt worden? Bijvoorbeeld in Rotjeknor, Utrech(t) en Goirle? Ze zullen toch niet allemaal op 1 standaard oplossing zitten?
Als anderen het daar ook mee eens zijn, dat als de bomen dicht genoeg op elkaar staan je ze als bos moet mappen. Dan vind ik dat prima om daar een maproulette voor proberen aan te maken.
Ik vind zelf wel dat als bomen dicht op elkaar staan, maar je er prima tussendoor kan lopen met kleine kinderen dat het dan gewoon als individuele bomen gemapped moet worden. Want een bos op de kaart is in mijn ogen een gebied waar je niet zonder moeite (of überhaupt niet) doorheen kan komen.
Ik kan zoiets proberen als dat ik alle al bestaande bos areas waar nieuwe bomen inkomen in een maproulette zet om die te checken. En dan is het aan de mappers zelf om te bepalen, of ze het bos weghalen en alle bomen laten staan, of alle bomen weghalen en het bos updaten, of alleen de speciale bomen laten staan en het bos updaten. Ik vind het zelf bijvoorbeeld nog best interessant om in een bos de bomen van bv voor 1950 te laten staan, omdat in een stad als Amsterdam dat wel redelijk zeldzaam is.
Maar ik ga dan wel eens uitzoeken hoe ik mijn lijst met way id’s in maproulette krijg. Denk mss wel dat ik wacht met die maproulette aanmaak totdat Noord-Holland aan de beurt is.
Dit is wat in de toelichting van de dataset staat:
Deze [dataset] is gemaakt op basis van een periodieke kopie (september 2023) van de webservice van het gemeentelijk Datapunt. De kaart van het Datapunt is verbonden met de dataset van het gemeentelijk beheersysteem GISIB en geeft daarom mogelijk een recentere weergave.
Bron: GISIB - Beheersysteem Openbare Ruimte, Gemeente Amsterdam, september 2023.
De boomgegevens zijn gestandaardiseerd conform de IMBOR en het Amsterdamse datamodel bomen.
En uhhh, nog een vraag aan de moderators (@Cartographer10 of @Tjuro ?).
Ik had misschien wat beter alles moeten doorlezen, maar moet ik deze stap alsnog volgen of kan ik deze thread updaten?
klinkt niet bij voorbaat geschikt voor gebruik elders.
De Goirlese ‘Groene Kaart’ laat als je inzoomt zien dat ze gebieden met heel veel bomen niet los van elkaar stippen. ‘Beschermde’ bomen (zoals onze 1980 esdoorn) staan erop, maar niet-beschermde (onze 1980 zomereik) niet. Helemaal actueel is de kaart natuurlijk ook niet.
Ik denk dat als je helemaal klaar er voor bent je beter even een nieuw topic kunt maken. Dan voldoe je aan de eisen. Dan link je gewoon even naar dit topic.
Ik kom - zeker in stedelijk Amsterdam - heel vaak grasvelden met een paar bomen gemapped als bos. Ik vind dat een verkeerde toepassing van bos, zoals je zelf ook aangeeft.
Het Amsterdamse Bos daarentegen is voor een groot deel wél bos met bosgrond of struikgewas hieronder. En daar kan je soms gerust doorheen lopen. Dit zullen de uitzonderingen op de regel zijn
natural=wood en landuse=forest geven OSM-breed allang geen “echt” bos meer aan, maar alleen “hier staan bomen”. Er zijn vele pogingen gedaan om het gebruik te beperken tot “echt bos”, met vele verhitte discussies tot gevolg over waneer een groep bomen “echt bos” is, of er verschi is tussen wood en forest, en vele andere punten (zoals welke grondbedekking er onder de bomen moet groeien om een bos te zijn) waarover de opvattingen verschilden, en bleven verschillen.
Er zijn telkens oplossingen voorgesteld, tegenstrijdige/aanvullende/allevorigeomvattende voorstellen, die er steevast toe leiden de de nieuwe oplossing als extra oplossing in de wiki aan de al bestaande lijst wordt toegevoegd, en dat er in de OSM-database niets verandert. De enige gemeenschappelijke basis waar alle mappers en data users het over eens zijn, is wat ik al zei: beide tags betekenen dat er (overwegend) bomen staan. Waarbij er ook nog niet helemaal (helemaal niet) vaststaat wat “overwegend” inhoudt.
Toch pak ik dan graag terug op een definitie zoals die ook door de naslag werken wordt gebruikt. En omdat OSM vanuit het Brits Engels werkt; ook die definitie:
Waarbij een Forest groter is dan een Wood; en de definitie van Wood als:
Woodland may form a transition to shrubland under drier conditions or during early stages of primary or secondary succession. Higher-density areas of trees with a largely closed canopy that provides extensive and nearly continuous shade are often referred to as forests.
Woodland is used in Britishwoodland management to mean tree-covered areas which arose naturally and which are then managed, while forest is usually used in the British Isles to describe plantations, usually more extensive, or hunting Forests, which are a land use with a legal definition and may not be wooded at all.[7] The term ancient woodland is used in British nature conservation to refer to any wooded land that has existed since 1600, and often (though not always) for thousands of years, since the last Ice Age[7] (equivalent to the American term old-growth forest).
Merriam-Webster
a dense growth of trees usually greater in extent than a grove and smaller than a forest —often used in plural but singular or plural in construction
Dus De Veluwe zijn wat mij betreft een Forest; en het Amsterdamse Bos zo je wilt ook. En met een stretch is een groepje bomen met daaronder struikgewas of zelfs gewoon wat aarde en hoog gras en andere planten een Wood.
Maar een keurig grasveldje met 3 of 4 bomen erop is precies dat wat het is.
Maar dit is m.i. dus geen wood en geen forest; maar gewoon een grasveld met bomen. Eventueel zou je met landcover=trees dit aan kunnen geven; maar voor die paar bomen geef ik de voorkeur om die paar bomen aan te geven.
Bij gebrek aan een beter tag en voor de ‘luie’ mapper (waar niets mis mee is overigens); zou je dit met Wood kunnen taggen; hoewel ik het eerder natural=shrubbery met een paar bomen vindt:
Alleen al de verscheidenheid aan definities en kriteria laat zien dat er geen algemeen acceptabele afbakening gaat komen. Welke definitie je ook kiest, anderen kiezen met evenveel recht een andere. Daar komt nog bij de verschillende inschattingen en voorkeuren van mappers en communities, vaak gebaseerd op eigen omgeving/regio/land… En de meeste kun je geen ongelijk geven, vanuit hun oogpunt. Kortom, er staan bomen, dat is de grootste gemene deler.
De beste benadering vond ik nog om forestry te gebruiken voor gebieden waar daadwerkelijk bosbouw plaatsvindt. Dan heb je een landuse, die ook goed samengaat met verschillende naturals (wood, water, grassland, scrub) die je in een bosbouwgebied kan aantreffen.
Helaas probeerde dat voorstel om een aantal extreem veelgebruikte tags deprecated te maken, en het wapperde dacht ik ook tussen het gebruik van landuse=forestry en boundary=forest. Daardoor had iedereen wel wat om bezwaar tegen te hebben, oftewel tegen te stemmen, wat de kansen heel snel laat kelderen.
Althans, dat is mijn herinnering eraan.
Toch zijn Wikipedia, Merriam-Webster de Cambridge dictionary en de United Nations Food and Argriculture Organization niet ‘zomaar’ meningen. En die zijn het er wel over eens dat een Forest significant groot is en in ieder geval groter dan een Wood wat dan in ieder geval meer is dan ‘een groepje bomen’ wat dan weer een Grove zou moeten zijn.
En er zijn ook bronnen die een ander onderscheid maken, bijvoorbeeld percentage grond dat onder de bladkroon valt, of andere kenmerken van het ecosysteem onder de bomen, of de oorspronkelijkheid/ongereptheid van het bos.
Een “officiële” indeling naar grootte, dat zou een van de vele indelingen kunnen zijn. Maar wat zijn de grenswaarden? Wordt een forest ineens twee woods, of wordt een wood ineens twee groves als je er een brandgang met track doorheen mapt, of het opdeelt in kavels of landgoederen? Hangt dat ook van vorm, dichtheid en/of boomsoort af, en/of van wat er onder de bomen nog groeit? En/of van de landstreek waar het ligt, en of er al dan niet aan bosbouw gedaan wordt of andere soorten onderhoud?
Trend: Naarmate er meer gedetailleerd gemapt wordt, worden oppervlakken in telkens kleinere stukken gedeeld.
En hoe krijg je de bestaande database aangepast zodat de mapping redelijk betrouwbaar wordt op dit punt? Dan zou je de hele OSM-gemeenschap achter deze indeling moeten krijgen, en een automatische edit moeten doen die alle forest en wood omtagt naar oppervlakte. En een bot in de lucht brengen die dat blijft doen, natuurlijk. En alle editors, presets en QA-tools aanpassen. Gaat dat gebeuren? Tuurlijk, waarom niet!
In de praktijk gaat dat niet gebeuren, en blijft het: landuse=forest en natural=wood zijn voor data users precies hetzelfde, namelijk: “hier staan vooral bomen”. En het zegt niets over andere kenmerken, waarbij het ook niet uitmaakt of en welk onderscheid de mapper mogelijk bedoeld heeft.
Dat neemt niet weg dat je grootte zou kunnen gebruiken om mogelijke fouten op te sporen. Bij de zoektocht naar valse village_greens was er een osmose test op grootte: een heel klein oppervlak getagd als village_green is vermoedelijk geen echte village_green (brink, meent, es, nes) maar een stukje opvulgroen (hedge area, shrubbery of greenery). Ik kan die wel weer eens bekijken, er zal inmiddels wel weer eea verkeerd getagd zijn.
Je blijft altijd grens gevallen houden. Een bos waar een brandgang doorheen loopt blijft een bos. Zelfs als er een doorgaande weg doorheenloopt of wat mij betreft een snelweg dan is het nog steeds een bos.
Dit zal je niet snel kunnen automatiseren, want er bestaat teveel grijs gebied. En dat is ok en dat hoeft ook niet. Maar het begint er m.i. wel mee dat je duidelijk afspraken en onderscheid maakt tussen de verschillende waardes. En gelukkig hoeven wij die consensus niet per se wereldwijd te maken.
Dus het volstaat als we hier in de Nederlands community enige consensus over bereiken. Ik denk dat Nederland wat dat betreft sowieso een beetje afwijkt van veel andere landen:
Nederland is exteem georganiseerd; nagenoeg elk stukje landoppervlak is bekend en beheerd.
De Nederlands Overheid investeert in een gedetaileerde open data vwb kadaster, BGT, BAG, PDOK etc… natuurlijk is het in de ene regio duidelijker dan in de andere; maar er zijn maar weinig landen die dit met deze kwalitieit en detail niveau doen en kunnen doen.
En dan kan je het going forward consistent gaan toepassen.
Hier ben ik het wel mee eens. Dat de wereldwijde de community geen consensus kan bereiken betekent nog niet dat wij dat binnen Nederland dan ook niet kunnen.
