This was further addressed two years ago by the tech staff in 6098d3f.

In T228812#5368645, @MSantos wrote:

... we use Kartotherian, with mapnik + tm source and styles using CartoCSS and OSM database.

much shorter duration, like 7 days, might also be desirable

Aside: do you have links handy to 2-3 edits that show the above happening?

In T300942#8151596, @Sdkb wrote:

We made some adjustments to the wording, stored here (see the talk page), so I'm not sure there's all that much else to do.

Purge right was removed a few months ago in dcaf840.

I suppose to some degree at least Kartographer could draw from MultimediaViewer on how to handle long/stylized captions.

From merged task T271627#6738943:

FWIW, this is the work Maptiler/OpenMapTiles is doing for using Wikidata labels in the maps

This is likely due to the usage of width=100%

A map from Wikimedia Commons is NOT rendered in a browser for the property 'geoshape' with datatype 'Geographic shape'. There is a link to a Wikimedia Commons map instead of an image of a map.

it looks like only relations with specific tags are shown on the map

Some individual ways with QID also can be retrieved, including the Bryant Park example in the docs, but others currently don't work due to a regression, see T311203.

This makes me wonder, how did this came to be that these language names are maintained in multiple places, or is it even intentional?

I'm no longer sure why I figured that this one relates to the placement of neighbouring labels. It also occurs on tile boundry, and so the root cause is likely the same as in that other task. Closely packed labels might somehow contribute to this issue but I don't really know.

That's another case of T312938: Multiple overlapping OSM area relations with the same QID are imported as a single polygon with unwanted hole(s).

I notice that patches here make use the nullish coalescing operator (??). In some older browsers, possibly including some browsers of Grade A support, this seems to break most of site JavaScript.

Update: It was not the Name property. Gonna test now if it was the altitude or the other change

A working example is https://www.wikidata.org/wiki/Q122936541#P3896

So by "fails" you mean that mapdata isn't diplayed on a map next to Commons link in this Wikidata item page? To me it seems that item pages just aren't set to display this data (using mapframe or otherwise). If I'm not missing something in browser console then it doesn't try to load respective jsondata on this page nor on any other item page with P3896 statement.

What exactly is not working on Wikidata as expected? Where is this jsondata query used? Is there an example page?

Most tasks relating to these undeployed styles were closed/declined long ago so I'm closing this one too.

See T195318. We have been considering it might be better to simply ignore suffixed language keys.

I'm closing this one as originally reported examples work now. About the remaining regression there's T311203: Geoline referencing individual way(s) with a QID renders empty map.

Just recently we run into this again and fixed it in one place, see https://gerrit.wikimedia.org/r/901538. Is this the reason for the 400? I.e. is this a duplicate of T331977?

It seems this issue no longer comes up. Thanks!

I suppose it's still worth pointing out from original task description that full screen mapframe map (its dynamic content) wasn't broken. So what we might ask for here more specifically is to treat the data in more uniform manner, i.e. take either approach:

1. if this GeoJSON was invalid and shouldn't be expected to work then break the map entirely (also in full screen), or
2. if Kartographer can skip bad features in GeoJSON and still show the rest of the data then also add this capability to snapshot service.

In browser console these 400s have the following response: Cannot read property 'coordinates' of null. The map data for all of these three examples include features that lack geometry ("geometry": null) which I assume breaks snapshot image. So I suppose the image would appear if JSON data was cleaned up and these particular features were removed from it?

It doesn't seem to occur anymore. I suppose it was fixed as part of the work done in subtask. Please reopen if I miss something.

This doesn't seem to occur any more. Please reopen if miss something.

Assam example is mainly about a tagging error in source data, introduced a couple of weeks ago. I now fixed it (see OSM history), and tiles are expected to update within a few days, too.

In T333318#8906256, @akosiaris wrote:

In T333318#8900126, @AntiCompositeNumber wrote:

is there a specific reason the tile viewer at https://maps.wikimedia.org/ was broken?

Misconfiguration. This specific one is fixed, we still have a few pending items though.

And when Q16887380 got redirected then Q28813620 in turn got double redirected (as it had been redirected to Q16887380 a little earlier). By now a bot has fixed the double redirect in Q28813620. So was double redirect in a class tree enough to break the mw.wikibase.getReferencedEntityId call?

It looks this issue is there since 1.41/wmf.6 branch. Does it relate to T333160?

This should be fixed now. Around the time when this task was created some replica map servers were out of sync.

