Diary Entries in English

Recent diary entries

Back to Chiapas backcountry.

Posted by Sunfishtommy on 20 August 2015 in English (English)

Mapping las Margaritas can be very time consuming so I have moved back to the Backcountry of Chiapas. I estimate that I have mapped 95% of the roads in the lower right corner, not counting the tracks which are relatively unimportant and extremely numerous in the area. What I am calling the lower right corner of Chiapas is basically the flat lands that are to the south east of Parque Natural Montes Azules within Chiapas. I estimate that within the week I will finish mapping all major roads, and residential roads within this lower right corner of Chiapas. I have begun adding names to the towns using what I find in Google Maps, It seems to be trust worthy, as on more than one occasion the names have been supported by signage within Google Street-view. I also hope to finish adding all the names of these small towns in the lower right corner within the week.

So what is next?

I have already begun expanding into Guatemala. So far I have constrained myself to the obvious natural borders with the area, Río Chixoy(OSM)/Río Negro(Google Maps) has been my main constraint to the south Mapping here is practically finished with lower right corner Chiapas. My main constraint to the east has been Río Salinas(OSM)/Río Negro(Google Maps) to the East. This is actually the same river as Río Chixoy(OSM)/Río Negro(Google Maps) and I will need to do research to find the correct name. Río Salinas(OSM)/Río Negro(Google Maps) is the eastern border of Chiapas so for the most part this is finished as well.

The plan of action right now, is to see where the edits take me. But the plan is that I will continue to the north on MEX 301 and finish off the last bits of lower right corner to the north of Benemérito de las Américas, and finish the major highway editing within lower right corner!!! =D After that the I will probably move to 3 major areas. First East of Lower Right Corner in northern Guatemala where similar to Lower Right Corner's condition a year ago there is virtually no basic highway data. A name personal name is pending for this area, but I will likely just keep calling it East of Lower Right Corner This area should go relatively quickly as the roads main roads are very strait, and with no guarantee on the accuracy of the of the satellite imagery as far as offset, accuracy of every 2˚ bend is not critical. The main constraining factor to this area is imagery as there is no imagery to east.

After this The next obvious place to map is the River Lands which is what i call the area to the west of Lower Right Corner in Chiapas. I plan to expand to the north and west in this area, until eventually mapping everything east of Las Margaritas. I am also working on adding basic highway data in the areas to the south of the River Lands in Guatemala. The main constraining factor here is again no satellite data to the south. The imagery is also somewhat dated as there has been recent construction of a new major highway in the area, this is the limiting factor tow the west in this area of Guatemala. in the River Lands only so much mapping can be done to the west, as the quality of the satellite imagery degrades, and there is a large number of clouds making mapping difficult. This means that once basic expansion has been done to the south and west, the obvious place to expand to is to the north where the satellite imagery is of relatively high quality.

This is all just a basic plan, and subject to change, but I have found in the past that working in areas where there is a clear direction to expand in is helpful in preventing exhaustion as when there are no constraints, such as in the campo areas of Puebla, it is easy to become overwhelmed by the sheer amount of area to be mapped.

Well that is mostly it for now I will update as time goes on.

Location: Tierra y Libertad, Chiapas, Mexico

Design proposal for a HOT quality assurance support tool

Posted by dekstop on 20 August 2015 in English (English)

If you're subscribed to the HOT mailing list you've seen a recent invitation to help develop a funding application for the Knight Prototype Fund, coordinated by Russ and Blake. The intention was to discuss project proposals that may be suitable for this grant. The initial IRC meeting then developed into a larger conversation around current HOT needs for better tools: the resulting Google Doc with meeting notes lists six project ideas.

The strongest candidate was a proposal to develop a HOT/OSM tool to support Quality Assurance (QA). You can read some details in the grant proposal writeup, however it's a fairly high-level text. Informed by our discussion I also developed a draft specification, with a more detailed list of considerations and potential features.

I'm posting this draft specification here to get your feedback, and to hopefully stimulate some debate about what a good QA support tool might look like. The proposal is a result of conversations with HOT practitioners, and based on my own use of HOT and OSM data. However there are likely many community members with further ideas, and some may even have worked on HOT QA initiatives. We would love to hear from you! In particular we would love to hear from validators, and from existing users of HOT data. What specific data quality concerns arise in practice?

