1. Armchair Mapping Mistakes

• Going to a place to survey it, returning home to mark it on OpenStreetMap, and then saying it was an armchair edit since I wasn't actually at the location when I uploaded my changes.

• Assuming that just because something was there in my childhood, that it still would be there and unchanged.

• Trusting satellite imagery more then my own eyes.

• Not correcting misaligned satellite imagery with GPS traces.

1. Surveying Mistakes

• Taking photos in public places like Main Street. It's better to be discrete and take photos from behind a car window then risk aggravating rural locals.

• Trusting a wonky smartphone satnav and compass when using Mapillary. Openstreetcam handles the wonky satnav part really well, but it's even worse with the compass since you can't currently correct it manually after uploading like in Mapillary.

• Using OpenSTREETcam on a footpath.

• Not uploading high quality 360's to Mapillary when possible and instead focusing on low quality 2D images.

• Not using Mapillary or OpenStreetCam at all when there was no coverage in my area.

• Not annotating as I mapped of areas with really outdated satellite imagery.

• Surveying without a full charge on my devices.

• Using a standard lens instead of a wide angle one.

1. Community Mistakes

• Not taking advantage of my surveys to also improve Wikipedia, Wikidata, and Wikivoyage.

• Not editing the OpenStreetMap wiki to help other mappers.

• Trying to do things alone.

Something in the weekly newsletter caught my eye:

Miguel Sevilla Callejo (msevilla00) from Zaragoza, Spain, is currently in Wales. He noticed an inconsistent use of English and Welsh in OpenStreetMap. His email resulted in a readable, long-lasting and controversial discussion on the Talk-GB mailing list (threads in July and August) and comments in an OSM changeset. Nearly the same problem in Switzerland – read the following article. 😉

— http://www.weeklyosm.eu/archives/9374

Miguel Sevilla Callejo (msevilla00) de Saragosse, en Espagne, est actuellement au pays de Galles. Il remarque une utilisation pas toujours cohérente de l’anglais et du gallois dans OpenStreetMap. Son courriel a donné lieu à une longue et controversée discussion sur la liste Talk-GB (juillet et août) et des commentaires dans un changeset OSM. Presque le même problème en Suisse – Lisez l’article suivant. 😉

— http://www.weeklyosm.eu/fr/archives/9374

So I went to the “Multilingual names” page https://wiki.openstreetmap.org/wiki/Multilingual_names and found Canada conspicuously absent. Is this because:

1. we're already doing it perfectly in Canada; or
2. local mappers already know what they're doing (an argument that seemed to be dismissed in the original discussion about Wales); or
3. nope nope nope not touching that with a rad-hardened barge pole?

I recently received notice that a changeset I had made had been reverted due to not following the protocols in place for importing data. First the facts of the matter. My family was going to vacation at Folly Beach in South Carolina and I thought it an excellent opportunity to do some mapping while in the area to verify local businesses and add information about them to the map. When viewing the area in OSM I saw that only a few buildings had been mapped and that the majority of POIs were nodes. I decided that I would see if I could find a building footprint file already created from the county so that I could add the buildings to the map and then replace the node information with tags connected to the structures where a single occupant resided within the buildings. I find this to be cleaner when it is able to be done rather than have closed ways and nodes trying to describe the very same thing. Now I will admit that I had some confusion and very much a lack of knowledge of what constituted an import and the process that was in place to regulate them. I found a file with the county for building footprints, exported the buildings for Folly Beach using Qgis, cleaned up the attribute data so that when bringing them into JOSM they would have the tag building = yes and proceeded to copy them into the main layer. After this was done I scoured the area for duplicates and resolved any there were, removed nodes that had POI information and instead attributed that information the the closed ways, and used the error checker to insure that I had not introduced any errors. I believe it was necessary to move some roads that ran through buildings due to geographical error but other than that it was nearly a blank canvas. I posted the changeset and readied myself for my vacation.
On arrival and with the mind to do some mapping in the wild I loaded up Vespucci and began downloading the data so that I could get to it. I was amazed to find that the buildings I had placed and properly attributed had been removed. When I arrived back at home I checked my email and found that a user had redacted my changes and rolled everything back to as it was before I began editing, citing a lack of a wiki page or discussion within the import mailing list. I searched out the import page to see if I had been in violation and it would seem that I had been. Mea culpa, mea culpa.

