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 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 x got redirected then x in turn got double redirected (as it had been redirected to x a little earlier). By now a bot has fixed the double redirect in x. 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.

So this means that raster tiles too would be generated based on inaccurate data? I doubt this is desirable. Don't we also need unsimplified data so that T155919 could be improved in some form?

In T309745#8366733, @Seddon wrote:

I think it's fair to aim for greater than sufficient :)

Sure. It's just that due to translation issues current wording seems less sufficient than previous one. I think return to status quo may be considered an improvement as long as there isn't a better solution.

In T309745#8366436, @CBogen wrote:

1. The easiest: keep wiki name at the beginning of the sentence, so result will be something like "English Wikipedia doesn't have articles named オジブワ"

... do you have any concerns with this proposal?

It looks to me that here too a multi-polygon is improperly built from multiple OSM objects. In case of this geomask example it looks that geometry from one OSM object is used for outer mask area, and identical geometry from another OSM objects gets treated as an inner area, without a cap between the two

This might be a special case of T312938: Multiple overlapping OSM area relations with the same QID are imported as a single polygon with unwanted hole(s).

Per merged task steps to reproduce is to submit/preview mapframe tag without width/height attributes. I remember that earlier an error message was displayed in place of mapframe tag in this case. Does this relate to recent work on Kartographer's error handling?

In T309745#8217467, @Nikerabbit wrote:

The project-localized-name-* messages are not designed to be used in a sentence context. They are not inflected and letter casing is not for the sentence context.

In T302861#8168121, @awight wrote:

Thiemo found /.../ Maki has dropped the outlines on symbol icons

I'm curious: why the entire .mw-indicators block or at least the individual #mw-indicator-<id> element wasn't wrapped inside .mw-parser-output? I've found it useful to target #mw-indicator-<id> in CSS as it allows me to adjust e.g. vertical alignment of an individual indicator without affecting alignment of other indicators inside the block, and it'd be nice to do so via TemplateStyles as well.

In T310289#8189152, @nichu42 wrote:

I followed this task due to my example https://de.wikipedia.org/wiki/Philippsruher_Allee not working. Should this be resolved now? Because for me it still doesn't work and I have no clue how to fix it.

Currently it doesn't work for me neither. I now created T316365 to gather issues on outdated data. Likely the cause for this example is the same.

In T310289#7992388, @JStrodt_WMDE wrote:

Potentially related to T292613?

I'm closing this as "Invalid" per my previous comment. This is about template design which is an on-wiki issue and also alternatives exist. Please reopen and respond if you disagree.

In T218097#8157470, @MSantos wrote:

.... a DC switchover that brought old and broken data in the codfw cluster

Currently the only OSM object referring x is this:
https://www.openstreetmap.org/relation/22494
https://www.openstreetmap.org/relation/27116
This relation is of type=network which isn't/wasn't supported.

In T313844#8119915, @JeLuF wrote:

Is there any reason why a circle in OSM can't be retrieved as a line, but only as shape?

As mentioned, T288400 has the hints. This behaviour is affected by patches referenced in this other task. Since last year geoline objects are queried from new database table which includes objects that are built from only relations. Geoshape objects are queried from different database table(s).

In T313844#8119095, @JeLuF wrote:

... the OSM relationship attribute in Wikidata is being used for Kartographer

It isn't and it's easy to find examples where geoshape/geoline object can be retrieved without Wikidata property, e.g. see item Q3743006 and its geoshape (from way/26900845). As far as I can recall, Wikidata ids were perceived to be more stable than OSM ids, for both ways and relations, and this is why geoshape/geoline queries don't rely on OSM ids.

In T311343#8117721, @Nikerabbit wrote:

If this task is only for consultation, then we can place it on a different column.