Archiv der Kategorie: FOSSGIS

The state of campsite tagging in OSM

Back in 2019 when I started Open Camping Map a relevant part of my motivation to create this site was that this might help motivating mappers to improve the then very poor tagging state. Now about five years later I was wondering if this actually worked. So I extracted the development of campsite tagging of the last 10 years from Openstreetmap-data using Osmium and osm2pgsql.

So here are the results.

Looking at sites with insufficient tagging (mostly only a name tagged and nothing else) we have now only 47% compared to 70% 10 years ago (absolute number of campsites is roughly three times higher). So unfortunately still a lot of work to do with 81880 sites insufficiently tagged. If you wonder what I consider completely insufficient, well these are sites which are solely tagged tourism=camp_site without any further information at all. BTW, all completely insufficient sites are of course also insufficient sites.

Unfortunately we do not see an impact of the advent of Open Camping Map in January 2019. So did my map really not help improve tagging at all?

Well there is a bit of an impact, but frankly I would have hoped it would be bigger. The impact can be recognized on my second chart which shows the tags which I consider the most important ones.

News from Open Camping Map

Looking at one might get the impression that nothing has changed.

This is true as far as the general UI is concerned, however quite a lot has been changed behind the scenes.

BTW, I still would like to have prettier site icons. Probably somebody with better graphic skills than mine can help here!

So here is what has been changed behind the scenes:

In the past I was somewhat frustrated that search engines like Google did not find the link to a particular campsite on my map even if there was no better information somewhere else on the web.

Often search engines come up with mostly useless stuff like which is basically just a rip of locations from OpenStreetMap data tagged tourism=camp_site providing no further information.

That they did not find the more useful information on Open Camping Map has mostly technical reasons and is hopefully fixed now.

In the past a campsite description like has been generated by pure Javascript in the users web browser so no way for a search engine to index this description as these usually can not select sites from interactive maps.

So what I did now is generating a static version of the campsite descriptions on the server side using the same code executed only inside the users web browser before. The result can be seen if Javascript is turned of in the browser. So finally this is something a search engine should now be able to index.

My backend is now running osm2pgsql (flex) instead of imposm and a clever setup allows for faster database updates. I also generate sitemaps for crawlers like Googlebot which should then be able to find and index all the campsites shown on the map.

My most wanted new features for osm2pgsql

In light of the upcoming virtual meetup on osm2pgsql I decided to write a short blogpost about the top five features I want to see in osm2pgsql.

  1. To be able to move my map localisation stuff from PostgreSQL stored procedures to the data import stage I will need the get_bbox() feature of the new flex output driver to also work for relations. The reason is, that I do geolocation aware transcription which would not be possible on relations without such a function. This will then hopefully recover my development of the German map style.
  2. The flex backend has a new feature which will allow to pass information from a relation to its members. Currently this works for ways only but would be very nice to have for nodes and relations as well. What I think about where such a feature will be handy is for rendering of site relations.
  3. There are many ways to import OSM data into PostgreSQL, but if the target database needs to be kept up to date with osm there are only two options left. These options are imposm and osm2pgsql.Unfortunately there are features which are not available on both applications. Currently imposm will need rougly half the storage size osm2pgsql uses for updating. The main reason for this is the usage of LevelDB which might also be an option for osm2pgsql.
  4. Another feature which imposm provides is support for generalized tables for rendering low zoom objects which would be nice to have in osm2pgsql as well.
  5. Finally I would like to see support for geometries to be stored in TWKB format which will help to further reduce the storage size of production databases.

Why development of German OSM Carto style is currently stuck.

I am the Maintainer of the German Style OSM Carto fork and operator of for a couple of years now. Usually I try to follow upstream releases as fast as possible to make sure that the fork keeps as close to upstream as possible.