(I should also state that I don't have a deep understanding of the Humanitarian Data Model -- there are likely some useful concepts in there that could be more emphasised in the spec.)


Our general ambition is to make HOT progress more visible. More specifically, the proposal aims to support our existing QA processes around HOT validation. Crucially it further aspires to provide a means of demonstrating HOT data quality to prospective users of the maps.

Aims of the proposed QA support tool:

  1. Impact analysis of HOT coordination efforts: to describe our outputs in ways that are meaningful to the HOT community, to prospective data users, and to a wider public.
  2. Evaluating fitness for specific purposes: to assess the quality of the data in relation to the specific concerns of data users.
  3. Integration support: to assess the structure of the data in relation to the Humanitarian Data Model (HDM).

Target audiences

The design of the QA support tool should be informed by the needs of existing users of HOT data: most importantly HOT activation partners, and requesting organisations with specific information needs. This also includes prospective users in aid organisations who still need to be convinced that the data can be useful.

It should also be informed by the needs and experiences of HOT validators: they are most well-informed about HOT data quality concerns, and they are likely going to be the most active users. The QA support tool should integrate well with HOT validator workflows, however it is not meant as a replacement for existing tools. I imagine its most useful function will be as a final check: a summary report of the outcomes of a particular mapping initiative.

The design could further consider the needs of other potential users of HOT data: people who want to report on current issues, or who as part of their work can make use of geospatial data. This includes local communities, local and international journalists, engaged citizens, and supporters of aid organisations.

What are their needs?

(This is a bit speculative. Please share your thoughts on this.)

"Which data sets are available?" Which regions are covered? What kind of information is captured?

"What is the quality of the data?" An assessment of map completeness (coverage), consistency (e.g. of annotations), and various measures of accuracy. An assessment of the age of the data, and of its provenance: which imagery sources were used to produce these maps?

"How can we access the data?"

"How can we integrate it with our information systems?" For example, how well does it map to the Humanitarian Data Model, or other standard data models?

The QA process: tests and reports

I. Basic report (derived from OSM edit history):

  • How much data is there?
  • How many people contributed?
  • How old is the data?

II. Coordination report (derived from edit history and TM2 data):

  • HOT project identifiers: links to the projects that produced this data
  • Have contributions been reviewed (validated)? where? what changes were made?

III. Automated QA (basic validation):

  • Untagged objects
  • Overlapping objects

IV. Annotations report: which annotations are available?

  • Geospatial information: road names, place names, ...
  • Data provenance: description of imagery source
  • Data management: review-related annotations (e.g. 'typhoon:reviewed')

V. Humanitarian data report (derived from OSM edit history, HDM):

  • What map object types have been mapped? how many objects are there?
  • E.g. "150 buildings, 15 hospitals, 3 helipads"

VI. "Fitness for purpose" reports: assessing the availability and completeness of data in relation to specific needs:

  • Availability of building data needed for population density models
  • Availability of road data for transport planning
  • Availability of infrastructure data (hospitals, schools, helipads, ...) for aid coordination and logistics
  • Others

Other considerations

Should a QA support tool also include its own workflows to address specific issues, or focus on descriptive reports as outlined here? Will our existing validator workflows remain sufficient as we grow?

Who should be doing QA work? How much of QA requires "expert" knowledge? Can we consider QA a general community activity that's open to all? E.g. by using guided workflows with good documentation. (This is also a discussion about HOT validation practices.)

iD editors simple turn restriction feature

Posted by andy mackey on 20 August 2015 in English (English)

I have not used iD much as I usually use Potlatch2 which I'm very happy with. I was interested in seeing how iD handled turn restrictions, the answer is very well. It works like this. Start iD, click on junction node. click on the "in Way" and the allowed out ways have a green indicator and the not allowed show red. You only have to click on one of the Reds or Greens to toggle or swap them, Excellent.

Walking along Tavelsjöleden

Posted by MMN-o on 19 August 2015 in English (English)

Last week I went over Tavelsjöberget three times, tracing and looking for points of interests for hikers. As I don't have a an ATV (nor a snowmobile during the winter) I didn't bother checking those routes. The picnic sites and toilets are still, afaik, available all year around for such activities as well.

I went by bus to one side of the mountain, to Sand bus stop C which is next to Tavelsjön. Nearby there is a café, beach, minigolf course and such there which of course attracts some tourists, so I figured I could map some of it. When walking from there to the mountain path's start, you pass an attraction (which is along Tavelsjön Runt, something I'll probably build a relation for some day) called "Sikta Tavelsjöodjuret". In English this translates to "Find the Tavelsjö monster" (see: local version of the Loch Ness monster). There's a small information board next to it, while the attraction itself is a metal pipe aimed at Tavelsjön, which shows the location "where the monster is most often sighted".

