Diary Entries in English

Recent diary entries

Deteriorating Bing aerial imagery. - Mount Arrowsmith, Vancouver Island, British Columbia, Canada

Posted by Robert Copithorne on 3 March 2017 in English (English)

Referring to the OSM map of part of BLK 1324S on Mt Arrowsmith / Mt Cokely at the location

Previous versions of Bing aerial imagery available through Java OSM editor clearly showed a harvested area and related roads surrounding the reference point, which were mapped and tagged as farmland. Tree farm that is, a concept with legal meaning in British Columbia.

Current available versions do not show the harvested area, indicating a change in the aerial photos, possibly to an earlier date.

Mapbox satellite views of the same area clearly show the harvested area.

What has happened? Why the change in Bing Satellite imagery? An explanation is desired, and a revision to Bing aerial imagery if necessary.

Geely calls for relaxation of China mapping laws

Posted by ika-chan! on 2 March 2017 in English (English)

In a bid to speed development of self-driving cars, Geely has called on the Chinese Government to relax strict laws on mapping (Reuters, 2 March 2017).

This is relevant to OpenStreetMap, because the Surveying and Mapping Law bans all private surveying and mapping activities in mainland China.

The law means that OpenStreetMap is illegal in mainland China, and there have been cases where casual mappers have been prosecuted (see WikiProject China on OpenStreetMap Wiki).

Location: Dongcheng, Dongcheng District, Beijing, 100010, China

this is interesting

Posted by FKC2004 on 2 March 2017 in English (English)

I didn't know you can do diary entries on here.....

Beginning the mapping of Phoenixville, PA

Posted by GreyTK on 2 March 2017 in English (English)

I've been a member of the OSM community for several months with sporadic contributions to the map. Now the time has come for me to get serious about improving my area's representation and honing my mapping skills with a little project of my own. My goal is simple: put every business in Phoenixville, PA on the map. It's not my home town, but I spend a lot of time and do most of my business there.

The data for my most recent changeset comes from a GPS trace that I made on a whim a few days ago. I took pictures of the store fronts, but the app that I'm using doesn't seem to link pictures to coordinates. Learning as I go.

Location: Bridge Street, Phoenixville, Chester County, Pennsylvania, 19460, United States of America

Surfacing Wikidata objects with coordinates to match them with OSM

Posted by sabas88 on 1 March 2017 in English (English)

Wikidata, as a project derived from Wikipedia, could be viewed as a crowdsourced database of VGI (Volunteered Geographical Information), of course less structured than OpenStreetMap spatially but at least comparable: we think that a cross-reference could be worthwhile for both projects. This work has already started from some years ago with the wikipedia tag (notably the WIWOSM project, and in Italy wtosm) but now the focus seems to be moving towards the use of Wikidata instead of Wikipedia.

In this post I would like to introduce our experiment in this direction, powered by the resources we have as a chapter of both the OSMF and the WMF.

We started from an existing OSM database replicated every half hour through osmosis, where all the tags are dumped in an hstore column and we added a table called wikidata and a view which gathers existing elements tagged with the wikidata key (UNION of nodes, ways and relations).

The wikidata table is populated by a script which parses the weekly Wikidata dump (~10 GB gzipped line delimited json): we get only the elements having a claim with the P625 property (an element with at least a coordinate) and we take only the ones in Italy (a "rough" point in polygon test). The objects are then saved with the most precise coordinate available, their id and a label (italian, english, serbo-croatian or the first available).

Why serbo-croatian you may ask? We noticed that the Wikipedia editors created a lot of stubs from Geonames which went to generate new Wikidata items having only the label in the sh iso code :-)

Now we have our brand new table and we can create our service: a map showing all the Wikidata elements colored by their OSM status. Green if already matched, Red if it’s an element which can't appear in OSM (an historical battle or structure for example), Grey if they still need to be processed. Each marker has its popup, linking to the object on Wikidata (and on OSM), the wikidata tag to copy, and two buttons: one to mark the object as non-mappable, the other to mark it temporarily done (it would -hopefully- become green on the next run).


