Diary Entries in English

Recent diary entries

Need to confirm these beauty care shops

Posted by Chetan_Gowda on 21 December 2016 in English (English)

This changeset look suspicious where a user added lot of point's of interest like amenity=coffee, and amenity=beauty shops in Mexico city, Mexico. The user used editor to add data.

screen shot 2016-12-21 at 4 42 56 pm

One of my colleague @upendrakarukonda has left a comment on the changeset 3 months ago and removed only coffee shops. Again, I've commented for the second time on another changeset. We didn't observe any reply from the mapper since. So sharing here with the community to examine beauty care places and take necessary actions.

Thank you

Yule Holiday activities

Posted by Skippern on 20 December 2016 in English (English)

Now that much of Guarapari have had buildings designed (the rest probably being added shortly as there is a drawing frenzy going on), and I am alone with the dog, than I have been looking for something useful to do. Luckily there is something called FieldPapers where I can print out small maps, put them on a clip board, and make notes as I walk the dog. That would mean I would need to walk the dog in different routes every day in order to cover more ground, but so be it. I am ready for my first test now, the streets around my house. Goal: harvest addresses and floor numbers for all mapped buildings.


Location: Parque Areia Preta, Centro, Guarapari, Microrregião Guarapari, Greater Vitória, Mesorregião Central Espírito-Santense, Espírito Santo, Southeast Region, 29200260, Brazil

Fuzhou and summer escapes....

Posted by Ghostpayroll on 20 December 2016 in English (English)

Living in China isn't all that bad. But in FUzhou the summers will boil you. But never fear....

There are spots all around in the mountains which provide GREAT relief. Check it out yo. I'll be posting my tour of the Fuzhou mountain areas, roads, swimming holes .......

Location: 台江区, Taijiang District, Fuzhou City, Fujian, China

Creating buildings and checking house numbers

Posted by The hiker on 20 December 2016 in English (English)

If you haven't checked OSM in the last few months, you'll be surprised to see that many houses (and buildings) have been added in Kamloops. - I did most houses on the North Shore - I completed Sun Rivers - I finished Juniper - I just finished Valleyview

Since many people are now using in order to add POIs, having the buildings ready makes the operation very easy.

Gedling Church Panorama #2

Posted by alexkemp on 19 December 2016 in English (English)

My September diary entry contained a view from near the top of Marshall Hill, looking north down the length of Chatsworth Avenue at the spire of All Hallows Church in the middle distance (All Hallows is the CoE parish-church for Gedling village). I believe that that was my first photo of that church spire.

My mapping since September seems to have taken me in a clockwise-rotation around the spire, and I am now approaching the church from the west.

Most householders do not like having photos taken of their homes, and I try my very best to respect that. At the same time, I know that panoramic shots of a district are one of the best ways to allow strangers to get a feel for an area, and I do my best to include such shots if I'm lucky enough to come across one.

Below is, I believe, only the 2nd shot that I've taken of the Gedling Spire. It is at a very similar distance to the first (as listed at top), but this time looking east from a walk at the top of Linby Close:—

Gedling Spire from the West

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

Routing — circular junctions

Posted by daniel-j-h on 19 December 2016 in English (English)

In which I outline the need for the recent junction=circular tag.

Traffic circles are a modern feature of intersection design. They come in multiple forms and shapes.

OSRM distinguishes between roundabout intersections, named, and unnamed roundabouts. Roundabout intersections are a special case of roundabouts that are small and offer up to four clearly distinguishable exits.

Roundabout Turn

To be considered a roundabout in the strict sense the road junction has to follow certain criteria. One of the criteria for a roundabout is that traffic in the roundabout has the right of way.

There are circular junctions which may look like and be commonly identified as roundabouts, but they are not roundabouts because they do not fulfill all of the criteria for being a roundabout.

For example, traffic in the roundabout at Bersarinplatz in Berlin has to give way to incoming traffic on B 96a, disqualifying it as a roundabout. This is in conflict with the desire to provide instructions of the form "use the second exit" from a navigation engine.

Bersarinplatz Route Before

Since a junction=roundabout tag is not appropriate, mappers will often document the intentional absence of any roundabout tag on these junctions using notes. This approach means however these junctions will not be tagged in a way that lets routing engines distinguish them from non-roundabout roads.

Notes are only an unreliable pseudo-tag, however, and don't provide any clear structured data. A junction=circular tag properly documents the mappers intent and makes it possible for routing engines to handle.

