Thu, Nov 30
This makes me wonder, how did this came to be that these language names are maintained in multiple places, or is it even intentional?
Mon, Nov 27
Wed, Nov 22
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.
Mon, Nov 20
Thu, Nov 9
Mon, Nov 6
Oct 29 2023
Update: It was not the Name property. Gonna test now if it was the altitude or the other change
Oct 25 2023
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?
Oct 20 2023
Most tasks relating to these undeployed styles were closed/declined long ago so I'm closing this one too.
Oct 12 2023
See T195318. We have been considering it might be better to simply ignore suffixed language keys.
Sep 28 2023
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.
Aug 5 2023
Jul 16 2023
It seems this issue no longer comes up. Thanks!
Jul 14 2023
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:
- if this GeoJSON was invalid and shouldn't be expected to work then break the map entirely (also in full screen), or
- if Kartographer can skip bad features in GeoJSON and still show the rest of the data then also add this capability to snapshot service.
Jul 6 2023
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?
Jun 23 2023
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.
Jun 7 2023
May 19 2023
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?
May 2 2023
It looks this issue is there since 1.41/wmf.6 branch. Does it relate to T333160?
Apr 19 2023
This should be fixed now. Around the time when this task was created some replica map servers were out of sync.
Apr 10 2023
It looks this is actually specific to access=private key not amenity=parking. T334413 has an example where a garden is rendered the same.
Mar 19 2023
Feb 14 2023
The remaining regression here is that individual ways, not part of a relation, are missing via geoline.
Feb 13 2023
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.
Feb 7 2023
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.
Feb 3 2023
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:
(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?
Jan 31 2023
Jan 30 2023
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.
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?
Jan 29 2023
Jan 25 2023
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.
Jan 9 2023
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.
Jan 5 2023
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.
Dec 13 2022
Dec 6 2022
Possibly the fix is already merged, but not yet deployed, see T323307: Kartotherian autozoom not showing results on single points.
Dec 4 2022
Nov 21 2022
In the meantime associated OSM relation (r14300290) has been changed to unsupported type=site. So empty data is expected now.
Nov 18 2022
Nov 17 2022
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.
Nov 14 2022
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.
Nov 4 2022
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?
Nov 3 2022
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.
Oct 20 2022
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
Oct 19 2022
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).
Oct 6 2022
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?
Sep 30 2022
Sep 28 2022
Sep 26 2022
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.
Aug 26 2022
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.
Aug 22 2022
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.
Aug 19 2022
Currently the only OSM object referring x is this:
This relation is of type=network which isn't/wasn't supported.
Aug 4 2022
Aug 1 2022
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).
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.