OpenStreetMap

Diary Entries in English

Recent diary entries

Updates going forward

Posted by foxer57 on 29 November 2017 in English (English)
  • add Wild Rose trails.
  • 3rd south buffered track needs to be changed to a track.
  • remove the relation on 2nd and 3rd Avenue
  • add bike lanes to Victory Road
  • figure out why bike lanes are indicated on Wall St

  • Is there a better city resource for bike lanes other than the BikeSLC map that only displays arbitrary comfort levels?

Mapping the Student City

Posted by Anxhelo Lushka on 27 November 2017 in English (English)

I have spent two or three days now and have mapped a large part of Student City using correct data provided by the Municipality of Tirana and applied as a background layer to make my job easier. I am pretty happy with the results so far, have added around 2500 buildings, many businesses based on pictures I took while biking and I intend to map at least 90% of that area part of Tirana.

After seeing a before and after comparision I just love the final results, you can notice how dense that part of the city is now even compared to the city centre (still a LOT of businesses missing from the map, but I'll make sure to add some more too in the upcoming days).

Watching the Map Grow: State of the Map US Presentation

Posted by Jennings Anderson on 27 November 2017 in English (English)

SOTMUS Logo

At State of the Map US last month, I presented my latest OSM analysis work. This is work done in collaboration between the University of Colorado Boulder and Mapbox. You can watch the whole presentation here or read on for a summary followed by extra details on the methods with some code examples.

OpenStreetMap is Constantly Improving

At the root of this work is the notion that OSM is constantly growing. This makes OSM uniquely different from other comparable sources of geographic information. To this extent, static assessments of quality notions such as completeness or accuracy are limited. For a more wholistic perspective of the constantly evolving project, this work focuses on the growth of the map over time.

Intrinsic Data Quality Assessment

Intrinsic quality assessment relies only internal attributes of the target data and not on external datasets as points of reference for comparison. In contrast, extrinsic data quality assessments of projects like OSM and Wikipedia involve comparing the data directly to the external datasets, often authoritative, reference datasets. For many parts of the world, however, such datasets do not exist, making extrinsic analysis impossible.

Here we look at features of the OSM database over time. By comparing attributes like numbers of contributors, density of buildings, and amount of roads, we can learn how the map grows and ultimately improves overtime.

Specifically, we aim to explore the following:

Contributors

  • How many?
  • How recent?
  • What type of edits?

Objects

  • What types?
  • How many?
  • Relative Density?
  • Object version?

The bulk of this work involves designing a data pipeline to better allow us to ask these types of questions of the OSM database. This next section takes a deep dive into these methods. The final section, Visualizing, has a series of gifs that show the results to-date.

The interactive version of the dashboard in these GIFS can be found here: http://mapbox.github.io/osm-analysis-dashboard

Methods: Vector Tiles

Specifically, zoom level 15 vector tiles are the base of this work. Zoom level 15 is chosen because (depending on Latitude), most tiles have an area of 1 square kilometer. For scale, a zoom 15 tile looks like this:

z-15-vector-tile

Vector Tiles are chosen primarily for three reasons:

  1. Vector Tiles (specifically OSM data in the .mbtiles format) are standalone sqlite databases. This means very little overhead to maintain (no running database). To this end, they are very easy to transfer and move around on disk.

  2. They are inherently a spatial datastore. With good compression abilities, the file sizes are not dramatically larger than standard osm pbf files, but they can be loaded onto a map with no processing. This is mostly done with mbview

  3. Vector Tiles can be processed efficiently with the tile-reduce framework.

In sum, at any point in the process, a single file exists that can easily be visualized spatially.

Quarterly Historic Snapshots

To capture the growth of the map overtime, we create historical snapshots of the map: OSM-QA-Tiles that represent the map at any point in history. You can read more about OSM-QA-Tiles here.

Boulder Map Growth

This image shows the growth of Boulder, CO in the last decade. The top row shows the road network rapidly filling in over 9 months during the TIGER import and the bottom row shows the the densification of the road and trail network along with the addition of buildings over the last 5 years.

The global-scale quarterly snapshots we created are available for download here: osmlab.github.io/osm-qa-tiles/historic.html.

While quarterly snapshots can teach us about the map at a specific point in history, they do not contain enough information to tell us how the map has changed: the edits that happen between the quarters. To really answer questions such as, "how many users edited the map?" or "How many kilometers of roads were edited?" or "How many buildings were added?" We need the full editing history of the map.

Historical Tilesets

The full editing history of the map is made available in various formats on a weekly basis. Known as the full history dump, this massive file can be processed in a variety of ways to help reconstruct the exact process of building the map.

Since OSM objects are defined by their tags, we focus on the tagging history of objects. To do this, we define a new schema for historical osm-qa-tiles. The new vector tiles extend the current osm-qa-tiles by including an additional attribute, @history.

Currently, these are built with the OSM-Wayback utility. Still in development, this utility uses rocksdb to build a historical tag index for every OSM object. It does this by parsing a full-history file and saving each individual version of each object to a large index (Note: Currently only saves objects with tags, and does not save geometries). This can be thought of as creating an expanded OSM history file that is optimized for lookups. For the full planet, this can create indexes up to 600GB in size.

Once the index is built, the utility can ingest a 'stream' of the latest OSM features (such as those produced by minjur or osmium-export). If the incoming object version is greater than 1, then it performs a lookup for each previous version of the object in this index.

The incoming object is then augmented to have an additional @history property. The augmented features are then re-encoded with tippecanoe to create a full-historical tileset.

Tag History

Here is an example of a tennis court that is currently at version 3 in the database. The @history property contains a list of each version with details about which tags were added or deleted in each version.

A Note on Scale & Performance

Full history tilesets are rendered at zoom level 15. OSM-QA-Tiles are typically rendered only at zoom level 12, but we found zoom 15 to be better not only for the higher resolution, but it lowers the number of features per tile. Since many features are now much larger because they contain multiple versions, this helps lower the number of features per tile, keeping tile-reduce processing efficient.

One downside, however, is that at zoom 15, the total number of tiles required to render the entire planet can be problematically large (depending on the language/library reading the file). For this reason, historical tilesets should be broken into multiple regions.

Processing 1: Create Summary Tilesets

The first step in processing these tiles is to ensure that the data are at the same resolution. Historical tilests are created at zoom 15 resolution while osm-qa-tiles exist at zoom 12 resolution. Zoom 12 is the highest resolution that the entire planet should be rendered to osm-qa-tiles to ensure efficiency in processing. Therefore, we start by summarizing zoom 15 resolution into zoom 12 tiles.

Summarizing Zoom 15 Resolution at Zoom 12

A zoom-12 tile contains 64 child zoom-15 tiles (64 tiles = 4^(15-12), resulting in an 8x8 grid). To create summary tilesets for data initially rendered at zoom 12 (like the snapshot osm-qa-tiles), we calculate statistics about each child zoom-15 tile inside of a zoom-12 tile. This is done with a tile-reduce script that first bins each feature into the appropriate 64 child zoom-15 tiles and then computes various statistics for each of them, such as "total kilometers of named highway" or "density of buildings"

Since each of these attributes pertains to the zoom-15 tile and not individual features, individual object geometries are ignored. Instead, these statistics are represented by a single feature: a point at the center of the zoom-15 tile that it represents. Each feature then looks like:

geometry: <Point Geometry representing center of zoom-15 tile>
properties : {
   quadkey :        <unique quadkey for zoom 15 tile>,
   highwayLength:       <total length of highways>,
   namedHighwayLength:  <kilometers of named highways>,
   buildingCount:           <Number of buildings>,
   buildingArea:            <Total area of building footprints>
   ...

These features are encoded into zoom-12 tiles, each with no more than 64 features. The result is a lightweight summary tileset (only point-geometries) rendered at zoom-12.

Summarizing Editing Histories

The summarization of the editing histories is very similar, except that the input tiles are already at zoom 15. Therefore, we skip the binning process and just summarize the features in each tile. Similarly, up to 64 individual features that each represent a zoom-15 tile are re-encoded into a single zoom-12 tile. Each feature includes editing statistics per-user for the zoom-15 tile it represents:

geometry: <Point Geometry representing center of zoom-15 tile>
properties : {
  quadkey : (unique quadkey for zoom 15 tile),
  users: [
  {
    name: <user name>,
    uid: <user id>,
    editCount: <total number of edits>,
    newFeatureCount: <number of edits where version=1>,
    newBuildings: <number of buildings created>,
    editedBuildings: <number of buildings edited>,
    newHighwayKM: <kilometers of highways created>,
    editedHighwayKM: <kilometers of highways edited>,
    addedHighwayNames: <Number of `name` tags added to highways>,
    modHighwayNames: <Number of existing `name` tags modified on highways>
  },
  { ... }
],
usersEver: <array of all user ids ever to edit on this tile>

Why go through all of this effort to tile it?

Keeping these data in the mbtiles format enables spatial organization of the editing summaries in a single file. Encoding zoom 15 summaries into zoom 12 tiles is the ideal size for the mbtiles format and can be efficiently processed with tile-reduce.

Processing 2: Calculate & Aggregate

With the above summarization, we have two tilesets each rendered at zoom 12 with zoom 15 level resolution. We can now pass both tilesets into a tile-reduce script. This is done by specifying multiple sources when initializing the tile-reduce job:

var tileReduce = require('@mapbox/tile-reduce');

tileReduce({
  zoom: 12,
  map: path.join(__dirname, '/map-tileset-aggregator.js'),
  sources : [{
    name: 'histories',
    mbtiles: historicalTileset-2010-Q4,
    raw: false
   },{
    name: 'quarterly-snapshot',
    mbtiles: snapshot-2010-Q4,
    raw: false
  }]
  ...

In processing, the map script can then access attributes of both tilesets like this:

module.exports = function(data, tile, writeData, done) {  
  var quarterlySnapshots = data['quarterly-snapshot']
  var histories = data['histories']

For performance, the script builds a Map() object for each layer, indexing by zoom-15 quadkey. Next, the script iterates over the (up to 64) features of one tile and looks up the corresponding quadkey in the other tile to combine, compare, contrast, or calculate new attributes. Here is an example of combining and aggregating across two tilesets, writing out single features with attributes from both input tilesets:

features.forEach(function(feat){

  //Create a single export feature to represent each z15 tile:
  var exportFeature = {
    type      : 'Feature',
    tippecanoe: {minzoom: 10, maxzoom: 12}, //Only renders this feature at these zoom levels.
    properties: {
      quadkey   : feat.properties.quadkey //The z15 quadkey
    },
    geometry: tilebelt.tileToGeoJSON(tilebelt.quadkeyToTile(feat.properties.quadkey)) // Reconstruct the Polygon representing the zoom-15 tile.
  }

  exportFeature.properties.buildingCount_normAggArea  =  < Lookup the number of buildings on this zoom-15 tile (and normalize by area).
  exportFeature.properties.namedHighwayLength_normAggArea = < Lookup kilometers of named highway for this zoom-15 tile (and normalize by area).

  // Access the contributor history information for this zoom-15 tile.
  var tileHistory  = contributorHistories.get(feat.properties.quadkey)
  var users = JSON.parse(tileHistory.users) // Get user array back from string

  // Sum attributes across users for simple data-driven-styling
  users.forEach(function(user){
    exportFeature.properties.editCount         += user.editCount;
    exportFeature.properties.newFeatureCount   += user.newFeatureCount;
    exportFeature.properties.newBuildings      += user.newBuildings;
    exportFeature.properties.newHighwayKM      += user.newHighwayKM;
    exportFeature.properties.editedHighwayKM   += user.editedHighwayKM;
    exportFeature.properties.addedHighwayNames += user.addedHighwayNames;
    exportFeature.properties.modHighwayNames   += user.modHighwayNames;
  });
  writeData( JSON.stringify( exportFeature ) ) //Write out zoom-15 tile summary with information combined from both tilesets.
})

This script produces two types of output:

  1. (Up to 64) polygons per zoom-12 tile that represent the child zoom-15 tiles. Matching the editing-history format, these features contain per-editor statistics, such as kilometers of roads.

  2. A single zoom-12 summary of all the editing activity.

Processing 3: The Reduce Phase

When the summary zoom-12 tile is delivered to the reduce script, it is first written out to a file (z12.geojson) and then passed to a downscaling, aggregation function, described next.

Downscaling & Aggregation

Last year I made a series of similar visualizations of osm-qa-tiles. I only worked with the data at zoom 12 and kept the features very simple in hopes that tippecanoe could coalesce similar features to display at lower zooms. While this worked, there were a lot of visual artifacts in busy parts of the map and the tile individual geometries must be low detail to fit:

Last Year's Example

To address this, we rely heavily on downscaling and aggregation in the current workflow to successively bin and summarize children tiles into a single parent child. Each zoom level is then written to disk separately and tiled only at specific zoom levels. Unfortunately, this is done by holding these tiles in memory. Fortunately, however, with a known quantity of (4) child tiles per parent zoom level, we can design the aggregation to continually free up memory when all child tiles of a given parent tile are processed.

Psuedocode:

zoom_11_tiles = {
   'tile1' : [],
    ...
   'tileN' : []
 }

processTile( incomingTile (Tile at Zoom 12) ){
  z11_parentTile = incomingTile.getParent()
  tiles_at_zoom_11[z11_parentTile].push(incomingTile)
  if (tiles_at_zoom_11[parent].length == 4){

    // Aggregate, Sum, Average attributes 
    // of zoom 12 tiles as appropriate to create
    // single summary zoom 11 tile

    // Write aggregated, summarized zoom 11 
    // tile to disk and delete from memory.
  }
}

In reality, these are not done for every zoom level, but instead for zoom levels 12, 10, and 8.

To ensure this function works as designed, the order of tiles being processed by the entire tile-reduce job is modified to be a stream of tiles grouped at zoom 10. While we cannot ensure that tiles finish processing in a specific order, by controlling the order of the input stream, we can create reasonable expectations that groups of tiles finish processing at similar times and are therefore appropriately aggregated and subsequently freed from memory.

Processing 4: Tiling

The final result of the tile-reduce job(s) is a series of geojsonl files (line-delimited) representing different zoom levels. Using tippecanoe, we create a single tileset that is optimized for rendering in the browser. Recall that each geometry is a polygon representing a vector tile. The attributes of each feature are consistent among zoom levels to allow for data-driven styling in mapbox-gl.

tippecanoe -Z0 -z12 -Pf --no-duplication -b0 \
  --named-layer=z15:z15-res.geojsonl \
  --named-layer=z12:z12-res.geojsonl \
  --named-layer=z10:z10-res.geojsonl \
  --named-layer=z8:z8-res.geojsonl   \
  -o Output.mbtiles

Visualizing: Mapbox-GL

Loading the resulting tileset into MapboxGL allows for data driven styling across any of the calculated attributes. An interactive dashboard to explore the North America Tileset is available here: mapbox.github.io/osm-analysis-dashboard

Downscaling across Zoom Levels

This first gif shows the different layers (the results of the downscale & aggregation):

Since everything is aggregated per-quarter, we can easily compare between two quarters. This gif compares the number of active users in mid 2012 to mid 2017. Users active Per Quarter: 2012 vs. 2017

New Building Activity

Here is a high level overview of where buildings were being added to the map in the second quarter of both 2015 (left) and 2016 (right). We can see a few major building imports taking place between these times as well as more general coverage of the map.

New Building Activity: 2015 vs. 2016

If we zoom in on Los Angeles and visualize the "building density" as calculated in July 2015 and July 2016, we see the impact of LA building import at zoom 15 resolution:

LA Building Import

Users

The 2010 Haiti Earthquake:

This slider shows the number users active in Haiti during the last quarter of 2009 (just before the earthquake) and then the first quarter of 2010 (when the earthquake struck): Users active during the Haiti Earthquake

We can see the work done by comparing the building density of the map at the end of 2009 and then at the end of the first quarter of 2010:

Building Density increase in Haiti (Quarter 1: 2010)

Ultimately, the number of (distinct) contributors active to date in North America has grown impressively in the last 5 years. This animation shows the difference between mid 2012 and mid 2017:

5 Year Growth

Looking Forward: Geometric Histories

So far, when discussing full editing history, we've only been talking about history of a map object as told through the changes to tags over time. This is a decent proxy of the total editing, and can certainly help us understand how objects grow and change overtime. The geometries of these objects, however also change overtime. Whether it's the release of better satellite imagery that prompts a contributor to re-align or enhance a feature, or just generally squaring up building outlines, a big part of editing OpenStreetMap includes changing existing geometries.

Many times, geometry changes to objects like roads or buildings do not propagate to the feature itself. That is, if only the nodes underlying a way are changed, the version of the way is not incremented. Learning that an object has had a geometry change requires a more involved approach, something we are currently exploring in addition to just the tag history.

With full geometry history, we could compare individual objects at two points in time. Here is an example from a proof-of-concept for historic geometries. Note many of the buildings initially in red "square up" when they turn turquoise. These are geometry changes after the 2015 Nepal Earthquake. The buildings were initially created non-square and just a little while later, another mapper came through and updated the geometries:

5 Year Growth

Location: The Hill, Boulder, Boulder County, Colorado, 80302, United States of America

Tool for measuring elevation above sea level on the OSM map

Posted by Alex-7 on 27 November 2017 in English (English)

I created a tool to calculate an elevation at the point of a click on the OSM map: http://ausleuchtung.ch/elevation/

The elevation is calculated as an average from the values of the ele=* keys found around the click in the radius of 1 (or 2, or 3) kilometers.

I decided to write this simple application after I read an excellent article GPS Altitude vs Pressure Altitude.

For some areas of the world there is a lot of elevation data in the OSM database, and for some there is practically none. I think it is due to the misunderstanding about the difference between GPS Altitude and Pressure Altitude. The article makes it clear that both approaches are not perfect, but these are all what we've got, and we are to use one or another.

The application seems to be simple because all the heavy lifting is done by the Overpass API, OSM, and the Leaflet.

Elevation data could be useful for many purposes. For example, for planning a hiking or a cycling route, for planning a RPAS flight, for water management, etc. For example, if a hiking route starts at the altitude of 400 meters, and ends at 1600 meters, then it is immediately clear that it would be a hard day.

I also plan from now on to measure and add more ele=* data to the OSM.

Feedback and suggestions are very welcome.

Washington Post story on subterranean map exhibit

Posted by apm-wa on 27 November 2017 in English (English)

Human cognition influence on the OSM data classification Study

Posted by loai_84 on 27 November 2017 in English (English)

Dear participants,

Thank you for helping science and supporting voluntary geographic contents. The contents which have been exclusively collected by voluntary efforts. In these contents, public with local knowledge is the main source of information. Thus, we are (as a computer scientist) concerning with human cognition influence on data classification. To participate in the study press here

Step1 Step2a Step2b Step3a Step3b Step4

For example, regarding landuse/landcover classification, we could agree on that a parcel of land is covered by grass or water which is an abstract level of classification. However, whether this parcel is a park, a garden, a cemetery, or even a golf court might be perceived differently. Whether this water body is a pond, a lake or a reservoir likely requires finer measures, geographic knowledge, and particular expertise.

Therefore, we developed a study to understand more about how people perceive geographic contents remotely. The study aims to:

  • find out human capabilities to provide landuse data.
  • understand the influence of classification mechanism and schema on data quality.
  • study human behaviors in providing voluntary data, and
  • emphasis challenges of data classification in voluntary contents.

The study takes about 25-30 min. We do not collect any personally identifiable information. Thank you again for your time and your contribution. To participate in the study press here

Don't hesitate to contact me for further comments and feedbacks.

Best regards, Dr. Ahmed Loai Ali loai@informatik.uni-bremen.de

Geoweek Mapping Party with Grab, MapPH, and OSMPH

Posted by feyeandal on 27 November 2017 in English (English)

In celebration of the Geography Awareness Week, Grab, Map the Philippines and OpenStreetMap Philippines co-organized a mapping party to teach people how to map, and meet other mappers. It was held at Grab PH’s headquarters in Makati and was attended by volunteers, students, government employees, NGO workers, and Grab personnel.

OSMGeoWeekPH

Celina Agaton talked about the objectives of the mapping party and also introduced her organization, Map the Philippines.

It was followed by an introduction to OSM and Tasking Manager by David Garcia.

OSMGeoWeekPH2

Lastly, I gave a brief introduction about UP NOAH and UP Resilience Institute. I also introduced the mapping tasks that will be used for the mapathon. See image below.

OSMGeoWeekPH3

OSMGeoWeekPH4

We used the hashtag #osmgeoweekPH to track the edits by the participants. Here are the statistics:

OSMGeoWeekPHstats

We also gave three major awards for the users who have contributed the most during the mapathon.

Huge thanks to Grab, MapPH, and OSMPH for organizing this activity!

Editing in OSMAnd

Posted by contrapunctus on 26 November 2017 in English (English)

For some reason, I've moved to using OSMand instead of OSMtracker+JOSM for adding POIs. It's just so quick and immediate, and doesn't require me to remember or guess about anything. (well, for most part; I tried Vespucci a few times, but it's not nearly as simple and quick).

I did wish OSMand could put multiple POIs in the same changeset, though. It added each POI into its own changeset. There is this checkbox to close the changeset, and it seems to be there for adding modifications to a POI to its previous changeset.

...or so I thought until today, when I saw my changeset history for the first time since I started editing in OSMand. Oh. My. God.

Once again in my time with OSM, I wish I could modify my changeset comments x-P

The little cape made out of slag

Posted by ChristianA on 26 November 2017 in English (English)

Yesterday morning I went on a short bike trip. Since the mountainbike conditions are not very good at the moment, I took a ride on my cyclocross bike. As the temperature had been a few degrees below zero, the gravel roads were perfect (like sandpaper glued to concrete!) so the ride was very enjoyable.

The "Slag cape" in Stavsjö

I checked out a few paths and small logging roads that I had not mapped before. I also visited "Slaggudden" (meaning "The Slag cape") in Stavsjö. In lake Stavsjön it is a small piece of land that consists mostly of discarded slag from the ironworks that started in this village in 1666. The ironworks in this small village was the largest producer of cannons in Sweden, during the time of the Swedish empire.

Anyway, I tagged the place as "natural=cape", though it is not really natural.

Slag

Slag

Location: Björkebo, Stavsjö, Nyköping, Landskapet Södermanland, Södermanlands län, Svealand, Sweden

Its been 5 years I used Google map, but...

Posted by farhadGuli on 25 November 2017 in English (English)

I was Google map user, its been 5 years I work for it making new place names and lining roads and now im Local Guided user , but Google map has an old satellite version comes from 2004 especially in my town ! And recentrly stopped for making roads ! , Now I'm OSM user since 2014 but the things I noticed is the acceptable for my changes when you make new place and street OSM accept it quickly, not like Google map it takes 2 week for accepting or not. Im Glad to help with you OSM. And sorry if my English is bad :)

Alt text

Location: Batifa, Zakho District, Dohuk, Iraqi Kurdistan, Iraq

A user study to understand human cognition influence on data classification quality

Posted by grass_and_green on 25 November 2017 in English (English)

Dear participants,

Thank you for helping science and supporting voluntary geographic contents. The contents which have been exclusively collected by voluntary efforts. In these contents, public with local knowledge is the main source of information. Thus, we are (as a computer scientist) concerning with human cognition influence on data classification. Human perceives things differently.

For example, regarding landuse/landcover classification, we could agree on that a parcel of land is covered by grass or water which is an abstract level of classification. However, whether this parcel is a park, a garden, a cemetery, or even a golf court might be perceived differently. Whether this water body is a pond, a lake or a reservoir likely requires finer measures, geographic knowledge, and particular expertise.

Therefore, we developed a study to understand more about how people perceive geographic contents remotely. The study aims to:

  • find out human capabilities to provide landuse data.
  • understand the influence of classification mechanism and schema on data quality.
  • study human behaviors in providing voluntary data, and
  • emphasis challenges of data classification in voluntary contents.

The study takes about 25-30 min. We do not collect any personally identifiable information. Thank you again for your time and your contribution. To participate in the study press here

Don't hesitate to contact me for further comments and feedbacks.

Best regards,

Dr. Ahmed Loai Ali

loai@informatik.uni-bremen.de

OSMF Board election manifesto

Posted by pnorman on 25 November 2017 in English (English)

I'm Paul Norman, OSM user pnorman. I've been mapping since 2010, and involved in other facets of OpenStreetMap since 2011. For the last three years, I’ve been on the OSMF board, and am running for re-election. During my time I’ve seen the board grow in productivity, the finances become more stable, and us make good strides in transparency.

Outside the board, I’m also involved with the OSMF on the Data Working Group, License Working Group, and Membership Working Group. As a software developer, I’m a maintainer of OpenStreetMap Carto and osm2pgsql, as well as being involved in many parts of rendering toolchain.

In my work life I’m an independent software developer, working on map rendering, cartography, and PostGIS for clients. My main contract right now is with Wikimedia Foundation, as the developer on their maps team. In the past I’ve worked for CartoDB, Mapquest, and other companies.

Looking back at what I put in my 2014 manifesto, I’m moderately pleased with the progress we’ve made in both transparency and productive board meetings. Neither are perfect, but they’re a vast improvement over three years. Overall, I’m satisfied with my time on the board. I accomplished some of what I wanted to, and think my manifesto desires were realistic.

My concerns are now

Conflicts of interest

6/7 board members work with OSM somehow in their jobs. This includes four with employers who sell services based on OSM data and can easily run into conflicts of interest. We are not managing this, which might have worked in the past, but is not a good practice. There’s stuff we need to set up like having an email discussion out of sight of the people with conflicts. Right now it’s considered acceptable for a board member to take part in discussions where they have a conflict of interest. Clear rules would also protect board members from pressure from their employer.

On a working group whenever there’s occasionally been an intersection between my work and the WG. In these cases I’ve removed myself from the discussion. This is what we should all be doing on the board.

Unfortunately, as someone who is paid to work with OSM data, I run into conflicts of interest myself, but in practice, I have less than most with the nature of who I work for.

Support, but not control

The job of the OSMF board is to support the mappers building the map, but not control them. I worry we are losing sight of that, and people increasingly want to exert control and consider the mappers secondary. We need to protect the ability for people to independently do activities, even if it’s not something the board agrees with.

Volunteer capacity

A lack of volunteers was an issue when I ran three years ago. It’s a bit better, but still one of the biggest issues facing the OSMF. Working groups need more people. A growing number of members have been attending board meetings, but I’d like to see multiple ones at every meeting. We need good people on the board, but we also need an active membership who are interested in what we do, watch us, what we do, track that we deliver, and offer appreciation in return.

Location: Quayside, Brow of the Hill, New Westminster, Metro Vancouver Regional District, British Columbia, V3M1K3, Canada

Memory hog?

Posted by Yoshinion on 24 November 2017 in English (English)

OSM is taking up huge amounts of memory on my Chromebook. Is this a known issue or is it because of the huge amounts of tiles, features, etc. that defines OSM?

Geoweek 2017 with students from the University of San Carlos [Cebu, PH]

Posted by GOwin on 24 November 2017 in English (English)

Earlier today, we (belatedly) celebrated Geoweek 2017 with students from the University of San Carlos of Talamban, Cebu. Many thanks to Ms. Rose Lapad (Cebuano Studies Center) and Ms. Lalia Labajo (Chairperson, Department of Anthropology, Sociology and History) for accommodating the mini workshop to introduce OpenStreetMap to their students.

We were able to do basic editing with iD, work with the Tasking Manager, and capture a few Mapillary imagery of the campus, plus the usual Q&As for beginners.

Group photo of participants of the Geoweek micro-workshop. © 2017, Debra Ouano. image

Also, as a short, half-hour mapping exercise, we digitized the fetures of a remote settlement near the Abuno river, in the city's outskirts,

Screen-grab from the Tasking Manager managed by Mapbox image

Screen-grab of the AOI from the JOSM editor image

Digital humanitarians at work. Results of remote mapping a remote neighborhood in Cebu image

A few early ones, joined the Mapillary imagery collection demo session.

Participants from the optional, Mapillary session. (ɔ) 2017, Erwin Olario image

A group-fie. (ɔ) 2017, Erwin Olario image

Mapillary screen-grab, showing imagery collected in University of San Carlos, Talamban Cebu image

Thank you Carolinians! I hope to see more mapping activities in your neighborhoods soon.

Location: Maria Luisa Estate, Cebu City, Cebu, Central Visayas, 6000, Philippines

#BC2020 Mapathons

Posted by Noznoc on 23 November 2017 in English (English)

North Battleford, SASK, task (You can see the visualization here and this entry can also be seen on my website.)

BC2020

Building Canada 2020 project (BC2020) is a community-led initiative driven by a simple and clear vision: map all buildings in Canada on OpenStreetMap (OSM) by the year 2020. While interning at Mapbox, the Community Team supported my participation in the BC2020, but but my involvement actually initiated from my work at Statistics Canada on the Crowdsourcing project, as well as my personal interests in volunteered geographic information. For more details about the project, check out the Mapbox "Points of Interest" blog post I wrote.

Though conceptually simple, mapping all buildings in all of Canada on OSM is no simple task. Without a large and diverse group of individuals that are willing to maintain participation, we may find that contirbutions decline with time, as has been seen in many past crowdsourcing projects. Interest usually starts strong, which has been the case so far in BC2020, but other priorities can affect a volunteer's ability to remain committed to a proect, and thus participation can weaken or even stop. Therefore, in my opinion, the success of BC2020 comes from continuous engagement and education to various private and public organizations across all of Canada, which includes NGOs, government entities at various geographic levels, local citizens and experienced OSM contributors, and academic institutions.

Mapathon Organization

There has been a growing interest to incorporate OSM into academia, which I have witnessed online and which my former and current colleagues have informed me they witnessed at the HOT Summit in Ottawa (Sept. 14-15, 2017). With this in mind, Mapbox's Community Team and I believed engaging with Canadian post-secondary institutions would be a great opprotunity to educate academics and students, as well as other interested individuals, about OSM and how to contribute data onto OSM for BC2020 during OSMGeoWeek (Nov. 12-18, 2017) in a meaningful way!

When beginning, I wanted to ensure that the leaders for each mapathon had a GIS background, so I decided to reach out to individuals at various universities and colleges across Canada that were affiliated with either Geothink or were the heads of Geography libraries. After solidifying interest from 8 different groups (2 in BC, 1 in ATLA, 1 in MAN, 3 in ON, 1 in QC), I created a wiki page documenting guidelines and resources for hosting mapathons specifically for mapping buildings on OSM. I also helped identify the area of interest (AOI) that each mapathon would armchair map. Since I wanted to avoid beginner mappers adding buildings within already mapped regions on OSM, I scanned rural Canadian regions on OSM that I suspected would be unmapped. After identifying a suitable region, I then researched whether or not that region had an already existing open dataset of buildings that could be imported. If there was no existing dataset, I concluded that the region was appropriate for the mapathon. Some universities even reached out to their AOI's municipality to see if there were building footprint open datasets that could be imported instead (in which case they would have selected a different region as importing requires more expertise). The municipalities who stated they did not also expressed support for the initiative! It was warming to see eager mapathon leaders connecting with local municipalities, and even local OSM contributors, to collaborate.

Once the AOIs were picked, I wanted to develop tasks in the Canadian Tasking Manager for the mapathons so that the participants had clear instructions on how to map buildings on OSM with the iD editor. (Note: JOSM would have been preferred because the building_tools plug-in makes adding buildings seamless, but there is a learning curve because JOSM's graphical interface is not user-friendly.) After communicating with a Canadian OSM community member about my intentions, I was granted admin rights to create projects in the Tasking Manager. The image below shows a task I created for North Battleford, SASK.

North Battleford, SASK, task

Data Visualization

After the mapathons took place between Nov. 10 - 17, I wanted to analyze and visualize the contributed data. First, I used Overpass Turbo to see what buildings were contributed in the 8 AOIs that were mapped; so, on Nov. 20, I zoomed into each AOI and used the following query to select the OSM buildings contributed from the mapathons: building=yes and newer:7day. I then opened each query within JOSM and saved them as individual OSM XMLs to ensure I didn't lose the metadata, which would have been the case if I directly saved the queries as GeoJSONs from Overpass Turbo. Next, I used osmtogeojson to convert the OSM XMLs to GeoJSONs for each AOI. I then imported the GeoJSONs into QGIS to assess the data. Some GeoJSONs had point and polygon data, but I only imported the polygon data into QGIS. In QGIS, I calculated the total number of contributors and buildings for each AOI. After analyzing the data, I merged all GeoJSONs together using geojson.io. I saved the merged GeoJSON and then used tippecanoe to convert the GeoJSON into a vector tileset. Lastly, I imported the tileset into Mapbox Studio to create a custom style (although I used Mapbox's Standard style as the starting point).

With all the data cleaned, I was ready to create the data visualization. I used Mapbox's Malaria Mapping visualization as a guide, but instead of running the repo's scripts, I just altered the timestamps in Sublime Text (e.g., 2017-11-17T21:26:38+00:00 to 20171117). After adjusting the timestamps, I used Mapbox GL JS to create the time slider functionality. I also wanted every mapathon participant to see their contributions, so I added a button for each participating organization. This way a mapathon leader or participant can be directed to their AOI and review their contributions and stats. From my interactions with the visualization, it was neat to see how some AOIs had mapping done over multiple days.

Validation

I believe validation is very important for BC2020, and more generally to OSM. It is not just about adding data, but about having data that is reliable. Also, validation is especially important because most mapathon participants were beginner armchair mappers and new to OSM. I wanted to make sure the visualization supports validation efforts, thus I added popups so users could select a building footprint and then be directed to that specific building in the iD editor. Also, whenever a user zooms into a selected AOI, they can click on a button to be directed to the task in the Canadian Tasking Manager, or directed to review the validation documentation I wrote up in the wiki. You can see the visualization here!

Conclusion

My work isn't done yet; it is just beginning. I am working with the universities to conduct validation and I intend on adapting the visualization to handle dynamic data that visualizations all changesets with #bc2020 in the comments. Please let me know if you are intersted in contributing or helping in any capacity! As mentioned above, the success of BC2020 requires a group of active participants!

Hi Friends

Posted by farhadGuli on 23 November 2017 in English (English)

I'm from iraq kurdistan,zakho,batifa, I love this site its very useful, by this I added many roads and new places to my unknown town called batifa, I love the way you accept all our new suggestions about adding new place and roads. I'm happy for helping with you, openmapstreet its NO1 best map site.

Alt text

#batifa #kurdistan

Location: Batifa, Zakho District, Dohuk, Iraqi Kurdistan, Iraq

A user study to understand human cognition influence on data classification quality

Posted by grass_and_green on 23 November 2017 in English (English)

Dear participants,

Thank you for helping science and supporting voluntary geographic contents. The contents which have been exclusively collected by voluntary efforts. In these contents, public with local knowledge is the main source of information. Thus, we are (as a computer scientist) concerning with human cognition influence on data classification. Human perceives things differently.

For example, regarding landuse/landcover classification, we could agree on that a parcel of land is covered by grass or water which is an abstract level of classification. However, whether this parcel is a park, a garden, a cemetery, or even a golf court might be perceived differently. Whether this water body is a pond, a lake or a reservoir likely requires finer measures, geographic knowledge, and particular expertise.

Therefore, we developed a study to understand more about how people perceive geographic contents remotely. The study aims to:

  • find out human capabilities to provide landuse data.
  • understand the influence of classification mechanism and schema on data quality.
  • study human behaviors in providing voluntary data, and
  • emphasis challenges of data classification in voluntary contents.

The study takes about 25-30 min. We do not collect any personally identifiable information. Thank you again for your time and your contribution. To participate in the study press here

Don't hesitate to contact me for further comments and feedbacks.

Best regards,

Dr. Ahmed Loai Ali

loai@informatik.uni-bremen.de

Location: Altstadt, Mitte, Stadtbezirk Bremen-Mitte, Bremen, Free and Hanseatic City of Bremen, 28195, Germany

#MY INTEREST IN MAPPING

Posted by jonisia93 on 23 November 2017 in English (English)

I became involved in mapping in 2015 when i joined with my fellow youth mapper in HOT. We Mapped some wards in Dar es salaam like Vingunguti , Mwananyamara, Hanannasif and Mzimuni ward on which we mapped some featured like Drainage features, roads, building features also those areas which are vulnerable for floods . Tools which where used were like GPS, JOSM software, Also there were involvement of community members in order to create awareness in the community about mapping. It was very interesting exercise .

Announcing my candidacy for OSMF Board Elections 2017

Posted by David Dean on 22 November 2017 in English (English)

I have been an active OpenStreetMapper since 2007 (and an OSMF member since early 2016), and have been organising Mapping Parties in my local city of Brisbane, Australia since 2008 (although both activities were a bit quiet for a few years in the middle there - sorry about that!). I want to join the OSMF Board to primarily help increase representation from the AU/NZ/South Pacific Region, and indigenous populations worldwide, and secondarily to bring my decades of expertise in machine-learning to the upcoming challenges of integrating automated mapping with the local-community focus that should always drive OSM contributions.

Since coming back into OSM solidly in the last 5 months, I have re-caught the mapping bug big time. I have mapped locally, and across the world for the Humanitarian OpenStreetMap Team, every single day since July! I am working on re-ramping up my involvement in the project significantly, and I am performing outreach in the local spatial community to increase the awareness of both OSM and the Humanitarian OpenStreetMap Team. I particular enjoy teaching and introducing new members to the project, and have run two Missing Maps events, alongside other local Mapping Parties, and I will continue to organise events locally every month.

I am an active participant of HOT mapping efforts, and I believe strongly in the ability of remote mapping to provide a great starting point for local communities to take ownership of their maps. In fact, I believe that this is the first and foremost principle of OpenStreetMap, that if anything is taking away, or discouraging, local ownership of the map it is probably not a good idea.

If elected, I would seek to improve the representation of the needs of Australia, New Zealand and the South Pacific mappers towards the OSMF Board. In particular, I am very interested, and already working towards, how the OpenStreetMap project and communities can extend our community, models and techniques towards indigenous populations around the world. Indigenous populations often look at the world differently than the Euro-centric origins of the OpenStreetMap project, but I believe that some of the valuable lessons already learnt by HOT in how local disadvantaged communities can take ownership of their maps can be extended and improved upon for the indigenous populations of Australia, New Zealand, the South Pacific, and around the world. To be clear, I am not indigenous myself, but I am in already in the process of building relationships to work towards this goal in the Greater Brisbane area, then hopefully across the entire region, and the world!

One other aspect that I would like to bring to the board will be the present and future impact of automation, machine-learning and/or artificial intelligence on OpenStreetMapping, both generally and specifically for Humanitarian Mapping. It might appear that this is antithetical to my belief in local communities owning local maps, but that is why I want to focus on using these powerful techniques in ways that promote, rather than degrade, local ownership.

I have more than a decade of machine-learning experience, and I want to investigate existing techniques in development by Facebook, Development Seed and others, and develop new ones, and I am working with a team at the University of Queensland to begin a study on how these and similar techniques can be opened to all mappers through the Humanitarian OpenStreetMap Tasking Manager and editing tools in a way that ensures that remote and local mappers are assisted directly in our mapping tools, rather than having the output of an algorithm imported widescale without their direct involvement in the process. I am in particular interested in efforts that can focus on getting ML to people on the ground in things like FieldPapers, and in apps like StreetComplete, Kort and OpenMapKit. We need many more of these great simple-survey focussed approaches, and I think ML can help with guiding these efforts.

You can find out more about me at https://dbdean.com, and my OSM profile at https://www.openstreetmap.org/user/David%20Dean contains links to my many OSM-related activities. If you have any questions, or want to get in contact, please don’t hesitate to ask me here, by email at ddean@ieee.org, or at the Election to Board Talk Page at https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM17/Election_to_Board, where I will begin to wade through the many existing questions shortly.

Thanks, and Happy Mapping!

Location: Merthyr, New Farm, Brisbane, Brisbane City, Queensland, 4102, Australia

Youth Mapping the Driver to Change

Posted by chomba chishala on 21 November 2017 in English (English)

Hello, my name is Chomba Chishala, I am a student doing Environmental Education at the University of Zambia. At the same time the president of the YouthMappers at the University of Zambia Chapter (YMUNZA) I came to know YouthMappers through Open Street Map Zambia (OSMZAMBIA) in February this year 2017 when OSMZAMBIA had a meeting in Lusaka’s Bongo Hive training center. From that meeting, I learnt how to use different tools when mapping including the importance of the maps and how maps can be used for humanitarian help.

As YouthMappers UNZA, we have been involved in different tasks or activities and some of the prominent tasks that we have been doing include the malaria elimination where we have been mapping buildings / houses to help people who are into spraying for malaria as well as distribution of mosquito net as well as mapping for urban and rural areas in Zambia.

Many communities especially in African countries remain underdeveloped due to geographical impediments such as Hills, Mountains and lack of information with regard to how they are distributed especially their location that act as a hindrance to people willing to help in case of an outbreak of a disease.
Thus mapping buildings, roads, and streams as well as showing their actual location and potentials has derived me to engage myself in mapping as many communities as possible for the betterment of most of the communities. ‘’I am a proud YouthMapper who is willing to make a change, just urging everyone out there to join us and make a difference.’’

“As YouthMappers UNZA, our vision is to cultivate a generation of young people to become leaders in creating resilient communities and empowering them to define their world by mapping it.”