Bersarinplatz Route After

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

Thanks to Tom Pfeifer for pushing this endeavor forward, writing up the Wiki pages and tagging circular junctions in Berlin.

Here are some more examples of junction=circular tags in use:

You can read up on the original discussion with the Routing Engine. This feature is included in the latest OSRM v5.5 Release.

Evaluation of participatory transport mapping data: MapatónCDMX

Posted by mapeadora on 19 December 2016 in English (English)

Why evaluate?

OpenStreetMap is an international community of citizens who are experts in open geographical data, from different perspectives and specialties, and in methods of collaborative construction of information. OpenStreetMap is part of the trend of Voluntary Geographic Information.

The Mexican community of OpenStreetMap is mainly involved in 3 lines of action:

  • Strengthening the community (training and methodological support in projects, integration with academia and activism)
  • Procedures with government institutions for the importation of large public databases
  • Management with institutions to promote open and collaborative practices in its information management

As a community and ecosystem of technologies, OpenStreetMap has participated last years in several initiatives of participatory mapping of informal transport. This lack of good transport systems and lack of data is crucial in developing cities.

Objectives of transport mapping initiatives

These operations usually pretend to:

  • Create a complete transport system map to allow citizens to orient themselves in their city and make their mobility more efficient. Having this map allows more people to use collective transport instead of individual transport, with important implications on the mobility system, economy, environmental conditions and the quality of life of people
  • Provide local governments with data to regulate their transport, when they do not exist in useful formats
  • Provide city and transportation planners with the necessary information to generate diagnostics, analysis, and design
  • Allow research and innovation on the subject of transport and mobility with georeferenced open data and with quality standards

In order to make it possible for organizations, communities and governments to systematize the different experiences already developed in the world, the OpenStreetMap Mexico group undertook a medium-term exercise in collaboration with WRI and MIT to document all cases, evaluating, and highlighting successful practices in terms of organization, management, participatory method, technology, data produced, socialization and outputs given to the data, as well as the methods used to be able to update them. The result may be in the future a platform that catalyzes and shares knowledge: where in addition to providing the open technologies and data generated in different cities, a methodological guide is shared with the methods that have led to the best results.

The experiences developed in the world - Mapanica in Managua, Matatus in Nairobi for the best known, but also in Egypt, India, Bangladesh, Colombia, Mexico, etc. Have been led by different organizations, usually in an horizontal collaboration: associations, NGOs, communities such as OpenStreetMap, groups of civic technologies, universities, small businesses or startups, local governments.

This text is the first step of an evaluation work line of participatory transport mapping operations. This first evaluation is about the final data of MapatonCDMX developed in Mexico City.

Guidelines on the work process of MapatónCDMX

The results presented are from the MapatonCDMX organized in 2015-2016 by the "Laboratorio para la Ciudad", the area of innovation of the Government of Mexico City. The Laboratory proposed to develop a methodology and participatory dynamics to carry out mapping on a voluntary basis.

The MapatonCDMX was initially developed based on a working method applied before in Mexico City and other countries (Bangladesh among others) by the organization Urban Launchpad with the app Flock Tracker. The strategy changed in the course to incline towards the development of an application proprietary for the track of the transport routes, with essentially the same methodology.

In parallel, a collaborative table was formed with participants from various profiles and institutions. The OpenStreetMap group had the opportunity to participate in some working meetings where we suggested the use of existing open technologies instead of developing an app from zero, and to provide in the information structure the necessary attributes to the later generation of GTFS **.

The participatory dynamics was directed towards methods of gamification, based on an open call and the formation of teams put in competition for the obtaining of sponsors' prices. To improve participation, other groups of young people already enrolled in a voluntary process (INJUVE youth) were added to the dynamic. The organizations represented at the collaborative table were also asked to contribute with the provision of volunteers.

The data collection season resulted in a data set that was subsequently cleaned with the contribution of several organisms, in 2 stages, with a relative result.

MapatonCDMX data evaluation

The data of the MapatonCDMX were published in different formats, the files of the GTFS specification can be downloaded here, the complete database can be consulted from its dashboard and API for developers.

The first public delivery of data via the API, yielded a route system with topology deficiencies and an erroneous validation process.

Alt text Photo 1. Routes contained in the API of the MapatonCDMX in the first delivery