However, back in March OSM Carto v5.0.0 has been released which requires a reimport of the osm2pgsql database. As doing this is a lot of work for my small two-server setup maintained by a single person I decided to combine this reimport with a new Approach for map localization I have been thinking about for some time. The code is designed for the new osm2pgsql Flex Backend introduced by Jochen Topf in February. Unfortunately I did not look closely enough at the Flex Backends documentation. I missed the fact, that the get_bbox()function is currently not available on relations which would force me to disable localization for relations. I decided against doing this for now in the hope that Jochen will add this missing feature to his code soon. If this situation will persist till the end of the year I will likely have to think about another solution, but for now we will unfortunately just have to wait.

A few updates on Open Camping Map

Just in time to the upcomming SOTM 2019 conference I added a few new features to Open Camping Map.

Despite the fact, that the tagging of campgrounds did not improve that much since my first announcement of Open camping Map the new features will hopefully motivate more people to help with the enhancement of campsite tagging.

So what did I add?

Generally the changes are mostly about features not rendered in Standard tile layer or German Style.

At the moment this is mostly about the rendering of tourism=camp_pitch which is rendered in different colors depending on the type of pitch (generic, for tents or permanent residents only).

In addition to this I also added a Plug Symbol for nodes tagged amenity=power_supply.

If you like to have more on the ground icons feel free to post a feature request. I will promise that I will implement it for each additional campsite where it has been added recently by the person requesting the rendering 🙂

Announcing Open Camping Map

When I started mapping the then newly established backcountry campsites in the Black Forest back in 2017, I discovered, that the current mapping quality of campgrounds in Openstreetmap is actually quite poor. Unfortunately this situation did not improve that much since then.

Being active in OSM for more than 10 years now, I also know that improvements will only happen, when there is an appropriate special interest map which will help motivate people to improve tagging.

So here comes Open Camping Map!

It is provided in the hope, that it will help getting mappers to improve the tagging. There is a bugs section and an edit button besides the actual info about a particular site. The Map will likely be of interest also to camping enthusiasts just looking for a site in a particular area.

Some statistics about the current (bad) state of campsites in Openstreetmap. There are about 120000 camping and caravan sites in our database. About 35000 of them do not even have a name tag. Another 39000 of them do only have a name tag and nothing else. Thus about half of the campsite data in Openstreetmap is of no further value than drawing a (sometimes named) tent on a rendered map.

Wouldn’t it be nice to use Openstreetmap to locate a suitable campsite for your next bicycle or hiking trip or just for your ordinary summer camping holiday?

I do think so, thus lets start and improve the map.

This task is even suitable for armchair mappers as most of the campsites do have a website nowadays. Probably I should also think about adding this to StreetComplete or MapRoulette challenge.

Finally here are some issues I came about while coding this map:

  • Duplicating campsites as node and way ist not a good idea. Please map the area only.
  • Please add at least some contact data to make the data useful for potential customers of a site.
  • caravan only pitches inside a campsite should not to be tagged as caravan_site.camp_site=camp_pitch would be a better option.
  • I invented a tag called permanent_camping=yes,no,only as it is common on many sites in Germany, that people rent a pitch on a seasonal basis and do not move their caravan for years. There are even sites where this is the only option.

So where will I go from here. I intend to make the map multilingual and probably add more improvement on the next Karlsruhe Hack Weekend. I will be happy about further suggestions for improvements or (even better) patches.

The backend is based on PostGIS and Imposm and the associated configuration is also available at GitHub. It is likely suitable for other POI maps. Thus feel free to contact me if you like to build one! The most easy frontend for such a map will likely be uMap.

Happy campsite mapping!

Some thoughts about localization of Openstreetmap based maps

Following this tweet about a request of localized maps on I would like to share some thoughts on this topic.

My first versions of the localization code used in German style dates back to 2012. Back then I had the exact same problem as Laurence using OSM based maps in regions of the world where Latin script is not the norm and thus I started developing the localization code for German style.

