Diary Entries in English

Recent diary entries

About another OSMF board meeting

Posted by imagico on 19 January 2018 in English (English)

Some time ago i reported here my impression of the first public OSMF board meeting and i kind of feel motivated to make another report on the most recent meeting.

I have attended quite a few of these meetings as a guest in the meanwhile and in most of them there were very few people listening in - rarely more than one or two in addition to myself. Listening to these meetings gives you a bit of insight into how the board ticks, how they communicate and how they make decisions. The last meeting had a quite extraordinary number of visitors and also seemed quite a bit different in several aspects. You can read up the formal minutes of all of the meetings on the OSMF wiki - what i here want to present is my personal impression and commentary on the thing. This is my subjective impression so there are certainly things i understood in a different ways than others and there are likely things i missed because i did not pay attention to them. If you want a neutral record of the meeting look at the minutes or better yet listen in on the meetings yourself.

Let me start by thanking the board for continuing to hold the meetings in public, i think this is of fundamental importance for connecting OSMF politics to the OSM community base. This diary entry is my contribution to this discourse - both by communicating my impression of the meetings to a larger audience than those who were able to be at the meeting and to provide feedback to the board on how their work is perceived.

It was the first meeting after the last board elections so there was the selection of officers - which was ultimately uninteresting because the same people as last time were elected.

Next topic discussed was the membership fee waiver program drafted by the MWG. What amazed me about this is that while there was some discussion among the board members there was no specific mentioning of the discussion that had occured in public on the OSMF mailing list about what is the best and fairest way to actually get more people to become OSMF members. Although a decision can of course be made on the proposal as it exists (which is purely for handling technical payment difficulties) it does not seem very productive to me to approve the MWG draft without giving feedback to the MWG and the community members who are interested in lowering the barriers for people to become an OSMF members on if and how moving in that direction is considered desirable by the board. There were vague statements of individual board members that further work should be done regarding the membership fees but no commitment or acknowledgement of the need to substantially lower the barriers.

I think this might indicate kind of a more general problem. During the last year we have seen - largely through Dorothea's work - a significant improvement of communication of overall OSMF matters to the OSM community but this might hide the fact that there is still a lot of room for improvement of the communication between the OSMF and the OSM community on specific matters. This is something the OSM community can work on (by better articulating their wishes and opinions to the board and WGs, better identifying the right point of time to provide input) but it is also something the OSMF board can and needs to work on. If input from the OSM community on matters of policy of the OSMF is being offered but either not considered or considered but the fact that and how it is is not communicated to the people providing this input that is a serious communication problem.

Next was a discussion about a possible face-to-face meeting of the board. The history of the board face-to-face meetings is an interesting one. When the first more recent dedicated meeting of this kind was planned in 2016 (not sure if there were other similar meetings in the early board history or more or less complete meetings of the board during other events like SotM) the main argument was that the board members getting to know each other in person was very useful and important for a practical working relationship. Last year there was then another dedicated face-to-face meeting although the board composition had not changed (since both Frederik and Kate were re-elected) so this argument was obviously not the primary reason any more.

When the board reported on the last meeting on the OSMF blog i mentioned in a comment:

... But i sincerely hope that with a meeting like this costing quite a bit of both time and money you do evaluate the success of it in terms of measurable results – in other words: Go in with a clear idea what you intend to accomplish and evaluate afterwards if you managed to do so.

which pretty much summarizes my attitude to this subject. If a face-to-face meeting is useful i see no reason not to have one but IMO the board needs to justify and demonstrate to the OSMF members and the OSM community as a whole that it actually is worth the money spent. If you look at the list of "what we want to change" from the 2016 meeting you can get doubts about this.

There were some comments in that direction in the discussion but everything was pretty vague and non-committal overall. What i distinctly noted is that no one even mentioned the fact that there is a SotM conference this summer in Italy and travel costs could be significantly reduced probably by making a meeting there.

Next topic was re-activating the osmf-announce mailing list for official announcements. This was an interesting and useful discussion about the purpose of this announcement mailing list and also the possibilities and the needs to communication to members from parties other than the board - like for example for initiatives from the membership to put forward proposals without going through and potentially even against the will of the board.

Then there was an item "Taking a stand against people publicly bad-mouthing the OSM project, OSM community, or OSMF" put forward by Frederik. This was about the infamous tweet by Dale Kunce which is the most recent and one of the most blatant examples of people badmouthing the OSM community on twitter and other social media channels. Frederik suggested that the OSMF board should make a clear statement to condemn such claims and make clear that the OSMF board stands behind the OSM community against people collectively calling them racists and other things while encouraging everyone to bring any specific cases of racism, misogyny or other discriminating behaviour to the attention of the board.