In the Mapaton API, which was the method for public consultation and download of routes in GTFS format in the first delivery, 2893 routes were available, of which only 501 were valid for GTFS format, representing only 20% usable in navigation and network analysis technologies.

Alt text Photo 2. Routes contained in the GTFS in the first delivery

The routes contained in the GTFS, despite having a good topology, did not manage to be representative of the public transport offer in the CDMX. The state of the information requires a process of validation and correction of the routes contained in the API that could not be integrated to the GTFS because of the topological errors.

The data were submitted to a second cleaning session with the support of the Mario Molina Center in October and November 2016. These data were made available in December. In this second stage, the API presents 4019 routes, of which 29 do not contain geographical information, the 3990 remaining routes are divided into categories:

  • Valid: 2162
  • Invalid: 1122
  • Invalid, out of time travel: 529
  • Invalid, data with error: 177

Of these routes, 501 were finally added in the GTFS format, which represents 23.17% of the total of API's valid routes. For these 501 routes, georeferencing is good and is attached to the road network, but some of the attribute information is missing and does not allow to validate the format and give it a possible use: service schedule, stops, time of arrival at stops. When this information can not be reliably robust (such as in the case of informal or unstructured transport systems mapping), the construction of a GTFS format relies on estimations, but information can not be dispensed with.

A visual summary of the information contained in the GTFS is presented:

Alt text Photo 3. Routes total Alt text Photo 4. Valid routes Alt text Photo 5. Invalid routes Alt text Photo 6. Invalid routes, short travels Alt text Photo 7. Invalid routes, travels out of time

As a synthesis

The current MapatonCDMX data has a very low part of valid strokes and the absence of the complementary attributes doesn't allow its use as a GTFS. For this purpose, this data may still go through an in-depth​ process of validation and correction, which could be done with some technological tool or with a crowdsourcing methodology, which should be submitted to a cost-benefit evaluation. Another strategy could be to re-raise the data or establish a permanent mechanism for contributing to the create new data over a long period, to progressively replace non-functional information.

Because of the scope it has had, the MapatonCDMX can be seen as a pilot test of cooperation and methods of citizen participation. We invite you to read soon about the methods and results of other non-structured​ transport mapping operations carried out in other cities around the world. We will inform about the upcoming evaluations in this blog and networks of OpenStreetMap México.

** The General Transit Feed Specification (GTFS) was created in 2005 by Trimet and Google so that transit agencies could share open information in a simple way, boost the technology development ecosystem and facilitate the development of applications that use this information.

Spanish version

Additional resources for data visualization:

Mapaton Viewer

GTFS Viewer

Read more about the first delivery of MapatonCDMX data

By @imleodc & @mapeadora

Location: Algarin, Mexico City, Cuauhtémoc, Mexico City, 06850, Mexico

Using Osmose to fix admin boundary errors

Posted by rorym on 18 December 2016 in English (English)

Over the past few days I have been using Osmose (docs) to find errors in administrative polygons in Ireland. OpenStreetMap does not have a native area type, so we have to create type=boundary relations. It's easy to break these areas, which means software which wants to extract boundary data from OSM is unable to "see" these areas.

As someone who consumes OSM data for administrative boundaries ( for townlands in Ireland), I have a certain affinity for admin boundaries in OSM in Ireland, and would like to be as good as possible, and that's possible if the OSM data is the best possible.

I've been turning off all checks in Osmose and enabling just the open polygon error. Click on each blue marker to open the popup with details. Then click the "josm" link for the relation with the problem, which will load that relation in JOSM using JOSM's remote control. The JOSM validator will then tell you where the open polygon is. You should then look at the problem and see what's wrong and how to fix it. The most common error is a small gap, and there's a missing way that you need to (re-)add to the relation. However I have seen more complicated errors sometimes.

Osmose will update regularly, but it can take a day before it's updated, so the "polygon error" will still be on the website. You can click on the "corrected" link in the popup to tell Osmose that this problem has been fixed. The popup & marker will then disappear from the map (for everyone). You can then clear the errors and work on the next problem. Sometimes I've seen many copies of the same error on top of each other, so if you click "corrected" and it looks like the popup & marker don't disappear, it probably did get recorded as corrected, it's just that there's an identical error in the same place which you're seeing. Just click "corrected" on all of them until it goes away.

Why OpenStreetMap US elections should use Single Transferable Vote (STV)

Posted by Alan on 18 December 2016 in English (English)

