| Urbanecm | |
| Jul 23 2019, 10:34 PM |
| F34947013: San rancisco.png | |
| Mar 28 2022, 9:15 PM |
| F34947017: Menlo Pa.png | |
| Mar 28 2022, 9:15 PM |
| F29854132: image.png | |
| Jul 23 2019, 10:34 PM |
Hello,
Czech city "Kladruby nad Labem" doesn't have its full name in Wikimedia Maps, see https://maps.wikimedia.org/#11/50.0560/15.4447 and screenshot below.
The circled "Kl" is for that city. This is zoom-11 specific issue, it's displayed correctly in zoom 12. Maybe maps should be regenerated?
Thanks,
Martin
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T205329 Labels are sometimes truncated on maps | |||
| Open | None | T228812 Place names get cut off and unreadable on tile boundary |
Specifically, the problem is with those two tiles: 1111/694, 1112/694.
OSM does on-demand tile rendering and makes it easy to request rerendering of dirty tiles; do we have something like that? Or, where can I learn something about our map rendering architecture? The newest documentation I could find is mw:Wikimedia Maps with updates to December 2018 and some links to various more-or-less outdated pages which link to other more-or-less outdated pages.
The technical wiki page can be found here https://wikitech.wikimedia.org/wiki/Maps
Also, about the rendering infrastructure, you should consider that we use Kartotherian, with mapnik + tm source and styles using CartoCSS and OSM database.
In ticket that I merged this was apparently a short term issue that disappeared when neighbouring tile also got updated.
In case of "Kladruby nad Labem" from task description intrestingly the issue is still present after two years. In this particular case, is this due to poor caching mechanism, or is the issue perhaps not only due to different age of neighbouring tiles?
The reason for that is because the MVT buffer of the adjacent tile (the "empty" one) still doesn't get the label POINT, therefore mapnik cut the label in one tile but not in the other.
I've recently deployed a fix [1] to that for Tegola, which is also applied to Tilerator and still didn't change anything.
The solution would be to increase the buffer/bounding box, but this has performance implications that can be impractical for Tilerator.
[1] https://github.com/kartotherian/osm-bright.tm2source/pull/76, which is deployed as of Today. I'll regenerate these tiles to test this hypothesis.
Found another example of this, in case the extra data helps -- thanks @MSantos and @ECohen_WMDE for pointing me to the right task. (Moved here from T228612.)
https://maps.wikimedia.org/#12/37.6014/-122.3192
This doesn't seem to be fixed yet, I still can find multiple examples of "New Y[...]" City or "[...]antic City", which, despite the map used mostly to put things on top, are very noticeable issues.