What followed were reactions mainly from Heather and Mikel who from my point of view very skillfully tried to spin this into yet another call for stricter rules on OSM communication channels, codes of conduct and policing use of these channels. This argument more or less went along the following lines:

  • the OSMF cannot control what is said on Twitter (which was of course not what Frederik was suggesting)
  • there were quite a few unfriendly, inpolite or similar statements on OSMF managed channels recently the Twitter statements should be seen in context with (i can't really help but this seemed oddly similar to Trump's famous "there was violence on both sides")
  • the OSMF should therefore strengthen and enforce rules on what may be said on OSM communication channels (which instead of condemning Dale Kunce's rant would actually kind of support it)

I of course paraphrase here, this is not literally what has been said but if i try to extract the essence of the arguments that have been made this is more or less what i end up with.

Peda was the only board members who spoke in support of Frederik's proposal so in the end no decision from the OSMF board to take a stand on bad-mouthing OSM and the OSM community. You can interpret this as you like. By the way Dale Kunce is president of HOT and works for the American Red Cross - the organization that has made the USD 25k donation to the OSMF last year that was kept 'secret' for more than half a year. Even if you are not into looking for conspiracies from a PR perspective this is really kind of like running at full speed towards a concrete wall. What credibility does a board that cannot even condemn a clearly outrageous statement that sweepingly calls essentially all OSMF members racists have on matters of communication tone in intercultural communication?

After that the meeting had already been running for an hour and several board members indicated they wanted to close it - Peda suggested to vote on the budget for 2018 before doing that.

For the visitors this is kind of a strange situation since the budget at this point is not public so you listen to a discussion about a budget that you cannot look at. The discussion however was mostly about the implications of the recent 200k donation and how this should be taken into account for financial planning. Ultimately the budget was approved as it was drafted by Frederik.

A followup meeting was scheduled for next week to cover the remaining agenda items.

It is still too early to draw conclusion in what direction the new board tends politically - even if there have been a few indications towards that in the way people communicated in the meeting. What i can say in review of all the board meetings i listened to overall is an increasing trend towards conservativism (mostly in the sense of sticking to a certain way of doing things because you are used to it rather than because there are convincing arguments to actually do it this way). This is not astonishing considering all of the current board members have been on the board for quite some time or bring in a certain experience from elsewhere how they are used to things being done they try to continue in this venue.

Also the board - with Ilya leaving - has become significantly less culturally diverse, we now essentially have a US-German-Canadian board. The most exotic voice on the board now seems to be Peda who is the only real hobby mapper with no professional relationship to OSM whose views maybe best represent those of a typical OSM mapper (though with a distinctly German perspective of course). Given that Peda is clearly the board member least fluent in English he also has the least chance to convincingly articulate his views against his rhetorically more skilled colleagues.

Non-English keywords in English iD interface.

Posted by Dzertanoj on 18 January 2018 in English (English)

I just noticed an interesting thing. If you want to create a point indicating a garbage dumpster (trash container or whatever similar) using iD with the English language interface, you add a point geometry and then start typing "garbage" in the Search field. Once you've typed "gar", found tagging options will be related to anything "garden" and "garbage", but there will also be a "ॐ Hindu Temple" as a sixth item. If you type one more letter and make it "garb", you'll have everything "garbage", but Hindu Temple will jump to the second place.

I'm not claiming that I know how it works, but I assume that there are keywords tied to an interface language and to every tag or set of tags for a specific object. They seem to be language-dependent (while it is still possible to type something in German, like "wald", and get Wood as an option), otherwise, there would be a lot more confusion with similarly spelled keywords from different languages.

However, I don't see any logic in this specific situation. As Wikipedia says, "Garbhagriha" is a Sanskrit word for a part of a Hindu temple (not even for a temple itself). How often might it be typed in Latin alphabet by iD users? Does it really belong to English interface, keeping in mind that English is not the main language in any of those countries where Hindu religion is prominent enough? It definitely belongs to Hindu and some other languages, but English? By the way, if you try typing "altar" (also a part of a temple in many religions) - nothing related to temples or cathedrals will pop up. Considering this logic, Hindu Temple should not show up on a list after typing "gar" or "garb" in a search form.

Just to be clear: I don't care if it will continue popping up - it looks amusing to me, not just "wrong". I'm not going to dig into iD's complicated structure and register on any translation services to fix that.

Mayon's core dange zone mapping is 100% complete - thank you!

Posted by GOwin on 17 January 2018 in English (English)

Mt. Mayon ash plume. Photo credits: unknown.

Mayon, the Philippines most active volcano, with 48 historical eruptions is restive. Over the weekend, tremors, lava fountaining, and lava collapse events has been noted. Government volcanologists report that “relatively high level of unrest as magma is at the crater and hazardous eruption is possible within weeks or even days.

The authorities has prohibited the public from entering the 6 kilometer-radius Permanent Danger Zone (PDZ), and the 7-km Extended Danger Zone (EDZ) on the southern flanks “due to the danger of rockfalls, landslides and sudden explosions or dome collapse that may generate hazardous volcanic flows.”

Yesterday morning, we appealed for help to map the 6-kilometer Permanent Danger Zone of Mayon, and the community responded quickly. Today, it's been 100% mapped, 57% validated (and still on-going). Thank you! The names of the generous mappers may be found in the project dashboard.

Mayon Permanent Danger Zone (PDZ): 100% mapped. 57% validated.

Today, a new project to map the 7-kilometer Extended Danger Zone (EDZ) around Mayon has been published: and we are again appealing for some of your precious time, and valued mapping skills, to map the EDZ. Most especially the priority tasks in the southern quadrant, where there are a number of villages and settlements.

Again, this is preemptive mapping activity to assist local government agencies and aid organizations to support future damage assessment. We call on the digital humanitarian community for their assistance for this project.

Location: New Lidong Trail, Legazpi, Albay, Bicol Region, 4508, Philippines

Motorway Junction Node Placement

Posted by daniel-j-h on 17 January 2018 in English (English)

It isn't always obvious where to position a highway=motorway_junction node that connects a motorway way to a motorway_link way (also known as an off-ramp or slip road). Over the years, mappers have used three different approaches.

Inconsistent placement of junction nodes can affect turn-by-turn navigation software, particularly instruction timing and rerouting. I'd like to raise awareness about the preferred placement, which is at the beginning of the gore, and explain why the other two approaches are suboptimal.

Throughout this post, I will refer to the term gore. A gore is a wedge that separates a ramp from the main motorway. A physical gore may be a barrier or a grassy area, whereas a theoretical gore simulates this separation using pavement markings and empty space. By “gore”, I am referring to the beginning of the theoretical gore, if present, or alternatively the physical gore.

Approach 1: Map the ramp node at the exit sign

Rationale: In the majority of urban areas a detailed overhead exit sign is located at the last point where the off ramp maneuver can take place - the physical or theoretical gore.


  • Many rural exits (and some urban exits, depending on the state) lack overhead signage. Instead, the only sign is located on the side of the road (at the beginning of the deceleration lane or even earlier), accompanied by a small “Exit” sign at the gore.
  • In many cases, the exit sign occurs well after a lane change restriction (change:lanes) begins (example - note the solid white line). However, lane issues should be remedied through tagging, not geometry alterations.

Example. In this case the exit sign and the theoretical gore are located at the same location. This is the last location where driver can exit the motorway. When the sign board is right next to the gore this approach makes sense.

Example. The exit sign does not coincide with the theoretical gore in this case. The exit sign is positioned much earlier than the gore. In this case mapping the exit from the sign position will not make sense.

Approach 2: Map the ramp node where the road begins to widen

Historically, some mappers have preferred to start the ramp at the point the road widens, mainly for aesthetic purposes.

Rationale: This appears smoother on a map rendering as it more accurately represents the path a driver should take to use the ramp.


  • If a driver has passed the point where the road begins to widen but has yet to reach the gore (or the start of chevron markings), it’s too early to reroute the user as if they missed the exit.
  • The exit may have a longer deceleration lane. If the junction node is placed at the beginning of the deceleration lane, the user’s distance to the junction node may differ from signage, creating confusion.
  • Does not accurately reflect the features on the ground.

Example (same junction as Approach 1 example):

Approach 3: Map the ramp node at the gore of the main road and ramp

This is the approach documented on the wiki. It balances the needs of renderers and routers.


  • Allows for precise lane mapping, as the junction node reflects reality.
  • Staggered exit lanes should be modeled using turn:lanes tags instead of separate ways.
  • The junction node reflects the exact point where it is no longer possible to cross back onto the highway, consistent with the practice of mapping a dual carriageway only when there’s a definite separation.


  • On rendered maps, the turn angle looks sharper than expected when zoomed way in.
  • Less sophisticated routers may consider the actual turn angle to be much sharper than in reality.
  • In some cases, the gore begins well after a lane change restriction (change:lanes) begins (example - note the solid white line). However, it’s better to add the lane change restriction as a change:lanes tag than to draw the entire exit lane as a separate way.

In approach 2 the ramp node is placed where the road begins to widen. In the same example, if approach 3 is used the ramp would appear like this:

Example: The junction node near the gore where it not possible to change lanes back to the highway.

Although this approach tries to place the junction node close to the gore, it isn’t necessary to make it exactly flush with the gore. The motorway_link would meet the motorway at a 90° angle, which would result in unintuitive rendering. A roughly 45° angle strikes a better balance between the needs of renderers and routers.


Based on this evaluation, we believe the best practice for mapping ramps is (Approach 3) map the ramp node at the gore of the main road and ramp. This follows the wider OSM convention of prioritizing mapping based on the physical barriers, is appropriate for diverse geographies, and aligns with developing work around lane guidance.

As next actions, from now on, the team at Mapbox will fix these ramp geometries by following the convention stated in approach 3 when we come across ramps mapped according to other approaches. It would be great to have everyone follow this approach as well when mapping ramps and make changes to existing ramp intersections that you come across. If there is consensus around this approach let’s update the wiki with further details to promote this practice.

It starts with the planet - downloading OSM the right way

Posted by pnorman on 17 January 2018 in English (English)

This is a repost of an entry on my blog.

To do something with OpenStreetMap data, we have to download it first. This can be the entire data from or a smaller extract from a provider like Geofabrik. If you're doing this manually, it's easy. Just a single command will call curl or wget, or you can download it from the browser. If you want to script it, it's a bit harder. You have to worry about error conditions, what can go wrong, and make sure everything can happen unattended. So, to make sure we can do this, we write a simple bash script.

The goal of the script is to download the OSM data to a known file name, and return 0 if successful, or 1 if an error occurred. Also, to keep track of what was downloaded, we'll make two files with information on what was downloaded, and what state it's in: state.txt and configuration.txt. These will be compatible with osmosis, the standard tool for updating OpenStreetMap data.

Before doing anything else, we specify that this is a bash script, and that if anything goes wrong, the script is supposed to exit.

#!/usr/bin/env bash

set -euf -o pipefail

Next, we put the information about what's being downloaded, and where, into variables. It's traditional to use the Geofabrik Liechtenstein extract for testing, but the same scripts will work with the planet.



We'll be using curl to download the data, and every time we call it, we want to add the options -s and -L. Respectively, these make curl silent and cause it to follow redirects. Two files are needed: the data, and it's md5 sum. The md5 file looks something like 27f7... liechtenstein-latest.osm.pbf. The problem with this is we're saving the file as $PLANET_FILE, not liechtenstein-latest.osm.pbf. A bit of manipulation with cut fixes this.

CURL='curl -s -L'
MD5="$($CURL "${PLANET_MD5_URL}" | cut -f1 -d' ')"
echo "${MD5}  ${PLANET_FILE}" > "${PLANET_FILE}.md5"

The reason for downloading the md5 first is it reduces the time between the two downloads are initiated, making it less likely the server will have a new version uploading in that time.

The next step is easy, downloading the planet, and checking the download wasn't corrupted. It helps to have a good connection here.

$CURL -o "${PLANET_FILE}" "${PLANET_URL}" || { echo "Planet file failed to download"; exit 1; }

md5sum --quiet --status --strict -c "${PLANET_FILE}.md5" || { echo "md5 check failed"; exit 1; }

Libosmium is a popular library for manipulating OpenStreetMap data, and the osmium command can show metadata from the header of the file. The command osmium fileinfo data.osm.pbf tells us

  Bounding boxes:
  With history: no

The osmosis properties tell us where to go for the updates to the data we downloaded. Despite not needing the updates for this task, it's useful to store this in the state.txt and configuration.txt files mentioned above.

Rather than try to parse osmium's output, it has an option to just extract one field. We use this to get the base URL, and save that to configuration.txt

REPLICATION_BASE_URL="$(osmium fileinfo -g 'header.option.osmosis_replication_base_url' "${PLANET_FILE}")"
echo "baseUrl=${REPLICATION_BASE_URL}" > 'configuration.txt'

Replication sequence numbers needed to represented as a three-tiered directory structure, for example 123/456/789. By taking the number, padding it to 9 characters with 0s, and doing some sed magic, we get this format. From there, it's easy to download the state.txt file representing the state of the data that was downloaded.

REPLICATION_SEQUENCE_NUMBER="$( printf "%09d" "$(osmium fileinfo -g 'header.option.osmosis_replication_sequence_number' "${PLANET_FILE}")" | sed ':a;s@\B[0-9]\{3\}\>@/&@;ta' )"


After all this has been run, we've got the planet, it's md5 file, and the state and configuration that correspond to the download.

Combining the code fragments, adding some comments, and cleaning up the files results in this shell script

#!/usr/bin/env bash

set -euf -o pipefail


CURL='curl -s -L'

# Clean up any remaining files
rm -f -- "${PLANET_FILE}" "${PLANET_FILE}.md5" 'state.txt' 'configuration.txt'

# Because the planet file name is set above, the provided md5 file needs altering
MD5="$($CURL "${PLANET_MD5_URL}" | cut -f1 -d' ')"
echo "${MD5}  ${PLANET_FILE}" > "${PLANET_FILE}.md5"

# Download the planet
$CURL -o "${PLANET_FILE}" "${PLANET_URL}" || { echo "Planet file failed to download"; exit 1; }

md5sum --quiet --status --strict -c "${PLANET_FILE}.md5" || { echo "md5 check failed"; exit 1; }

REPLICATION_BASE_URL="$(osmium fileinfo -g 'header.option.osmosis_replication_base_url' "${PLANET_FILE}")"
echo "baseUrl=${REPLICATION_BASE_URL}" > 'configuration.txt'

# sed to turn into / formatted, see
REPLICATION_SEQUENCE_NUMBER="$( printf "%09d" "$(osmium fileinfo -g 'header.option.osmosis_replication_sequence_number' "${PLANET_FILE}")" | sed ':a;s@\B[0-9]\{3\}\>@/&@;ta' )"


Nominatim and Postcodes

Posted by lonvia on 16 January 2018 in English (English)

Nominatim (the search engine that powers the search box on the OpenStreetMap website) has recently changed significantly its way how postcodes are handled. This post tries to give a bit of background on what has changed and why.

When you search for a place on, Nominatim not only presents the name of the place in the result but a complete address. This address not only helps distinguish the different places but is also used to narrow down your search. This address is not a postal address as you would put on a postcard. It is more a textual description where the place is located, in which suburb, city, state, country etc. This information is fairly easy to compute from OSM data. There are areas for all these administrative areas. So Nominatim just needs to check in which areas a place is inside, order all appropriately and there is the address.

Postcodes, however, are different. In most countries there is no such thing as postcode areas. Postcodes are simply assigned to a some place (a house or POI) in a fashion that is deemed most practical for the local postal service. Often the post codes follow delivery routes. It might be possible to draw an area around houses with the same postcode but this would be an artificial distinction and there is no guarantee that the resulting areas don't overlap.

For that reason, there are very few boundaries in OSM that describe postcode areas. Mostly postcodes can be found on house numbers and POIs in the addr:postcode tag. But even here coverage is rather sparse. So when computing the address of a place, Nominatim has to go a different way to determine the most likely postcode for a place where no addr:postcode tag exists.

With the new version, Nominatim tries two different methods to infer the postcode of the place: an address lookup and an area-based lookup.

The address lookup comes first. Nominatim assembles all other parts of the address and then checks if any part of the address carries an addr:postcode tag that might apply. It does that going from the most specific part of the address, the street, up to the most generic one, the country. As soon as it finds an appropriate tag, it stops and uses the postcode. This means that when tagging postcodes you can start with assigning an approximate postcode for a larger area, like a complete village or suburb, and then later come back and add addr:postcode tags to the handful of houses that are the exception to rule (or even complete postcode coverage for the whole village and then delete the postcode tag on the village again).

If there is no postcode to be found in the address, Nominatim tries the area method. That means that it ideally should be looking for the closest object with an addr:postcode tag within a certain area and use that postcode as a guess. This is unfortunately a bit expensive, so Nominatim implements a simplified version. For each postcode, it looks for all the points in OSM that are tagged with the appropriate addr:postcode tag and computes one central point, the postcode centroid. When guessing the postcode of an object with the area method, the closest postcode centroid is used. This is not quite as accurate but considerably faster. The postcode centroids are also used when you search for a postcode. If OSM has no postcode area, then an artificial point is returned with the same location as the centroid.

Postcode centroids have been a feature of Nominatim for a long time. However, they have always been static and only computed once when the database was initially imported. Starting with the next release, postcodes become their own entity in Nominatim and can be regularly recomputed and updated. On this is already done once per day now.

Finally, there is also a change in the way postcodes are handled in your search query. Formerly, if you added a postcode to your search, you had to use the one that Nominatim had guessed for the place or you would get no result at all. That was particular annoying when Nominatim had guessed wrong and the search had the right postcode. With the new version Nominatim is now able to detect postcodes in the query and ignore them, if necessary. So if a place has a wrong postcode in Nominatim it is now nonetheless able to find the place by the correct address. There is one catch though: Nominatim needs to understand that the part of your query is indeed a postcode. At the moment it takes this information from OSM itself. That means it can really only detect (and ignore) postcodes that have been previously mapped in OSM somewhere. At some point, it will learn to detect postcodes by their format but that is a project for a future version of Nominatim.

OpenStreetMap volunteers - you're awesome!

Posted by GOwin on 16 January 2018 in English (English)

On-going humanitarian mapping around Mt. Mayon, Albay, Philippines

This morning, barely 12 hours ago, the OpenStreetMap volunteers from the Philippines set up a task to map an area threatened by the restive Mt. Mayon.

And the global community of digital humanitarians quickly responded:

48% mapped. 7% validated.

We're not done yet, but we wish to acknowledge everyone who quickly responded to our call. Thank you, folks. You're awesome - and you know it. ;)