Fortunately I was able to improve this code in December 2015 as part of a research project during my day job.

I also gave some talks about it in 2016 at FOSSGIS and FOSS4G conferences.
Recordings and slides of these talks are available at the l10n wiki.

Map localization seems to be mostly unprecedented in traditional GIS applications as before Openstreetmap there was no such thing as a global dataset of geographical data.

Contrary to my initial thought doing localization „good enough“ is not an easy task and I learned a lot of stuff about writing systems that in fact I not even wanted to know.

What I intend to share here is basically the dos and don’ts of map localization.

Currently my code is implemented mostly as PostgreSQL shared procedures, which was a good idea back in 2012 when rendering almost always involved PostgreSQL/PostGIS at some stage anyway. This will likely change in a vector tile only tool chain used in future. To take this into account in the meantime I also have a proof of concept implementation written in python.

So what is the current state of affairs?

Basically there are two functions which will output either a localized street name or place name using an associative array of tags and a geometry object as input. In the output street names are separated by „-“ while place names are usually two-line strings. Additionally street names are abbreviated whenever possible (if I know how to do this in a particular language). Feel free to send patches if you language does not contain abbreviations yet!

Initialy I used to put the localized name in parenthesis, but this is not a very good idea for various reasons. First of all which one would be the correct name to put in parenthesis? And even more important, what would one do in the case of scripts like arabic or hebrew? So I finaly got rid of the parenthesis altogether.

What else does the code in which way and whats the rationale behind it?

There are various regions of the world with more than one official language. In those regions the generic name tag will usually contain both names which will just make sense if only this tag is rendered like osm carto does.

So what to do in those cases?

Well if the desired target language name is part of the generic name tag just use this one and avoid duplicates at any cost! As an example lets take Bolzano/Bozen in the autonomous province South Tyrol. Official languages there are Italian and German thus the generic name tag will be „Bolzano – Bozen“. Doing some search magic in various name tags we will end up using „Bolzano\nBozen“ in German localization and using „Bolzano – Bozen“ unaltered in English localization because there is no name:en tag.

But what to do if name contains non latin scripts?

The main rationale behind my whole code is that the mapper is always right and that automatic transcription should be only used as a last resort.

This said please do not tag transcriptions as localized names in any case because they will be redundant at best and plain wrong at worst. This is a job that computers should be able to do better. Also do never map automated transcriptions.

Transcriptions might be mapped in cases when they are printed on an official place-name sign. Please use the appropriate tag like name:jp_rm or name:ko-Latn in this case and not something like name:en or name:de.

(Image ©Heinrich Damm Wikimedia Commons CC BY-SA 3.0)

Correct tagging (IMO) should be:
name:th-Latn=thanon yaoverat
name:en=CHINA TOWN

So a few final words to transcription and the code currently in use. Please keep in mind that transcription is always done as a last resort only in case when there are no suitable name-tags on the object.

Some of the readers may already know the difference between transcription and transliteration. Nevertheless some may not so I will explain it. While transliteration is fully reversible transcription might not always be. So in case of rendered maps transcription is likely what we want to have because we do not care about a reversible algorithm in this case.

First I started with a rather naive approach. I just used the Any-Latin transliteration code from libicu. Unfortunately this was not a very good idea in a couple of cases thus I went for a little bit more sophisticated approach.

So here is how the current code performs transcription:

  1. Call a function to get the country where the object is located at
    (This function is actually based on a database table from nominatim)
  2. If the country in question is one with a country specific transcription algorithm go for this one and use libicu otherwise.

Currently in Japan kakasi is used instead of libicu in order to avoid chinese transcriptions and in Thailand some python code is used because libicu uses a rarely used ISO standard transliteration instead of the more common Royal Thai General System of Transcription (RTGS).

There are still a couple of other issues. The most notable one is likely the fact, that transcription of arabic is far from perfect as vowels are usually not part of names in this case. Furthermore transcription based on pronunciation is difficult as arabic script is used for very different languages.

