Problems with the map of City Thameslink station

Communities United Kingdom
, , ,
1

Hello all,

I am hoping to get some advice on how to improve the mapping of the National Rail station City Thameslink, in the City of London. This is off the back of changeset 173047537, which has been reverted for misuse of the `railway=station` tag. The comment left on the changeset by @DaveF was:

The railway=station node is distinct from entrance tags, of which there may be
many, scattered well away from the actual station, especially in London.
Station nodes for 2 platform, two track station the node should be placed
between the tracks & near to the middle of the platforms.

Is there a building with barriers & ticket office etc? (building:train_station)

Fair enough, I have a decent amount of experience using the OpenStreetMap data but I am admittedly inexperienced in actually doing the mapping, so it is not too surprising that this change ended up getting reverted. I modified a complicated part of the map without reading the entirety of the railway section on the OSM wiki, which I see is extensive. That is why I ticked the “request review” box on the change when I was making it!

However, it seems that neither the commenter nor myself are qualified to make the modifications that the station requires - my change misused the tags, but the suggested change will leave the map in its current state which is self-evidently incorrect to even a casual observer. So I’m reaching out here in the hope that someone very experienced in mapping underground railway stations with multiple entrances can suggest changes which both leave the data clean, and also result in a useful map.

Or, if the mapping community’s position turns out to be that the station mapping is already correct, then I would appreciate some assistance with the filing of useful bug reports against a range of open source software which consumes and processes OpenStreetMap data, including some projects which themselves fall under the OpenStreetMap project umbrella, and advice on how my own map should interpret the station’s mapping data.

I can’t find the source on OSM wiki for the advice I was given about the node tagged railway=station. The advice appears to be a rephrasing of the advice from the Railway Infrastructure section on the wiki page Railway stations - OpenStreetMap Wiki relating to nodes tagged railway=stop, which are members of ways tagged railway=rail.

I can appreciate that for routing reasons, a node in the middle of the rail is very useful (although I note this station currently seems to have those nodes at the end of the rail rather than the middle). But, I don’t see any such advice on the wiki for `railway=station`; although it is shown on a diagram it is not really discussed.

In any case, although the advice makes obvious sense as a rule of thumb for outdoor stations matching that description, it seems to me that this station being makes the utility of that rule considerably murkier.

I have surveyed many consumers of OSM data including “official” OSM projects and found that there is a clear disconnect between what this advice suggests / how this station is mapped, and how these consumers are interpreting the mapping:

1. The “carto” raster tile generator / OSM’s own raster tiles

The main station marker is placed in the middle of 10 Fleet Place. An entrance icon is placed for the main station entrance at Ludgate Hill and for the secondary station entrance at 1 Fleet Place, but only at a zoom level which makes it likely that the words “City Thameslink” are not even on screen.

One must visually follow a red line from the entrance marker along an underground path, and then along the train platform itself north or south for approx 125 metres to know what the marker relates to - the entrance markers themselves are not labelled.

Why I think the outcome is obviously wrong: A casual user of the map would take these entrance icons to be the entrance to the office buildings they are within, and not make the connection to the underground station. Additionally, the railway=station node named City Thameslink happens to be located in the middle of a building at 10 Fleet Place which cannot be used to access the station. A casual user of the map, however, would take this building to be City Thameslink.

2. Other vector-based tiles and styles

Mapbox, OpenMapTiles and Apple Maps’ vector maps all display the main station marker in the middle of 10 Fleet Place.

Neither OpenMapTiles nor Apple Maps display an entrance marker either at 1 Fleet Place or Ludgate Hill, nor any underground paths. It is therefore not possible from these renderings to use the map to navigate to City Thameslink station as you will be led to the wrong location.

Mapbox’s “street” style does display entrance markers, but stops rendering platforms and paths when the layer becomes -1, meaning that it is now unambigious that a user of the map will consider these as entrances to the office buildings they are situated in, as it is not possible for a user of the map to follow the connection to the main marker for the train station in 10 Fleet Place.

3. Nominatim

