[FEATURE] Subway lines (with offsets)

[nvkelso]

Is your feature request related to a problem? Please describe.

When designing a transit map it's ideal to have subway lines (and sometimes other lines like light rail) considered as a group along a way but offset from each other for visual display, by zoom. Right now the lines stack on top of each other (because that's how the OSM data comes in) instead of being offset for visual display per zoom.

Describe the solution you'd like

The older Maps.ME open source project has a good tool for generating offset transit lines:
https://github.com/mapsme/omim/blob/master/docs/SUBWAY_GENERATION.md
and
https://github.com/mapsme/subways

The downside of this tool is it had to be run per city instead of globally. (When running globally such algos can get greedy.) Ideally this can be run globally (or for whatever bbox and planet extract is input), though.

Describe alternatives you've considered

n/a

Additional context

Here's what this looks like in San Francisco, California in Organic Maps (a free continuation of original FOSS Maps.Me codebase):

NOTE: In this case station "pills" look like they are also being generated, which is something that MapboxGL to my knowledge doesn't know how to generate. However, you could probably trick it by calculating width and angle for each station node across the offset lines?

[bdon]

Do we want to use OSM as a datasource or something like aggregated GTFS via transitland?

https://www.transit.land/map#10.76/52.5183/13.3067

[msbarry]

So in this case what do you think we would have to do ahead of time vs what could the client do at render time? It seems like at one extreme we could have planetiler place the stylized subway lines at fixed points on the ground, or the other we could have planetiler pass along an "offset index" or something to maplibre to use with its line-offset property - although that doesn't handle splits/joins/turns/station angles ...

[nvkelso]

If you want smoothly interpolated line offsets between tile integer zooms, you need to include lines & their offsets as metadata on a single "railway" geometry feature. As you point out MapLibre / MapboxGL only kinda know how to render this properly (splits/joins/turns/station angles), though.

The poor man's version (so each line get's its own offset geometry feature) would probably render more reliably in current off the shelf graphics software.

[nvkelso]

Do we want to use OSM as a datasource or something like aggregated GTFS via transitland?

I'm a big fan of Transitland.

But most the subway (and railway) information is already in OpenStreetMap... so I'd start with OSM first.

The nice thing about OSM is it already includes the geometry, and the relations. While GTFS doesn't require sending down the geometries so you often have to backfill them.

[wipfli]

https://www.sbb.ch/de/freizeit-ferien/destinationen/staedte-laender-europa.html

[1ec5]

Possibly of interest: the QLever team has demonstrated generating transit overlays using SPARQL queries on QLever and various postprocessing steps that would definitely be more appropriate to Planetiler than anything on the client side.

[msbarry]

Cool - looks like there's an online demo here: https://loom.cs.uni-freiburg.de/global#subway-lightrail/geo/15/48.782366709946764/9.185643196105959

The transit tiles are served as mvt's, here's an example: https://gist.github.com/msbarry/6d7c306b137d0f37ace20b68671c693f

So it looks like they actually render lines and stations at pixel locations in the tile that change by zoom level. IMO that's a very "raster" way to do it that will lead to the results jumping every time you scroll into a new zoom level instead of the smooth transitions you expect from vector tiles.

I'm wondering if there are better ways to encode this data in vector tiles that let the client smoothly render these without needing to fall back to this raster-like approach?

[1ec5]

The colored lines can swap places as you zoom in, which would get even more confusing if it somehow supported incremental zoom. I wonder if this is a fundamental constraint of this kind of cartographic treatment though.

[msbarry]

Apple maps seems to make this work for vector maps. The lines appear to follow their geographic coordinates, but when you zoom out far enough that they would overlap they keep a minimum pixel offset so that they don't overlap. It's almost like they "collapse carriageways" but retain an offset and the client knows how to render a line with a minimum pixel offset to either side. The order of lines can switch when you zoom in, but that's the only abrupt change I notice. I think something like that would need some kind of new support in maplibre

[nvkelso]

Yes, good sleuthing! It's definitely the more "correct" solution but requires complex render support. So a 80% solution that's workable with existing tools would be valuable.