The status of this task is doing, but it's not clear what's happening and how someone can help.

It's worth noting that MapLibreGL JS suffers from the same problem as Mapbox GL JS in that it does not support all scripts. In particular, Bhramic scripts are not supported.

Also seeing this in kartotherian/babel

This was to be done in the new style stuff, which is no more, so it's now an issue again.

New style stuff.

Confirming as still an issue.

This was part of the new style work which isn't getting done.

What version of mapnik are you trying to build node-mapnik 3.7.2 against?

It's not an issue in osm-bright.tm2source. I did see some other cleanup issues there which I've filed.

My inclination would be to add an option to Kartotherian to bake a scale into the images. There are a few reasons for this

This is an error from a mismatch between a node-mapnik compiled binary and the mapnik library it's linking against. The only Mapnik we should have is the 3.5.x version we compile.

I'd rather not drop XML support, because it's still used by some people to develop tiles, and very important for writing testcases.

Yes - which of the two lines is the issue about? They're from different sources.

@MaxSem which line is this referring to?

The collab team added maps-specific tests. More are always good.

This should be re-checked to make sure it's still present.

We haven't seen this as a load problem, it would add complexity, and it would bypass the varnish caching layers which is a potential performance issue. If anything feels strongly that this is a good idea they can re-open and rediscuss.

Given the questions above and the lack of interest in it, I'm going to close it. If someone wants it, they can re-open, although it's unlikely to be worked on at the WMF.

I'll check if we've got this in production and close if so.

We still have XmlLoader, so as long as we have that we need to keep using xmldoc, so we're keeping this open.

This is still the most common message in the logs.

This would still be nice to have, but we're not likely to code it anytime soon.

This is most likely a data issue, so tagging it accordingly. It still needs investigation.

tiles.wmflabs.org isn't running kartotherian, so we're untagging it. It's mainly a community relations item.

This would be a big user-facing change which we would not deploy since there isn't a product manager for maps.

We don't want to use the internal endpoint since kartotherian allows arbitrary queries. We may want to set headers because it is essentially acting as a proxy, and throttling should be per user of kartotherian, not for all of kartotherian.

We allow fairly arbitrary queries, so we shouldn't use the internal endpoint.

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.

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 ?

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.

just pinging @CKoerner_WMF because I'm going to be closing the parent task and we're likely to get questions then.

@Pnorman TTBMK, the idea was to ensure that the new Cassandra cluster was setup to use the exporter instead of cassandra-metrics-collector (Graphite).

We're not deploying the new style work, but I'm not closing this as declined. This is a clear bug in osm-bright.tm2 and/or osm-bright.tm2source, and the style attempts to handle it correctly, it's just buggy.

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.

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.

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.

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. The same reasons would apply to hillshading implemented on the existing style.

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. The same reasons would apply to topographic feature enhancements implemented on the existing style.

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.

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.

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. This includes the borders work. If the borders work were separated from the new style work, it would still be subject to the same restrictions, so we wouldn't deploy it by itself either.

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.

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.

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.

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.

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.

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.

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.