Now based on the directions at the import site I can see that if a group was to be doing very large and numerous imports the instructions make complete sense, especially in regards to large geographic areas. The need to insure that data is duplicated or error is introduced has been addressed and I see that there were lessons learned the hard way. Based on the instructions included it seems that the idea is about very large imports along a county, province, state, country, or large city where the potential for error is far greater and much data may already exist. Folly Beach is, according to Wikipedia, 18.9 square miles, the data that existed were a few nodes, the beaches, the wetlands, the roads, and a couple of buildings. The chances of error were minuscule and the import, which I acknowledge failed the guidelines, was checked over for error. My problem is that the wholesale redaction of the changeset did not actually look at whether there was an improvement to the map (I believe throughout the OSM community it is generally found desirable to have buildings represented) nor if any error had been introduced. It would seem rather that a prominent individual within the community has created an account that is solely dedicated to a vigilante style role of cleaning up what he describes as vandalism and what he deems to be bad imports and mechanical edits. Now while this role may be a valid and needed one I do find it intriguing that while there is so much oversight in the import process, one individual can decide for himself without discussion or debate that a changeset is either vandalism or an illegal import or is damaging to the map. Be that as it may I submit myself to that editing as I had seemed to violate the protocols in place.

As to the protocols themselves I find that while it does seem to make sense to prevent error or duplication, it has a chilling effect on mappers and on entities that may wish to upload their data to map. In the United States there are 50 states, 3,007 counties, and 19,354 incorporated places that are, for the most part, independent of one another. This also does not take into account that each of these entities would have multiple commissions or departments that could have interest in uploading data to the map. What the import guidelines would mean for these groups, should they wish to share data with the map, is that they would each create a wiki page for each import they wish to do, they each create an account specific for the import, and that they would submit their import to a mailing list for approval. Having worked in the public sector for small government I can verify that the majority would not want to go through this hassle every single time they wished to share data with the community at large, nor would they have the time at their disposal to do such. This leads to less adoption of the map and a loss of great data for the map. The question would be what to do about this.

We could hope that the many different entities would work in cooperation to limit the amount of import wikis and requests by combining their efforts or even forming a committee to combine their efforts thus making the requests less numerous (presupposing mass adoption of the map). This could happen and it would be great, but I do not see it in the near future as many have no idea about the map or about contributing to it. The second proposal that I would humbly submit is this, allow a trusted partner status to communities and groups much in the same way that Google has done with their map. Communities have a great desire to see their communities represented accurately in online maps. In two of the local governments I worked for we had this partnership with Google, which did not exclude us from scrutiny but rather gave us the benefit of the doubt that we knew what we were talking about. With this process an entity would need only submit once for the right to import, committees that accept the applications can make a stress of what imports are allowed and the requirements the group must follow, verify that the group is legitimate, and then approve them to maintain their AOI on the map. I think this process could lead to greater adoption and more accuracy for the map in the long run.

Whatever may be decided on the future of imports I still acknowledge my error and humbly offer my apologies for breaking protocol in my efforts to strive for the bettering of the map.

Here's my list of some scientific articles on OSM that I might read once retired:

• Neis, P., & Zipf, A. (2012). Analyzing the contributor activity of a volunteered geographic information project—The case of OpenStreetMap. ISPRS International Journal of Geo-Information, 1(2), 146-165.

• Neis, P., & Zielstra, D. (2014). Recent developments and future trends in volunteered geographic information research: The case of OpenStreetMap. Future Internet, 6(1), 76-106.

• Senaratne, H., Mobasheri, A., Ali, A. L., Capineri, C., & Haklay, M. (2017). A review of volunteered geographic information quality assessment methods. International Journal of Geographical Information Science, 31(1), 139-167.

• Barrington-Leigh, C., & Millard-Ball, A. (2017). The world’s user-generated road map is more than 80% complete. PloS one, 12(8), e0180698.

Over the past few years, I've been mapping a lot of bus stops and routes. Over the past few months I've been looking around how it's done in other places around the world.

What I find (this may of course be influenced by what I wanted to find) is that most bus stops start out as a node next to the way, tagged highway=bus_stop, usually with a name on it.

Then somebody comes along, who glues it to the way. Then somebody else comes along who maps a platform next to the way, using a way, copying all the tags over. They do this regardless of the whether a platform actually exists. They think they need this to add 2 objects per stop to the route relations. Somehow the wiki convinces them of the need for this.

Mapping platforms as ways where there aren't actual platforms feels wrong to me. Adding a set of details to more than one object also doesn't feel like the most sensible thing to do. Adding 2 objects to each route relation for 1 real life object makes working with these route relations harder to do.