Today is the final day of the board elections for the US chapter of OpenStreetMap (OSM-US). Just a few days ago the international OpenStreetMap Foundation (OSMF) also held its elections. If you are a member of both groups, you may have noticed that the two organizations do their elections a bit differently. In OSM-US elections you just choose from a list of candidates, while in OSMF elections you rank the candidates in order of preference. What are these two systems, and which one is better? Well, I'm glad you asked...

The international OSM Foundation uses a system called Single Transferable Vote (STV). STV allows voters to rank candidates in order of preference, and produces a proportional result (meaning, for example, that 40% of the voters can choose 40% of the seats on the board). OSMF has been using STV in their last few elections, and Richard Weait wrote some detailed post-mortems of these recent elections, such as OSMF Board Election Results 2015, and the more descriptive OSMF Board Election Data 2014. He has more blog posts on STV here.

OSM-US currently uses a non-proportional Block Voting system (technically, "Plurality-at-large voting") where each voter can choose five candidates, and the candidates with the most votes win. While this voting method is easier to implement, it requires the electorate to vote strategically, rather than expressing their true preferences. Also under this system, there is the potential that 51% of the electorate could choose all five seats on the board.

So which method is better?

STV performs better than Block Voting in a few key ways:

First, voters can express themselves more fully because they rank the candidates from their most favorite to their least favorite. Voters don't have to make arbitrary binary choices of who's in and who's out.

Second, voters can vote sincerely for who they really like the most, without having to guess about whether their preferred candidate has a chance of winning or not. Because your vote transfers to your second choices if your first candidate doesn't win, you don't have to worry about throwing your vote away on "spoiler" candidates. STV lets you vote idealistically without giving up your chance to influence the results.

Third, every group within the electorate has a chance to elect someone who represents their views. Because STV is a proportional system, it's impossible for a slim majority of the voters to dominate the board. The result of STV is a board that represents the full diversity of the OSM community, and is better able to resolve differences and find compromise.

The consensus of all the major non-partisan electoral reform groups (FairVote in the US, FairVote Canada, the Electoral Reform Society in the UK, and so on) is that STV is significantly better than Block Voting. None of these organizations recommend Block Voting, and all of them include STV among their most recommended options.

For these reasons, OSM-US should switch to STV elections before we vote on the next board in 2017.

Ok, but is there actually a problem that we need to fix?

It's true that currently the OSM-US board elections are small, civil, and friendly affairs, and we do not have the concept of political parties and contentious campaigns. Right now with OSM-US our election system isn't causing any significant problems that we can see. The system isn't broken, yet.

In fact, there is a good chance that STV and Block Voting would produce mostly the same results in recent elections. Brandon Liu ran a simulation based on the previous two OSMF elections, and found that Block Voting and STV would have produced the same results.

Why is there little to no difference? Currently we still have a small number of candidates relative to the number of seats (roughly twice as many candidates as seats) and we don't really have strong factions (yet), so the difference between the two systems shouldn't be very noticeable. But we shouldn't be complacent and assume that these the status quo will not change in the future. When factions do emerge in the electorate, we need a system that will respond well to those changes without breaking. We need STV.

Then why should we change?

As OSM keeps growing, we will probably get more candidates, and see more vote splitting and factions forming. Also, if stronger divides in opinion develop within the OSM-US community, we might see board elections that fail to represent the diversity of opinions in the electorate.

The board should be able to resolve conflicts between different factions in the community if and when they develop. To do this, the board needs to include representatives with diverse perspectives. But with block voting, there is the strong likelihood that a minority group would not be able to get any members on the board to advocate for their views.

Imagine if 51% of the electorate wanted to ban imports (just as an example), and 49% did not. If the anti-import group ran a slate of five candidates (a common practice in elections using Block Voting) they could win all the seats under our current rules. The minority would be shut out completely. Under STV, however, the minority faction would be guaranteed some seats on the board.

But STV is also great because it doesn't require party affiliation like other proportional methods do. Voters can choose to rank candidates based on differences in their platforms, or they could allocate their vote based on regional affiliations, or gender, or whatever differences matter to them. STV produces boards that are proportional across whatever dimensions are important to the voters.

Who supports the change?

During the current OSM-US election, I asked each of the eight candidates whether they support a switch to STV or not. All the candidates who were familiar with STV supported it enthusiastically, and the others who hadn't considered the issue before were tentatively supportive. No one strongly supports Block Voting, and the only reason we keep using it is institutional inertia.