If you have some minutes to spare, we still have a little over half to complete:

Location: New Lidong Trail, Legazpi, Albay, Bicol Region, 4508, Philippines

New User

Posted by NinjaRage83 on 16 January 2018 in English (English)

Started mapping today. Nothing to grandiose. Fixed some streets in my city and added/fixed a few buildings and parks. It will take time, but I intend to fully map my area.

Location: Fremont Street, City of Gloversville, Fulton County, New York, 12078, United States of America

Days of mapping: Batangas City (January 2018)

Posted by TagaSanPedroAko on 16 January 2018 in English (English)

Once again, Batangas City's map is growing again with updates, particularly on mapping building floors, addresses and names, missing buildings and POI's, and land use zones.


In order to improve 3D renderings of the city's buildings, especially those in the Poblacion, number of floors are being added through on the ground work using In addition, tagging of building addresses are also done, as there are many buildings with known addresses that can be sighted on outdoor signage. Building numbering also exists, but not all buildings indicate them. Names of buildings are also one part of building map improvements, as the building name form one part of many POI addresses.

Not only missing building details are added, but also many missing buildings constructed or existent since the past year. I mapped new houses and apartments inside Duluhan in Cuta, and a new commercial building along Lt. Col. D. Atienza Street. Building remapping is also done to redraw buildings that does not align properly with the most recent images. As part of this, the building occupied by Novo Department Store is remapped using DigitalGlobe Standard imagery and physical survey.

