Last week the Red Cross put up some imagery of two cities in northern Uganda. The towns are being armchair mapped by tracing buildings and trees over the city and Red Cross volunteers will be on the ground in a few weeks to collect information to fill in the map details.
One of the goals of the mapping project is to measure the fire risk within the city. Gulu has thousands of small circular huts with grass roofs, many of which are densely clustered together. Furthermore, there are quite a few trees throughout the city and in a fire these could burn as well.
The mapping of the city is progressing rapidly, roads are mostly done and the buildings are nearing completion as well. Tree coverage is almost 100% in the areas that are mapped, but only about 30% of the city’s area has been covered for trees yet.
I have been working out an efficient workflow for mapping the rest of these trees (and any other ones people want to map) efficiently and accurately. I do the work in two passes. First, I just go through an area and put down untagged nodes on all the trees in the area (going methodically to make sure all are done in one pass). Holding down shift in add mode lets you just do a single click for each tree, very easy to do lots of them quickly like this. Then I click the upload button in josm and cancel the upload so the validator lets me select all the untagged tree nodes and add tags to them (this can be done with all of them in a single operation by double clicking on the group name to select them all). After all the newly created trees have been properly tagged I upload them to the server so they are visible to other mappers so they won’t duplicate them in their own mapping efforts.
The second pass is the more interesting one. After all the trees in a given area have been marked, I make a second pass over the area to measure the crown diameter of all the trees. The crown diameter is the side to side width of the leafy area at the top of the tree, i.e. it is how big of a circle it looks like on the ground when you look straight down at it. Knowing the crown diameter of a tree tells you how much fuel would be available in a fire, as well as giving you a rough estimate on the tree’s height and age as well. Therefore making this single measurement for each tree in the dataset makes the tree data far more useful for planning and mapping purposes. It also makes it useful to hide small trees (for example ones with a diameter of less than 8 meters at the lower zooms), or to draw them as circles on the map scaled to their proper size.
There are currently about 10,000 trees mapped in Gulu, and almost exactly half of these have had their diameters measured using the following process (I estimate there are approximately 40,000 trees in the city in total). I start by loading up the josm paint style in the picture below and setting the “inactive” objects color to bright green in the preferences panel (hotkey F12). Then I load in the trees queried from the overpass API, as well as barrier=hedge, landuse=forest, and natural=wood as a layer called ‘Trees.osm’. Then I create a new layer called ‘Tree diameters.osm’ and when I switch to this layer, the other layer becomes inactive and so all the trees without diameters show up as solid bright green dots that are easy to see, and trees whose diameter have already been entered show up as open circles of the appropriate diameter. Then to measure the diameters I draw a single, 2 node way across each unmeasured tree, putting these untagged ways in the ‘Tree diameters.osm’ layer. You can easily check that you covered all the trees in an area by doing a select all which will draw all your measurement lines in red and these should exactly cover the green dots for unmeasured trees in the area of interest.
This measuring goes pretty fast. I can typically measure about 1,000 trees per hour using this technique. After I have an area covered by these measuring lines, I save the file containing the lines and run a perl script on it that measures the length of every line in the dataset and writes a new osm file containing a single node at the midpoint of every line in the original osm file, with the node positioned at the midpoint of the line, with a tag containing the measured length in the diameter_crown=* tag. This new file is called ‘Tree measured.osm’ and a new instance of josm is launched with 2 layers, the ‘Trees.osm’ layer downloaded from overpass, and the ‘Tree measured.osm’ layer containing nodes with the measured diameters tagged on them.
The final step is using the conflation plugin in josm to merge the tag from the measured layer, onto the node for the tree it corresponds to. The conflation plugin is configured using ‘Trees.osm as the reference layer, and ‘Trees measured.osm’ as the subject layer. I just leave the max distance at the default of 20 meters as it doesn’t really matter since the resulting diameter nodes end up being within about 2 meters of the appropriate tree anyway (much closer than the distance to other trees in the dataset). The conflation plugin will match them up perfectly, due to the excellent agreement in position of the nodes and goes very fast; the only annoyance is at having to click the ‘Apply’ button on the tag conflict window for each of the thousand or so trees I am entering at a time. With the clicking for each tree this part of the process takes about 5 minutes, but would take less than a minute for any number of trees if the conflation plugin would just silently merge the tags when there are no real conflicts (i.e. just adding a new tag).
Once the conflation is finished the ‘Tree measured.osm’ layer which now has the newly measured diameters tagged onto the original nodes in the OSM DB with the position and source information is uploaded back to OSM. After this is completed I wait a few minutes and re-download the ‘Trees.osm’ file from overpass to get a single file with everything nicely merged together. :)
Below is a screenshot of the JOSM paint style I use for this work (trees with diameters are shown as green circles, trees without diameters are filled yellow circles).
Finally, what do you do when you are finished making a geodatabase with the crown diameter of 5,000 trees over a city, that’s right… science! I wrote a little script using grep and sed to cut out the diameter data from the osm file I get from the overpass query and then wrote a gnuplot script to fit a curve to the data and plot the results. The plot below is the size distribution of the measured tree diameters (in meters). The points are the number of trees in each 0.1 meter bin (the data is rounded to .1 meters as more than this is unnecessary). The green line is a bezier smoothed version of the raw distribution data, and the thicker blue curve is a lognormal curve fit to the raw bin counts. The data seems to be very clean and the curve ends up fitting rather nicely. I haven’t calculated the mean of the distribution but it would be interesting to see what it (and the other relevant statistics end up being). Parameters for the lognormal fit are as follows:
lognormal(x, mu, sigma, scale) = (scale/(xsigmasqrt(23.14159))) * exp(-1.0((log(x)-mu)2/(2*sigma2)));
Comment from Cobra on 22 August 2012 at 12:57
Do you plan to publish the tree style in the josm wiki so others could use it too?
Comment from joakimfors on 22 August 2012 at 14:27
No need to go through the validator process, just use search with the following criteria: type:node AND tags:0 AND id:0
Comment from AndrewBuck on 22 August 2012 at 15:08
I posted the style on the wiki at:
You can enable the style directly from josm by going to preferences (F12) then to ‘Map settings’ which is the third tab down on the left side, then to the Map Paint Styles tab at the top. The style is named TreeCrownDiameter and should show up in the list on the left side. This config menu can be reached directly from the ‘Map paint styles pannel (Alt+Shift+M).
Comment from AndrewBuck on 22 August 2012 at 15:46
@joakimfors Regarding the search string you posted, that search string will also select newly added nodes that are part of a way (such as a forest, or hedge). The validator groups untagged standalone nodes separately as ones that are part of a way normally don’t need tags. I’m sure the search can be extended to handle that properly, but I know the way the validator does it will always work.
Comment from bastik on 22 August 2012 at 16:18
Thanks for sharing this, it was really interesting to see how you combined all these tools. I wonder how this data will be kept up to date over the years, but anyway, pretty awesome!
Comment from AndrewBuck on 22 August 2012 at 17:59
The actual measuring of the trees goes pretty quick. With ~40,000 trees in the city and measuring a thousand trees per hours it is a bit of a job to re-measure them all but not impossible. It would not be difficult for a couple people to repeat when new imagery becomes available in the future. There will be new imagery probably as often as it would merit updating a map of tree sizes manually anyway. Because they are trees and you know their relative size, you can make a guess about their age and then simulate what size they are likely to be in the future. This means that a full re-measuring will likely be unnecessary anyway as you could have the computer algorithm age the trees and grow them accordingly and then just have the people check it against the imagery and adjust the ones that are not right. This would likely be much faster than the initial survey.
Comment from Jean-Marc Liotier on 23 August 2012 at 10:54
Did you buy the Digitalglobe Geoeye imagery for Gulu ? I would love to have it for Arua - it is in great need of armchair mapping !
Comment from AndrewBuck on 23 August 2012 at 13:38
The imagery is provided to us as part of the Humanitarian Openstreetmap Team (HOT) response for that city. The Red Cross acquired the image and runs a server that we have access to for tracing. I am not sure whether they bought the images or if they got them for free from Digitalglobe, but in any case it is a sort of “one off” event and unfortunately will not get imagery for other places unless a similar project happens there. We sign a special agreement with them agreeing to use it for humanitarian work in developing this map, so they probably got it via some special agreement with Digitalglobe, but that is just my guess.
Not sure exactly what city you area looking for imagery for but the [orbview 3[(http://wiki.openstreetmap.org/wiki/Orbview3) imagery covers a lot of the world and is good enough for basic mapping.
Comment from Jean-Marc Liotier on 23 August 2012 at 16:36
I’m specifically interested in Arua - in Uganda too (http://osm.org/go/wjK7iywV-). I have friends there and I would love to do the armchair mapping and then see if they are interested in contributing names and POI. I’m tempted to buy a tile of decent imagery as an humanitarian gesture : http://tsms.terraserver.com/?img_key=E5B54A39-7C35-4058-A799-1B8EEECC6E64 - this 3500x3500 pixels georeferenced JPEG would cost $145… But I’m not sure it would do much good to map just the town and not have imagery even good enough for the regional road network.
Comment from AndrewBuck on 23 August 2012 at 17:30
If you are interested in buying the image, the HOT team would probably make a task to map it, especially if there are people there in the city that can add on the ground information.
I looked at the city on openstreetmap and it looks like a lot of the major connecting roads to other towns are already mapped. Often these can be seen in even the low resolution imagery if they are major roads.
Wikipedia says the population is ~50,000 which is about 1/3 the size of Gulu, so it shouldn’t be too big of a job to trace it. If you are interested in pursuing this further you should subscribe to and then send an e-mail to the HOT mailing list laying out your proposal. With people working on Gulu and Lira right now there may not be many left over to trace Arua, but we should be finished with those towns shortly.
Comment from Jean-Marc Liotier on 24 August 2012 at 09:38
Good idea - better coordinate than do that on my own. I’ll think about it - that’s a plan for later this year.
Comment from JoshD on 9 October 2012 at 17:11
Great work, and glad to see someone has found my conflation plugin useful. I’ve been too busy with other things to work on this for quite some time, but consider filing a ticket for any annoyances you have, like the one about having to click apply thousands of times:
Hopefully I’ll get a chance to work on this more, but it might not be a for a while.