@TheDJ noted. It's up to the WMF to decide whether they're going to support users and improve the product in obvious ways such as the above; or whether they're just going to sit back and count their astronomically huge pile of money. It's really only all the users and all the editors who are currently being ill-served. it doesn't take much imagnation to see that wikimedia would be better served by appropriately detailed maps, and so the question is, why is this a backwater for WMF? I live in hope that WMF, replete with a plurality of communications managers, gets back to us on this one.

Can you describe any use cases, @Pikne, which are frustrated by the normal convention of showing progressively increasing amounts of information as the resolution of the map increases?

In T289101#7290502, @Pikne wrote:

While Wikimedia maps are most commonly used as an outline map on which markers and particular line or areas are highlighted. For the latter purpose different styles are better suiting, i.e. syles that aren't as overcrowded with information and where colours aren't as contrasting.

If I'm going to validate scheduled monuments in Scotland (8,086 items), I need to be able to see archaeological sites.

I'll end, for now, with: as I've spend many hundreds of hours over several years curating the geocoded items for a country - Scotland - WMF might want to reciprocate by providing maps fit for purpose. The current map set is demonstrably not fit. Boundaries, buildings, landuse, peaks, please.

Are my Scottish items with coordinates in the correct P131 area?

Bergen, zoom 11. Wikidata has 1,000s of hills & summits. use case: show them so that we can check whether WD coordinates point to the peaks.

Victoria Falls. The railway is one of the defining features, as it goes over the gorge from Zambia to Zimbabwe. Users can almost see it on the WMF map, if they know what they're looking for.

Downtown Lusaka, Zambia

Edinburgh: Look - no castle! Mostly, no buildings. Unrecognisable. Entirely useless for my listed buildings use case.

Noting T288897 ... if WMF maps are to be sorted out, it is reasonable to consider whether it is now time to learn from map specialists such as OSM/ACME and implement the easily available and obviously useful map detail which they supply.

in fact, it's more than a refresh issue; WMF choose to use maptiles which filter out most of the useful information. Compare WMF and OSM at the same resolution for Haroldswick, in the Shetlands:

With any luck these illustrate the issue, although clicking on https://maps.wikimedia.org/#9/45.7004/10.5139 and zooming around shows the problem.

It's been noted on WD:talk that there's no consensus to do this, and so a technical implementation is premature.

link this to https://phabricator.wikimedia.org/T185476 ... both presentation and specification of the title within the SPARQL could be improved. Arguably per T185476 and its children, there is considerable room for improvement of, clarity of configuration of, and documentation of charts. Right now it's a dark art.

I hope 'push[ing] it up the priority list' is not the case. The RfC would need to attract consensus, or even interest, first. What appear to be OWNer-ish facets of signed statements seem antithetical to WD's openness, at least, to me.

This issue is still occurring. We still get different answers depending on which report server we hit. That is clearly suboptimal. Could we please have an update on action being taken, and/or the timetable for proposed action, presuming that action will be taken. @Lydia_Pintscher

It may or may be not useful to note that Quickstatements, when used in (server-side) batch mode to create new items, creates duplicates at the rate of about 10% of the items created. QS run locally from a browser does not exhibit the problem.

Magnus was running 2 quickstatement batches at the time he got the above. My experience of this issue is that it'll sometimes happen when I have a QS or two running, but has never happened absent a QS.

UI which has the capacity to mangle input and demands that the user must do something beyond their simple input of the date, is unambiguously, categorically and unimpeachably broken. It should be considered as such.

We could maybe have a preference, such that the user can specify whether they want date parsing to be based on an assumption of MM/DD/YYYY or DD/MM/YYYY. Stop guessing. Ask the users.

Is there a problem with increasing the size limit. It /seems/ like a very easy quickwin. What's the story?

Wikidata currently gets ~660k edits per day.

