Finally I managed to import my hiking trip to mount Shir Kuh near Yazd in Iran into the OSM database.

So far, there was (at least to my knowledge) no map of the 2 hiking paths to the summit and the hut available. I hope that hiking enthusiasts visiting Iran in the future will have it a little bit easier to hike to Shir Kuh!

BTW: A guide is not really necessary (With the GPS map now anyways!)

Unfortunately my GPS accuracy was awful, but I tried to interpolate it with the satellite imagery.

Happy hiking in Iran :) (Yes, you should definitely visit this country!)

https://www.openstreetmap.org/#map=13/31.6338/54.0958

Might depend on what exactly one considers a point of interest, but looking at some common keys:

• http://taginfo.openstreetmap.org/keys/amenity
• http://taginfo.openstreetmap.org/keys/shop
• http://taginfo.openstreetmap.org/keys/craft
• http://taginfo.openstreetmap.org/keys/office
• http://taginfo.openstreetmap.org/keys/leisure
• http://taginfo.openstreetmap.org/tags/highway=bus_stop
• http://taginfo.openstreetmap.org/tags/railway=station
• http://taginfo.openstreetmap.org/tags/aeroway=aerodrome

we get around 17.8 million features that could be potential landmarks or points of interest.

Just counting points that have names, we get around 12.9 million features.

Maybe there is a better way of finding out, but here's a new conversation starter at your next mapping party!

Hi everybody,

I'm a newcomer enthusiast focused mainly in editing in Tirana (Albania) and Diber (Albania). It seems like there is a greater need for projects like OSM in Albania since foreigners that visit the country, but also locals find it hard to find directions to move around cities.

I really hope to make further steps for the OMS community in Albania in order to grow the project even more.

Cheers,

Recently, I wrote about [how you could use government road data to improve OpenStreetMap](www.openstreetmap.org/user/joost schouppe/diary/39250). Here's a move in the other direction.

As an employee of the city of Antwerp, I was involved in the recent 'validation' of the Road Registry (Wegenregister) for our city. This registry is managed by the central Flemish government, but final responsibility for the content is with the municipality. Validation means the central government gives us a new dump for us to check for errors. This way of working is only a temporary situation: in the future, we will be live editing in the central database itself.

Some background

There's an amazing amount of cleanup left to do, but we decided to focus on the completeness of the main road network. Before, we did this by comparing with our own city registry of roads. But that is not being updated anymore. So for the first time, we used OpenStreetMap for the validation. Using FME, we identified roads which exist in OSM, but not in the Road Registry. We excluded service roads and "slow roads" (paths, tracks, cycleways), as these are less of a priority right now.

Next time, we will also look at roads that are in the Road Registry, but not OSM. In some case, the lack of road in OSM is really an indication of an error in the Registry. For example when a road has been closed, and the government somehow missed that. This is more work, because the Road Registry contains a lot of little bits of "roads" that are really just driveways. Because nobody cares about them, they aren't in OSM. But they are quite hard to filter out from the Registry data.

The results

The cleaned up dataset of roads that are in OSM and not in the Registry was really quite limited. Only 138 situations needed manual review. Of those cases, 32 were a simple matter of slightly different geometry. For example when OSM mapped the road as a polygon, which we didn't really take into account. We identified 33 cases where the Road Registry was clearly wrong. Then there were 31 cases that looked like they shouldn't have been in the selection anyway: they are private driveways, parking aisles, tramways. About half of those needed a fix in OSM. But the "tramways" were actually dedicated bus roads on top of tramways.

Most of the "mistakes" detected in OSM were caused by larger geometry issues. Sometimes the centerline of a road is debatable, but in most of these cases OSM could be improved, sometimes vastly. These were most often roads that hadn't been touched in years. Only in a couple of cases was OSM really vastly wrong. This happened when the city reorganized streets, and somehow, nobody noticed. Most striking was the Troonplaats, which is a quite popular square. In several cases, OSM had already been corrected in the month or two between data download and final analysis (though to be honest, some of those were fixes of mine). A few mistakes were caused by errors in or outdated road classification.

There was one striking case (pictured above), where we were convinced OSM was wrong, but we apparently missed a big change in the road geometry. Fortunatly there was a [Mapillary sequence], of course one of the 1.1 million pictures uploaded by filipc. Even though the aerial photography in Flanders is excellent and recent, the only place this road shows up is on the OSM map.