I'd like to see that a casual mapper can start out mapping a bus stop as a node next to the way, as highway=bus_stop.

Possibly they add public_transport=platform to this node. It seems odd to do so, even if no platform is there, but that's how things evolved. Tagging it as public_transport=platform means that a role platform will be assigned to it in the route relation. (if the route relation has public_transpot:version=2). It's the answer I got when I asked the question a few years back on the mailing list. I usually put that node more or less where the pole is. But the exact position is not all that important, as long as it's more or less where passengers will be waiting.

As far as I'm concerned this node is what represents the bus stop at this side of the street, so it seems obvious that this is the node that should be added to the route relations. The nice thing about doing it that way, is that there is no need to transfer details or relation membership from one object to another. This node is there for the lifetime of the stop. One object to work with, containing all the details, including directly available coordinates.

Now the stop_position nodes. First off, I don't see a need to map all of them and since where I map bus lines they are not all present, I don't see why we would add any of them to the route relations. No need to repeat the stop's details on them either.

Then the platform ways. If there are actual platforms, I would tag them highway=platform/public_transport=platform. Nothing more, nothing less. No need to add them to the route relations.

Then the stop_area relations. This is where we get the chance to indicate which platform node(s) belongs to which stop_position node(s) (if mapped) and which platform way (if present). Doing it this way means to have such relations for each group, where a group is the ones on one side of the road or the ones belonging to 1 platform in a bus station. They can then be grouped in a hierarchy of stop_area_group relations, although this is only needed for the more complex ones and for bus stations.

Sometimes I wonder if I should create a proposal for this. Usually I give up before even getting started, as I know how hard it is to convince anyone in the OpenStreetMap universe, once they are set in their ways. Little by little I'm starting to build the courage to go ahead with it after all. Writing these diary entries is a small first step, also to see if there would be support for such a simpler way of mapping public transport.

Also don't get me wrong, it's still possible to fill in all the detail of the accomodation surrounding the bus stops, but in a way that builds further on what was mapped previously, instead of converting from one object type to another or needing to add details more than once.

Out of curiosity, I pulled some statistics on the US Rail network. This does cross into a bit of Canada and Mexico where the GeoFabrik extract approximated the boundary.

level_crossing  TOTAL   232167
crossing    TOTAL   8231

Rail_Bridge 47232
Rail_Tunnel 16394
Highway_Bridge  70811
Highway_Tunnel  8972

Total Layer Crossings 143409

A bridge or tunnel is counted as a single occurrence no matter how many rail lines are included. Each marked crossing node is counted, so a fully mapped rail yard could contain many crossing nodes.

For a closer look here is a breakdown of the top 20 categories of level_crossing - the first column is the type of 'highway', and the second column is the type of 'railway' in OSM:

residential rail    112659
service rail    29171
tertiary    rail    26789
secondary   rail    16717
unclassified    rail    12732
track   rail    10058
primary rail    6734
residential disused 1628
residential light_rail  1547
residential tram    1413
trunk   rail    1122
tertiary    light_rail  1114
secondary   light_rail  1059
service light_rail  676
residential abandoned   660
primary light_rail  517
tertiary    tram    493
service disused 435
tertiary    disused 372
residential Unknown 371
residential preserved   353

A type of 'Unknown' usually means that a node that joins 'highway' to 'highway' is marked as type level_crossing for example.

Similarly, here are the top 10 'crossing' types:

footway rail    2984
footway light_rail  2083
path    rail    881
cycleway    rail    762
footway tram    565
path    light_rail  116
cycleway    light_rail  96
footway miniature   86
footway preserved   62
residential rail    56
service rail    34

Note the presence of 'residential' and 'service' which are either newly incorrectly marked 'crossing's or a rail crossing at the junction of 'residential' and 'path' for example.

To see the complete breakdown to perform custom category groupings, obtain the raw .CSV files from Rail Crossing Counts

The Mayor and City Council of Baltimore acted swiftly after violence at the Unite the Right rally in Charlottesville, Va. led to a national conversation on the removal of Confederate monuments. The protests centered around the removal of prominent Confederate generals' monuments in that city. In Baltimore, the City Council passed a bill that permitting the removal of four Baltimore monuments to the Confederacy. The mayor executed the order by contacting local firms to remove the four Confederate monuments in Baltimore during the night of August 15, 2017, into the following morning.