Notable that WDQS lag seems to be paying not a blind bit of notice to this change :(

Per Laske, SPARQL for this issue in Germany [https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Surplus_of_coordinates_-_T198078]

Ditto http://www.wikidata.org/entity/Q17567523 ... there are probably others.

@Smalyshev Please check out the single coords property at https://www.wikidata.org/wiki/Q6522893#P625 versus the two rows returned by this query, suggestive of 'hidden' triples lurking still.

And note Ethan's assertion: The scheme for Geonames URIs requires a trailing forward slash.

Fix by all means, but I note "It is an error for aggregates to project variables with a name already used in other aggregate projections, or in the WHERE clause." https://www.w3.org/TR/sparql11-query/#aggregateExample

Tested - works for me in situation in which it previously didn't work.

Can I gently detach this issue, somewhat, from disputed territory. The current situation is that maps served by Wikipedias & (my key use) Wikidata WDQS use "OSM Bright for Mapbox Studio" tiles ( https://foundation.wikimedia.org/wiki/Maps_Terms_of_Use#Where_does_the_map_data_come_from? )

Worth noting that user:Twofivesixbot

@FriedhelmW ... purge != clear cache. https://www.refreshyourcache.com/en/home/

Seems more likely it's a data input issue than a query issue @matej_suchanek, given that WDQS doesn't exhibit the same sort of error for analogous wdtn:, such as wdtn:P244 (Library of Congress authority ID) - see for instance https://w.wiki/48X

de link is showing. local caching issue for @FriedhelmW ?

+1 for this. Further example of a long SPARQL report is at https://twitter.com/Tagishsimon/status/1128769104674996234 fwiw

And the clear risk with this issue is that if one enters a search term that should get a match ... for instance - Judith Schwarz - and places a reliance on the dropdown, then seeing no dropdown, as if the search term did not match anything, will, for instance, lead to the creation of duplicates.

That's not a fix, so much as a helpful workaround.

closed as duplicate of or subsumed within T214984

@Aklapper thanks - I've moved the contents to that ticket & will close this.

Let me add content from << T217103: Extension:Kartographer producing "Couldn't parse JSON" errors when SPARQL includes queryhints >> since this seems a part of the issue raised here and may provide an additional failure-mode example:

No, I'll not be doing that, any more than you just have. Whilst a serious outage is being treated merely as a curiosity, it is well worth reminding WMF employees that outages like this are far from acceptable.

Day 2 of no Quickstatements, no Listeria, no ETA for a resumption of service ... no comment from WMF on why what is a critical service - if we're taking this whole wikidata business at all seriously - is fritzed.

And to prove the curate's egg, http://petscan.wmflabs.org/?psid=7075446&al_commands=P31%3AQ5%0AP21%3AQ6581072 when run again, 502d.

Mixed results. The following three worked like a charm:

Sorry to burden you with this. As a user 502s are v.frustrating, but I can also imagine it's v.frustrating for you to be asked to debug when you could be making snowmen instead.

502 examples in the last couple of minutes:

Thanks Magnus. I run those two daily; get perhaps 20% 502s, without an obvious pattern. There are others (e.g. listed on https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Women_in_Red/Metrics/Wikidata ) which more reliably 502

How about we work out what's going on BEFORE we peremptorally close this issue. "As far as I know" does not cut it.

Ideally Cloud-Services will liaise with @Magnus either to bottom out & solve the issue; or else to provide an explanation for the 502 issue which we can use to console ourselves each time it happens.

So far as I know, the fault is not with Petscan, but with the WMF infrastructure on which it operates. Please do not be so hasty to dismiss problems like this.

@Jdlrobson Do we need to provide a description? Would not <meta name="twitter:card" content="title"/> provide our extant <title></title> contents to the twitter card. (I really don't know, but from first principles that seems to be what specifying content="title" would be likely to do.)

Is it really blocked, or is the best driving out the good? Would not something as simple as <meta name="twitter:card" content="title"/> be a massive improvement on the current highly suboptimal rendering - example: https://twitter.com/Tagishsimon/status/1064868689995071488

thx

Thx @LucasWerkmeister. All makes sense now :)

My regex is not great, but \?(\S*?)[\s\)}\.]

@Jonas - is there not a pattern that we could use instead of /^[\w\d]*/ ... we have a questionmark followed by not white space followed by a space or by ) or } or .

This issue is still occurring, lest anyone think we're done. I just got it on https://www.wikidata.org/wiki/Q55471970 when logged in.

see also T193214 which has a similar URL encoding issue.