Rotate stations

[der-stefan]

Railway stations could be rendered more intelligent by rotating the symbol according to the rails. Here is an example:

[max-dn]

Is it worth 15 minutes preprocessing after each update of the database?
I think we could rotate the station in the direction of the next some rails, but that needs some expensive geometric queries for each station to find the rails and some cheap queries to get their direction...

[der-stefan]

Yes, 15 minutes for a worldwide preprocessing is fine. There could be a problem when multiple stations are above each other in different directions (I can't give an example). A terminus ("Kopfbahnhof") could make trouble, too.
Perhaps we could make it similar to the mountain passes: Save a direction in the database. And for further runs we don't process the direction again, if it is already in the database. (Thinking about importing minutely diffs again...)

[severak]

(another workaround is to use circles for station symbols)

[max-dn]

I tested some stations in Erlangen and Paris with this script... Paris because there are real terminal stations.

The distinction between terminus and "normal station" works, but the layers make problems. Stations are mostly at layer=0, their rails may be at layer=-1 like here. I could handle that by taking the next rail which is at the same layer as the station and if that fails taking just the next rail. That leads to the next problem: In Fischbach, Sandreuth or Dürrenhof we have a station at layer=0 and rails on a bridge. The next rail on layer=0 is a part next to the bridge and for this rail this station seems to be a terminus...

[der-stefan]

Wow, good work so far. I can see the problem with short bridges. But should a terminus really be turned by 90 degree? Perhaps it is fine to make no distinction...

By the way: Subway stations should be excluded.

[max-dn]

But should a terminus really be turned by 90 degree?

For real terminal station (a lot of rails and a building crosswise at their end) I think it would be nice. But in OSM a lot of them are not mapped at the building but in the middle of the platforms (1 2 3). That's why I went to Paris ;)

Perhaps it is fine to make no distinction...

Jep, I think it's better and solves the problem with bridges. It's unlikely that we find a station where the station has a very different direction than the rail next to the bridge. Rails ar not very curvy.

[max-dn]

Demo without terminal stations and subways

We have still to calculate with railway=subway, because some railway=station are not tagged as subway, but belongs to a subway rail

BTW: What about railway=halt? (Node 27563383)

[der-stefan]

If some stations are tagged wrong or incomplete, it is not the subject of our renderer to try to fix the error. Perhaps our map style even animates people to correct those mistakes... (It would be important to keep our database more up-to-date... Damn... ;-)

railway=halt are interesting for us, too. We could calculate and save the direction, but render halts differently (lighter, only starting from higher zoom level).

There is a problem with Neuperlach Süd and I can't see why. There is no rail on a different layer going from north to south.

[max-dn]

Neuperlach ist rotated in direction of a historic tram ... With "railway IN ('funicular', 'light_rail', 'monorail', 'narrow_gauge', 'rail', 'preserved', 'subway')" Neuperlach is in direction 144 (SE).

I took every kind of rail because I found some stations along abandoned rails. We should be more restrictive, set an error return to NULL and set just sqares for stations without known direction.

An other problem was fixed: Stachus got its direction from a rail which is in a tunnel on the surface. Now we interpret tunnel=* as "not on layer=0" and Stachus is in direction 128.

Examples without historic rails and tunnels

(A dry run (just select no update) of all railway="station"|"halt" needs 10 Minutes for 115000 Nodes. I think we can do it in 15 minutes also with halts)

[der-stefan]

What about sorting the rails to look at by their importance? In SQL: ORDER BY (CASE WHEN railway='rail' THEN 5 WHEN railway='monorail' THEN 4 WHEN railway IN ('funicular','light_rail') THEN 3 etc......

[max-dn]

What about sorting the rails to look at by their importance?

I thing sorting by distance is the better way. In most cases there are 1..3 rails nearby and it's hard to decide whats more important. A railway=light_rail in 20m distance or a rail in 10m...
in the test region it looks good, some ugly red labels show funny railway=halt near abandoned rails and something like tram_stops tagged as stations. These "halts" are also shown on osm carto, so its ok...

About rendering:

Maybe we have to change the icons later, i'm not very good in painting 10x10px... rw=halt are rendered in Z14-17 and are slightly smaller (10%) than rw=station, label size is the same. stations without rotation get a square label like before.

[der-stefan]

In your test there is a good example of the wrong decision of a rail track: Erlangen-Bruck gets rotated like the branching rail. The main track goes from north to south. All the rest looks phenomenal! About the icons: We could change those icons later - creating pixel detailed icons is what I like a lot! :)

[max-dn]

Short rails were ignored at the limit was too high for the 2 rails next Erlangen Bruck. Now it's 50m and Erlangen Bruck hast direction 9, same as the next station "Paul-Gossen-Straße".

I made a pull request, let's see what happen ;)

[der-stefan]

Great work, @max-dn! Your pull request was merged and is online now. Btw: Processing time was 8 minutes.