Sotm11 blossoms


Published on

Published in: Sports, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I'm Harry and I'm from England... and I thought I'd compare OpenStreetMap to an English country garden. It sort of blossoms with a wondrous variety of shades and colours. I'll show you what I mean. Photo CC BY-SA 2.0 Katy Walters:
  • As we started the map in the beginning...
  • was like crocuses pushing up their heads in the early spring. Photo: Frühlingsblumen Krokus by Benjamin Gimmel CCBYSA 2 etc on wikimedia commons:
  • Somebody mapped the whole of Cambridge. .
  • ...the towering foxgloves of Cambridge Photo: CC BY 2.0 psd on flickr:
  • All of Hull was mapped by one person in glorious detail...
  • ... blossoming like beautiful marigolds Photo CC BY-SA 2.0 mariosp on flickr:
  • The collaborative mapping of Birmingham. .
  • like a bunch of forget-me-nots Photo GFDL/CCBYSA3 Quadell on wikimedia commons:
  • Sometimes I like to imagine I'm managing to keep a watchful eye on the map, and seeing how it develops worldwide. This is nonsense , because the map is big, and the community of mappers is big. I really love it when I look around the map and come across things which surprise me.
  • A couple of weeks ago I was just casually panning around somewhere in South England and I came across this glorious patch of detailed countryside mapping.
  • And what's this pink thing with circular footpaths around it? I don't know. I have never been there! It's a wonderful and surprising patch of detail to encounter. Somebody clearly feels passionate about the map of this area.
  • So these blossoms appear by surprise. Perhaps it's more like blossoms in the desert, appearing from barren desert floor, when the conditions are right. Photo CC BY 2.0 Slideshow Bruce on flickr:
  • Or like splats of ink Image by Kamikaze Stoat CC BY 2.0 on flickr
  • ….or perhaps like bombs dropping. But mappers don't drop bombs of destruction, they're dropping map bombs. An explosion leaving behind a circular areas of map coverage near where they live or work. I think the way the community builds the map is a glorious and fascinating thing to behold, and utterly unique to OpenStreetMap.
  • We see a similar thing within an area like London, where we have a backdrop of "complete" coverage in terms of having all the roads and basic features in place, but now we get these patches of mega-detail blossoming with every building drawn in., and lots of POI detail added. This is all good fun, and part of the same wonderful blossoming of map detail, but I am going to come back to talk about problems particularly related this kind of example, a little later on.
  • I want to compare that situation with another type of map growth, which is more relevant to the U.S. Here we see a lot of data imports. In particular we see TIGER data across the whole US which has really shaped and characterised OpenStreetMap here ever since it was imported
  • TIGER gives us even coverage. Perhaps like a nice flat garden lawn. Photo CC BY-SA 2.0 AdamKR on flickr
  • And then there's more detailed imports in some areas of the U.S. This Is MassGIS
  • Perhaps more like a field of corn. There's even coverage but none of the exciting blossoms of coverage coming from passionate local mappers CC BY-SA 2.0 Lilli2de on flickr
  • It would be unfair to say there are no blossoms in the U.S. In fact here in Denver we see some great details appearing, and as I keep an eye progress here I'm seeing more and more of this kind of mapping starting to pick up in the U.S.
  • Before TIGER was imported there really wasn't very much data in the U.S. and the community wasn't progressing well, but there was always a lot of talk about the TIGER data, and perhaps the community was in some sense waiting for TIGER. Perhaps the proactive tech-savvy folks who we need as community leaders, were aware of the pre-existing free data
  • But after the tiger import, with all this new data in place, the growth of the U.S. community was still slow, and this caused people to start speculating and theorising about the negative effects of imports. There was an imports panel at the Vienna conference a few months ago. I'm going borrow s slides and quotes from this.
  • “The best imports are those we avoid” was Frederik Ramm's summary. Matt Amos said “Imports bad. Surveying good” Actually that's not really a quote. That was his suggestion for my entire slideshow. So some fairly strong anti-import opinions.
  • This is also from Matt. A few years ago he ran some simulations showing how the map completeness progresses, taking into account new users arriving, and running out of areas to map as it gets more complete. It shows that if we start from nothing, but build up momentum and growth we actually end up getting better map coverage quicker than if we start with a certain amount of imported data. Obviously it's just a simulation, and with different parameters it would follow a different line. Also it doesn't take account of this effect of people waiting for an import when they know the data's available.
  • Frederik showed this example of an area of rural France where there's been an landuse import. As you can see the map looks quite rich with data, but if we count up the number of users editing, there have been 20 users editing in this area since the import, and only four in the past year.
  • He compared this with an area of the same size and the same population in rural Austria. Here we see a much more active community. 81 users editing, and 27 users in the past year. And the map is an expression of local interest and passion.
  • But why would an import stifle the community in this way. The usual theory is that a blank area of the map entices and excites people. It feels like exploration to go and map an empty area. But here's a different theory. Often imported data is just not very beginner friendly.
  • I thought I'd show you what I mean with an example in Atlanta. Atlanta has imported TIGER data, but also an import of some landuse data. There's been a little bit of mapping activity in the city centre, but if we zoom in here a little way out from the centre, there's a patch of woodland. I can bring in the bing imagery and just straighten this out a little bit. As an experience user I know that this is imported data with limited accuracy, and I have the confidence to plough in and make some improvements. For new users this is difficult, and that's before you consider that we're dealing with ways on top of ways which are fiddly and technically difficult to make sense of. I can also see some NHD data which has many nodes, but clearly isn't very accurate.
  • So for new users this is less like a field of corn and more like a thorny patch of weeds or brambles. Photo CC BY SA 2 Richard Webb on geograph
  • Here's another quote from Frederik. I think this is a great way of putting it. “It's not enough to just make sure you're leaving the map in a better state...” If you're running an import you may imagine that you're doing a good thing provided the map ends up being better. But “You should make sure you are you're leaving the community in a better shape”
  • Here's some more analysis form Matt. This shows the growth in number of different users editing POIs normalised to population. Germany and Austria rank highly. We know they have very strong mapping communities. The U.S. comes in last. Interestingly the Netherlands scores quite well. They imported the whole country , but it seems they've still managed to build a strong mapping community.
  • I'm going to talk about fixup. I don't want to give the wrong idea. If you're doing an import you should not be dependant upon users manually fixing up the mess you've made afterwards. Or if you do need a manual fixup phase, this should be planned and discussed before during and after the import.
  • But with existing imports, particularly the massive TIGER dataset, there's no point dwelling on whether or not the import was a good idea. We need to move on and think about fixup now. This is the big challenge in the U.S. There's been a lot of talk at the conference about ideas for encouraging more mapping. When it comes to doing this in the U.S. we're talking about encouraging fixup.
  • While we had our team at Cloudmade in 2009, we set up the “250 cities” project which looked at encouraging fixup with a focus on basic routing in the US.
  • Most routing disconnects are actually caused by duplicate nodes. Nodes sat directly on top of eachother. These need fixing all across the U.S., and the duplicate nodes map lets us see the progress with this. (Note this is broken/unreliable at the moment due to problems with OWL)
  • Also a widespread problem with TIGER data is the general positional accuracy. This is a display we created as a tutorial resource. I can flick between before...
  • ...and after. To show the kind of corrections we need people to make. Just simply dragging the roads into the right positions using the aerial imagery. It varies from one patch to another, but there are a lot of patches of TIGER data which are wildly inaccurate in this way.
  • I can show you a quick example of this in Cleveland ( Tennessee ) where this kind of fixup is needed and hasn't happened yet. Note: I skipped over this demo to save time. At time of writing there is still some good juicy TIGER alignment fixup to do here: I would expect this example to get fixed some time soon, but there will be other similar pockets for some time to come.
  • To measure the progress of this we have the TIGER edited map, showing in red any areas which have never been edited since the TIGER import, and green for those which have. This kind of thing really should receive more attention from the U.S. Mapping community, and perhaps also from developers working to make improvements (it doesn't work perfectly).
  • Likewise the keepright tool has an excellent array of automated checks built into it. It discovers all sorts of problems with the TIGER data. Again this should be brought to the attention of U.S. mappers more, but I think there's various ways the tool could be developed to make it more compelling for mappers.
  • So it's fair to say that in the U.S. we've got a bit of weeding to do, to tidy up the TIGER data. Photo CCBYSA2 Gordon Joly :
  • But if we look back at the situation in countries like the U.K, where we have grown our map organically, I want to talk about a different set of problems in relation to this. Local passionate map coverage appearing in blossoms is wonderful, but we often have a problem of uneven map coverage. This is an acute problem for map users .
  • My favourite example of this is my jigsaw puzzle. I got a jigsaw puzzle printed with the map of London on it. I wanted this to be a good clear complete map image from OpenStreetMap. But the London map has patches of building coverage , some arranged logically in the centre working outwards, but many patches sporadically appearing as blossoms of passionate building mapping around the outskirts. Building coverage is quite prominent in the default rendering. This illogically arranged data actually makes the map of London quite ugly and not good for map users. Knowing how to do so, I was able to use a rendering with the buildings switched off, but in general sporadic blossoms of detail can make the map uneven and difficult to use.
  • I think this points to a deeper problem. Perhaps one of the trickiest problems facing OpenStreetMap as we work towards a “complete” map. Mappers are working on their blossoms of mega-detail near home and work, and applying different ideas of what “complete” means. The level of detail we go to is a tricky question.
  • There's no real limit to the level of detail, because of the way we've framed our mapping process with the opportunity to flexibly invent new tags. Tagging ideas are open to progressively more insane levels of detail. It's a sliding scale. I regard things like mapping sidewalks and roads as areas, as rather crazy, but people are seriously talking about more and more detail. Soon we'll be talking about mapping every blade of grass
  • Of course this is taking things to silly extremes, but where do we draw the line? The usual response to these kinds of concern, is to say “why is it a problem?”. People map crazy levels of detail, and we all have a good laugh about it. It's a problem because its a waste of time and energy of the mappers doing it, but It becomes more a problem too when people encourage others (including confused new mappers) to follow their lead. This happens within the tagging proposals and documentation, and also blogs and other communication channels. More mappers mapping more and more crazy levels of detail. Image: CCBY2 meddygarnet:
  • I don't have a solution to this problem, and as I say, I do think it's a big problem we'll be facing more and more. This runs quite contrary to the way we've celebrated detailed mapping in the past, but perhaps we need to think about a new message. Among our pro-mappers perhaps the message should be: “consider the levels of detail around you”. Don't go crazy with the levels of detail within your blossom of map coverage. Keep a cap on this and map further afield instead. Go to a level of detail which is realistically attainable by you, or with the help of other mappers, across a wider area. It's almost like we're trying to make our coverage more like an even field of corn...
  • So we've got problems. Two sets of problems really. Here in the U.S. we want to see more blossoms of detail created by passionate local people. We've got a lot of a fixup work to do, and we need to attract a community behind the data to take on this task. But where we've grown our map organically, it can be like blossoms in the desert. We need to find ways of creating a map with more even coverage between the blossoms. We need to work towards something more balanced, more gentle and serene. Something more like...
  • English country garden. Thank-you very much! Bottom image: Summer Garden, Munstead Wood CCBY2 sarah from : &
  • These slides are (of course) freely re-usable under the Creative Commons Attribution-ShareAlike 2.0 License Map images cc-by-sa2 contributors.,,, OSMC Reitkarte,, ö,,, . Wrecking ball photo by Rhys's Piece Is. Photo of me photo mapping by Gordon Joly Adapted free clip-art from:,
  • Sotm11 blossoms

    1. 1. Blossoms, Weeds, and blades of grass Growing the map Photo CC BY-SA 2.0 Katy Walters:
    2. 3. Photo: Frühlingsblumen Krokus by Benjamin Gimmel CCBYSA 2 etc on wikimedia commons:
    3. 4. Cambridge
    4. 5. Photo: CC BY 2.0 psd on flickr:
    5. 7. Photo CC BY-SA 2.0 mariosp on flickr:
    6. 9. Photo GFDL/CCBYSA3 Quadell on wikimedia commons:
    7. 10. Keeping an eye on the map
    8. 13. Photo CC BY 2.0 Slideshow Bruce on flickr:
    9. 14. Image by Kamikaze Stoat CC BY 2.0 on flickr
    10. 17. Imports & U.S.
    11. 18. Even coverage Photo CC BY-SA 2.0 AdamKR on flickr
    12. 20. Even coverage. More detail CC BY-SA 2.0 Lilli2de on flickr
    13. 21. Blossoming Denver and the U.S.
    14. 22. Before TIGER ...waiting for TIGER
    15. 23. After TIGER Still slow Negative effects of imports?
    16. 24. <ul>“ The best imports are those we avoid.” Frederik Ramm “ Imports bad. Surveying good” </ul>Matt Amos
    17. 25. Do imports stifle community? <ul><li>Matt's simulation
    18. 26. Knowing the data is available </li></ul>
    19. 27. Landuse in rural France
    20. 28. Active community in rural Austria
    21. 29. Why would it stifle the community? <ul><li>Blank slate entices contribution and exploration
    22. 30. Existing data and existings mappers more exciting than just existing data.
    23. 31. Imported data is not beginner friendly </li></ul>
    24. 32. Atlanta example
    25. 33. A field of corn ...or thorny brambles Photo CC BY SA 2 Richard Webb on geograph
    26. 34. “ It's not enough to just make sure you're leaving the map in a better state ... You should make sure you are you're leaving the community in a better shape ” Frederik Ramm
    27. 35. Users editing some POI types, normalised to urban population
    28. 36. Fixup vs Community engangement <ul><li>New imports should involve planned fixup
    29. 37. “Leave the community in a better state”
    30. 38. Engage, discuss and plan before, during and after </li></ul>
    31. 39. Facing facts... facing fixup Imports are done. Move on. ...Fix up! <ul><li>Progress reports motivate
    32. 40. Gamification
    33. 41. Documentation. </li><ul><li>Spell it out. Video tutorials </li></ul></ul>
    34. 42. 250 cities
    35. 43. Duplicate nodes
    36. 44. TIGER alignment
    37. 45. TIGER alignment
    38. 46. Cleveland example
    39. 47. Important. Improvements
    40. 48. Keep Right
    41. 49. A bit of weeding to do... CCBYSA2 Gordon Joly :
    42. 50. Trouble in the garden <ul>Wonderful blossoms of details ... Uneven coverage Bad for map users </ul>
    43. 51. Uneven coverage problems for users <ul><li>Jigsaw puzzle example </li></ul><ul><li>Blossoms of
    44. 52. building coverage
    45. 53. Ugly map! </li></ul>
    46. 54. A deeper problem. Levels of details <ul><li>Blossoms of mega-detail near home
    47. 55. More details </li><ul><li>new ideas for types of features (& tags) </li></ul></ul>
    48. 56. Progressively more insane <ul><li>POI types. Map every shop
    49. 57. Building outlines and addresses
    50. 58. Walls and fences (Pedestrian routing)
    51. 59. Sidewalks on every road
    52. 60. Roads as areas
    53. 61. Every tree
    54. 62. Every plant
    55. 63. Every blade of grass </li></ul>
    56. 64. Every blade of grass Crazy example ...but where to draw the line? Problem? <ul><li>Even coverage
    57. 65. Wasted time of mappers
    58. 66. (new mappers) </li></ul>CCBY2 meddygarnet:
    59. 67. Solution? <ul><li>Encourage sensible tagging proposals
    60. 68. Config default/prominent renderers and toolchains
    61. 69. Efforts to even out coverage
    62. 70. A new message? :
    63. 71. “Consider the levels of detail around you” </li></ul>...more like a field of corn
    64. 72. Need more blossoms Need more even coverage
    65. 73. CCBY2 :
    66. 74. Harry Wood has been an OpenStreetMap enthusiast, and contributor since 2006. He works as a senior software engineer at on projects relating to transport and GPS data analysis. Previously he worked in a technical and OpenStreetMap community development role at CloudMade. In 2011 he has continued to volunteer for the project in several roles, as mapper, developer, documenter, community coordinator, promoter, and the chief London event organiser. These slides are freely re-usable under the Creative Commons Attribution-ShareAlike 2.0 License , Note that open licenses on some of the images are similar but not the same as this. Please retain all credits Map images cc-by-sa2 contributors