The walk I took was about 5km (not counting height differences) but as I didn't stay in any of the cabins there I had to walk about the same length further to get to my sleeping place. This was the "shortest and quickest" route, but I mainly wanted to get things like picnic sites and such properly marked. There are some reference data (such as the municipality's index numbers for the shelters etc.) that I still want to get - and of course I want to walk one of the longer paths to make sure they are correctly marked on the map as well.

The probably most popular and best equipped picnic site's coordinates is linked to this post, it's the "Tavelsjöberget" picnic site, relatively near the (small) mountain's peak. It has a toilet called "Ändamålet" (where "ända" means "butt" in Swedish and "mål" would here be interpreted as "finish line").

Right now I'm suffering a cold and my throat hurts when I swallow. Though I'm pretty sure this was due to meeting people who had suffered the same symptoms before I went out, rather than a result of the walk itself.

Location: Tavelsjöleden, Signilsbäck, Umeå, Västerbottens län, Norrland, 92262, Sweden

Mapping natural and planted habitats

Posted by BushmanK on 19 August 2015 in English (English)

OpenStreetMap has many tags, inherited from natural language with blurred meaning and definitions, depending on each mapper's understanding of associated natural language term. Also, many tags are representing more than one property of an object, such as, say, type of flora, populating particular area and presence of management of this area. (Good example is natural=grassland and landuse=grass.)

In ideal case, any classification system should have only "atomic" properties instead of "molecular", where several real properties are linked. (Good example is recently introduced scheme with leaf_type and leaf_cycle - independent properties instead of linked ones.)

One of extremely widespread tags with both bad features is natural=wood.

It belongs to natural=* class, and it gives people an idea, that only natural habitats should be tagged with it. Therefore, we also have landuse=forest, which means the same kind of habitat, but more related to man made objects.

Actually, it creates really huge problem. First, lets try to explain what exactly we should map with it.

Both natural wood and any kind of planted forest are areas of vegetation, dominated by trees. But there is no clear definition (in OSM), what does it mean "dominated".

natural=wood should, supposedly, tells us, that area of vegetation forms "natural habitat". But there is no clear explanation, what does it mean "natural".

landuse=forest should, supposedly, tell us, that area of vegetation is managed, or planted, or forms artificial habitat, or trees there are non-native. There is no clear explanation, is there any difference between landuse=forest and landuse=plant_nursery - difference is only implied, because nursery should be only used to plant young trees for sale or for planting it somewhere else for forestry management purpose.

So many variants, so many assumptions and lots of guessing.

Currently, in British OSM community, there is a process of habitat=* tagging scheme discussion going on. Concepts and definitions there are mainly based on Joint Nature Conservation Committee works and publications, including Handbook for Phase 1 Habitat Survey. I like this approach, but there is a problem: ecologists usually have different goals for their projects than OSM community has. They can use plain (single dimension) classifications with all existing variants, represented by compound classes.

This approach has positive features: it's impossible to classify any object with non-existent set of properties, and it's also impossible to classify anything incompletely, because each class has full set of required properties and its values. But in OSM it doesn't make any sense: mappers are non-professionals, and often they can't evaluate all required features to use compound classes. That's why multi-dimensional classification with no mandatory properties makes much more sense in OSM.

Multi-dimensional classification means that you can have any set of independently determined properties. For example, tagging scheme can have color and material properties. It means, we can tag only color, only material or both. We also can add third property (say, shape) to scheme completely independently. Single-dimension scheme will require total revision in this case, because adding another property will require making completely new classes.