Have a look

You can have a look at the cases here. There's a bit of work left on the cases with a difference in geometry. The easiest way to get the Road Registry into your editor is with this (slightly outdated) WMTS:

https://api.mapbox.com/styles/v1/joostschouppe/cir6gwq2p0016cjlyx6e1b1cc/tiles/256/{z}/{x}/{y}?access_token=pk.eyJ1Ijoiam9vc3RzY2hvdXBwZSIsImEiOiJjaWh2djF1c2owMmJrdDNtMWV2c2Rld3QwIn0.9zXJJWZ4rOcspyFIdEC3Rw

You can contact me to get the FME models we used to identify these roads - they aren't very complicated. You could easily do similar things in open source software.

Get ready for 1st Mapathon at Dhaka College!!! Link : OpenStreetMap Mapathon

Any one can join the event. If any new comer interested then He/She also can come to the program.

#Also Online available.

OpenStreetMap DhakaCollege OpenStreetMap DhakaCollege

Continuing from our previous weekly round up, these are the observations between 12 September - 30 September.

Commented:

• Deleted buildings: changesets 1, 2, 3.
• Deleted admin boundary of region in Burma: changeset.
• deleted mosque: changeset.

Community members commented on following changesets:

• Adding numbers on the name tags for lot of buildings: changeset.
• Renamed a department store in Italy to multilingual name tag with Chinese added: changeset.
• Deleted name tag of a multipolygon and other features: changeset.
• Deleted lake that exists in the imagery: changeset.

Reverted:

• Deleted tertiary roads: changeset community member reverted the changeset.
• Bad imports: changeset. We reverted the changeset.
• Uploaded learnOSM test data to the map. changeset community member reverted the changeset.
• Added fictional roads and deleted many existing highways & other features: changeset. We reverted the changesets.
• Deleted buildings in Philippines. We reverted 4 of his changesets 1, 2, 3, 4.
• Added natural=water to all the nodes of the lake. changeset. We deleted the edits with proper comment.

These were some of the inconsistent edits for this week. Do keep an eye and please comment on such changeset, this will help in maintaining the data on OSM accurate and coherent.

Look forward to another roundup next week.

I'm happy to announce a time limited Overpass API test drive that is based on the official 0.7.53 release + some experimental features. The server is updating continuously like the main instance, but doesn't have so called attic data.

That's a great opportunity to try out your favorite queries and post your feedback below

Switching to the test drive instance

In overpass turbo, go to "Settings", enter the following server address, hit the save button and you're all set for testing.

http://dev.overpass-api.de/test753/

(sorry, http only at this time, i.e. you need to run overpass turbo via http as well)

Remember: you can always switch back to one of the 3 public servers listed in the "Server" drop down list, in case there's some issue with the test drive.

A few examples:

(you need to switch to the dev server first)

• 'Ring of fire': http://overpass-turbo.eu/s/iBF
• Find all 'segments' of a street, even containing gaps: http://overpass-turbo.eu/s/iBH
• Global xmas-features: http://overpass-turbo.eu/s/iFM

Have fun!

Emmor (account Palolo) asked some questions in an OSM message, I've put my response here as it may be of general interest.

On 2016-09-26 22:32:47 UTC Palolo wrote:

Ben, Thanks for your contributions to OSM, especially for the rivers you have cleaned up on the west coast. I also just came across your spreadsheet tracking users and find it fascinating.

I was wondering if you could convert your notes into 3 categories of mappers: 1) Imports, 2) Mappers, 3) Combination mapper/importer ?

That's a good question, I've considered trying it, but it can be difficult to tell them apart, or it requires individual detective work that I just haven't gotten around to. Generally, for the import or part-import accounts, I've put the title of that import in the "Grouping" column.

If they have added millions of nodes, and there is nothing about importing in the "Where, What" or "Grouping", it means I haven't been able to figure out if they are an import account or not. For example the Japanese accounts, "Tom_G3X" and "ikiya" and "yamasan". They are probably imports(?)

I've also put the account name in bold (like katpatuka and Heinz_V) if they have contributed millions of features without any obvious importing. Anyone who belongs in this category that I've missed, please let me know!