The service is live at and covers Italy.


New edits not showing (yet again)

Posted by GMHeyes on 1 March 2017 in English (English)

The area I now live in is a bit short of detail, I enjoyed editing around my previous address, so last night I thought I would start adding features around my new home. the aim is to start locally and then moving around my home town! I made half a dozen or so edits, which included shops, a path, removed a road that no longer exists, grassed areas and terraced housing. None of the above is yet to appear on the map, I have checked on my iPad, PC and mobile phone. I used the id (In browser editor)

Location: Moorside, Oldham, Greater Manchester, North West England, England, United Kingdom

An OSM Vacation

Posted by mtc on 28 February 2017 in English (English)

Doing some mapping during a week-long vacation. Really fun indeed. Great way to explore a place that I have never seen before. At first glance, the area looks complete already, but it is all imported data, so there is a lot to check and fix.

Today, I was asking a very old lady - who was walking with her two unleashed cats in her front yard - where was the lighthouse that I was verifying. She looked surprised, but gave me quite clear directions. As it turns out, the tiny lighthouse had been converted into a residence, and it was no longer being used as a navigational aid. The neighboring houses are just as large, and they made the already squat structure look comically small. I had a good chuckle, on seeing this unusual neighborhood.

Location: Harbor Road, Barnstable, Barnstable County, Massachusetts, 02647, United States of America

Using DEM and slope data to find interesting mapping locations

Posted by ChristianA on 28 February 2017 in English (English)

I like mapping by going out in the field, especially in the forest. Finding new (for me) trails and roads is very fun.

For mapping in Sweden I often use an old (expired copyright) map called Ekonomiska Kartan, by adding is as a tile layer in JOSM. It has names for farms, hamlets, mountains, forests, lakes and so on, which is often hard to come by otherwise. However, since it is old many things have changed on this map. I use this map together with Mapbox satellite images in JOSM, which is more recent.

Sometimes it is hard to determine if an old road, or similar, still exists, bu purely looking at Ekonomiska Kartan and Mapbox satellite. Recently I made a tile layer (just for the area where I live) that consists of DEM from SRTM, together with slope data from the Swedish forestry administration (Skogsstyrelsen). While this data is "open data", it has a license that is incompatible (I think) with OSM. So I just use this tile layer to figure out where to go with my GPS to map in the field.

One such example is shown below. Ekonomiska kartan (the old map) Ekonomiska kartan show a road traversing the railroad track in the center of the picture.


It is clear that some parts of the old road still remains. So I went there as part of a recent mapping/biking tour, and found a nice path on both sides of the railroad tracks.

And the final result is

Final map

Location: Grindstugan, Lilla Lövhälla, Nyköping, Landskapet Södermanland, Södermanlands län, Svealand, Sweden

Mapper of the Month

Posted by escada on 28 February 2017 in English (English)

Sorry, this month I have no time to publish a Mapper of the Month interview. I am too busy with those 9 creatures.

Moon Orchid Q Litter

I hope to publish a new interview next month, when they have moved to their new homes.

DOST – Project NOAH finishes mapping building footprints of 16 provinces in the Philippines

Posted by feyeandal on 28 February 2017 in English (English)

Project NOAH has finished mapping the building footprints of ISAIAH’s 15 target provinces and an additional province for "good will". The completion of its mapping initiative was made possible through the help of several organizations and individuals such as MAVC program, Aurora Provincial Disaster Risk Reduction and Management Office, UP Rockhounds, Geographic Society of the University of the Philippines (GSUP), Eastern Samar State University, Eastern Visayas State University, UP NSTP-CWTS program, and OSM-Philippines contributors. NOAH finished mapping the building exposure data of Abra, Aurora, Bataan, Batangas, Biliran, Camiguin, Cavite, Eastern Samar, Ilocos Norte, Ilocos Sur, Leyte, Misamis Oriental, Northern Samar, Samar, Southern Leyte, and Zambales. NOAH also mapped the building footprints of Pateros and Taguig City of Metro Manila.