Nominatim has three entries for this station: it is importing both nodes tagged railway=stop and the node tagged railway=address. This may be an upstream issue as it seems unambiguous to me that railway=stop should be used for routing purposes and therefore seems out of scope for Nominatim’s purposes.

In any case, it uses the nearest named way to calculate the address, so:

  • railway=stop node 1272204251 (north). An address of Bear Alley is assigned automatically. This is not correct. The alley cannot be used to access the station.
  • railway=stop node 1272204271 (south). An address of Ludgate Hill is assigned automatically. This is correct.
  • railway=station node 3637195703. An address of Limeburner Lane is assigned automatically. This is not correct. The lane cannot be used to access the station.

I have since added the correct address for the station to node 3637195703 which will at least make this more correct for forward searching albeit not too useful for reverse geocoding.

It also appears that the forward search will get better if an upstream bug report is raised with Nominatim stating that `railway=stop` should not be used as an indication that a POI exists at that place, and therefore Nominatim should not import and calculate an address for these nodes. Is that correct?

4. Routing engines

I asked various routing engines to give me instructions to walk from St. Sepulchre’s Church (W31755869) to City Thameslink station (N3637195703). These all seemed to use Nominatim for forward address search but I presupposed that Nominatim accept that the railway=stop nodes should not return results and made sure the result I selected was for the railway=station node.

Valhalla, OSRM and Graphhopper all direct the user to half way down Limeburner Lane.

OpenRouteService directs the user to travel down Limeburner Lane and then to proceed to the entrance of the office building at 10 Fleet Place.



In overall summary, whether the mapping and tagging of this station is currently right or wrong, it would appear quite comprehensively to be at odds with what all of the above consumers of OSM data are expecting.

An additional comment was left on my changeset by @Cebderby:

For info, there are entrances at both ends, both more or less equal status and
mapped in some detail. At both ends, the entrances share parts of the
buildings with offices etc above, the station being underground. At the north
end, even the ticket hall is underground, under the Conductor pub. At the
south end, a central part of the ground floor of that building is dedicated to
the station.

The station node used to be at the south end of Fleet Place which was
definitely confusing, but the current mid-platform location is probably the
best we can do.

The background here is useful. But I would note that the status of the Ludgate Hill entrance would seem to be “higher” just by virtue of the fact it is the station’s official address. And the above survey has led me to conclude that the current location of the marker is not serving any useful cartographical, navigational or routing purpose that I can discern. That begs the question - by which metric is the current location considered “best”?

As for my own usage of the OSM data, I produce my own vector tiles and styles for those tiles, and will also be implementing a text search which integrates free and non-free data soruces, i.e. not relying on OpenMapTiles or Nominatim. So I believe if I can get some kind of clarity here I can at least make sure I draw an accurate and useful map and return accurate and useful search results, even if the open source projects I surveyed above can’t or won’t.

But I do think if I can get answers to the below questions which consider all of the points above, it would illuminate some latent disagreement which appears to exist between mappers and cartographers, which could therefore be used as a case study to improve the map more generally. The questions that come to mind immediately are:

  • The OSM wiki states that the station=railway tag can be on either a node or an area. It therefore seems to me like it would be acceptable per the guidelines on the wiki to delete the node 3637195703, moving all of its tags to relation 1572292. Compared to the node this has the benefit of making it abundantly clear that the tag serves no navigational or cartographical utility in this particular case, and that member objects of the relation must be used instead. Is there any reason why this should not be done?

  • If the above cannot be done: since the station=railway node must be placed between the platforms or rails, and the rails have layer=-1, it seems a three-dimensional interpretation of this rule is that the node must also be tagged with layer=-1 so that it is between the tracks, not above them. Is this generally accepted? Would / should this also communicate that it is not related to the building at 10 Fleet Place or would it be at risk of communicating the incorrect interpretation that the station is in the basement of 10 Fleet Place?

  • From the above survey it would appear that cartographical, routing and address interpretation is currently being done incorrectly and that there should be upstream bug reports raised with osm-carto, OpenMapTiles, Nominatim, Valhalla, OSRM, Graphhopper and OpenRouteService. Is anyone aware of such bug reports already having been made? If so, do they remain open and can we draw the maintainers’ attention to City Thameslink station as an example of a correctly mapped railway station with incorrect outcomes? Or, are they closed in a way which indicates that the maintainers of the named projects would all consider City Thameslink station to be incorrectly mapped?

  • As for my own usage of the data (and potentially for upstream bug reports), would the mappers consider the below to be a cartographically accurate and useful way to interpret railway tagging for an outdoor street level map and address search?

    • Find all relations which are tagged as railway=station, or who have a member node tagged as railway=station. Materialise POIs according to the following precedence. Once one rule has been matched, do not continue to process the relation.

      • At all member nodes tagged railway=train_station_entrance or railway=subway_entrance
      • At the centroid of all member ways tagged building=train_station
      • At the member node tagged railway=station
      • At the centroid of the relation

    • Find all ways tagged railway=station or building=train_station which are not members of a relation. Materialise POIs according to the following precedence. Once one rule has been matched, do not continue to process the relation.

      • At all nodes within the bounds of the way which are tagged railway=train_station_entrance or railway=subway_entrance
      • At the centroid of the way

    • Find all nodes tagged railway=station or building=train_station which are not within the bounds of a previously processed way. Materialise a POI there.