Also have you thought about gender classification?

I've thought about it, but it is also very hard to tell. Very few account names/images are clearly gendered, and nearly all those that are, by name or image, appear male.

It appears to me that there are very few female top contributors. I wonder why this is since it is open for anyone to edit.

Probably for the same reasons that cartography and technology in general is so male, cultural bias encourages it for men and encourages other things for women.

The top-ranked female account that I know of is "ediyes", a Mapbox mapper at #137/88 (more than 88K changesets!). However, it's entirely possible that some of the mysterious accounts in the top 100 are female. In the top 1000, there are many, including other female mapboxers (dannykath, karitotp, samely...) and the Queen of #MapLesotho, tshedy.

One editor that has been super active over the past 9 months is "Aiko Nakata", which is a Japanese female-only name. Also "Febrina Dewi" and "Fatisya Ilani Yusuf" and "asti_shinoda", all women I believe, were the top-ranked contributors to #MissingMaps last year, all from Indonesia, an amazing amount of mapping work.

Intrigued by Alan McConchie's presentation on OpenStreetMap past(s), OpenStreetMap future(s), I took a stab at looking at several cities in Asia using a similar approach at charting nodes creation and modification. In his talk, Alan gave a portrayed an ideal scenario where the data is constantly-maintained reaching a state of singularity. Are we seeing any of this trend in Asia?

The only non-Asian city I included is Berlin, Germany (in thick grey). This will be my benchmark as it is widely known that the German community is one of the most active in our community. I intentionally won't draw specific conclusion to any of the city listed here. Each community is unique and deserves an in-depth look on its own but, I am posting questions that interest me by looking at the charts. Of course, everyone is welcome to share their own insight in the comments!

Cumulative nodes created and edited in the last 10 years

Cumulative nodes created (x) versus edited (y)

At 5 million node limit

At 3.5 million node limit

At 1 million node limit

Some questions

• Most cities had its first edit since the beginning of 2007, but mapping really took-off around 2011. Why is that?
• Compared to Berlin, the cities that has a constant steep upward slope through time are Tokyo, Manila and Bangalore, is this an indication of an active community?
• What's up with Bangalore? There's striking increase of creation/modifaction middle of 2015.
• The singularity model doesn't appear in any of the city. Even for Berlin, the ratio is ~2 creations to 1 modification. No Asian city got this proportion at all. Are we seeing a Borgesian trend in Asian cities or this is just an indication of a young but slowly growing community?

I look forward to any of your insight, please post them here. I am also excited to meet some of our Asian mappers this weekend at the State of the Map Asia. I'm hoping the State of the Country talks can shed more light to what's happening in these cities. :)

Caveats

Data came from Geofabrik's country pbf extracts as of Aug 2016. This is not the full history, so deleted nodes were not counted.

Okay, I've got tired of this UI, and I'm swamped with other tasks, but there is some money left from my travel to SotM. So I am announcing a grant: 100€ for a merged pull request allowing people to subscribe to comments in OSM user diaries. (NB: 300€ now, thanks to Stereo and Mikel.)

There should be a checked by default checkbox near the "Save" button ("Receive notifications about further comments"), and a button to subscribe/unsubscribe. All notifications should go to e-mail, much like changeset comments now.

When you have your pull request merged, I'll transfer that money to your card or bank account. And of course I'll publish a big thank you :)

The offer is not indefinite: the PR must be submitted until the 1st of November and merged before the 1st of December. And yes, there might be a competition, in that case OWG will decide the winner by merging a pull request.

Just started mapping this area. Currently looks uninhabited on the map, but check back later in a few weeks or so, or join me in tracing the area. Mapping areas like this is so much different from mapping in Western Europe where you sometimes wonder if there's anything to add. It gives a larger sense of accomplishment to 'discover' a town or an entire valley compared to drawing in a missing footway.

Improvement of OSM data quality using osmlint and to-fix

To help make it easier for mappers to clean up various quality issues OSM, we have used osmlint to detect dmap ata issues using javascript validators and automatically publish them as tasks daily into To-fix.

In this way mappers are solving thousands of connectivity errors, overlapping ways, unclosed ways, incorrect tags or adding missing tags on the data using satellite imagery daily. Most issues are caused by inexperienced users who may be unaware of how to use the map editor and tags correctly and can be easily fixed by experienced remote mappers. Task descriptions and instructions to fix are provided in the Github repository.