OpenStreetMap is a database of physical features. Since the four monuments are no longer physically present, I have removed them from OpenStreetMap. The removed statues include the Roger B. Taney Monument, the Lee-Jackson Monument, the Confederate Soldiers and Sailors Monument, and the Confederate Women's Monument.

Weekend before last I spent several hours roaming Abadan and Gypjak, far western suburbs of Ashgabat, collecting street names, points of interest, and adding streets that didn't appear on the map (unplugging the SD card from the Garmin navigator forces it to collect tracks where you actually are, rather than trying to align them to the nearest street). Those towns, while not yet complete, are in much better shape in OSM now.

The research continued on names of monuments in traffic circles within the Ashgabat city limits. I count 22 monuments inside traffic circles and believe we now have names for all of them. If you are curious, enter "binasy, Ashgabat" or "monument, Ashgabat" in the OSM search box (without the quotation marks) and see what pops up.

Construction in Ashgabat is winding down as the Asian Indoor and Martial Arts Games approach. They start September 17 and the city is preparing.

This Friday, I will be at SOTM in Aizuwakamatsu, Fukushima this weekend talking about the state of validation on OpenStreetMap! I will talk about the need for making a validated error free map with OSM data, the recent efforts of the Mapbox Data team to review OSM changes and what the future of data validation might look like. If you are interested to attend the talk, grab a seat in the main hall at 4:10pm on Friday at the Aizuwakamatsu City Culture Center.

If you are interested in a deep-dive into validating edits in your area on OpenStreetMap, attend Validating the Map workshop conducted by manoharuss on Sunday at 1:30pm in Room-1.

Distribution of reviewed and validated changesets using OSMCha in 2017 | View Interactive Map

There's recently been a thread on the talk-gb mailing list where someone has decided that, despite previous custom and practice there, the "name" field in both English- and Welsh-speaking areas of Wales should be a compound of both the English and Welsh names. No-one says "I'm climbing up Snowdon / Yr Wyddfa today", they'll use one name or the other, not both together.

In the Welsh-speaking areas the Welsh names are more likely to be used; in the English-speaking areas the English names. It's not a hard-and-fast rule; this peak in the Black Mountains is referred to about equally by both the Welsh and English names, despite it being in a predominantly English-speaking area.

Wikipedia gives an idea of Welsh-language take-up here. That's a bit broad-brush; for example I don't think there's an isogloss between Carmerthenshire and Swansea where people gain/lose the ability to speak Welsh.

So how is it possible to extract data from OSM with the Welsh name in the Welsh-speaking areas and the English name in English-speaking ones, both when creating e.g. a rendering database for the first time and when updating it as people update OSM? Firstly we'll just consider the "loading the database" part.

There are a couple of possible solutions to the problem. I used "osmosis", which has a handy "tag transform" feature. The Welsh one is here; the English one is similar.

Very roughly, the Welsh-speaking area of Wales corresponds to this area. That's not perfect, but it's not a bad approximation for a rectangle. I downloaded the latest Welsh data from Geofabrik and cut that area out of it:

osmosis  --read-pbf wales-latest.osm.pbf  --bounding-box left=-4.82 bottom=52.02 right=-3.34 top=53.69 --write-pbf wales_cy_before.pbf

Convert the "Welsh-speaking" part to names based on "name:cy":

osmosis --read-pbf wales_cy_before.pbf --tag-transform transform_cy.xml --write-pbf wales_cy_after.pbf      

Create a copy of the larger file with names based on "name:en":

osmosis --read-pbf wales-latest.osm.pbf --tag-transform transform_en.xml --write-pbf wales_en_latest.pbf

Merge the two together (do it this way around and the "Welsh" file seems to take precedence):

osmosis --read-pbf wales_cy_after.pbf --read-pbf wales_en_latest.pbf  --merge --write-pbf  wales_merged.pbf

And load:

osm2pgsql --create --slim -d gis -C 2500 --number-processes 2 -S openstreetmap-carto.style --multi-geometry --tag-transform-script ~/src/SomeoneElse-style/style.lua wales_merged.pbf

The "osm2pgsql" command to use obviously varies depending on the data and the style used; I'm using this lua tag transform (that's unrelated to the "osmosis" tag transforms described above) and this map style.

The result is that this road now displays as "Stryd Fawr" and this road as "Glasfryn Road". Success!

Edit: There's an automatic script to do this (for the style I use) here. I've updated that to use a .poly file (thanks to SK53 for that). I've also used Scots Gaelic names for the far northwest of Scotland, and the results can be seen here