Philippines Before and After Edits NOAH

Stats Report

The building exposure data is essential in calculating the disaster risk of the communities. Part of the ISAIAH’s objectives is the completion of risk profiles of the 15 target provinces. With this data, local government units can formulate their disaster risk reduction and management plans and make informed decisions when they are threatened by natural hazards.

The translated building footprint data mapped by NOAH through OSM is integrated into the WebSAFE application of Project NOAH. It is a web and mobile-based impact assessment tool used to identify the number of affected people and structures when a hazard scenario (e.g. flood, landslide, or storm surge) hits a certain area. WebSAFE can help us identify the buildings exposed in hazardous area that is useful in disaster preparedness activities, especially for preemptive evacuation.

Camiguin WebSAFE WebSAFE feature on the NOAH Website showing a sample calculation of how many buildings might be affected in the event of a 3-meter high storm surge in Mambajao, Camiguin

Thank you for helping us in mapping the Philippines through OpenStreetMap!

Routenplanung — Trennung von Geschwindigkeiten und Kantengewichten

Posted by happygo on 27 February 2017 in English (English)

Wir haben gerade v5.6 der Open Source Routing Machine (OSRM) veröffentlicht. Wie gewohnt mit Dokumentation, NodeJs Bindings und einem osrm/osrm-backend:v5.6.0 Docker Image. Mehr Details gibt es hier. Sieht auch die Release Notes und den kompletten Changelog.

Was ich in diesem Beitrag vorheben möchte ist das Hauptfeature des 5.6 Releases: Die Trennung von Geschwindigkeiten und Kantengewichten

Bis zum 5.6 Release konnten Nutzer nur die Geschwindigkeiten per Lua Profile anpassen and diese basierend auf Tags und Präferenzen verändern. Die Routenplanung hat dann den schnellsten Weg gefunden und dabei die Zeit minimiert.

Allerdings gibt es klare Fälle in denen Nutzer bestimmte Strassen vermeiden möchten: schmale Gassen und Passagen über die normalerweise nicht gerouted werden sollte. Bisher konnten Nutzer diese Wege entweder komplett aus dem Strassennetz entfernen oder aber die Geschwindigkeiten künstlich herabsetzen. Die Geschwindigkeiten zu modifizieren hat jedoch einen gravierenden Nachteil: wenn die Routenplanung nun doch über eine solche Strasse führt sind die Ankunftszeiten falsch!

Was wir stattdessen benötigen ist eine Trennung von Geschwindigkeiten (und damit Reisezeiten welche die Routenplanung aggregiert) und Kantengewichte auf denen die Routenplanung optimiert. Mit dem 5.6 Release haben wir diese grundlegende Trennung!

In den Profilen können Nutzer nun:

  • Die Geschwindigkeiten weiterhin basierend auf Tags setzen um realistische Ankunftszeiten zu erhalten und
  • Spezielle Strassen vermeiden indem Kantengewichte unabhängig zu den Geschwindigkeiten verwendet werden.

Zusätzlich erlaubt uns die Trennung von Geschwindigkeiten und Kantengewichten die Handhabung von access=destination und ähnlichen Tags, die es erlauben die Strasse nur zu verwenden wenn sich das Ziel dort befindet. Ein typisches Beispiel sind Gated Communities durch die Nutzer nicht gerouted werden möchten, ausser sie wollen explizit ihre Reise dort enden.

Wir können solche Tags nun behandeln indem wir nur die Abbiegevorgänge auf solche Strassen mit einem hohen Gewicht versehen und gleichzeitig die realistische Turn Penalty unberührt lassen. Die Routenplanung vermeidet dann z.b. Gated Communities ausser Nutzer wollen explizit dort hin. Ankunftszeiten werden dabei nicht beeinflusst!

Ein Beispiel für Destination Routing gibt es hier. Destination Routing