JOSM integration

Fixing issues using To-Fix JOSM plugin

To make it even easier to cycle through a task of interest, experienced mappers can solve issues much faster using the To-Fix JOSM plugin.

Progress of fixes

The community along with the data team at Mapbox has helped cleanup many thousands of issues in the last 2 years.

To-Fix errors fixed in the last two years

During the course of making these fixes remotely, our team has tried to minimize making incorrect fixes by montioring all changeset comments and taking appropriate steps to improve the algorithm and processing. Now countries with active mapping communities are ignored, changeset comments more descriptive and we recently made a fix to prevent the creation of large changesets that clutter the history view on OSM.

Our workflow to solve to-fix issues

The data team constantly monitors and fixes to-fix errors every day to clean up OpenStreetMap data.

Issues solved in July

A task is assigned to one specific data team member after its completion so that it is constantly monitored for new errors. These new errors are detected and fixed immediately thus reducing the response time to fixing bad edits on the map. Every week, the corresponding tracker on Github is updated with total detected errors and total resolved errors to monitor and document any sudden spikes in issues.

Keeping OSM data error free

The goal is to have a community made map which is constantly growing at the best possible quality. Reaching this goal requires a lot of work to improve the map editors, better validation tools, and the contribution of more experienced mappers. If you are a javascript developer, you can help improve osmlint to catch even more complex data issues or contribute to the development of to-fix, and if you are an experienced mapper you can help fix issues on to-fix.

From the data team at Mapbox

it took a month to add 99 percent of all district boundaries of Afghanistan. Only problem left is the fate of Darwaz district which I couldn't decide: en.wiki says it got split into Maimay, Nusay and Shekay District but other sources name a Darwaz and Darwaz-e-Balla District.

Someone else can now make nice svg-files for use with wikipedia articles!

☺

At the beginning of July I published the website schools.mapthe.uk.

Since then more than 1000 Schools have been mapped or improved. The user base is currently quite small so I hope more people are going to use it.

The Database contains about 50,000 School addresses and other metadata and 30,000 schoolground polygons, so there is still some work left ;-)

On the website you find a video with detailed instructions how to use the tool and how to identify a school. Additional information is avalilabel at the help page and on github

This application was built to enable a quick overview and import of existing open data into OpenStreetMap. It tries to demonstrate a possible approach and can serve as a blueprint to build your own Application.

Technical details of the import are avalilable in the wiki

Please let me know your thoughts and happy mapping :-)

Last week we released version 0.9.8 of Vespucci, see http://vespucci.io/help/en/0.9.8%20Release%20notes/ for what is new.

This was a bit earlier than expected and does not yet include the opening hours editor (but does include a form editor for conditional restrictions) because we couldn't update the 0.9.7 version on googles play store any more.

The versions available from google and amazon have been updated, we are in contact with the person responsible for the F-DROID build but we cannot provide an ETA for release there yet.

Although recent development steps of the (Java-less) OSM editor Merkaartor are not so present in the main public OSM channels, there is quite some activity in its github sourcecode repository. We also had the release of version 0.18.3 a few weeks ago!

So the developer Ladislav is asking these days for votes towards the next issues to be solved about Merkaartor in this issue.

Feel free to add opinions or hints there if you have a github account, or try the Merkaartor mailinglist.

Also the translation files for all used text items inside Merkaartor maybe need some polishing, see the Transifex project (where you can also log-in via your github account or similar).

Finally there is a nightly-build service for latest testing versions linked on the OSM wiki via https://wiki.openstreetmap.org/wiki/Merkaartor for Windows and OS-X releases.