Like, originally we had classes: "red_steel", "green_steel", "red_wood", "green_wood", Adding shape to single dimension classification will make it look like: "red_steel_round", "green_steel_round", "red_wood_round", "green_wood_round", "red_steel_square", "green_steel_square", "red_wood_square", "green_wood_square".

Looks extensive, right? So, multi-dimensional classification with independent properties is definitely more suitable for OSM. Then, lets try to establish basic properties for different types of tree vegetation, that will allow us to map almost everything we want without implications and assumptions.

First, we need fundamental tag to show, that "here are trees". Trees in general, nothing more. I believe, that natural=wood can probably work for it. Its meaning is currently blurred enough to use it like very broad thing.

What to map with this tag? Answer is simple: any area, where trees grow, regardless of anything. Yes, if trees are sparse enough to see them independently, you can try mapping them as independent trees with natural=tree. But even if you can, it doesn't mean you have to.

Ecologists and forestry management using canopy coverage as a criterion for classifying any area as "forest". But I think, for our purposes we can have certain scale of percentage ranges, for example:

  • 0..25% of coverage - single trees, not recommended to tag as wood, recommended to tag single trees
  • 25..50% of coverage - sparse wood
  • 50..100% of coverage - wood

These values (single, sparse, normal) can be assigned to density key.

It's pretty easy to use these ranges, because if canopies covering a bit less than a half of territory, it's sparse, if more - normal wood.

Origin of wooded vegetation area can be tagged (if we know it), and it's pretty obvious, which values to use for this property:

  • natural
  • planted
  • mixed

But it only a kind of historical reference information, because 100 years old plantation of native trees is currently unlikely looks differently from completely natural forest, even in aspect of rows.

Therefore, we need something for current habitat state. It's only about how it looks and how similar is it to reference natural habitat. Based on ecological classifications and practical experience, we can define values for this key as:

  • natural (which means similar to natural)
  • semi-natural (which means, this area has significant traces of planting, cleanup, removal of dead branches, or, otherwise, being artificially planted, it has traces of succession, growth of new young trees and scrub)
  • artificial (which means, it looks completely or almost completely different from natural habitat typical for this area).

These definitions are just a framework, but it explains the idea.

Management is another obvious property, describing the situation, but it could be tricky to find right values for this key, because management can consist of very different works. Therefore, I suggest using general tag like managed=yes in case if it's managed and making separate scheme (considering namespace usage) for types of management, such as cleanup, fire protection, pest control and so on.

Obviously, these framework keys and values are only an example, because correct tagging scheme should be discussed and tested on different real cases. Also, definitions for values should be given in clear manner to avoid any contradictions, broadening of usage and so on. But as a framework, it gives good example of classification, based on independent "atomic" properties.

For sure, it doesn't solve certain problems completely. Like, it doesn't help to filter out tree groups within city limit (which should be done using spatial functions of SQL extensions). But it is potentially able to solve all controversy of real situations, like proper and simple description of difference between city park vegetation and wild forest vegetation.


Posted by ausiddiqui on 18 August 2015 in English (English)

Trying to get involved in OSM in BD. Have used open source maps and tools a lot and wanted to really help in my hometown where I constantly find data lacking especially geo data.

Location: Gulshan 2, Dhaka, Dhaka Division, 1213, Bangladesh

Temporary big events maps on OSM?

Posted by masticator on 18 August 2015 in English (English)

I have just an idea popping up that I want to share. In the city I live, there is a yearly big event. I think OSM is particulary suited to let the organisers display the map of the event (walking paths, small shops, parking) on OSM.

This would enable them to communicate effectively, to the partners, and to the general public using OSM.

Location: Heilig Kerst, Gent, Ghent, Gent, East Flanders, Flanders, 9000;9042, Belgium

People who blindly "fix" things in OSM

Posted by naoliv on 18 August 2015 in English (English)

Sometimes I have the impression that people blindly "fix" some problems in OSM. For example, I saw this:

Motorway links with wrong direction

One user traced the links without any oneway tag and another user just inserted oneway=yes to them. His changeset even says "Fixing motorway_link without oneway"...