So where to go from here?

Having localized rendering on for every requested language is unrealistic using the current technology as any additional language will double the effort of map rendering. Although my current code might even produce some strange results when non-latin output languages are selected.

This said it would be very easy to setup a tile-server with localized rendering in any target language using Latin script. For this purpose you might not even need to use the German Mapnik style as I even maintain a localized version of vanilla OSM Carto style.

Actually I have a Tileserver running this code with English localization at my workplace.

So as for a map with English localization or would be the right place to host such a map.

So why not implementing this on I suppose that this should be done as part of the transition to vector tiles whenever this will happen. As the back-end technology of the vector-tiles server is not yet known I can not tell how suitable my code would be for this case. Likely it might need to be rewritten in C++ for this purpose. As I already wrote, I have a proof of concept implementation written in python which can be used to localize osm/pbf files.

News from German OSM Carto style

Back in June 2017 the OpenStreetMap Carto style (which German style is based on) finaly made the change to a hstore based PostgreSQL backend (a key value store, well suited for OSM tags).

I have been using hstore in German style for many years now and went even further by eliminating all columns in the database tables which represent an individual key.

Unfortunately upstream still uses columns for the most common keys used in OSM tagging.

Especially the decision to keep name in a different column than localized names (name:* tags are kept in hstore) is not well suited for localization, one of the main features of German style.

For this reason German style still uses a slightly different database schema which can however be made fully compatible to upstream using the database views available in our Github repository.

At Karlsruhe Hack Weekend in October I also updated the l10n code to make it possible to use them with an unaltered upstream database schema as an alternative. See l10 repository on Github for details.

I still recommend using using the German style schema though.

The Github repository does also contain a l10n only branch of Openstreetmap Carto which is an exact copy of upstream with the notable exception of localized labels in any desired latin character based language.

Because of the new Lua based transformation functions that upstream uses since Carto 4.x (the hstore based branch) I had to do a database reimport on our German tileserver as well, despite the fact, that I have been using hstore ever since.

I took the chance to go for --hstore option instead of --hstore-match-only which will allow for rendering of any tag used in osm, as exotic it will be. One example of such a thing is the now active rendering of the golf tag taken from french carto style (see screenshot above).

A few other changes include the adaption of road colors to be more close to the ones used in upstream and a few minor improvements like rendering of the infamous Dönertier instead of Hamburgers on Döner fast-food restaurants very common in Germany (see screenshot below).

I still hope to get one or two people to support maintenance of this fork as keeping it current with upstream will always require a little bit of work! Please contact me if you like to help.

At the time of writing is in sync to the current version of upstream Carto style which is v4.4.0.

A simple way to localize (latinize) an Openstreetmap style

Based on a request on the german mailinglist back in july, I thought about how the perfect localization of the german mapnik style would look like and finaly implemented something which comes close. Unfortunately up till now I did not document it.

However Reading about a map in manx today, I came to the conclusion, that I really need to do this.

First of all I came up with the following assumptions (valid for all languages using latin script IMO):

  • always prefer mapped names over automated transliteration
  • prefer name:<yourlang> over any other name tags (name:de in my case)
  • prefer int_name over non-latin script
  • prefer name:en over non-latin script if int_name has not been specified
  • transliterate non-latin script as a last resort

So how has this been implemented?

I decided to do it inside the SQL-query. This way it is independent of the rendering Software. It will certainly work at least with mapnik, mapserver and geoserver. Even the proprietary ESRI rendering stuff should actually work 🙂

Basically any rendering system using a PostgreSQL backend can be easily adapted. Of course your database must provide all the required name columns.

So how would one enable rendering a latin name insead of just the generic name tag?

Assume your style uses something like this for rendering a street-name:

FROM planet_osm_line;

Now just replace this by the following:

