At zoom level 12 and lower, motorway links are not rendered in Wikimedia maps. Compare, for example:
Screenshot with missing motorway links circled:
This probably just needs a CartoCSS change to make sure it gets rendered at lower zooms.
The decision on when to stop rendering links is a tough one. Because I was finding the same issue, I changed the min zoom for links to z10 in brighmed, which will fix this as part of T153282: [epic] Migrate to a new vector tile structure.
The downside to decreasing the min zoom is you get more little blobby artifacts at junctions, which is why you don't want to render links all the way to z5.
To solve both problems would require some form of road generalization for medium-low zooms.
Just to clarify, this is still an issue with the current map styles (but would probably be easy to fix there as well).
Related discussion about a similar issue with OpenStreetMap Carto: https://github.com/gravitystorm/openstreetmap-carto/pull/2601
I've suggested updating the existing styles in https://github.com/kartotherian/osm-bright.tm2 for this as a good task for @MSantos to get started working with the kartotherian codebase.
We'd have to decide if we're going to fix issues in our osm bright fork that were fixed in the new style work that isn't being deployed.
We should probably first find out what type of changes we're allowed to deploy. This one would probably involve a regeneration of vector tiles, at least on the relevant zooms, because it'll likely need changes to the tm2source.
@Pnorman, good point—we probably don't want to get into changes of this nature at this juncture. I'll try to find a suitable task or two limited to changes in Kartographer and/or Kartotherian proper in the meantime.
Even though this task needs to be reevaluated, the provided examples don't have the issue showed with the print screen when I am accessing.
The data has likely changed there.
https://maps.wikimedia.org/#12/49.1743/-122.9610 exhibits the same problem with the ramps near https://maps.wikimedia.org/#16/49.1776/-122.9615
It has been decided that because we don't have a dedicated user-focused product manager for maps changes we can't make material product changes for maps, so the new styles work will not be deployed.
No - stalled is waiting on someone else before the work can be done. Here, the work has been done but it's been decided not to merge it.
That distinction is internal politics to me. Effectively, i'm waiting on a product manager to be made available to do his work.
The problem is valid, the ticket is valid and the ticket will be refiled when closed (pretty sure). That a TEAM declines it, doesn't change any of that does it? Most tickets aren't actively being worked on by WMF. If we start declining all tickets that WMF doesn't want to actively work on, we'd be left with pretty few tickets and a whole lot of lost history (and little to do for volunteers). Remove the team tag perhaps ?
Or maybe we should create an 'awaiting next card style update' tracking ticket that we can block this ticket on.
The problem is valid, the ticket is valid and the ticket will be refiled when closed (pretty sure). That a TEAM declines it, doesn't change any of that does it? Most tickets aren't actively being worked on by WMF. If we start declining all tickets that WMF doesn't want to actively work on, we'd be left with pretty few tickets and a whole lot of lost history (and little to do for volunteers). Remove the team tag perhaps ?
This is different that a ticket where no one is working on it. Those are valid. This is a ticket even if someone did work on it the WMF would not deploy the work.
The decision has been made not to deploy this enhancement request, even if someone did the work. In this case, someone has done the work, as part of a larger project. That could change in the future, but that is true of all declined tickets.
This would be different for a bug, although it still might run into issues depending on the changes needed.