Last weekend I was down in Ware again to baby-sit my grandchildren (‘babysit’? at 14 & 11? maybe not). Mum had the opportunity for a hen-night away (or was it a wedding? I forget) and as a single mum gets almost zero chances for time to herself. She had all the other days covered but needed someone for Sunday so I got the call. As a grandparent you are a whore for your grandkids (pay attention! I'm trying to pass some wisdom across here) so there was never any doubt that I'd say ‘yes’.

We had a fantastic day together. I suggested seeing a film on the evening & Mickey suggested Kubo And The Two Strings. Wow! What an inspired suggestion! Someone on twitter (kubothemovie) said:

Well, Kubo and the two strings just about blew my ruddy socks off. Thank god the kids spotted it and dragged me along.

My sentiments precisely. It is rated PG but make no mistake, this will thoroughly satisfy every human with a living heart, soul & spirit. Go watch it.

The following day was Monday, 26 Sep.. After making sure that they got away for school on time I faced a 2 hour journey back up the Great North Road to Nottingham in time to meet a British Gas salesman to examine my deceased boiler. Just enough time to map a couple more streets in Ware.

I mentioned last time that the King George Fields area where they live has homes built in the 1930s – the same period as for much of Carlton NG3 & NG4 (and for the country as a whole, as the period following WWI saw a tremendous expansion in the housing stock) (just in time for the Nazis to come along and bomb it all flat again during the second half).

The house, terrace & flat's outside toilets (‘khazis’) were first documented by me whilst mapping close to the heart of Carlton, and then again with some flats on the other side of the same patch of road. These khazis in Ware are at the rear of a set of flats on Cundalls Road and, if you compare them to the earlier post, they have an identical design (the roofs differ), even down to the shades of blue paint on the doors:

This was my first State of the Map. That is if you do not count my virtual visits to all previous ones via the video sessions I have seen afterwards.

In this diary entry I will not write about the individual sessions, I keep that for another entry.

Let me start by congratulating the organisers and the volunteers for a great experience. Furthermore a big thank you to all people that did a presentation. I found the talks that I followed of a high level. That is they were informative, entertaining and brought by passionate people. Something I have not seen in other (non-OSM-related) conferences that I visited.

What I did wrong was that I visited too many sessions that are recorded and not enough bird of a feather (BoF) sessions. The ones that I visited (Public transport plugin for JOSM and Wikimedia's Kartotherian) were very interesting.

It was good to see people that I only met virtually before, either via a forum, a Mapper of the Month interview or as part of the Weekly OSM team.

BTW, a big applause to my colleagues of the Weekly OSM/Wochennotiz team for winning the Influential writer award. It's a pity that the SOTM team nor the OSMF team made more publicity about the winners of the awards (e.g. live via Twitter). Because I was in a BoF at that time, I still don't know the other award winners.

Update: They are now listed on https://blog.openstreetmap.org/2016/09/26/we-have-our-winners/

I should also have been braver to talk to more people, but what do you say to famous people like Andy Allen or Frederik Ramm? Anyhow, if I would have talked to you, I would have thanked you for your hard work for OSM and for the "courage" to continue with your work for carto-css or "promotion" for craftmappers despite all critiques.

As for the OpenStreetView team, I love to have discussed the de-blurring in the website. For what I do (mapping destination signs), it's a necessity and should take far less time than in Mapillary.

The social event had good food, but was missing beer. Not for me (I had to drive home), but an event in a former brewery with almost no choice in beer is strange, especially in Belgium. During the event, I had a nice talk with the woman that made the winning design for the SOTM logo and her partner, an American journalist.

I had a great time and feel sorry I missed the first day due to other obligations. And as Gregory sang at the end, we now will continue to "map, map, map".

Hi OSM community,

my name is Ivan Garcia and I am by the way looking for a python job(GIS, web, bigdata, etc) in case you are know of(just saying).

I helped many regions of the world to convert their official boundaries into OSM format and import them into OpenStreetMap following, of course, the OSM import guideline.

So I decided that since a lot of people are doing these conversions manually therefore wasting a lot of time, I created a python script that you can see and improve, it is called SHPtoOSMBoundaries.py

It already exists an script called polyshp2osm.py but it is not specific for administrative boundaries and it is not capable to extract and join together different admin_levels into a single OSM file. That script works perfectly for converting all the features from SHP to OSM format.

Normally, what OSM contributors have is a SHP file received from some official institution or downloaded through some OpenData portal, this example will show the user case of Fiji islands SHP file.

If we open the SHP it with QGIS, we see that it contains a lot of boundary polygons, and that each of the polygon contains a ID tag (in this case the TID) and another tag that identify the name of the deepest boundary(the tiniest), or in OSM, the one with the highest admin_level number. In our example this tag name is TIKINA(which corresponds to the village boundary in Fiji)

Also most of the times, from the same SHP we want to obtain the upper admin level boundaries, in this case we also have the PROVINCE ID (PID) and the tag name (PROVINCE).

So we know find out that:

• For the level 8(village) we have TID and TIKINA tags
• For the level 6(province) we have PID and PROVINCE tags

Before we can run the script, we need to create convert the polygons into lines, this is easily made with QGIS using the menu option Vector -> Geometry Tools -> Polygons to Lines

So the result looks like this, a lot of lines that overlapped one to another:

but OSM cannot have repeated ways inside the relation boundaries, so we will break this lines and make them unique.

Luckily, the GRASS plugin in QGIS provides us of a function named v.break:

Once generated the result breaked lines, we export as GEOJSON format to a filename "fiji_splitted.geojson" for example, also we will export the original SHP boundaries file into GEOJSON format, example to "fiji_level8.geojson".

Now is time to run the python(with python 2.7) script, you will need the python library "shapely", before we run it, we edit the script to change the needed parameters, that is:

• ALL_LEVELS_GEOJSON: filename that contains the original boundaries SHP file.
• SPLITTED_WAYS_GEOJSON: filename with the broken, splitted ways.
• DEEPER_LEVEL: level number and uniquetag and nametag that we discovered, in our case: DEEPER_LEVEL = {"level":"8", "uniquetag": "TID" ,"nametag":"TIKINA"}
• OTHER_LEVELS: a python list with the other upper levels that you want to extract also and mix together, in our case: OTHER_LEVELS = [{"level":"6", "uniquetag": "PID" ,"nametag":"PROVINCE"}]

Optional: There is an extra parameter called MAINTENANCE that you can set up to True to let the script to clean up the ways in case that the GRASS v.break did split the ways a bit too much, having too many ways into OSM. When the script is runned this way, it will create a "tofix_splittedways.osm" that can be loaded into JOSM to fix and join those little ways into a bigger one. Then make sure to save the fixed result as GEOJSON to the same filename of the splitted ways we had before, and change the MAINTENANCE to FALSE before reruning the script.

Running the script will create a "final.osm" output which is the file that we need to import into JOSM in order to upload into OpenStreetMap, preferably using the JOSM multiple-parts upload option.

WARNING for uploaders: Of course, before you upload the generated result, you need to be an experienced OSM user and understand pretty well what are administrative boundaries, otherwise, learn about them see examples, ask in the forums, etc.

Before uploading, you need to see what boundaries already exists in the area you are supposed to upload(I assume you studied the area since you decided there is a lack of boundaries), for example in JOSM you can get all the boundaries of a region, to do so you can use the option "Download from Overpass API", (you will need to have the Expert Mode activated) in JOSM. Then put the following Overpass query: ( way["boundary"="administrative"]; node(w); rel(bn)->.x; way(bn); rel(bw); ); out meta;

I would like to repeat again that you need to follow carefully the OSM Import Guideline before uploading or deleting anything.

Once you have made sure that your new boundaries are correct, accurate, exact(you can compare with satellite imagery in case some boundaries match some rivers, coastline, etc), my regular approach when I have to upload many automatically generated boundaries into Openstreetmap is the following:

• Carefully clean up the previous boundaries useless(if any), if necessary, contacting the user or importer who did the previous one, also make sure you have permission by the data source to do so with the OpenStreetMap license, etc.
• Upload the OSM file using JOSM multiple part (maybe with chunks of 500-1000 objects, depending on the my internet speed).
• How to join our uploaded boundaries with the neighbor boundaries: Now this is a very careful part and you need JOSM experience with relation editing since you will have to modify already existing OSM boundaries(sometimes delicate country borders). My advice is not to delete the ways of the existent neighbors boundaries but YOUR border ways, and add the already existing ways into your new boundary relations(if necessary you can split those ways).
• In case that you need to join your boundaries with a country border, NEVER delete the already existent border, since their OSM way ids may be being used by some 3rd party applications, if inaccurate, you can just align them or split them. There is a great online OSM tool created to verify if you messed up with some country border.

Here is how the result looks like:

In you have doubts or errors, you can just write a comment here or add a issue into the github of the script.

I hope it helps saving lots of time to OSM contributors.