Points of interest

Many POIs scattered on the urbanized Poblacion and Cuta areas are being added one by one, also on the ground using

Land use zones

Land use zones have been part of my mapping work for Batangas City, but it is not in my priority on the previous mapping. I now placed it in my list of tasks for the city, to mark land use zones the LGU's City Planning and Development Office should have added on their Comprehensive Land Use Plan. Supposedly, the land use tag should go on the large area, not on the individual buildings, especially buildings I, and Project NOAH volunteers, mapped. Land use has been already added on part of Poblacion (the area around barangays 15, 16, and 21), and some areas elsewhere, but most has been not yet mapped, so, I now slowly adding those zones based on previous data added to buildings by LGU employees.

Location: Duluhan, Cuta, Duluhan, Batangas City, Batangas, Calabarzon, 4200, Philippines

Proposed Admin Levels for Turkmenistan

Posted by apm-wa on 14 January 2018 in English (English)

Now that I have been editing OSM's Turkmenistan map for nearly three years, I feel confident enough to offer a suggested set of administrative levels. I invite one and all to take a look at my proposal at and offer constructive feedback. This proposal is based on my by now fairly good knowledge of the political structure of Turkmenistan and the way the hierarchy works.

The last two days have been fairly productive. Ann and I went exploring neighorhoods in Gypjak, Choganly, Taze Eyyam, and Taze Zaman where we were missing street names, numbers of schools, and such. We mostly filled in blanks in the map but also updated some streets in Taze Eyyam plus added a few in the new subdivision being built on the west side of Choganly. We visited the unidentified neighborhood on the northwest corner of the demolished former Ruhabat dacha community, which has absolutely no signs, but asked locals what it is called. They identified it as Galkynysh (Turkmen for "renaissance"), a neighborhood subordinate to the Choganly jurisdiction, which is part of the city of Ashgabat.

