OpenRailwayMap-vector announcement

Hello fellow mappers,

Hereby I announce OpenRailwayMap-vector, a reimplementation of OpenRailwayMap using vector tiles. There was already discussion about the future of OpenRailwayMap in Future of OpenRailwayMap and this post is the expanded announcement.

Over the past years I have had a wish to expand the existing OpenRailwayMap with more features, specifically Dutch railway signalling. The signalling data is available in OpenStreetMap, but was not visualized on the map. However, multiple pull requests with these features and some technical improvement remained unanswered. (This is in no way criticism upon the maintainers of OpenRailwayMap, I understand we are all persons maintaining and contributing to the OpenStreetMap community in our free time.)

I decided to fork the OpenRailwayMap project, and start implementing the needed changes to visualize the Dutch railway signalling on the map. In addition to the features, I wanted to experiment what is possible with vector-based rendering of the data. This changes the technology stack of the map significantly, because the software between the database and the user was replaced with other software. Mapnik and CartoCSS were replaced with Martin and a MapLibre style specification. The frontend is no longer a slippy map displaying images, but rather a rich library visualizing the vector data using the given style.

After porting the existing style verbatim to the vector-based technology, more became possible in terms of development and user experience. It is easy to add signalling symbols and train protection symbols on the map. The style is decoupled from the data, allowing rendering improvements without changing the data in the database.

The visualized data has been expanded by railway signalling in The Netherlands, Germany, France, Austria, Switzerland, Poland, Belgium, Finland, Spain, Luxembourg and Sweden. Train protection systems that are documented and mapped all over the world are now rendered. A big shoutout to the railway mapping community in Poland, France, Germany, Sweden, Switzerland and Austria for creating a great amount of well-tagged data. During this work the wiki has been expanded for certain well-tagged but undocumented data. Official sources where OpenStreetMap tagging is derived from are also added to the wiki.

The user interface has improvements from using vector tiles. Instead of plain images for each tile, the features on the map are interactive, allowing highlighting and popups with details of the features. The legend is dynamic, listing the features for the current zoom level in the selected style. Much more is possible, for example filtering, grouping and selection of features and dynamically configuring a combination of visualized features, but it still has to be built into the map.

The data on the map is updated daily, and deployed for Europe and North America. The railway data of the entire planet is imported, but I currently do not have access to the server resources to render tiles for the entire planet in a timely manner. The deployment is currently set up as a “dance” between Github Actions and Fly.io to update, build and deploy the tiles. This is work in progress to get the entire planet tiles updated and deployed daily.

There have already been multiple contributions to this project. This is incredible and much appreciated! Contributions in the form of issues, discussions, ideas, code or reviews are welcome!

The project is not finished and will probably never be. Making small changes, improvements and trying to find the limits of the OpenStreetMap data, database and visualization tools is what makes this project so much fun.

All this would not be possible without the original work on OpenRailwayMap by all the original contributors. Huge thanks and credits to those who created and maintained this beautiful work. I would love to contribute the work back into the upstream project.

Kind regards,
Hidde Wieringa

18 Likes

As I understand someone willing to sponsor server resources (either by donating access to hardware or by giving funds) would be useful to solve one of bottlenecks.
Is this interpretation correct?

What other help would be welcomed?


Are there plans to pull data also from OpenHistoricalMap?

That could reduce attempts to map in OpenStreetMap no longer existing railways, gone without any trace whatsoever.

(like railway across a village that is now gone and replaced by an open pit mine - with railway and village and its fields gone without trace whatsoever. Incorrectly mapped in OSM at least twice so it will appear in ORM (from what I see it was not yet added again).


)

4 Likes

As I understand someone willing to sponsor server resources (either by donating access to hardware or by giving funds) would be useful to solve one of bottlenecks. Is this interpretation correct?

Currently, an OSM file containing the OSM railway data is updated daily for the entire planet.

In terms of deployment, the data processing (updating the OSM data, importing it into a database for consumption by the OpenRailwayMap vector tiles, rendering vector tile files) and the publishing of those tiles is currently done in Github Actions, and then published using Fly.io as a simple deployment platform. All of the processing happens daily. Doing the data processing in Github Actions is free for open source projects, and having prerendered tiles keeps the hosting costs on Fly.io low. The data processing time is currently the limiting factor to deploy the entire planet: Europe and North America takes ~1.5 hours daily. There may be ways to split up the work, or optimize the tile rendering to deploy the planet daily. I am looking into this (issue Deploy the entire planet · Issue #231 · hiddewie/OpenRailwayMap-vector · GitHub).

Another way to achieve the same deployment, is to have a server that imports the database daily, and serves the vector tiles directly from there (with appropriate caching). No tile prerendering is needed in that case, but the server hardware requirements (and also costs) will be higher than currently.

Then, to answer the actual question, help can be provided by:

  • sponsoring Github Actions resources to quicken tile generation (e.g. private runners)
  • sponsoring server resources to host a live database and tile server (the alternative deployment)
  • funding to achieve the same, indirectly

What other help would be welcomed?

Anything listed in the contributing section in GitHub - hiddewie/OpenRailwayMap-vector: OpenRailwayMap vector tiles or the contribution documentation OpenRailwayMap-vector/CONTRIBUTING.md at master · hiddewie/OpenRailwayMap-vector · GitHub.

Are there plans to pull data also from OpenHistoricalMap?

There is an open issue OpenHistoricalMap · Issue #246 · hiddewie/OpenRailwayMap-vector · GitHub that proposes to integrate OpenHistoricalMap into the OpenRailwayMap. I did not look into that deeply yet. But it does seem to solve the problems you pose with historical data being entered into the OpenStreetMap database.

2 Likes

Looking at the YAML files, this looks to be a big step forward in hackability; might even make me want to hammer out more on what signal iconography in North America shoud look like!

3 Likes

Really nice! I had lots of fun helping out with improving the German signalling :smile:

However, this project also reveals a bunch of flaws the with currently tagged things. :sweat_smile:

@Rokotell, can I ask you to please be more specific about what you mean by “reveals a bunch of flaws…with currently tagged things?”

It would be great to both more widely understand these flaws and actually correct them: this could lead to strategies to better tag rail all around the world. Thank you in advance!

@stevea For example, railway=power_supply is used for two completely different things:

  1. power=outlet - A point where train’s batteries can be charged, while they’re out of operation.
  2. A catenary mast that has a connection to powering ground wires, which looks like location:transition to me.

IMHO railway=power_supply should be deprecated in favor of these two above.

Additionally, railway=museum should, imo, be deprecated too in favor of museum=railway.

@Rokolell, thanks for your thoughts, apologies for getting your moniker wrong.

To the greater thread / topic (especially @HiddeWie), this tiling / rendering is awesome news, a banner achievement!