If we ignore some not properly traced parts and a missing circular road on top, how could somebody fix them and not see that there are 3 motorway links with the wrong direction?

Mapping Streams in Mountain Areas

Posted by pratikyadav on 17 August 2015 in English (English)

Some tricks to map Streams in Mountain Area.

Mapping streams/rivers in mountain region could be very tricky. Sometimes it's difficult to differentiate between the valley and the peaks. Other times the imagery is covered with cloud, snow or not visible due to the shadow. image Satellite Image showing parts of Gangotri National Park, India.

A few steps can be very helpful to deal with such problems.

Overview of the area

Before jumping into the task of mapping, take some time to have an overview of the whole area. This helps to have a better understanding of the region.

Switching between layers

Better to select the layer that best shows your interest features clearly. A better resolution imagery is not always the best one.

Using terrain layer

Basic knowledge contours could be very helpful while tracing rivers and streams, specially when hill shadow makes it difficult to see the riverbed. It helps to differentiate between peaks and valley. Also, you can easily find the way of the stream. Try using a combination of both terrain data and satellite imagery, works best.

Bottom to top approach

Water always flows from higher ground to lower(into the sea). Better to mark the big streams first, one which are major rivers and easily visible. Now try to upstream connecting small streams. Won't be a good thing to leave a stream going nowhere

What not to mark?

Mountain regions are filled with landslides and very small seasonal streams. It's very difficult to defferntiate between them. What is the correct way to map them? natural=scree,hazard_type=landslide or waterway=stream & intermittent=yes? What do you think?


Happy Mapping.

Location: Idgah hills, Bhopal, Bhopāl, Bhopal, Madhya Pradesh, 462001, India

How to map seasonal roads and rivers in Benin

Posted by Maarten van der Veen on 17 August 2015 in English (English)

For a Missing Maps event in Amsterdam and London, next wednesday august 19th, the Netherlands Red Cross is going to map the south of Benin, specifically some villages prone to flooding and Porto-Novo.

Due to this flooding, roads are used in two ways during the year:

  • Dry season: normal vehicles on road
  • Wet season: boats on these same roads, which are then flooded

We are trying to decide how to tag these roads:

  • tag the roads as 'highway residential'
  • add the tag 'seasonal=yes' AND/OR
  • add the tag 'flood_prone=yes'

Additionally, the rivers have specific docking areas for canoes. We are still deciding whether to map these. And if so, what are the proper tags.

Location: RNIE 1, Porto-Novo, Porto Novo, Ouémé, Benin


Posted by Pyrhic Victor on 17 August 2015 in English (English)

Size of words

Posted by Guvani on 16 August 2015 in English (English)

Hello, somebody know how increase the size of words editing the maps?

How to see your fieldpaper grids in OSMAND (From GeoJSON to GPX) ?

