Additional note: @tstarling said on Mastodon that this is most probably just T344233 manifesting for old images that haven't yet been purged.

@TheDJ, thanks for confirming the issue. Is there a way to use your shell trick to determine which images would need purging? (For instance, the next image in the sequence also has the same issue.) I think it's a UX issue if people who don't know the purging workaround will get broken images when they click on the perfectly okay-looking thumbnail links on Commons.

Let me demonstrate how it looks on my end.

@Aklapper: Hmmm. I actually have no idea what the expected protocol for this is. I created this task because I wasn't aware of T232984. It might be better to consolidate both into just 1 ticket, probably the earlier one since that was what prompted this ticket.

I can't think of any items right now that need to have millimeter-precision coordinates. But there are certainly objects that can have sub-meter precision. For example, there are at least a couple of geodetic survey markers in Finland (Q10684553 and Q10682441) that have a stored precision of 0.000001 (decimeter-level). And somebody could survey the locations and coordinates of the existing Arago medallions found in Paris that marks the Paris meridian and add them all to Wikidata and these should have sub-meter precision. Sure, these coordinates may become outdated because we are assuming the WGS84 datum and plate tectonics is a thing, but these coordinates could be qualified with a point-in-time qualifier.

Please do not just change the COORDINATE_PRECISION value. The coordinates are stored in Wikidata together with a precision value. These precision values can represent decimal-degree precision (like 0.01 for ~kilometer-precision or 0.00001 for ~meter-precision or 0.00000001 for ~millimeter precision). If you really must round down, then please round down considering this stored precision value and not using a global constant value.

I have filed T232984.

With the debug=true, I can move pages as long as I am able to submit the form before the namespace and title form fields disappear.

Hmmm. When I add the debug=true parameter to the URL, the problem disappears and there are no errors in the JS console.

Also, at zoom level 2, most of Eurasia and northern Africa is "flooded". I am guessing that whatever is causing the garbage tiles at zoom level 9 (and 10), is also causing this ocean/water polygon error at zoom level 2. See attached screenshot for the rendering error.

As mentioned on Facebook, I agree that the tool should retain grouping_property to make using this tool easy for simple cases. But for more complex types of grouping, I think having a separate field like grouping_sparql (that will be used in case grouping_property is not present) would be nice.

I'd like to note that allowing access to third-party map tiles should also have the consent of the third party. Usually requests like this is meant to add the OpenStreetMap Standard map style, but OSM explicitly forbids heavy usage of this map layer due to limited resources. I guess this might be OK for Wikivoyage, but I expect this will not be allowed for Wikipedia due to the heavy traffic involved. Remember that one of the reasons why WMF is rolling out its Maps service is to remove the burden of the heavy use of OSM's map tiles.

Sorry, there is no consensus for this renaming.