Utrecht bomen import project

Ik ben bezig met het opzetten van een project om de bomen van de gemeente Utrecht te importeren. Het project staat hier op de wiki: https://wiki.openstreetmap.org/wiki/Utrecht_tree_import.

Uiteraard hoor ik graag of dit een nuttig project is en op welke zaken ik moet letten. Als je even snel de data wil bekijken staat het op deze kaart: https://gemu.maps.arcgis.com/apps/webappviewer/index.html?id=53c67672c1fa46e5bef555a611b58301.

Zie ook de eerdere discussie hierover:
https://forum.openstreetmap.org/viewtopic.php?id=58126

Kijk ook even naar wat we in Leeuwarden gebruiken: https://github.com/jdhoek/bomen-leeuwarden-osm

Dit is een dataset uit 2015 (enkel monumentale bomen); ik hoop in de loop van dit jaar een update te kunnen vrijgeven (zal de gemeente weer eens achter de broek zitten). Door de dataset als OSM-bestand aan te bieden kan een mapper die vanuit JOSM gebruiken om bepaalde bomen te kopiëren naar de kaart.

Tip: gebruik de dataset enkel ondersteunend voor de eigen observaties van de mappers (ter plekke of satellietbeelden indien herkenbaar); vermijdt een massale import. Als je een stukje stad aan het verrijken bent is zo’n set handig om te hebben, zeker als de tags al goed staan (zie daarvoor ook de documentatie van de Leeuwarder bomenset hierboven). Je kan dan gelijk zien of de wegen wel goed genoeg uitgelijnd zijn (en ze dus niet bijna door de boom heen lopen op de kaart), en of er geen andere gemapte objecten zijn waarmee je botst.

Zo’n dataset is mooi gereedschap voor lokale mappers, maar volledige imports maken op dit detailniveau vaak meer kapot dan wenselijk door duplicaten en fouten door een gebrek aan verificatie. Ik kan de Leeuwarden-methode van harte aan raden.

Eens met Jeroens advies. Geen massale import “omdat het kan”

Utrecht stelt haar bomen beschikbaar als CSV download via Dataplatform https://ckan.dataplatform.nl/dataset/afa19ac8-e63e-4e27-a42e-3bb4f9082c59/resource/2d6893b4-d56d-4865-b6cc-0bda42e547f5/download/20200415bomenkaart-csv.csv. Ook de BGT die je bij het Kadaster kan ophalen bevat bomen van de gemeente Utrecht. Rest inderdaad de vraag of je zulke bulk-imports wilt toevoegen aan OSM…

Ook ik ben geen voorstander van massale bomen imports, het heeft mijn inziens niet veel voordelen voor osm.
Wel ben ik voorstander om eventuele monumentale bomen, of “mooie” solitaire bomen in OSM aan te brengen.
Het gevaar alleen al dat de data snel verouderd bij een massale import, geeft bedenkingen.

Het is een woordkeus die je gebruikt. Maar “even snel” is niet de doelstelling van OSM lijkt mij.
Alhoewel sommigen heel snel een porselijnkast binnen rennen, omdat het kan…, met alle mogelijke gevolgen vandien.
Er zijn legio voorbeelden geweest.

Verder wil ik niet aan je vaardigheden twijfelen, maar soms wordt er geïmporteerd terwijl de basiskennis niet aanwezig is.

Mijn pogingen in de richting van import zijn uiteindelijk allemaal handmatige invoer geworden, in series, dat wel. Grootste problemen:

  1. De exacte locatie. De coördinaten klopten zelden precies.

  2. Objecten met gegevens al aanwezig in OSM. Je wil geen al ingevoerde gegevens overschrijven, dus je import moet vaststellen dat het object op of bij die locatie al in OSM staat, en dat dan overslaan of updaten ipv importeren.

Met name van punt 2 zie ik niet hoe je dat kan automatiseren tijdens een import.

Ik kan wel verzinnen hoe het beter zou kunnen, maar dan heb ik iemand nodig die goed kan programmeren met OSM-data. En dan zou ik voor een generieke import-tool gaan die de OSM-dataset-vergelijking kan doen en minimaal een concordantielijst oplevert met al bestaande objecten die dus niet geïmporteerd gaan worden. De vergelijkingskriteria moet je dan per dataset instelbaar maken in termen van objecttypes, tags en locatie (afstand).