Posted by aHaSaN on 16 August 2015 in English (English)
  1. Download the QGIS from the link according to your operating system ( and install it.
  2. Download the *.GeoJSON file for the area of interest you prepared for field paper/s and store in your drive.
  3. Open QGIS > Click on ‘Add vector layer’ (top of left side panel) > browse the ‘*.GeoJSON’ file saved in your drive> Open it.
  4. Select the ‘LAYER’ in the table (left side)> Click right button > click ‘Save As’ > Save as vector layer dialogue box opened > choose the ‘.gpx’ format from dropdown list > give desired name in ‘Save As’ box > browse the location you desire to store.
  5. You can open the ‘*.gpx’ file in JOSM to see the grid/s and manually draw Girds Number like A1, A2, A3…. And save the file.
  6. Copy the ‘*.gpx’ file from where you stored.
  7. Connect your android device with computer > open as usb storage device > open ‘OSMAND’ folder > open ‘TRACK’ folder> paste the ‘*.gpx’ file > disconnect your device from computer > restart your android device.
  8. Now you can see the grid/s overlayed on the map in your OSMAND. Happy mapping!!!


Ahasanul Hoque


Posted by BamweseMansoor on 16 August 2015 in English (English)

Let me extend my sincere appreciations to all mappers who have contributed to the Open Street Map globally, because before digital maps travellers and other people had a lot of problems in navigating the maual maps!!!!!!!!!!!! We can do it more better for the next generation...........

Hacking on mobile apps with the London crowd

Posted by zool on 16 August 2015 in English (English)

I made a last-minute dash down to the London OSM Hack Weekend and had a lovely time there.

I worked on a mobile app which I was pleased to get into a basically working state. It is called osmbi3, which stands for OpenStreetMap Building Information and/or Zombies. The aim was to geolocate the user and find nearby buildings using an Overpass query. This could then be linked to building management information or form the basis for some location-based game. Having managed the basic task, showing a map with annotated every building with an icon reading "yes!", I set out to try and get OAuth working against the OpenStreetmap server from a mobile device, a task which I have yet to achieve.

So, what last weekend was a very simple but perfectly functional app, is now buggy as hell while it tries to do more. However the source code is on github and i will probably keep working on it, because I could use a very lightweight building editor which doesn't require any typing.

I am doing a dangerous amount of app development now, helping finish up a project from the last codethecity event in Edinburgh, and working on a dinosaur card game app for - eventually with? - my boy. But it's all apache cordova and webviews, so i'm not doing anything too evil.

Apart from a successful weekend's hack, I was very glad to visit London put faces and voices to some names I only know from the internet; also to reconnect with some folks I hadn't seen for the last ten years. If only more people in the wider community would make the journey up to State of the Map Scotland!

SRTM global 1 arc second release complete

Posted by yvecai on 16 August 2015 in English (English)

For those interested in DEM data, the release of void-filled, 1 arc-second and global SRTM data is now completed at USGS. See

OpenStreetMap Carto v2.33.0

Posted by pnorman on 15 August 2015 in English (English)

OpenStreetMap Carto 2.33.0 has been released. This release focuses on cartographic style improvements, but the release notes also include 2.32.0.

The biggest changes are

  • A randomized symbology for forests for natural=wood and landuse=forest #1728 #1242

A long time in the works, this improvement has finally landed. The two tags were merged - they are indistinguishable to the data consumer. A randomized symbology was first suggested by SK53 at SOTM-EU 2014, and this feature would not have happened without his extensive research, or imagico tools for creating an irregular but uniformly distributed and periodic dot pattern

As all residential, unclassified, and service roads in a city became mapped the rendered view became over-crowded, bloblike, and difficult to read.

  • Unification of footway/path and rendering surface of them

The mess that is highway=path is well-known, and it is necessary to do some kind of processing as a data consumer. A distinction is now made between paved and unpaved footways.

  • Rendering of Antartic ice sheets from shapefiles #1540

Ice sheets in Antartica are a bit of a special case, and pre-generated shapefiles are now used

  • Mapnik 3 preperations #1579

The style is not yet fully tested with Mapnik 3 and we don't claim to support it, but several bugs were fixed. Most of the work was done on the Mapnik side

  • No longer rendering proposed roads #1663 #1654

  • Power area colour adjusted #1680

  • Better place label order #1689

  • meadow/grassland and orchard/vineyard color unification #1655

  • Render educational area borders later #1662

  • New POI icons

A full list of changes can be found on Github

Mapping Hervery Bay, QLD

Posted by TuanIfan on 15 August 2015 in English (English)

I started mapping the city of Hervey Bay, QLD a few days ago. It's a nice city with close proximity to the coast and serves as the gateway to Fraser Island. Incorporated from 4-5 nearby coastal villages, Hervey Bay surely has much potential for tourism.

However, it does not have a hard urban core, a shopping precinct with old buildings and parklands and blabla.. Instead, it possesses a long coast, which is ... too long and serves no link to any combined urban centre as in other real city. Ah, the area of Pialba around the Hervey Bay library, Pialba Place and USQ can be said as a preparatory centre, however, it is too small and underdeveloped, thus cannot be considered as a real centre.

Perhaps, I believe, the Council needs to work more on this to make it a liveable place.

** In OSM, I have to redraw the roads, which seem to have been automatically generated from incorrect data. I also have classified some roads as Tertiary and redraw several roundabouts.

The USQ campus was drawn as well, although I'm not sure if the campus area is correct or not.

Hervey Bay, QLD

Pialba centre

Cooperation between free content projects: how to link from Wikipedia to OSM

Posted by Polyglot on 14 August 2015 in English (English)

This blog entry describes how and why the following module was developed:

In the mean time I added extensive documentation to it, which might be more interesting than what I wrote here... so go and have a look!

With the advent of Wikidata my interest in Wikipedia flared uponce more. I'm a mapper for Openstreetmap in the first place, but last year I already made a little sidestep to Wikivoyage. That's a project which is closer in many ways to Openstreetmap than Wikipedia.

Recently I started adding wikidata tags to streets and other objects in Openstreetmap. Which in itself doesn't do all that much. So a way is needed to make this available to the rest of the world. Wikipedia seems like the way to accomplish this.

I had already experimented a bit with links to saved queries on Overpass Turbo. But creating these queries from scratch over and over again and creating such links to them, isn't the most straightforward way to get things done.

When it became clear to me that sometimes an additional query of wikidata may be necessary, before invoking Overpass, I knew I had to tackle the problem in another way.

This made me look into Lua, the scripting language which was chosen to automate the plethora of MediaWiki projects. After one day I came up with a working script (in the mean time it's been developed quite a bit further):

On the Dutch Wikipedia reception was luke warm. I'm afraid, I hadn't been able to carry across what I was trying to achieve. On the English Wikipedia a Lua developer saw the potential and he helped me to improve the code and explained me how to go about adding test cases. This helps a lot to not introduce bugs while attempting to add new features. For the case of querying several Q-numbers at once using a regex query, help came from a specialist in Overpass.

So this saved query:


now looks like this in the article:

{{#invoke:OSM|etym|display=Streets named after Leuven|timeout=50|query=[highway]|coord=50.879;4.701;9}}

which results in the following query:

[timeout:50][out:json]; ( node["name:etymology:wikidata"="Q118958"]highway; // remove the ({{bbox}}) if you want the query to be executed globally way["name:etymology:wikidata"="Q118958"]highway; relation["name:etymology:wikidata"="Q118958"]highway; ); out geom;

The difference with the stored query is that only streets closer to Leuven are fetched. If the user wishes to do so they can either remove the ({{bbox}}) statements or they can move the map to another region and press Run. In case the user also wants to see other objects named after Leuven, they can remove the [highway] part.

Now, let's hope the Wikipedia contributors at large see value in this. I deployed it on the French Wikipedia as well and will probably continue with Spanish, German and Esperanto. Feel free to deploy it on other language versions as well. I will keep all the modules in sync. I'm only going to develop test cases on the English Wikipedia, so that will be the primary place to continue development. One test is failing because of lack of arbitrary access, but that should be resolved shortly.

Actually there is a whole plethora of possibilities:

  • objects named after the subject of the Wikipedia article (on condition they got name:etymology:wikidata tags on the OSM side)
  • the object of the article itself (on condition they got wikidata tags on the OSM side)
  • other objects related to the article (this is probably not OK with Wikipedia policies)
  • objects of which the subject of the article is the architect or the artist who created them (architect and artist.wikidata)
  • objects related directly to the subject (subject.wikidata), this can be tombstones as well
  • objects carrying brand:wikidata or operator:wikidata tags
  • relations representing public transport lines. The names of the stops are emphasized with help of MapCSS styles
Location: Hertogensite, Leuven, Flemish Brabant, Flanders, 3000, Belgium

New road style for the Default map style, the full version - PR, casings on z11

Posted by Mateusz Konieczny on 14 August 2015 in English (English)


Next pull request for changing road style was opened. This time it is a final stage of proposing a rendering change including new colours for roads, new widths and rework of a railway styling. Feedback is welcomed.

PR link:

All changes before PR were squashed into two commits - as result changes done based on feedback since creating PR are listed on

Casings on z11

One of repeated comments was that casings on z11 are not working well. Therefore I prepared also another casingless variant for z11. Below are test renderings for some places (current rendering, rendering from PR, potential rendering using low zoom styling for z11)



Iceland, Reykjavik




New Jersey

Rural UK


z11 will be now using casingless style, especially as attempt to improve casings on low zoom by reducing it failed to solve problems with pixelated casings and managed to create new.

Older Entries | Newer Entries