For those that have check my previous tutorials, are aware of the benefits of using Mapillary imagery (especially the traffic signs detections), however some crosswalks don't have traffic signs nearby. By using Mapillary AI we are able to detect them fast and add them to OSM. Here's the video tutorial how you can use AI Detections for OSM.

Find out more about Mapillary AI Detections

My previous tutorials: ID Editor and JOSM

The end of the 2017 Google Summer of Code is getting closer. In the last weeks I was working on styling the map.

The most challenging task this month was definitely the anti-aliased ways, and I ended up doing that with the help of barycentric coordinates. I also added borders to areas and paths. I did a mistake previously, and not all buildings were visible, but I have fixed that issue, and now small buildings are also visible.

There is still some work to do, I intend to concentrate on the obvious things in the next day. Looking at the pictures below one can see that dotted/stippled lines are not yet supported (in the first picture the tiny red lines should be dotted). Fixing the looks of the texts also have high priority. The size is not quite right, and it is blurry. I also want to add support for patterns before the GSoC ends.

Debrecen:

Budapest close:

Links:

Libosmscout: https://github.com/Framstag/libosmscout

My project: https://summerofcode.withgoogle.com/projects/#4992829691527168

I was wondering how to revert an edit made on political bias. This user deleted the majority SeaWorld Orlando but the rest of their edits look to on the up and up. Change set: 50681538

Chris Barrington-Leigh and I have been working for the past few years to assess the completeness of the street network in OSM. We're pleased to have now published our results in the journal PLoS ONE. Thanks to many suggestions from the OSM community on our preliminary analysis.

Here are the highlights from the paper's abstract:

We find (i) that globally, OSM is ∼83% complete [as of January 2016], and more than 40% of countries—including several in the developing world—have a fully mapped street network; (ii) that well-governed countries with good Internet access tend to be more complete, and that completeness has a U-shaped relationship with population density—both sparsely populated areas and dense cities are the best mapped; and (iii) that existing global datasets used by the World Bank undercount roads by more than 30%.

An update using the April 2017 snapshot suggests that completeness is now ~89%. Our more detailed results and all our code are available on GitHub. Here's a sample of the largest 10 countries (updated through 2017), showing the actual growth in OSM road length and our model fits:

And here's the fraction complete, also updated through April 2017:

out there is trying to run Vespucci 0.7.0 which dates back to April 2011 on a Xiaomi Redmi Note 4 with Android 6.0.

While the app will run, 0.7.0 was released a while before 64bits for OSM element ids became necessary (early 2013), and trying to parse current data will lead to a crash.

With other words: please upgrade to a current version!

Thank you

Again a bit of prototyping today.

I always wondered what the best way to download all objects along some GPX track (more generally a list of lat/lon pairs) in Overpass API might be.

Usually, you don't want to create some complex poly-filter for this, or even worse upload your gpx track as OSM way just for the sake of finding out what's close by.

You might have come across the around filter, which comes in handy to find objects around a center point. I have extended this idea a bit to also handle linestrings.

Here's a first result: a turquoise circle in the middle is our great made up GPX track, consisting of about 20 points. All the yellow stuff in the background is what Overpass API returned as highways up to 500m away from our circle. Obviously, that circle doesn't exist in OSM, so we're really looking at what's close to our virtual way.

Circle

Live demo: http://overpass-turbo.eu/s/qX9

Road trip

Imagine you want to create a map with only minimum features (motorways, some important nodes), and some place names along your own lat/lon pairs. Here's an example for such a trip from Frankfurt to Basel, downloaded as 10MB PBF file, processed via osm2pgsql and rendered by Kosmtik:

Live demo: http://overpass-turbo.eu/s/qXI

Github issue: https://github.com/drolbr/Overpass-API/issues/418

Always wanted to make a nice railway map style. A well spent 20 mins before bed.

Dark Railway Map

A turn-restriction defines restricted or mandatory turns at a junction and are one of the most important features to map for accurate driving directions. Thought I would quickly make a comparison of how different map data editors visually represent this feature for mappers. Pick the best:

OSM

iD

JOSM

OSM navigation map

Restriction Validator

Add me now ! Cwassim87 👻👻👻👻

Yesterday we had our anniversary OSM Time meetup, where we celebrated 13th years of OSM, and we also had a workshop for the participants, to learn how they can extract information's from OSM, using overpass API and overpass-turbo.

Attaching 2 slides examples :

You can find the slides here

You can find the materials for the participants here