Phew, sorry that my first post is a bit of an essay, but I hope it is at least well-researched and thought-out enough that it leads to a productive discussion and a better map after some experienced mappers weigh in.

Cheers!

Mark

3

Hello, and thank you for trying to trying to improve OpenStreetMap in a “difficult” area. I have read through your post a couple of times, but unfortunately some of the words at the beginning had escaped by the time that I got to the end. Something else that also doesn’t help is that I’m not familiar with City Thameslink.

However, with those big caveats aside, there are a couple of general issues with mapping stations in general:

  • how to tag the various parts of the station in OSM so that they broadly reflect what is on (or under) the ground
  • how data consumers (maps, routers, etc.) can present that data to users in a way that is useful that makes sense.
  • each data consumer is often developed by someone who has a fierce mind of their own, so it really does make sense to address “how X should render Y” issues separately from “how to tag Y”.

Data tagging and data consumption are two separate issues and generally speaking there should be no “mistagging” to make things “easier” for data consumers. Part of the reason for that is that the “mistagging” that would be nice for data consumers who create maps is actually different from that that would be nice for those who create routers.

On the tagging of stations, all stations in London (and in fact in mainland GB) are nodes. This isn’t unusual in Europe and elsewhere - see also this previous long-running thread. With a station like City Thameslink, if you try and pick simple OSM geometry (i.e. not some sort of relation combining OSM objects) for it, a node in the middle of the tracks makes as much sense as anything else (as would, say, an underground polygon with the centroid in about the same place as the node currently is, but I’d argue that it’s not particularly better than a node).

Data consumers than have the job of figuring out what is mapped here and how everything relates to everything else. As you have noted there are a couple of top-level objects that they can look for: building=train_station is useful in many places, but not here, and railway=subway_entrance might also be useful.

Does this help? If not, perhaps ask further questions in this topic that are a bit more tightly focused around an individual issue? FWIW I create raster, vector and Garmin maps of this area, none of which are great but each of which is about as it can be due to Ian Gillan’s rule (“you can’t have everything louder than everything else”).

4

The documentation for type=public_transport relations indicate that it is expected that an element with a public_transport=station tag will be included in the relation. Granted it says it will be a building/area rather than a node, but from the limited list of suggested tags there doesn’t appear to be the expectation that all of the station tags will be transferred to the relation.

Based on the relation documentation it seems to me like some of the ticket machines etc. might also be candidates for inclusion if they’re within the station rather than on the surface.

If the station is under and not in 10 Fleet place then it seems reasonable to include a layer tag to indicate this.

5

level and/or location is the correct tag here. layer is only only used for the correct ordering of linear ways, especially roads and railways. It is a common misconception that layer can be used to impose an overall rendering order.

Interesting. That seems a non-standard tag interpretation. OSM Carto does not render platforms, pipelines etc. with location=underground.