SELECT get_localized_name(name,"name:de",int_name,"name:en") as name
FROM planet_osm_line;

Quite easy isn’t it?

Well, here comes the (slightly) more complicated stuff…

Of course PostgreSQL does not provide a get_localized_name function out of the box, we have to install it first. So here is how to do this in two steps:

The get_localized_name function has been implemented in PL/pgSQL and is available at

So first add this function to your database using the following command:
psql -f get_localized_name.sql <your_database>

Second add the transliterate function available at

To compile and install it on GNU/Linux (sorry, I don’t care about Windows) do the following:

  • svn co
  • Install the Server dev package (On Debian/Ubuntu this would be called postgresql-server-dev-x.y, postgresql-server-dev-9.2 in my case)
  • Install the libicu-dev package
  • compile and install calling make; make install
  • On Debian/Ubuntu you would be better off using dpkg-buildpackage and install the resulting package instead of using the make install procedure.

Now enable the function from the shared object using the following SQL command (from a postgresql admin account):

CREATE FUNCTION transliterate(text)RETURNS text
AS '$libdir/utf8translit', 'transliterate' LANGUAGE C STRICT;

Here is how to check if this works:
mydb=> select transliterate('Москва́');
(1 row)

Well that’s it, I hope that this will be useful for some people.

Unfortunately this stuff has currently (at least) two problems:

  • Transliteration of Thai Language uses ISO 11940 instead of the RTGS system
  • Transliteration of japanese Kanji characters end up with a chinese transliteration (e.g. dōng jīng instead of Tōkyō for 東京)

If anybody has some suggestions on how to solve these please post them here!


Warum die „offenen Geodaten“ von Baden-Württemberg eine Mogelpackung sind

„Baden-Württemberg gibt Geodaten frei“, so titelte beispielsweise Pro-Linux vor zwei Tagen. Schaut man sich das etwas genauer an, dann bleibt von dieser Aussage leider nur wenig übrig 🙁

Gut, die Maps4BW Rasterkarten stehen jetzt unter CC BY 3.0 zur Verfügung (leider derzeit nur in einem proprietären Format von ESRI[1]) und man darf daraus jetzt mit offizieller Erlaubnis durch abmalen von Rastergrafiken freie Vektordaten in (verglichen mit den Rohdaten) geringerer Qualität für OSM erzeugen!

Die eigentlichen Geodaten, aus denen diese Rastergrafiken erzeugt worden sind bleiben hingegen proprietär!

Wörtlich steht folgendes in den Nutzungsbedingungen des WMS:

Maps4BW liegen nicht offene Geobasisdaten zugrunde, deren Nutzung einer gesonderten Vereinbarung bedarf.

Die Rohdaten also, deren Erstellung zu einem Großteil vom Steuerzahler finanziert worden ist, stehen diesem also weiterhin nur unter einer teuren kommerziellen Lizenz zur Verfügung.

Sorry liebe Leute, aber das ist doch genau das worum es bei Opendata geht: Um die Freigabe von Rohdaten und eben nicht um irgendwelche hübsch aufbereiteten Rasterkarten! Bei Maps4BW handelt es sich zwar um eine recht brauchbare Webkarte, aber Anwendungen für die man Rohdaten benötigt (z.B. Routing oder Geocoding) kann man damit natürlich nicht machen.

Es wäre technisch erheblich einfacher gewesen Rohdaten zum download anzubieten statt daraus erzeugte Rasterkarten.

Es bleibt also festzustellen, dass die Freigabe von Geo-Rohdaten wohl auch unter einer Grün-Roten Regierung weiterhin nicht erwünscht ist.

Fazit: Opendata geht anders 🙁

[1] Der Firma ESRI, ist hier kein Vorwurf zu machen, deren Software kann die Daten problemlos auch in offenen Formaten liefern. Im Gegenteil ESRI verhält sich als Firma sogar ausgesprochen Opendata freundlich.