Furthermore, the OSM-US bylaws are not prescriptive about the exact method of our elections, so it should be relatively easy for the board to switch to STV elections without any change of the bylaws. Given the apparent consensus of the incoming board members (no matter whoever gets elected), hopefully we can switch to STV before the next elections in 2017.

Even if OSM US doesn't have problems yet, there's inherent value in us using the most democratic voting methods we can, and being a model for best practices of self-governance. OSMF is taking the lead here, by using STV for their elections, and it's time that OSM-US joined them.

Location: Prospect Street, Bellingham, Whatcom County, Washington, 98225, United States of America

True namespace versus Colon-delimited suffix/prefix

Posted by BushmanK on 17 December 2016 in English (English)

Thanks to this diary entry, I just discovered a Wiki page Date namespace which exists there since 2014 as an improperly published proposal. Basically, it is about an introduction of syntax that supposedly gives us the ability to indicate a date range for virtually any key. Proposed syntax looks like this:


Unfortunately, I haven't been aware of this until today, but it's never too late to address it.

First of all, storing a variable value in a form of colon-delimited suffix (or prefix) is not the same as utilizing a namespace because namespace always serves a purpose of grouping. So, this proposal has nothing to do with a namespace.

The second problem is that variable colon-delimited suffix makes data processing awfully redundant. With a proper namespace suffix, it is easy to compare it with a set of known ones within a simple query, while the date "namespace" syntax requires a complex regex (including an ISO 8601 date format pattern) to find all keys containing it. There is no way to "just" select them all because this scheme does not include a qualifier of any kind. Even a bit improved syntax like <key>:daterange<year>-<year>=<value> would allow way simpler preprocessing, but it didn't happen.

You can read more detailed explanations of these two main issues on Talk:Proposed features/Date namespace page.

I am perfectly aware of at least one web service, where developers have managed to utilize this data salad, but it only means that they had enough free time on their hands. Anyone who wants to argue is welcome to start from writing an Overpass Turbo query, showing the names of Irish counties for a specific date (say, 1920) and showing it here in comments. supports historic names

Posted by rorym on 17 December 2016 in English (English) now displays the historic name of areas! is a website which shows the Irish traditional boundaries in OpenStreetMap, like townlands, civil parishes, baronies and counties. It's very useful for Irish genealogical research, and mainting Ireland's heritage into the digital era.

An example of this is County Offaly, which was initially created as a county in 1556 as "King's County", and was known as that until Irish independence in 1922, when it was changed to County Offaly. Neighbouring Co. Laois was known as "Queen's County".

We use the date namespace suffix to support this. The current OSM relation for Co. Offaly shows how to add this data: name:1556--1922=King's County, name:1922--=County Offaly currently supports the following 3 forms. Other options may be added later.

  • name:--YEAR: Name before YEAR
  • name:YEAR--: Name from YEAR to the present
  • name:YEAR1--YEAR2: Name between the years YEAR1 and YEAR2

There is already support for adding the name Griffith's Valuation (with name:griffithsvaluation tag), and the 1901 and 1911 census names (name:census1901 and name:census1911). However that is often used for transcription errors.

Please add more historic names to OSM in Ireland!

Filling in the gaps of the maps....Providing a humbler service to humanity...

Posted by tasauf1980 on 17 December 2016 in English (English)

In year 2015, 344 disasters triggered by natural hazards were reported worldwide, affecting 108 countries and nearly 142 million people. That’s 344 times that local communities and organizations, local and national governments, and international organizations needed geographic information on the affected area to inform a rapid and effective response. Unfortunately, there are still many places across the world which lack this basic geographic information, remaining unmapped.

Detailed maps give individuals, organizations and governments’ information to support them in planning DRR activities and preparing for crises. Detailed maps also help humanitarian response actors to get aid where it is needed most, by helping to understand the population size and density, as well as identify and address logistical challenges. Efforts are being made to address the lack of maps in the most neglected places.

Humanitarian OpenStreetMap Team (HOT) is a global NGO that creates and provides digital and print maps to address the world's toughest challenges. In times of crisis and natural disaster, HOT rallies a network of volunteers to rapidly produce maps relied upon by humanitarian relief organizations to reach those in need.

