Archiv der Kategorie: Openstreetmap

Running an Openstreetmap-Tileserver with “readable” names

Datum:        Schreibe einen Kommentar zu Running an Openstreetmap-Tileserver with “readable” names  
Standard tile layer rendered with Latin localization.

For most westerners the standard tile layer is basically unreadable in regions of the world where Latin script is not the norm. For this reason German style has been using localization for years.

Unfortunately for some people this has been implemented in a somewhat incompatible way regarding standard tile layer which would require changes to the style itself to get localized names.

Fortunately I changed this now and this has hopefully simplified a lot for people using standard tile layer or German style.

Now, if all you want to have is standard tile layer with localized names what you have to do is using openstreetmap-carto-flex-l10n.lua from German style for database import instead of the one from standard tile layer. This will still require the installation of osml10n but once you have done this it is possible to localize names during database import (or update) easily.

Likely this comes especially handy if your target language ist not German but something like English, French oder Spanish and thus just using our tile-servers providing German style is not an option.

If you also want German road colors in addition to localized names, then just go for German style as before which now also uses the upstream database layout. It is now even possible to render German style without localized names easily, but I doubt that this is something anybody will want to do.

Technically all of this localization stuff works by modifying the name tag of OpenStreetMap objects to the names we want to see in the map during database imports. Probably I should add an option to keep an unmodified version of the name in the hstore columns of the database.

Tags:

The state of campsite tagging in OSM

Datum:    

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

Datum:    

Looking at https://opencampingmap.org 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 https://campingspots.info 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 https://opencampingmap.org/de/way/164951603 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.

More updates on Open Camping Map

Datum:    

While looking at current campsite tagging I came across a very common mistake which is nested campsite objects as shown on the map above.

The problem with such a tagging is that it is unclear for a data consumer like my map what this is supposed to mean if a node tagged tourism = camp_site resides inside a polygon also tagged tourism = camp_site.

For this reason this is now shown as a bug in Open Camping Map. Please do not nest such objects but use a polygon only and no additional node tagged tourism = camp_site. Unfortunately there are currently about 3000 campsites with such an inconsistent tagging!

However I did not only add more stuff to the bug view. I also added rendering for a few more amenities in Zoomlevel 19. These are sanitary_dump_station, water_point and drinking_water (the same icon is currently used for both).

Happy campsite mapping!

Announcing support for site-relations in OpenCampingMap

Datum:    

In most cases it is sufficient to map a camp-site as a closed way or multipolygon.

However, there are exeptions and this is what this feature is for.

On backcountry campsites there is often no well defined boundary. Thus it may be appropriate to map them as a node only.

This is where an additional site-relation comes in handy.

Such a facility may have two clearly related nodes tagged amenity=toilets and leisure=firepit which might even have an access=customers tag in addition to the tourism=camp_site node itself.

To explicitely map the fact that these 3 nodes are part of a single campsite a
relation tagged tourism=camp_site and type=site should be added containing all
three nodes.

Here is an example of such an object:
https://opencampingmap.org/#12/49.0690/7.8621/1/1/bef/node/3824691120

And this is how it looks like on osm.org:

Another example would be a case where amenities like toilets or showers are used by multiple facilities like a camp-site and a sport-center and are thus not located inside the closed way or multipolygon of the camp-site itself.

In this case again a relation tagged tourism=camp_site and type=site should be added which does contain the actual camp-site object as well as the related amenities.

Sometimes even the information desk is located outside the campsite polygon. No problem for the site-relation approach.

This said. Please do not use a site relation if all facilities are located inside the closed way or multipolygon tagged tourism=camp_site. In fact this is shown as a bug in https://opencampingmap.org/.

Another bug would be to add more than one object tagged tourism=camp_site to such a relation. Likely the correct mapping in this case would be a multipolygon containing two areas which might then optionally be part of a site-relation.

Happy campsite tagging!

My most wanted new features for osm2pgsql

Datum:    

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.

Datum:    

I am the Maintainer of the German Style OSM Carto fork and operator of http://tile.openstreetmap.de 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.

Wie man die Qualität von Fernradwegen mit Hilfe von OSM und Brouter berechnet

Datum:    

Vor vielen Jahren habe ich mich in diesem Blog schon einmal über die Absurdität von ausgeschilderten Fernradwegen ausgelassen. Was sich seither geändert hat ist die Tatsache, dass es das Openstreetmap basierte Routingprogramm, dass ich mir damals gewünscht habe inzwischen gibt. Die Rede ist von Brouter. Eine Software von Arndt Brensched, die es sowohl als App für Android als auch als Web-Planungstool gibt.

Nun lese ich heute einen Tweet von Hanno Böck, der sich ebenfalls über solche Fernradwege beschwert.

Nachdem ich wie üblich bei solchen Fragen das Brouter Tool empfehle wird mir klar, dass Brouter vermutlich genau das was Hanno gern hätte leisten kann. Was man gerne hätte wäre ja so eine Art Qualitätsfaktor für Radrouten.

Nach einer kurzen Kommunikation mit Arndt wird klar, dass das ganz einfach ist. Man konfiguriert das Routingprofil für Trekkingrad so um, dass man die Behandlung der Fernradwege umkehrt.

Aus folgender Anweisung:

else if ( is_ldcr ) then 1

macht man einfach diese hier:

else if ( not is_ldcr ) then 10000

Nun deaktiviert man noch die Höhenkosten und fertig ist der Engine zur Berechnung der Qualität von Fernradwegen.

assign consider_elevation = false

Je kleiner der durchschnittliche Kostenfaktor im Brouter-Web um so besser ausgebaut ist die Radroute. Wer die beschriebenen Änderungen nicht selbst machen möchte kann sich unter https://home.geggus.net/score.brf das geänderte Profil runterladen.

A few updates on Open Camping Map

Datum:       2 Kommentare  

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

Datum:       15 Kommentare  

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!