Wir können den selben Trick für weitere Tags verwenden, beispielsweise für delivery, private oder customer access restrictions. Sogar für HOV-Strassen falls Nutzer diese normalerweise vermeiden möchten, aber trotzdem eine Route möchten falls sie explizit auf diesen Strassen unterwegs sind.

Wir freuen uns gerne auf Feedback zu anderen Tags die wir ähnlich handhaben sollten; einfach in die Diskussion einsteigen.

Wir werden auch auf der FOSSGIS Konferenz dieses Jahr sein - Kommt vorbei und sagt Hallo!

Location: Scheunenviertel, Mitte, Berlin, 10119, Germany

Routing — Making Travel Time and Edge Weights Independent

Posted by happygo on 27 February 2017 in English (English)

We've just released version 5.6 of our beloved Open Source Routing Machine (OSRM). The release comes with documentation, NodeJs bindings and a osrm/osrm-backend:v5.6.0 Docker image for an easy setup. More details here. See the Release Notes and the Full Changelog for more details.

What I want to highlight in this post is the 5.6 release's main feature: Making Travel Time and Edge Weights Independent

Up until the 5.6 release users were able to adjust way speeds based on tags and their preferences via user-provided Lua scripts. The routing engine then did fastest path routing minimizing for duration.

Now there are use-cases for which you want to penalize certain ways: think alleys or small roads which you don't want the routing engine to prefer. Before the 5.6 release all you could do was to either discard those ways completely or adjust their speeds and make them artificially slower. Adjusting speeds sounds like the way to go, but if the routing engine then really needs to route you over such a way your ETAs will be off by the adjusted amount.

What we instead need is a split between travel time the routing engine aggregates along the way and edge weights the routing engine minimizes. With 5.6 we finally made that major architectural switch.

In your profiles you can do both now:

  • Fine-tune way speeds based on tags to make for great and realistic ETAs and
  • Penalize ways by setting edge weights independently of speeds.

In addition we can handle restricted ways now, too. By restricted ways I mean access=destination and similar which you are only allowed to travel on if you are going to this area. A typical example are gated communities which you don't want to get routed through except you explicitly want to go there.

We do this by penalizing the turns onto such restricted ways setting a very high turn weight but keeping the turn penalty duration untouched. The routing engine will now only ever route you e.g. into gated communities if there is no other option and the user explicitly wants to go there. The ETAs won't be affected at all!

Here is an example of destination routing for when we really want to go there: Destination Routing

We can make use of this technique for certain other tags: think of delivery, private or customer access restrictions. Or even for HOV-ways if you normally want to avoid HOV ways but want the routing engine to still give you routes when you drive your car on a HOV way and re-routing triggers.

If you know of other tags we should penalize this way, feel free to jump into the discussion.

This feature is included in the latest OSRM v5.6 Release. We're always glad for user feedback; in case you stumble over issues like this please talk to us! You can find us in the OSRM Repository on IRC and on the osrm-talk mailinglist.

We will also be at this year's FOSSGIS conference - stop by and say Hi!

Location: Scheunenviertel, Mitte, Berlin, 10119, Germany

The Most Confused Roads in Nottingham

Posted by alexkemp on 27 February 2017 in English (English)

At the end of my most recent mapping session in Gedling, Nottingham I mapped Albert Street & Victoria Street. It was only right at the very end that I got the point (Victoria & Albert: geddit?). It is immediately obvious from the state of it's road that Victoria Street is unadopted (a private road), but I was surprised to discover that the end of Albert Street is also unadopted. My goodness, but it is confusing...