A common question about aid is, does it work? In some cases, yes, but not always. Unfortunately, nothing in life is that straightforward. When someone external comes in to do the work and eventually returns home, they leave with the skills and knowledge of the project as well, so how is this sustainable? We believe initiatives carried out by community members, not only provides local knowledge, which instantly enhances the project, but the skills and knowledge associated with the project remain in the area and continue to be applied.

Micro grants are a way to support local champions of open geo-spatial data (maps), community organizing and an open source software tool chain and building OpenStreetMap from the ground up every step of the way. Many local OSM community builders face obstacles that can be difficult to imagine but they are succeeding in turning OpenStreetMap into a global, open map of the world every day.

Your donation regardless how big or small, is needed urgently to map the world’s most vulnerable and least mapped places through Micro grants, before the next disaster. 100% of each Micro grant donation goes to a local leader who is transforming their country by filling in critical data gaps. Your donation will help provide the basic necessities to these leaders, in the forms of micro-grants. Micro-grants will cover the basic costs of mapping additional villages and cities by paying for things like transportation, equipment, internet, printing, and more.

By contrast with the starry-eyed Silicon Valley evangelists who often claim their technologies have changed the world, we see the process of filling in the gaps of the maps as providing a humbler service to humanity.

“We are not trying to claim that this map is saving a kid’s life. It’s just not true,”

“Doctors, nurses and aid workers save kids’ lives. These maps help them do their jobs better.”

#mapthedifference @hotosm

Location: Hazaribagh, Dhaka, Dhaka Division, Bangladesh

Bonner ACT Australia 2914

Posted by chrisPir on 16 December 2016 in English (English)

Bonner district

Location: Bonner, Gungahlin, Australian Capital Territory, Australia

Cyprus Road Network Data!!

Posted by MapMakinMeyers on 15 December 2016 in English (English)

OpenStreetView review by The Register

Posted by alexkemp on 14 December 2016 in English (English)

OpenStreetView? You are no longer hostage to Google's car-driven vision
(14 Dec 2016, The Register)

One of the great bright lights of open-source software and user-driven community projects is OpenStreetMap, which offers an open-source mapping platform similar to, but also very philosophically different than, Google Maps.

This review is about Telenav's OpenStreetView. I find it a little odd, because it mentions OSM at the top of the article (extract above) and also has a link to Mapillary and yet, does not contain a single link to either the topic of the article (OpenStreetView) nor to OSM. Most odd.


(with thanks to mmd (see comments)):

The Register review is already well out-of-date as, after OSV attracted the wrong kind of attention from Google, OSV changed it's name to OpenStreetCam on 25 Nov 2016 and can now be found at

Share with Twitter / Facebook

Posted by OpenBrian on 14 December 2016 in English (English)

Hey I just posted to my diary! Where's the checkbox on this form that says "Share with Twitter" or "Share with Facebook"?

In fact, where the link on this page that says "Provide Feedback on the Diary Feature of OpenStreetMap"?


Tracing guide for Aweil, South Sudan

Posted by JanBohmMSF on 13 December 2016 in English (English)

This is a tracing guide for people mapping Aweil in South Sudan for MSF with Missing maps (see the task here). Aweil is the capital city of the state of Northern Bahr el Ghazal. The city's infrastructure is relatively developed. Aweil now has a functioning railway station, hotel, airport, soccer stadium, and public hospital. [1]

As we are mapping the suburbs of Aweil, you will see rather sparse settlement. Here are some photos of the structures that are visible on the satellite imagery. Very detailed information on what MSF is doing in this area, along with many useful photos (some published in this tracing guide) can be found here: One Day in Aweil: An MSF Team Portrait

Residential areas

Residential areas look like this in the idEditor Aweil in idEditor

Residential area is an area with more than two buildings. Whenever you draw one or two buildings, do not draw residential area around it. Sometimes, it makes sense to draw one huge residential area instead plenty of small ones. Please, do zoom out and consider the right size of the residential area you are mapping. Here is an example of an area, where drawing one bigger residential area is a better decision. Big residential area in idEditor


The houses you are looking for look like this from the ground

Aweil huts -areial image [2]

Another photo of Aweil from above

Areial photo of Aweil [3]

And the last one

Areial photo of Aweil [4]


Houses in this area are usually either traditional African tukuls - round (or square) structures with thatch roof or more solid square buildings with roof from metal.


Tukul image [3]

Other buildings

Aweil building image [3]

How does it look like in the aerial images?

