Support passing route relation members & attributes to vector tiles

[jeffreyameyer]

What's your idea for a cool feature that would help you use OHM better. Pass type=route relations through to the vector tiles to make their relations members available for styling using relation attributes.

Common practice in OSM & OpenRailwayMap is to store style-impacting attributes in route relations. This enables changing of attributes without necessarily requiring duplicative and overlapping way geometries. OHM does not currently pass type=route relations through to the vector tiles, thus is hiding important rail-related information that it should include.

Current workarounds Tagging at the route member level, and duplicating & overlapping geometries, which is undesirable from effort, data representation, and difficulty perspectives.

[jeffreyameyer]

Related: #439, #440.

[jeffreyameyer]

@dan - any update here?

[danrademacher]

@Rub21 and @batpad can you take a look at this?

Is this easily done? Or tied up with larger question of how we handle relations in the vector tiles more generally?

If the former, let's do it! I assume then there might be style changes that would need to happen to handle relations not currently in the tiles.

If the latter, we need to find a way to break that larger issue down and make some progress

[Rub21]

From https://github.com/OpenHistoricalMap/issues/issues/439#issuecomment-2010500295, I have been adding some relations that are type=multilinestring and type=route in the Vtiles, in a layer called transport_lines_relations. We cannot add to the existing transport_lines layer because of the conflicts, and also I have included all the attributes that are in transport_lines to make it more similar and maybe not repeat my style code."

[jeffreyameyer]

@Rub21 - can you point @flha127 to an example of these relations in the vector tiles?

@vknoppkewetzel - heads up that these may need to be styled soon.

[danrademacher]

See examples in this ticket comment: https://github.com/OpenHistoricalMap/issues/issues/439#issuecomment-2010500295

[danrademacher]

So these are ready for @vknoppkewetzel to style

[vknoppkewetzel]

Okay I am getting to this now.

How were folx envisioning this getting styled? some "route=train" (as example) overlap same areas as "usage=rail" Should I just style all train styling the same as the general rail styling? As an example

[jeffreyameyer]

@flha127 @luke04 @natfoot - any thoughts here? Anything @vknoppkewetzel should look at?

[1ec5]

This is https://www.openhistoricalmap.org/relation/2738230 by the way. It isn’t a great example, since it lacks dates, but relations with dates are currently broken due to #761.

A stylesheet can only style a feature based on the properties of that feature, not an arbitrary feature in another layer that happens to overlap it. In this case, all you can do with this transport_lines_relation layer is label railways by name or mname (apparently one or all of the member ways’ names?).

I think we need to take a step back and think through the structure of these relation-based layers. OpenMapTiles’ approach is worth a look. They have a transportation_name layer for all thoroughfares, not just route relations. Stylesheets are expected to plot the paths of roads and railways using the transportation layer but label them using the transportation_name layer, so both layers would need some basic properties like start_date and name. The transportation_name layer also needs some non-name-related properties such as class so that the stylesheet can filter them consistently. These properties would come from a route relation, falling back to an individual way if it isn’t part of a route relation. Does that seem feasible? The current approach of a relation-specific layer could also work too, but the downside is that a stylesheet would have to style railways twice, once per layer, and accept that some labels might overlap or be filtered incorrectly.

OpenMapTiles also coalesces all the concurrent route relations into a single LineString feature with numbered properties such as route_1_name, route_2_name, etc. This enables a stylesheet’s individual layout properties to consider all the routes that affect a stretch of railway or roadway simultaneously, rather than in isolation. However, it could get massively complex when considering all the route relations from different time periods that need to contain the same member ways. I suppose it would be OK to avoid the issue of concurrencies for now, just to get something usable.

/ref https://github.com/OpenHistoricalMap/issues/issues/440#issuecomment-1990684305