Het was zeker niet mijn bedoeling om de indruk te geven dat ik even snel deze import wilde doen. Het ging mij hier vooral om mensen die nieuwsgierig waren naar de data en deze even wilden bekijken. Als ik één ding weet is dat een import doen vooral met goede afwegingen moet gebeuren, daarom ook deze discussie :).

Ik ben ook met OSM en bomen bezig. In Parijs staan 93.000 bomen in OSM, in Ottawa 150.000, Bologna 84.000. In Nederland scoort Lelystad het hoogst met 28.000.

Ik werk aan een site waar javascript een json bestand (uit Overpass) parset en de data als layer op een OSM kaart zet.
Detail in Parijs, een park: https://infodisiac.com/trees2/osmtreefinder.html?data=trees_paris_PdBC_c.json
De hele kaart van Parijs (even geduld voor alles binnen is): https://infodisiac.com/trees2/osmtreefinder.html?data=trees_paris_c.json

Ik kwam er pas vrij laat achter dat er eigenlijk al een betere oplossing bestaat: opentrees.org
15,331,460 open data trees from 226 sources in 20 countries. Dat zijn dus allemaal open data, maar lang niet allemaal uit OSM. Utrecht staat er ook in. Maker dezes heeft een eigen tile server.

Ik vind het een interessant project. Ik vraag me wel af of er dan ook groepen bomen geïmporteerd gaan worden die je liever als landuse=forest wilt weergeven.

Massaimport lijkt inderdaad zelfs mij niet verstandig, handwerk stukje bij beetje waar je de rest van de omgeving ook meteen opknapt is beter.

Ik had het al eerder met een andere mapper gehad. Een bulk import bomen is niet handig. Wie gaat deze databank bijhouden als de gemeente, aannemer of via een botsing een boom verloren gaat? In het najaar worden traditie getrouw veel bomen gezaagd. Zo zijn er in Utrecht stad vanaf 1okt al 500 bomen gezaagd. Ik zie het niet gebeurden dat iemand deze gezaagde bomen gaat controleren en aanpast van de kaart.

Bomen die een bepaalde status hebben kunnen m.i. handmatig op de kaart worden gezet.

Handmatig bijhouden lijkt me inderdaad ondoenlijk. Als die bomen uit een bestand worden toegevoegd, dan is hopelijk er over een of enkele jaren ook een ge-update bestand. En kan vergelijken van die twee versies een verschillenlijst opleveren. Of die nieuwe lijst vergelijken met alle bomen waarbij de oude lijst als bron genoemd is in OSM.

Er zijn dus steden waar zo’n beetje alle bomen uit externe bestanden zijn opgevoerd, van de plantsoenendienst neem ik aan. In Parijs staan 93.000 bomen in OSM, in Ottawa 150.000, Bologna 84.000. In Nederland scoort Lelystad het hoogst met 28.000.

Daarom teken ik zelf meestal tree_row’s in plaats van individuele bomen.

Dit is in feite wat we met de BAG import voor gebouwen doen, maar in de praktijk is het technisch gezien toch wel lastig. Vergis je daar niet in. De software ondersteuning voor dit soort semi-automatische imports is naar mijn inziens toch nog wel wat gebrekkig, en je zit met het probleem dat mappers buiten een importproces om ook veranderingen doorvoeren.

Misschien is dan een massa-import iets te grootschalig. Is het een idee om in plaats van één alomvattende import een reeks aan kleine imports van bijvoorbeeld alle bomen in één park tegelijk toe te laten? Dat lijkt me makkelijker te controleren en zo zorg je ook dat je minder losse bomen importeert die je liever als landuse=forest of natural=tree_row zou mappen.

P.s. Ik zit dan te denken aan imports op aanvraag zoals de BAG updates die we nu hebben. Dan kunnen mappers geleidelijk stukken invullen en ook valideren.

Ik weet niet precies welk nuanceverschil je bedoelt tussen massa-import en een alomvattende import. Het lijkt mij dat die twee toch erg veel gelijkenis tonen.

Individuele, markante, bomen okay, voor de rest lijkt mij landuse=forest voldoende.