See the huge square building on west of the residential area, and few tukuls (rounded or semi-rounded). South from a tukul in the north-east part of the area, there is a yard - you can see, that unlike buildings, the yard not drop a shadow. As the task is to map residential areas and buildings, there is no need to map the yard. Tukuls and other buildings

If you need any help, feel free to leave a comment here and post a screenshot of the area that you are mapping.





3 years of welcome messages, more than 3400 of them

Posted by SimonPoole on 13 December 2016 in English (English)

Three years back I started sending welcome messages to new mappers on behalf of SOSM, using a simple tool chain based on the RSS feed of new mappers from Pascal Neis.

The message is not customised as from the beginning it was seen as a replacement for the welcome message that had gone away with the web site redesign. The text (in 4 languages, no Romansh version though) is designed to welcome the new contributor and give pointers to the resources available nationally.

Has it worked? Difficult to say, as the whole point was a replacement of something that existed before, we didn't expect drastic change and we didn't get it.

And, no, I'm not stopping :-)

New data sources available for Western Australian roads

Posted by Sam Wilson on 13 December 2016 in English (English)

The Main Roads department of Western Australian recently released quite a few datasets under the Creative Commons Attribution licence. We have explicit permission to use two of these in OSM: the Road Network (MRWA-514) and Road Hierarchy (MRWA-515).

I'm part of a local geogeeks group that meets fortnightly in Perth, and with the help of some people far more knowledgeable than me about spatial stuff I've been attempting to derive a comparison between the Main Roads data and what's already in OSM. That's a work in progress (eventually it'll spit out an OSM file containing only correctly-attributed roads that are missing from OSM), but for the time being I'm going down a much more manual route:

1. Download shapefile from the site linked above

2. Use ogr2osm to convert it to OSM format:

python RoadNetworkMRWA_514/RoadNetworkMRWA_514_1.shp -o mrwa514.osm`

3. Create a JOSM style file that makes the names stand out:

way[cwy=Single] {
text: auto;
width: 3;
color: #c0c0c0;
text: "road_name";
text-position: line;
text-offset: 14;
font-size: 16;
font-color: lightyellow;

4. Mostly, road geometry is actually already in OSM, but the names and road types aren't. To make it easier to find where to work, I apply filters in JOSM to hide everything apart from roads with no names. Then it's just a matter of clicking a road, adding its info, and as soon as it's got a name it disappears (thanks to the filter).

This is still pretty slow, but it's safe. I'm sure there's going to be lots of better ways to work with this, but at least some missing names (and geometries) are being fixed.

I'll use source:name=Main Roads Western Australia to designate where the name has come from. The geometries I'm double-checking against Bing.

Location: Northbridge, Perth, Western Australia, Australia

Routing — alternating oneways

Posted by daniel-j-h on 12 December 2016 in English (English)

Every now and then OSRM users report routes that take puzzling, unrealistic detours. For example, a user reported this route that went to extensive means to avoid going over Flottsundsbron, a narrow bridge with alternating direction of traffic in the south of Sweden. Investigating this strange route led us to the oneway=alternating tag in OpenStreetMap.

Uppsala Route Before

Flottsundsbron Mapillary View

Flottsundsbron Photo by Mapillary user alatius under CC BY-SA 4.0.

The oneway=reversible tag's usage on Flottsundsbron meant our routing engine avoided it completely. A search for this tag in OSM will reveal that it has been used to express two different semantics.

On one hand the tag has been used to describe narrow bridges and tunnels that alternate direction of travel on a high frequency, say every five minutes. Encountering a oneway of this variety may add some amount of waiting time to the user's route, but the route is always accessible. Flottsundsbron is an example of this type of way; a changing traffic light dictates the direction of travel.

On the other hand there are oneways that change direction of travel very infrequently, like highways for the commute into a city in the morning and out of it in the evening. For these it does not make sense to let the user wait until the direction of travel changes. This highway, I-95 in northern Virginia is an example of a highway that reverses its direction twice a day.

If the routing engine doesn't know about the frequency of direction change there is no way to distinguish between the two semantics being overloaded in the oneway=reversible tag.

To pacify this ambiguity, we came up with the oneway=alternating tag at the Elbe-Labe-Meeting. The semantic distinction is clear now:

With distinct semantics in place we route you over oneway=alternating but apply a penalty for waiting time.

Uppsala Route After

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

The next step would be tagging oneway=reversible with the specific times and oneway=alternating with the waiting times or the frequency.

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

Older Entries | Newer Entries