A few questions about railway mapping

Railways
1

Hey!

I’m a Dutch rail history buff (and when I say railfan I mean the actual rails. I don’t really care about trains) and when I grew up I wanted to be a cartographer.

I recently found out about https://openrailwaymap.app/ - a site that I have dreamed of creating myself for years but I don’t have the programming skills. What I really love is the historic railway maps in a modern context (for who doesn’t know, select the “infrastructure” layer, then the little calendar icon and see the network in any date you want).

I am an experienced OSM editor (user IIVQ there too) but completely new to OHM, and finding documentation quite scarce. I don’t really understand the concepts as written under #Evolution over Time, are there some examples of what are best practices?

As a starter, I mapped the two first lines of the Amsterdam Metro (collectively know as “oostlijn” and from

Just a few questions:

  • I assume all non-date-related tagging from OpenStreetMap is valid here too?
  • I am not quite sure how to do the date tagging. start_date and end_date are easy enough, but how would I handle the following scenario’s?
    • A railway segment was officially opened in October 14, 1977, but construction was ongoing since at least 1973. Is there a way to put in a “railway=construction” tag from 1973-october 13, 1977 using the same way or do I need to duplicate ways?
    • How do I go for a pretty normal railway lifecycle: Construction, Open, closed to passengers but open to freight, officially closed but available to works trains (or the occasional railfan tour or sugar beet train), disused (not available due to e.g. asphalted crossings and growing trees, but could be reopened without considerable rebuilding), abandoned (not usable as a rail line but recognizable to the railfan/geography fan as a former rail line)?
    • How do I cover a line that is, say, opened in 1900 but electrified in 1950?
    • I am especially fan of railways that started to be built (railway=construction) but then construction stopped and lay dormant for decades (e.g. the Métro léger de Charleroi, the Ferrandina-Matera railway or the Saint Maurice-Wesserling railway). How do I map those? As eternal construction or as abandoned?
    • In my nearby metro line (built 1977), in 2020-ish a new bridge was built (even though the road under it opened only in 2023 or 2024) on exactly the same alignment. Do I need to draw a new way for the bridge itself in the after situation?
  • Is there consensus on how to map a multiple-track situation? E.g. the Amsterdam Metro, I drew the tracks for 2 of the current lines (53/54) as separate tracks where above ground as I know the tracks have always been the same. But for many lines, we will not know more than “built as single track in 1880, doubled in 1920, singled again in 1950” without knowing the exact alignment. How do we handle this?
  • Is there a way to map “railway land” which cover a wider area but were we don’t know the exact layout of tracks (yards etc?)
  • How do we cover railway services? I by no means want to cover railway train services, but for metro and tram networks, the routes of tram line “1” (Amsterdam) or “the Northern line” (London) has changed over the years and not always covered the same track.

Please, if there is already good documentation I have overlooked or good examples of current mapping practices, point me there!

1 Like
2

Hi, first of all a welcome, always nice to see a new rail face here :slight_smile:

  • yes, almost all tags are exactly the same as on OSM.
  • unknown multi track situations are handled in OSM via the tracks=* key. This could be a potential solution for OHM, too. But it requires the tag on the way to change over time, what poses an issue as you already discovered.
  • “railway land” can be mapped using landuse=railway. Here is an example where I did that for a station with an (to me) unknown track layout: OpenHistoricalMap
  • services can be mapped the same as in OSM, with the according relations

The one big question left open is how to map changes that do not affect the geometry. This is currently the Achilles’ heel of mapping in OHM, as we have not yet found a satisfying solution:

One common solution is to simply draw a new way on top for the newer set of tags. This solution is the simplest for data consumers and well supported as it is no different then OSM data. But this hits a practical limit for the mapper very quickly, even with just two versions it becomes very tedious to handle and I consider three the absolute limit already.

An other method is to put all tags in relations. For this the multilinestring relation is used. Instead of handeling overlapping ways the mapper now needs to juggle a lot of relations, not perfect but a lot easier. The bigger issue is the question how these are supposed to be handled for data processing. Most OHM renderers can handle them now, but there are major questions about further users such as routers.

The third method was to put the years in the key of that tag itself. While this is a very satisfying solution for the mapper software support has turned out to be basically impossible so it is not done anymore.

As a result I currently focus on mapping geometry and only map basic tags, sometimes drawing overlapping ways when a change is way too big to be ignored. ORM is currently not rendering more anyway, so I wait with going into details with tags until we found a good solution. And there have been more then enough rail layouts to keep me occupied for a while, lol.

1 Like
3

Welcome! I’m you got a good response. The topic you posted to is the Railways category’s introduction topic. Introduction topics are very easy to miss because they don’t show up on the forum’s homepage after you’ve read the first post. I’ve moved your post to a new topic.

2 Likes
4

Thank you for your response!
I really hate the “multiple ways” for what was essentially the same feature.

It’s a shame that the “put the key in the years” (I assume you mean Proposal:Date namespace - OpenStreetMap Wiki ) doesn’t work well, it seems like a simple solution.

Do you have an example of the multilinestring-relation? The explanation at Relation:multilinestring - OpenStreetMap Wiki is really tailored towards OSM use, not OHM use.

Minh_Nguyen, also thanks for moving this topic!

1 Like
5

Ok, I tried something with promising results, but want to take a day until all renderers fully take this. How long does it take openhistoricalmap.org (historical layer) to usually render an added feature! - oh less time than it takes to write this post!

I modeled the “Amstelveenlijn” ( Metro/sneltramlijn 51 - Wikipedia ), which has a complex history.

  • From 1990-2019, the Amsterdam Zuid-Poortwachter section was a light rail line (relation)
  • In 2004 3 more stops till Westwijk were added (relation)
  • In dec 2019 the line was closed for works till dec 2020 (relation)
  • Then in 2020 Amsterdam A.J. Ernststraat-Poortwachter was reopened as tram (relation)
  • In 2024 an extension was made to Uithoorn (relation)
  • From just north of Westwijk to Uithoorn was also part of the Haarlemmermeerlijnen in 1915-1972…(relation)

I mapped this all in this chronology relation (although I should probably remove the Haarlemmermeerlijnen one and make it it’s own chronology relation, because that has a complex chronological history as well)

Both openhistoricalmap.org and openrailwaymap.app seem to take this really well! Cool!

I did not add the “metro” part of the Amstelveenlijn (from Centraal Station to Zuid) as a relation because that is just now working.

I guess this is the same way one could add public transit routes (i.e. the historical movement of tram and metro lines)! That’s something I’m gonna try next time for the Amsterdam Metro lines!

One small thing I notice though is this piece: Way: ‪‪‬ [ – 2019]‬ (‪201537211‬) | OpenHistoricalMap It’s mapped as tunnel=yes / layer=-1 and no other tags, those come from the relations. But both in OHM and ORM.app, it’s shown as not a tunnel (and ORM.app even explicitly mentions tunnel=no). Is this a bug on both OHM and ORM.app? Or is it intended behaviour to not inherit keys that are on the way in case of a multiline-relation? I modified it to have a start_date, see if that changes anything!

6

Conceptually, the “one” in “One feature, one OSM element” refers to the topmost relation, such as the chronology relation or route relation. In OHM, we don’t otherwise count the number of copies of the feature, just as OSM doesn’t count the number of ways that join together to form a complete road. However, you have reason to dislike this approach; it isn’t as usable as it should be in either iD or JOSM.

To elaborate, the most immediate issue is that data consumers can’t accommodate an infinite number of possible keys in a key-value store. We’ve got a very small development team, so we can’t realistically customize all the OSM software and database software to handle this better. However, if the OSM community were to formally adopt the date namespace syntax and enough OSM data consumers added support for it, we’d gain that support for free.

The other issue is that we often need to record more than just a simple date range. For example, start_date:edtf=* is for advanced dates (uncertainty, seasons, etc.), and start_date:source=* is for the source of the start date. This kind of structured information can’t fit in a key.

Nevertheless, if you have the dates but don’t have the time to duplicate a feature, we’d rather you record the dates somehow, even if it’s in an unsupported syntax or an unstructured fixme=*. The map doesn’t have to be perfect right away.

Correct. When a way is a member of a multilinestring relation, it lends its geometry to the relation. Otherwise, the tags have nothing to do with the multilinestring and instead define a separate feature. So any partial changes to the physical characteristics over time, such as a segment getting double-tracked or grade-separated, will result in mapping multiple copies of the feature even if you use multilinestrings.

By analogy, in OSM, this way is tagged as a place=islet. It’s also an outer ring of a natural=wood multipolygon and an inner ring of a natural=water multipolygon. None of the tags on the way pertain to the multipolygons or vice versa.

That said, at a glance, the multilinestring relations you’ve mapped seem kind of like route relations. If you tag them as type=route route=railway, then you have more opportunities to simplify the structure. Let’s say a portion of a route starts out at ground level with a level crossing but becomes a tunnel later on. You could map two coterminous ways, tag one as a tunnel, and add both to the same route=railway relation. JOSM may complain that the route relation is no longer linear, but it’s fine as long as the two ways have mutually exclusive dates. With this approach, you’ll end up with fewer relations overall and only minor overlapping ways.

7

Yes, indeed. Maybe I shouldn’t be posting after midnight, lol, my sentence makes no sense.

https://www.openhistoricalmap.org/way/201457890

Yes, indeed!

Yes, they sadly don’t. Imo it would be easier if you would only need to put the keys that change in the relation, but now you basically need a different relation for the tunnels.

1 Like
8

I don’t think that would work as you would need a changing railway=* tag, I’m not really seeing how you would fit that one into a railway route.
In other tests I tried putting actual route names into railway routes and it did nothing in for the renderer so I’m not sure if OHM or ORM is even doing anything with them. (Relation: ‪‪Schwarzwaldbahn‬ [1874 – 1920]‬ (‪2861779‬) | OpenHistoricalMap)

1 Like
9

It would mean more members in that route. To reiterate, this is sort of tossing out the idea that a route relation is linear, or at least adding a caveat that it’s only linear after filtering the members by date. I don’t think it minimizes the number of ways, especially if we’re talking about a change in railway=* classification. But if it’s just a minor realignment, grade separation, or speed restriction change along a short track section, then this could help to isolate the complexity to just that section.

Yes, the tiles now include the names, but the stylesheets aren’t looking for them yet:

1 Like
10

I disagree. In this case, the tunnel has always been there from the first construction start. In your proposal this would mean 3 new multilinestring relations just to map this tunnel, even though the geometry doesn’t change over time.
In e.g. an OSM route relation the value of an element is used in the relation, a way which is a highway=x is different from a way which has public_transport=stop_position.

Not including the “mother” value here in the rendering makes things unnecessary complicated.

For now I’m including the tunnel as is, i.e. with tunnel=yes and layer=-1 on the way and the three timewise relations. The data is in there, otherwise everything becomes unecessarily complicated.

They are not. From 1990-2019 this was a light rail (metro, just not legally) line. The next year, the line was completely rebuilt (completely new track, two new tunnels added, all platforms rebuilt etc) into a tram line. It really is a “new line”.

11

This is why I figure that multilinestrings aren’t as helpful as you might think at first glance. Multilinestrings have a pretty clear meaning across GIS. I certainly wasn’t making up the semantics when I coined this relation type in OSM.

This is the technical difference between a route relation and a multilinestring relation. Think of multilinestrings as the linear version of multipolygons. The way you’ve tagged as a tunnel is sort of like if you were to combine multiple buildings into a type=multipolygon building=* relation, then tag the member ways with different names and levels. It isn’t really a single multipolygon at that point.

By the way, whenever I have enough information about a tunnel or bridge, I make sure to map an explicit man_made=tunnel or man_made=bridge area, so that the evolution of that structure over time doesn’t interfere with the modeling of any thoroughfare above or below it.

Hm, that might not be so clear to future mappers if the relations are all hanging off of the same ways. I realize mapping the infrastructure multiple times over can be tedious though.

12

I am really new to this project, so I might be kicking a few shins here, but it really seems like the attitude is: “We’re using the codebase of Openstreetmap, a project that was explicitly made to only map the current situation, and then use that codebase to make a time-based application”.

I understand this is a project without a lot of coding voluntary power and the ability to reuse tooling makes things easier, but the data model of OSM has some known pitfalls and does not lend itself well to the core of this project. Then making things unnecessarily hard for the editor (and later: the data processor) is not the right step.

13

OpenHistoricalMap does do some things differently, such as having a vector based map from the start. But as you said it is way easier to reuse OSM tools. But more importantly we have the support of OSM and Wikipedia. We would have none of these things if this were just some separate project. I myself would have never contributed if it wasn’t a sister project to OSM. Because that’s where I come from.

14

I appreciate your candid assessment of the state of our project. We’ll only grow as a project if we welcome feedback from people who come here with fresh eyes. I too have a lot of opinions about what OSM got wrong over the years. OHM’s founders have even stronger opinions about that, and then I have opinions about their opinions. (Hey, we were all young once.)

OHM is a wonderful opportunity to fix what’s broken, but every departure from OSM tagging schemes hurts interoperability and prevents happy accidents, like someone discovering they can use OHM data with OSM software we’ve never heard of. JOSM users already face enough annoyances because of assumptions we break in that software.

We do depart from OSM where there’s enough of a strategic benefit. In general, we expect to coin new tags more often than redefining existing tags, because new tags don’t carry as much baggage. Eventually, OSM may start importing data from OHM, spreading our tagging ideas further. That’s one reason we’re particularly unlikely to change the OSM XML format (though I always daydream about promoting start_date and end_date to attributes alongside lat and lon).

Specifically regarding multilinestrings, adherence to the ISO 19125 “Simple Features” standard for geometry types allows people to use OHM data with software that wasn’t even designed for OSM. This is important because there’s already a crowded field of historical GIS projects, some of which have better standards compliance than we do. We compete against them for mindshare among academics and professionals. If the standard semantics for multilinestrings don’t solve the problems we’re facing, we should find a better-suited relation type or devise a new one.

I think this will be clearer once we set up a routing engine for OHM data. From what we can tell, existing off-the-shelf software should pretty much just work with the overlapping ways method after some minor modifications, whereas multilinestrings would most likely require writing our own routing engine from scratch. With that level of effort, it would be better to convince the OSM community to reform their tagging scheme so we can piggyback off those improvements. Otherwise, we’d be stuck with the burden of developing custom software on our own, even where the requirements aren’t unique to historical mapping.