The Ruhabat dacha community is definitely gone. We drove through part of the territory, and crews were there watering saplings that have been planted where old imagery shows a dacha community.

Location: Ahal Region, Turkmenistan

On Sett Pavements

Posted by Pieter Vander Vennet on 14 January 2018 in English (English)

I'm from Bruges (Belgium). You know, that famous medieval city in Belgium.

As everyone in Belgium knows, the center of Bruges is paved mostly in sett/cobblestones. Personally, I'm pretty fond of those sett pavements. They're way nicer to see then asphalt (not to mention conrete plates), the absorb a lot of heat in the summer (cooling the city) which is released again in autumn.

But, as the bicycle is my primary means of transportation, one drawback comes to mind: they're uncomfortable to cycle on - especially when pulling a cart. Some types of set pavement are to be avoided then - I'd rather drive 200 meters over asphalt than 100 over the big boulder. However, the smaller sett -often laid in arcs- is more comfortable to drive on and has a smaller penalty.

This implies that more information should be added to the 'surface'-tag. In this document, I propose a few extra tags to deal with this extra information; and what kind of sett these are. These tags are used in Bruges; feel free to use them in other places as well.

All example pictures are taken by me, and may be used freely for OSM-related endeavours (e.g. wiki, tools, ...).

Cobblestone vs. Sett