It looks this is actually specific to access=private key not amenity=parking. T334413 has an example where a garden is rendered the same.

In T288400#8614899, @MSantos wrote:

The only possibility I can see is to explore the imposm mapping and include more relation types.

The remaining regression here is that individual ways, not part of a relation, are missing via geoline.

In T310259#8609888, @Pginer-WMF wrote:

... the "edit language links" option, unlike other options such as "Translate" is not displayed for pages not available in other languages

I still wonder, shouldn't the links and functionality be the same as in old Vector, i.e. display "Add (interlangauge) links" link instead of "Edit interlanguage links", both when not connected to Wikidata and also when connected to Wikidata but without sitelinks in other languages (example)? This link opens the "Link with page" dialog (for logged-in users) instead of directing the user to Wikidata.

Oh, indeed, now that I look closer I realize that this outline is not for a tile. It's fixed to the map centre while tiles aren't, and it's only tile-shaped.

I wonder if this also concerns individual background tiles that recently got blue focus outlines (T315997). Individual tiles don't really have interaction either, do they? If so then these shouldn't be focusable either nor have focus outline, right? At first, till I found respective task, I suspected this new and confusing tile outline is some sort of bug.

Currently there seem to be some limited use for static snapshots if previewing in VisualEditor. That is if mapframe is generated via wrapper template and map is without JSON overlay. E.g. if I edit map in the following article then new snapshot is visible in preview:
https://et.wikipedia.org/wiki/Johan_Laidoneri_plats?veaction=edit
(If such map has JSON overlay and is edited in VisualEditor then just broken mapframe without any image is displayed in preview, partly because we wanted to avoid a defective snapshot preview getting cached in case autopositioning is used.)

Currently it shows "Edit language links" link also if article is connected to an item and if there are no sitelinks in other languages yet. Probably instead there should be a link to open Wikibase Client's link with page widget, the one that can be accessed via sidebar, also when item yet isn't connected to Wikidata. Is this covered in some other task?

In T288400#7597231, @MSantos wrote:

Querying from both tables requires a little extra work AFAIC. I'll investigate that.

In T312938#8569510, @thiemowmde wrote:

It looks like there is just no place in the relation tables to store the information if a hole in a shape is intentional or not.

In docs it says "Imposm uses geometry operations to verify if a member of a multipolygon is a hole, or if it is a separate polygon." This generally works fine, as long as data from multiple relations don't get mixed up somehow.

In T312938#8508538, @thiemowmde wrote:

... we shouldn't try to change it. Not with the remaining resources we have.

What about arrow key controls? In beta these appear to be still enabled. Also, if I enter full screen, then zoom/pan and exit full screen, then would it be possible to reset the position?

Tiles did look fine earlier when the data was served from eqiad but it seems old tiles resurfaced now after switching to codfw. I suppose the regeneration of all tiles was forced in eqiad but not in codfw, or something like that? @Jgiannelos could you please check.

I think the main difficulty with site is that it's designed to gather multiple geometries (areas, lines, points). So if it's supported then we should also make sure that it's indicated what its different parts actually stand for. The same applies to public_transport and street. In case of boundary and route we keep only the main geometry, respectively area or line, but for these other more complex relation types this probably wouldn't work as well.

In T313010#8502098, @JStrodt_WMDE wrote:

What type could the OSM object have so that it would show here?

For instance "multipolygon". A few hours ago someone changed given relation to this type once again. But this necessarily isn't solution as it can be changed again, also others may complain that Wikimedia user is tagging for the renderer. In this case it's difficult to agree what the proper tagging in OSM should be.

Possibly the fix is already merged, but not yet deployed, see T323307: Kartotherian autozoom not showing results on single points.

See also T209067: Provide way to check if reference to external data returns external data.

In the meantime associated OSM relation (r14300290) has been changed to unsupported type=site. So empty data is expected now.

Currently it reuses message for previous button text, but it'd nice to use different capitalization (lower case first letter) for a bracketed link, similar to other bracketed links that appear in e.g. recent changes or history pages.

In T322104#8392818, @TheDJ wrote:

I'm assuming it is just using one of the broken (out of sync) db nodes ? T321885

This corresponds to previous revision of respective OSM object. It was corrupt briefly around September 27th, see https://osm.virtuelle-loipe.de/history/?type=relation&ref=192800.

My understanding of how this all works is vague. If simplified data is kept in addition to unsimplified data then I suppose I got the wrong idea what this task is about.