Open 1ec5 opened 1 year ago
Related #planetiler Slack discussion here: https://osmus.slack.com/archives/C031V9E9RMG/p1688647853439579
To fix this problem, additional code would be needed here to differentiate routes at the state level: https://github.com/ZeLonewolf/openmaptiles/blob/master/layers/transportation/update_route_member.sql
That’s probably a good thing to polish up in the long term, though increasing the maximum concurrency would also work around the issue, functionally speaking.
Greater concurrency would prevent this particular label from appearing until a higher zoom level. If that’s a problem, we could introduce a redundant layer that only includes a few shields at a time, as a backup.
Please confirm whether this issue is resolved now!
That segment has up to route_8
now in the tiles, and I see appropriate shields when I crank up the concurrency in the shield expression.
The tilejson implies that route_19
exists somewhere, have fun finding it.
That segment has up to
route_8
now in the tiles, and I see appropriate shields when I crank up the concurrency in the shield expression.
Cool, now we just need to increase this literal that limits the shield image expression to a six-way concurrency:
This eight-way concurrency is only a block long so it doesn't really seem like a major issue to me if a few of the shields aren't included (as long as they are properly sorted by importance). With such a short concurrency, the missing shields will display nearby and it will be relatively clear how each route connects. Are there any examples of actual signed seven or eight-way concurrencies of significant length? If so I could see a compelling argument for increasing the limit.
as long as they are properly sorted by importance
That’s another issue: a scenic byway is being prioritized over a truck U.S. Route and the most important state route in the state. Fortunately, I don’t think increasing the concurrency limit in the expression has much of a downside. Any increase in the style’s size would be massively outweighed by the label code anyways.
Are there any examples of actual signed seven or eight-way concurrencies of significant length? If so I could see a compelling argument for increasing the limit.
Here are some more substantial seven-way concurrencies in Georgia. I haven’t checked whether they’re all fully signposted, but they’re all in ref
rather than unsigned_ref
:
Moreover, even if a route relation is tagged unsigned_ref
, it still takes up a slot, potentially crowding out a signposted route.
[^grip]: Governor’s Road Improvement Program (GRIP) corridors are modeled as unnumbered route relations; nevertheless, they are exposed in OpenMapTiles output.
That’s another issue: a scenic byway is being prioritized over a truck U.S. Route and the most important state route in the state.
Now that all the routes are in the tiles, it looks like SR 3 is being properly prioritized before the scenic route and the truck route. So that's good at least.
Fortunately, I don’t think increasing the concurrency limit in the expression has much of a downside
The downside I see is just that sometimes eight shields won't fit in the available space and MapLibre will instead show no shields. Of course we already have this problem with a limit of six, but it gets worse the higher the limit. Ideally we'd be able to progressively truncate the shield string so if 6 didn't fit we could show 5, then 4, then 3, etc. I'm not sure if that's possible, but it sounds like your backup layer idea would have a similar goal.
The downside I see is just that sometimes eight shields won't fit in the available space and MapLibre will instead show no shields. Of course we already have this problem with a limit of six, but it gets worse the higher the limit.
Perhaps, but this downside is no more significant than the concurrencies themselves.
Ideally we'd be able to progressively truncate the shield string so if 6 didn't fit we could show 5, then 4, then 3, etc. I'm not sure if that's possible, but it sounds like your backup layer idea would have a similar goal.
The fallback layer would be the way to progressively show shields in a concurrency. I’ve experimented with something similar for #793, but the shield concurrencies should be more straightforward to accommodate than road labels.
If we’re really concerned about clutter, I think one fallback layer would be enough. Six layers (representing a factorial of concurrency cardinality) would probably be overkill and possibly counterproductive. The user needs to be able to trust to some extent that we’re showing all the shields we can. If there are too many fallback layers, the user needs to keep zooming in further to verify that the map has fully expanded all the labels.
This query turns up 1,698 roadways that are part of five or more unique route relations of numbered highway routes.[^numbered] The vast majority of them are in the Southeast:
Cincinnati’s Central Avenue is the most highly concurrent roadways in these results. Tied with it is a roundabout in Augusta, Maine that should probably be refactored so that each route only traverses part of the roundabout.
[^numbered]: We don’t show a shield for every numbered route; conversely, not every shield we show is for a numbered route.
In Downtown Cincinnati, Central Avenue between 5th and 6th Streets carries U.S. Routes 22, 27, 42, 52, 127, U.S. Route 50 Truck, and Ohio State Route 3 – in that order. This seven-way concurrency is apparently too much for OpenMapTiles, which can only handle up to a six-way concurrency: openmaptiles/openmaptiles#1128. Americana shows all the shields except for U.S. Route 50 Truck.
Once changeset 138,168,933 makes it into the tiles, there will be an eighth route to display along this block: the Ohio River Scenic Byway. #893 is adding a shield for that route. Presumably it would go missing at 5th Street and pick back up on the 6th Street Viaduct.
Blocked by openmaptiles/planetiler-openmaptiles#95