First things first.. What is sett stone? And what are cobblestones?

According to Wikipedia, Cobblestone is a natural building material based on cobble-sized stones, and is used for pavement roads, streets, and buildings. Sett is distinct from a cobblestone by being quarried or shaped to a regular form, whereas cobblestone is generally of a naturally occurring form.

In practice, cobblestone is often used in OSM to describe sett stones - although incorrectly. The wiki itself acknowledges this:

  • surface=cobblestone: Cobblestone paving. "Cobblestone" is used in the colloquial meaning here, and therefore includes the type of stones that would more precisely be called "setts". (Used for around 162k ways)
  • surface=sett: Sett surface is formed from stones quarried or worked to a regular shape. In OSM, this is a subset of "cobblestone", and it is far more common to tag these surfaces with surface=cobblestone instead. (Used for around 52k ways).

In other words, please, only use sett from now on; and use cobblestone only for when the natural form of the stones is still visible and thus results in a random pattern of laying the stones.

And then there is the even more attrocious surface=cobblestone:flattened; still in use for around 4k ways. The wiki says on this that this is neither a correct name, like sett (cobblestone is by definition not shaped into any form), nor a colloquially used name, like cobblestone. In other words, a tag that should not be used anymore and be translated to sett.


As already discussed: cobblestone is somewhat chaotic in natura, as can be seen in this image (again, from Wikipedia).


Types of sett

With these prerequisites out of the way, lets talk about the main topic of the post: sett in all its sizes and patterns.

In Bruges, there are three kinds of shapes:

  • Rectangular, often quite big (25cm*10cm)
  • Square, measuring around 10cm*10cm
  • Cube, small cubes of around 5cm

These can be laid down in various patterns, as described belowed.

Patterns of sett

Big boulder (aka 'normal sett')

surface=sett implies sett:pattern=interleaved and sett:type=rectangular

The first, and most common type of sett are the 'big boulders': the big, rectangular sett stones, in a interleaved pattern like a brick wall. As these are the most common stones, I didn't bother to add more tagging to them.


surface=sett sett:pattern=arc implies sett:type=cube

The second most common type of sett are small cubes, in a pattern of multiple, parallell arcs. Nice to see, and not to be confused with the very similar belgian fan.

Some examples I found in Bruges:

  • Simon-Stevenplein has arcs, where a few arcs are in white cubes. Notice how those white arcs never touch each other:
  • De Burg in Bruges has arcs as well:

Belgian Fan

surface=sett sett:pattern=belgian_fan implies sett:type=cube

Even more beautifull -and extremely rare- is the belgian fan. The cubes are laid in shell-like or fan-like patterns, as can be seen in the Sint-Amandsstraat near the Markt:

This is the only street in Bruges that still has this pattern! There used to be Belgian Fan in the streets around the Simon Steven-square as well; but a recent (~10 year ago) reconstruction of the site used 'normal' arcs, as visible above. The other place that still has a few specs of belgian fan is one construction site as well; so it is endangered as well. Perhaps someone should complain to Unesco that we are losing some world heritage!


surface=sett sett:pattern=interleaved implies sett:type=square

Although square sett is mostly used for foothpaths, it is sometimes used for shorter streets or speed tables as well. The square sett can be used interleaved, as here:

Square without pattern tag

surface=sett sett:type=square implies sett:type=square

... or used in a straight way, as here:

Paving stones

