dcausse added a comment.
Data has been reloaded, please reopen if you encounter the problem again.
TASK DETAIL
https://phabricator.wikimedia.org/T198078
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Gehel, dcausse
Cc: dcausse, Mahir256, Gehel,
Tagishsimon added a comment.
Per Laske, SPARQL for this issue in Germany
[https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Surplus_of_coordinates_-_T198078]
SELECT ?item ?itemLabel ?stat ?lat ?long WITH {
SELECT ?item ?stat (COUNT(?lat)+COUNT(?long) AS ?count) WHERE
Tagishsimon added a comment.
Ditto http://www.wikidata.org/entity/Q17567523 ... there are probably others.
TASK DETAIL
https://phabricator.wikimedia.org/T198078
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev, Tagishsimon
Cc:
Tagishsimon added a comment.
@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.
SELECT ?item ?itemLabel ?stat ?lat ?long
WHERE
{
Nikki added a comment.
I'm not aware of anyone else noticing yet, so it wouldn't appear to be urgent.
The main issue from my point of view (it's the reason I noticed at least) is that queries including things like wd:Q1707 p:P625/psv:P625 [ wikibase:geoLatitude ?lat ; wikibase:geoLongitude ?lon ]
Smalyshev added a comment.
I don't remember the exact time, but it looks like the only place the wrong (and old-format) triples could have come from... Generally, with our data volume now, and 12 servers, full reload is much larger proposition than before (and yes, we'd need to think if we can
Lucas_Werkmeister_WMDE added a comment.
A full reload would also fix this, right? I thought we had at least one reload (for unrelated reasons) since last November anyways, but I must be remembering something else if those triples are still there.TASK
Smalyshev added a comment.
A problem though would be that some values only exist in old format, with xsd:decimal only, and we probably should not delete those, at least without updating. That makes the queries a bit harder. Still possible, but will probably take a bit more time to fix.TASK
Smalyshev added a comment.
Ohh, this is to be expected, and I forgot to address this unfortunately. The problem is that the hash of the value didn't change, but the content of the node did, so the update didn't work properly, because it assumes that nodes with the same hash have the same data.