This photo shows not just the state of Victoria Street (it is the road in the foreground) but also the locked-gate that lorry drivers keep trying to use to cut through from Westdale Lane East (at the end of the service road) to Main Road (well behind the camera) (I've done my damnedest to make sure that that does not happen with OSM):–

Albert Street gate

Unfortunately, I did not take any pictures of the next bit (22 March 2017 correction:– got one now), and even the Mighty Google does not show it since their street-view is dated 2014 & thus pre-dates the street re-tarmacing that makes all this obvious...

It is fairly easy to identify an unadopted road in Britain; it's residents are responsible for upkeep of the road (unlike most roads which are adopted by the local council, which also then maintains the roads & charges for that service) and they are normally cul-de-sacs. That often means that, if the road is at all old, that the road is very rough indeed. In the Thorneywood neighbourhood of Nottingham, Thorneywood Rise is both unadopted & on a steep slope. The tarmacadam upon it's road is immaculate. However, that is because the road used to be so foul that council wagons were suffering weekly damage whilst emptying the bins, and the Council eventually threw in the towel & re-surfaced it at zero cost to the residents.

Sure enough, Victoria Street meets both of these criteria, being both a cul-de-sac & as rough as can be. At one end is the gate (see picture above) and at the other is Albert Street. At this point it all gets a little quasi.

Numbers 10 & 11 Albert Street are each part of a semi-detached house which faces down Victoria Street (the houses on that side of Albert Street are numbered consecutively, whilst those on the opposite side are odd/even; this is a very confused road). 10 Albert Street stands on the adopted part of the street, whilst 11 Albert Street is on the unadopted bit. The road is very bumpy outside number 11 but very smooth outside number 10. However, it is only smooth on it's side of the road...

Opposite 10 Albert Street is the side of 1 Victoria Street. That house stands on an unadopted road, and be damned if the council are going to tarmac it's half of the road! So, 10 Albert Street's side of the road (LHS in photo below) is nice & smooth, whilst the other side (RHS) is most bumpy:–

the 2 halves of england

Welcome to England.

Location: Arnold and Carlton, Gedling, Nottinghamshire, East Midlands, England, United Kingdom

Recycling Containers

Posted by Ogmios on 26 February 2017 in English (English)

The German OpenStreetMap-Blog Wochennotiz № 343 mentioned an article in the German OSM-Forum about glass recycling containers. It criticises the use of the more general recycling:glass=yes instead of recycling:glass_bottles=yes.

While checking the tagging of containers in my region I found plenty other errors. Many containers in Germany have names describing their purpose and other problems.

Names instead of proper tags

In many cases recycling containers aren't tagged properly (e.g. recycling:glass_bottles=yes or recycling:paper=yes tags are missing) but with names describing their purpose. Very often they also have a name tag with an address or description of their location.

While names containing a description of their purpose are easily translated into proper tags, others are not. With names containing a description of their objects' location it is difficult to decide if it is a reference given by their operator (which should be tagged as reference), a helpful description (which should be tagged as a description) or redundant description of their location.

One can find recycling containers having a name tag using an Overpass Query:

out meta;

Excessive use of recycling:*=no

Some recycling containers have plenty recycling:*=no tags. According to the Wiki anything not having an recycling:*=yes is implicitly recycling:*=no. In some rare cases the explicit use of recycling:*=no might be helpful but in most cases it seems excessive and unnessesary.

Overpass Query:


out meta;

Incomplete Tagging

Many recycling stations are insufficiantly tagged, missing recycling:* or recycling_type=[container|centre] tags.

In many cases one can assess whether an object describes a container, recycling centre or landfill from satellite imagery. Recycling centres can also be recognized by their name. In some cases containers can also be recognized via satellite imagery (e.g paper containers in Goslar are alway moss green and in Koblenz they are blue).

Recycling stations without recycling:*=yes tags can also be found with an Overpass Query:


  node._[amenity=recycling] -

out meta;

Usage period (opening_hours)

To avoid noise pollution recycling containers have a defined usage period which is usually regionally uniform and can be expressed with opening_hours tags. Unfortunately it is not wiedely used.

Overpass Query:


  node._[amenity=recycling] -

out meta;

Contradictory Tagging

Beside the forementioned errors there is the full range of common errors with contradicting tags e.g. benches (amenity=bench) having recycling:* tags. Some can be found with the following Overpass Query:


  node._ -

out meta;


coloured glass

In Germany there are seperated containers for brown, green or white glass. Some containers have three slots for each type of glass. In that case there is imho no need for distinction. As well as when there is a container for each type of glass in one place.

In rare cases there is only one container for one specific type of glass. In that case I suggest to make a distriction. Since there are several tags in use I prefer recycling:glass_bottles=[yes|white|green|brown] where yes is default for including all types of glass.


According to the Wiki landfills are tagged as areas with landuse=landfill. It is not defined how to tag the purpose.

I reccommend to tag it as beforementioned and add a node tagged with the amenity=recycling scheme. This would be helpful for smaller landfills (especially for those without supervision, like green waste disposals in small towns). In that case it would be helpful to add another recycling_type like dump or landfill. Of course this should be discussed with the tagging mailinglist first.


Many recycling stations are a mess. In most cases it could easily be fixed. In less obvious cases one should check the concerned object on-site before making any changes.

In regard of the names I have to stress that names are an individual property and should not be a class-descriptor. I recommend consulting the Wiki.

Desolation Alley

Posted by alexkemp on 26 February 2017 in English (English)

I appear to be obsessed with broken-down garages. Here is one of the best examples so far, next to Priory Road,Gedling (otherwise, a very smart road):-

desolated garage

Location: Arnold and Carlton, Gedling, Nottinghamshire, East Midlands, England, United Kingdom

Routing — `exit_to=` to `destination=` rewriting

Posted by daniel-j-h on 26 February 2017 in English (English)

In which I explain the differences between the exit_to= tag on the highway=motorway_junction node and the more recent destination= tag on the way branching off of the motorway. In addition I will show the need for handling both tags and leave you with a tool for automatic rewriting.

To provide great guidance for our Open Source Routing Machine users we want to include ramp information for highway navigation.

There are two established tagging schemes for highway ramp signage:

  • Using the exit_to= tag on the highway=motorway_junction node where the ramp branches off of the motorway. This tagging scheme was established mainly because the default Mapnik style displayed the tag quite nicely.
  • The more recent destination= tag on the way branching off of the motorway.

Why do we have two completely different tagging schemes? Have a look at the following example where a ramp branches off the continuing motorway:

a . . . b . . d .
          ` . c .

In this case the exit_to tag is placed on the node b together with the highway=motorway_junction tag. So far so good. Now consider the common situation where multiple numbered exits diverge at a single point.

            . c
a . . . b `
          ` . d

Now there are destination signs for the ways bc and in addition for bd. There are workarounds like exit_to:left and exit_to:right tags but as you can imagine these do not suffice for more complex situations.

For these situations the destination tag is the better alternative.

Here in an example for where we need such a workaround.

Mapillary View

Photo by Mapillary user andrewsnow under CC BY-SA 4.0.

The Open Source Routing Machine supports destination= tags for quite a while now. Unfortunately handling exit_to= tags on nodes is not easy to implement for us, since we would have to create the road network representation first in order to derive the ways the destination signage is meant for.

There is a similar problem with stop sign nodes: without direction tag we have to find the nearest intersection to apply the stop sign penalty to the right turns. But in order to find the next intersection we already need the road network. It is simply not compatible with how the routing engine is structures to allow for high-performance parsing at scale.

Unfortunately the exit_to node tag is still quite popular, especially in the US. See the Bay Area as an example:


In contrast, the destination way tags:


We clearly have to support both tagging schemes at this point.

This is the reason I spent some time to build a tool for rewriting exit_to node tags to destination way tags where unambiguously possible:

It is quite conservative, taking care of oneway link roads, destination tags that are already present, making sure the highway=motorway_junction tag is present and more. It prefers correctness over quantity.

For the Bay Area it is able to add roughly additional 800 destination tags in a matter of seconds. A viable pre-processing step for making highway navigation with the Open Source Routing Machine more user-friendly, especially in the US!

Check out the tags' Wiki pages for more detailed descriptions:

Check out our recent Open Source Routing Machine v5.6 release in case you want to give it a try yourself.

Expedition GIS and OSM in Oman

Posted by Thom Starnes on 25 February 2017 in English (English)

Geographers - expeditions need you!

It was some time in October 2016, and my friend James asked me if I was up for an adventure. Without hesitating, I agreed. We had met at the Royal Geographical Society, at the annual 'Explore' weekend several years ago. We had stayed in touch, become good friends, and the previous year I had joined an expedition that he had led to Madagascar. There we studied the forest 'edge effect' i.e. the effect of proximity to forest edges, on amphibians and reptiles. On that expedition I had been appointed GIS and Data Specialist - a role not dissimilar to my then-day job with Amphibian and Reptile Conservation in the UK. I think it was somewhat to James' surprise when it turned out that I knew relatively little about herpetofauna, but my saving grace was that I did know about GIS. Evidently I had proved my worth because now - one year later - James was inviting me on another expedition. This time it was botanical. This time it was Oman. I had just enough leave left to take the three weeks that I needed to go. I began furiously downloading data and preparing maps for the next adventure...

How do you use GIS to prepare for an expedition?

I bought a laptop specifically for the expedition - a Lenovo ThinkPad X220 - which is still going strong having now survived the montane forests of Madagascar as well as the burning desert of Oman. On the previous expedition to Madagascar I had used Google Earth extensively, and I stand by it as a very reliable tool for expedition. Google Earth allows you to very easily cache (but not download) satellite imagery and elevation data for use offline - which lends itself to remote expeditions. It also consumes common files like GPX, KMZ and SHP. I used Google Earth to navigate to our chosen fieldwork location, make dynamic logistical decisions on the go, and to manage and visualise points of interest and all of our GPS data. Having a system capable of managing GPS data from many sources, I was able to maintain a centralised GIS or 'geographic information system'. Points of interested included the locations of our forest transects, navigational aids such as 'path through swamp' and the locations of important animal sightings. I was then able to distribute these locations back to all of the field GPS units every night, ensuring that every expedition team member had the latest spatial information necessary to manage the fieldwork effectively.

I also used the free and open source GIS software ‘QGIS’, which allowed us to visualise data from more diverse sources, and to analyse this data to tell us things about the environment. About one month before the expedition we met at James' house in London, and I was already able to show to the team the area that we were going to in great detail. On my little field laptop we pored over elevation models, satellite imagery and environmental data, all of which helped us to put our study site in context within the wider environment. I downloaded some OSM data showing roads and settlements, which I overlayed on top of the satellite imagery and the elevation model. These maps I also printed out to take into the field, and they proved invaluable for navigating to our remote field study site which lay beyond navigable roads, ox-cart tracks and mountain paths. I realised during that expedition that we could be doing much more with the OSM data - we could contribute to it, as well as benefit from it, and I resolved that on my next expedition I would aim to do just that.

What do expeditions stand to gain from OSM?

So it was that while preparing the maps and GIS for the recent expedition to Oman, I did a few things differently. First of all, I asked the other members of the expedition team to do some mapping in their spare time. I explained that by creating an OSM account they could map roads and settlements from the aerial imagery, and that I would download this data onto the laptop just before heading out into the field. This way, everyone on the team could actively contribute to our mapping resource before we’d even left home. Unfortunately, none of the team actually did this, and so on the next expedition I plan to run a quick intro session to get everyone set up in OSM and demonstrate just how easy it actually is to map in the iD editor.

The night before departure, I downloaded the entire OSM vector dataset for Oman onto my laptop. This may sound like overkill, but last year in Madagascar we had had to change our study site at the last minute, and all of the map data that I’d downloaded was suddenly redundant. Two of the team had then been forced to make an arduous day’s hike across the savanna in order to get enough mobile signal to cache the Google Earth imagery for our new study site. This time I wasn’t taking any chances. This time I was using ArcGIS, and I set about symbolising some of the key features such as roads and cities. I believe there’s an ArcGIS style file for symbolising OSM data in ArcMap, but I wasn’t able to get this to work in time for the expedition, so that’s something I’ll work to resolve next time.

When we arrived in the field, I began updating our OSM data based on local knowledge. There was one day in particular when we were stranded in Al-Jazer awaiting the fuel tanker to come and replenish the petrol station. We were sitting outside a coffee shop across the road from the petrol station and I got talking to a local gentleman named Said. It wasn’t long before I had pulled out the laptop to show him where we were going and where we had been, with the aid of the OSM data and the satellite imagery which I had also downloaded in preparation for the trip. He pointed excitedly at the fishing settlements that punctuated the coastline, calling out their names one after another. He would spell them out while I typed them each into the map, and then make me say them repeatedly until I had perfected their pronunciation. It was evidently a source of great pleasure to him to see the map updated in real time with the place names that he was providing me. Sometimes I wasn’t quite sure of Said’s information, and I would verify the place names with the two young English-speaking coffee shop proprietors.

As well as mapping roads which don’t yet exist on the map, it can be just as useful to remove features which have been added erroneously, or to update information about existing features. One afternoon James didn’t meet us at our agreed rendezvous. We couldn’t know for sure which direction he would arrive from, and eventually we decided to set up camp at this location and await his arrival. Darrach, one of our collaborators from Oman Botanic Garden, went off in search of him and by a great stroke of luck was able to make contact. Later that evening, James arrived back at camp with a truckload of weary botanists. They had followed a road on the map which turned out to be unsuitable even for their 4x4 vehicle. After this realisation, they had been forced to make a great detour to get back around to our rendezvous location. We’ve now updated that road to prevent others from falling into the same trap.

How can expeditions contribute to OSM?

After returning home, we are planning to sync our changes back to the OSM server. Anyone looking at this remote region of Oman will have access to better map data, and as a consequence will be better informed about the region’s geography. On future expeditions, I’ll be using OSM again, and I’ve been advocating this to friends and contacts who are planning their own expeditions. Every day, expeditions are going to remote corners of the globe. What an incredibly powerful tool we have here; to be able to openly access the latest geographic information and to contribute back to it for others to benefit from. I’m convinced that OSM is the future of global cartography; get mapping!

Location: 41, Al Wusta, Oman

1st Time Tracking/Diary 25FEB2017

Posted by KenK425 on 25 February 2017 in English (English)

Note to self: Amber's Birthday today. Today she is 40 years old (1977). OMG, 40?

First sunny day in a while. Temp: Low 30s, highs: l Low to mid 40s. Taking the bike out for a 200 mile trip to.... Don't even know if I'm going North or South. I'll fill you in when I'm back

Location: 8th Street Northeast, Lake Stevens, Snohomish County, Washington, 98258, United States of America

Adding unknown roads using ImproveOSM

Posted by mvexel on 24 February 2017 in English (English)

When using ImproveOSM, the Telenav tool to find and add missing roads (and other missing things) in OSM, sometimes there is just no detailed aerial imagery to see exactly what road type it is.


While you could say, 'Well without being able to see, I won't add anything'. But because ImproveOSM uses actual GPS traces from drivers, you know that people have been driving there. From the image in the example you can see that a fair number of people must have taken this route, so there must be some sort of road there.

So what I suggest is to add the road as simply highway=road (generic road tag). Then you or someone else can improve it later, based on better imagery or local knowledge.

The example in the image is this new way.

Remember that you can select multiple tiles on ImproveOSM by holding Shift while selecting. That way you can more quickly mark multiple tiles as Solved.


Fixing broken riverbanks

Posted by PlaneMad on 24 February 2017 in English (English)

Stumbled upon a dried up Nile on the map, which seems to be a jumble of large multipolygons.

This might require the expertise of an expert with the JOSM relation editor which can be a time consuming process.

It would be great if someone could make a simple howto tutorial for fixing such scenarios to help fix so many other big rivers that are broken this way.

Location: Ed Dueim, an-Nil al-Abyad, Sudan
Older Entries | Newer Entries