At last a word on paving_stones: the consensus here is that these are (in general) modern, mechanically shaped to neatly fit. The can be cast from concrete, they can be natural stones that are cut in a specific shape, ... For example, I consider brick roads to be a subclass of paving stones (but I'd tag it as surface=brick anyway).

The distinction with sett can be very small and subjective. For example, I have been doubting what to call the following:

In conclusion: a nice map to see

As you've already noticed in my previous posts, I've customized the routing parameters for OSMand to help with this task. It also was an excellent reason to map all the street pavements of Bruges. It was a lot of fun to do, and it helped to discover new places in Bruges; both beautiful or ugly.

The result of all this mapping can be visualized, thanks to overpass-turbo.

Location: Brugge-Centrum, Brugge, Bruges, Brugge, West Flanders, Flanders, Belgium

Missing Highways in Metro Manila, PH, and neighbouring provinces.

Posted by GOwin on 14 January 2018 in English (English)

Last week, we shared a a tasking project to update missing roads in Metro Manila 0 in the local mailing list. We've also published a few more tasks to cover adjacent provinces:

The data is not perfect, and you may even encounter false positives, but it's pretty good with pointing out a good number of missing roads in essential areas that local mappers have yet to digitize.

These are all part of the on-going initiatives by Kaart, to make awesome data for PH, and help grow local mapping communities.

If you're keen on improving the map of your home town or province, and they're not on this list yet, please let me know so I can put them up sooner rather than later, and we can work together in filling-in gaps in your favorite neighborhoods.

How about a mapa-thon soon? I'm planning to organize one, primarily to work on these tasks, and for the community to meet each other, and maybe welcome new ones. Would you folks have any suggestions, or is your org interested in collaborating? Let me know.

Do email me for any concern, or other questions, about these tasks.

Location: Mahogany Townhomes, Plainview, Mandaluyong, Metro Manila, 1550, Philippines

Network Rail - Sectional Appendix

Posted by Legolash2oLiam on 12 January 2018 in English (English)

Short, but sweet.

Great news today in regards to rail (United Kingdom). I have been in contact with Network Rail and have received permission to use the information within the Sectional Appendix or NESA to share rail data including speed limits, references, codes and restrictions. The only condition was that it needs to be attributed to 'Network Rail'.

I have various FOI requests currently in progress like TIPLOC latitude and longitudes which is useful for stations but also junction locations. Hopefully, signal locations too (most likely a no to that one due to potential theft and damage).

Reminder of human-centered classification study

Posted by grass_and_green on 11 January 2018 in English (English)

Dear All,

Thanks for the large number of participants who contributed to our study. If you keen to see some pilot results. Feel free to visit this page

To know more about the figures, please visit out study pages.

However, we still looking forward to more participants. Please, support our study and participate in the study here

Thanks in advance

Dr. Ahmed Loai Ali

Bremen Spatial Cognition Center, Bremen University, Germany

Geochicas, closing the gender gap in OSM is a path that is just being mapped

Posted by mapeadora on 11 January 2018 in English (English)

The dialogue of the Openstreetmap LATAM community in the channels used (chats, lists, forums, events) has revealed a very low female participation and the need to develop a general and permanent reflection on gender in this community.

Staring 2016, with this objective, a group of 10 female mappers (Geochicas) has been formed within the community, who dedicate a particular effort to help the development of this debate, in addition to mapping activities directed by and toward women with a gender perspective. One of the channels for this debate is through the organization of panels for reflection and discussion at each event of the OpenStreetMap community (State of the Map) and different events in communities related to technologies and open data. Alt text

Since the creation of Geochicas, we had organized three panels focused on gender which took place in SOTM LATAM 2016 (Sao Paulo, Brasil), SOTM International 2017 (Aizu Wakamatsu, Japón), CubaConference 2017 (La Habana, Cuba), SOTM LATAM 2017 (Lima, Perú) and other activities in different events such as the 1st Meeting of Cyberfeminism in Ecuador, Digital Security Workshop in Paraguay, among others. At the end of 2017, the main channel of Geochicas has 74 members and about 15 active people.

The purpose of the panels is to demystify the gender topic, sensitize the community to the existence of a gap, understand the problem that this gap represents in terms of production (technology, information, space representation, definition of work agendas), of data generation and validation, to raise awareness about the structures that condition participation, and also about difficulties and discriminations in the community.

The panels give many lessons in the simple observation of the type of participation

Only a few men participate in the dialogue, many leave, maybe considering the talk of little interest for them or considering it is a panel for women. Those who stay tend to take an observer role or to provide an idea to the mode of the statement, of the testimony, but do not debate or pay too much attention to the answers.

The panel made during the SOTM Latam de Lima, has made visible what was said previously, a little participation from men, but also contributed to understand that a lack of participation and silence are a response from the community about their position regarding integration and diversity. From Geochicas we emphasize that the map is a structural reflection of those who build it. Alt text Alt text

Geochicas also conducts research projects to learn more about these aspects within the community

We are doing a survey on the gender gap and the type of participation women have in global OSM, which aims to contribute to the dialogue between peers of the community. See preliminary results of the survey -in Spanish-

Main findings

  • Women express a difficulty from the different communities where they participate (careers in engineering and technology, in their families, in activist communities, etc.) to communicate and express their opinions, both because of the place they are granted within these communities to participate in leadership activities, the legitimacy received inside and outside by their peers, as well as the weight of their daily activities, the insecurity that affects their mobility, etc.
  • We observed through in both the survey and the panels, that men tend to consider there is a kind of freedom and equality to access topics such as technologies and data sciences, and to access to activist communities. This idea reduces to a matter of free will and personal taste the participation of women in these careers, activities and communities, invalidating the weight of social structures on the assignment of roles to genders.
  • According to Agnieszka Leszczynski and Sarah Elwood, researchers from the Geography schools of the University of Washington and the University of Birmingham, gender inequality in a community such as OSM is based on the editorial leadership conferred on a male majority, which has an authority implicitly endorsed within the discourse of "open and democratic community" that raises the truths of a world built by a masculinized vision, since they determine what may or may not exist within a spatial data schema, and impulse work lines and topics, in mapping activities and events.

In conclusion, there is a very broad road to travel to: 1. Know the causes and effects of low gender diversity in the community 2. Generate a successful analysis on inclusion within OSM communities 3. Innovate in communication methods that are given within the community as in the production of data and information so that it is relevant to everyone on the map 4. Achieve open, keep open, and expand the dialogue in the community on gender, with a sensitive, in-depth, responsible participation, on the part of all the people who collaborate and the diversity of genders. Let's move from testimonies and statements to a real dialogue and collective construction of the agenda.

The activities carried out by Geochicas in the framework of the SOTM Latam 2018 in Lima, Peru, were thanks to the support of the OpenStreetCam Team and Mapbox, who have been a fundamental contribution for the projects of the collective and also for the possibility of participating in events of community.

Geochicas actively seeks for the support of companies, groups as well as the community to carry out projects focused on closing the gender gap in OSM, and also financial support to achieve greater participation of more women in the OpenStreetMap and open technologies events.

Location: Algarín, Mexico City, Cuauhtémoc, Mexico City, 06880, Mexico

Descriptions of OSM tags in any language using Wikidata

Posted by PlaneMad on 10 January 2018 in English (English)

Ever wanted documentation of OSM tags in your own language?

Thanks to Wikidata, this might be quite simple: OSM tags in Japanese | German | English (Hit edit query to change to your language)

If you find a missing tag or translation, you can add it by editing the relevant Wikidata item and adding a new translation or a new OSM tag property.

The post was inspired by a recent discussion on OSM wiki questioning the value of Wikidata links on the wiki pages. Atleast in my part of the world, this is going to be quite useful since the Wiki pages have not been translated into my language.

Note It is known that OSM tags don't always map 1:1 exactly with existing Wikidata concepts and such derived definitions need further review to make sure it is consistent with the OSM Wiki. In such cases a new concept can be created in Wikidata if it does not overlap with any existing definition.

How to import open source boundaries -- Like Wards

Posted by chandusekharreddy on 10 January 2018 in English (English)

Steps to follow Import Boundaries using JOSM Create Relation for each boundary, copy details like name, ref etc to relation Split Boundary

After splitting boundaries search any closed polygon is there to cross check, if any split them. Only once we have to split closed boundary. Remaining splits at 'T' junctions can be under using split adjacent ways under more tools. Validate the features, this will give you overlapping features. Merge duplicate ways and keep the relations.

OSMCha News - January/2018

Posted by wille on 9 January 2018 in English (English)

It’s a new year and we have some new features in OSMCha!!! Let’s take a look on them:

Save filter UI improved

save filter instructions

Now it’s easier to save a filter! After set your filter parameters, click on the Save button on the top of the screen, give a name to it and press the Confirm Save button. The filter will be saved and applied, so the sidebar will update with the results. If you want to change something in your filter later, repeat those steps. Remember that the filters have a RSS feed. Get the link in your OSMCha user page.

Changeset comments

Changeset comments example

From now on, when we review a changeset in OSMCha, a comment will be posted in the OSM changeset page. That way, we give a feedback to the user and make that information accessible to other Quality Assurance tools. The comments have a predefined message and are posted with your username.

Tag changes summary

tag changes summary

Each changeset now has a summary of tag changes. This makes it easy to identify the modifications made in the features without the need of clicking on them one by one.

We’d love to hear your comments and suggestions. You can do so by participating in our mailing list or open issues on our github repository.

popular opening hours for museums in OSM

Posted by dieterdreist on 8 January 2018 in English (English)

These are the most frequently used opening hours for museums and other art related features in OSM. Apparently, most are closed on Mondays, or do not close any particular day: count value

263 Tu-Su 10:00-18:00

199 Tu-Su 10:00-17:00

186 24/7

175 unknown

144 Mo-Su 10:00-18:00

119 Mo-Su 09:00-17:00

110 Mo-Su 10:00-17:00

87 Tu-Su 09:00-17:00

67 10:00-18:00

63 10:00-17:00

61 closed

60 9:00-17:00; Mo closed

59 Tu-Su 11:00-17:00

52 9:00-17:00

50 Mo-Su 09:00-18:00

48 Tu-Su 11:00-18:00

43 09:00-17:00

43 Mo-Fr 09:00-17:00

42 Tu-Sa 10:00-17:00

40 Mo-Su 10:00-20:00

40 Su 14:00-17:00

39 Mo-Su 10:00-19:00

38 Tu-Su 09:00-18:00

38 We-Su 10:00-18:00

33 Tu-Su 10:00-16:00

30 "on appointment"

30 Tu-Sa 10:00-18:00

Parks Again

Posted by jremillard on 8 January 2018 in English (English)

Over the past week there has been a very long and detailed conservation about tagging parks and conservation land on the talk-us email list. This is a topic of great interest to me, but, the emails have reminded me of the fact that attempting to model everything on earth as an XML file is ultimately futile. Happily, this contradiction built into the OSM seems to insure that the project stays alive and vital over the long term. There is always room for improvement, the map can't ever be completed. The XML file is never going to be 100% right.