Property talk:P625

From Wikidata
Jump to navigation Jump to search

Documentation

coordinate location
geocoordinates of the subject. For Earth, please note that only WGS84 coordinating system is supported at the moment
Representsgeographic coordinate (Q104224919)
Data typeGeographic coordinates
Corresponding templateTemplate:Coord (Q6294369)
Template parameter|coordinates= in en:template:infobox stadium
Domainplace, event (note: this should be moved to the property statements)
Usage notesonly WGS84 coordinate system is supported at the moment
value is of a complex data type, see documentation for details.
ExampleMount Everest (Q513) → 27° 59′ 17.00″ N 86° 55′ 31.00″ E
Mont Blanc → 45° N, 359° E
Formatter URLhttps://geohack.toolforge.org/geohack.php?params=$1
Robot and gadget jobsmw:Manual:Pywikibot/coordinate_import.py
globe.js script adds a UI to set the globe parameter of coordinate location (P625)
LocatorBot may automatically update the globe parameter of coordinate location (P625) when not set according to located on astronomical body (P376)
Tracking: sameCategory:Pages with identical coordinates at Wikidata (Q20119568)
Tracking: differencesCategory:Pages with coordinates different from Wikidata (Q15961075)
Tracking: usageCategory:Pages using Wikidata property P625 (Q18199220)
Tracking: local yes, WD noCategory:Coordinates not on Wikidata (Q15181099)
Tracking: avail. bothCategory:Coordinates on Wikidata (Q15181105)
See alsolocation (P276), KML file (P3096), location of the point of view (P7108), coordinates of the point of view (P1259), coordinates of depicted place (P9149), lunar coordinates (BEING REPLACED) (P8981), coordinates of geographic center (P5140), coordinates of northernmost point (P1332), coordinates of easternmost point (P1334), coordinates of westernmost point (P1335), coordinates of southernmost point (P1333)
Lists
Proposal discussionProposal discussion
[create Create a translatable help page (preferably in English) for this property to be included here]
Conflicts with “instance of (P31): human (Q5), company (Q783794), railway (Q22667)”: this property must not be used with the listed properties and values. (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P625#Conflicts with P31, SPARQL
Conflicts with “instance of (P31): feminine given name (Q11879590), given name (Q202444), masculine given name (Q12308941)”: this property must not be used with the listed properties and values. (Help)
List of violations of this constraint: Database reports/Constraint violations/P625#Conflicts with P31, hourly updated report, SPARQL
Single best value: this property generally contains a single value. If there are several, one would have preferred rank (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Schuitenbeek (Q22986477), Kloster Megingaudshausen (Q81829291), Squaxin Island Reservation (Q106928756)
List of violations of this constraint: Database reports/Constraint violations/P625#single best value, SPARQL
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P625#Conflicts with P31, SPARQL
Conflicts with “instance of (P31): Wikimedia template (Q11266439)”: this property must not be used with the listed properties and values. (Help)
List of violations of this constraint: Database reports/Constraint violations/P625#Conflicts with P31, hourly updated report, SPARQL
Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P625#Scope, SPARQL
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P625#Entity types
Places around the Sahara
50 km around the Sahara (Help)
Violations query: SELECT ?item ?dist { SERVICE wikibase:around { ?item wdt:P625 ?location . bd:serviceParam wikibase:center "Point(23.4035581 25.6623178)"^^geo:wktLiteral . bd:serviceParam wikibase:radius "50" . } BIND(geof:distance("Point(23.4035581 25.6623178)"^^geo:wktLiteral, ?location) as ?dist) } ORDER BY ?dist
List of this constraint violations: Database reports/Complex constraint violations/P625#Places around the Sahara
Places around the point (0, 0)
50 km around the point (0, 0) (Help)
Violations query: SELECT ?item ?dist { SERVICE wikibase:around { ?item wdt:P625 ?location. bd:serviceParam wikibase:center "Point(0.0 0.0)"^^geo:wktLiteral. bd:serviceParam wikibase:radius "50". } BIND(geof:distance("Point(0.0 0.0)"^^geo:wktLiteral, ?location) as ?dist) FILTER (?item NOT IN (wd:Q24041662, wd:Q16896007, wd:Q23538)). }
List of this constraint violations: Database reports/Complex constraint violations/P625#Places around the point (0, 0)
Places around the point (0, 0) (300 km)
300 km around the point (0, 0) (Help)
Violations query: SELECT ?item ?dist { SERVICE wikibase:around { ?item wdt:P625 ?location. bd:serviceParam wikibase:center "Point(0.0 0.0)"^^geo:wktLiteral. bd:serviceParam wikibase:radius "300". } BIND(geof:distance("Point(0.0 0.0)"^^geo:wktLiteral, ?location) as ?dist) FILTER (?item NOT IN (wd:Q24041662, wd:Q16896007, wd:Q23538)). FILTER NOT EXISTS { VALUES ?t { wd:Q32099 wd:Q146591 }. ?item wdt:P31 ?t. } }
List of this constraint violations: Database reports/Complex constraint violations/P625#Places around the point (0, 0) (300 km)
Non-fictional places on Earth would generally not have "unknown" as coordinates
TODO fix or define exceptions (Help)
Violations query: {{{sparql}}}
List of this constraint violations: Database reports/Complex constraint violations/P625#Non-fictional places on Earth would generally not have "unknown" as coordinates
Non-fictional places on Earth would generally not have "novalue" as coordinates
TODO fix or define exceptions (Help)
Violations query: {{{sparql}}}
List of this constraint violations: Database reports/Complex constraint violations/P625#Non-fictional places on Earth would generally not have "novalue" as coordinates
Coordinates from Earth with ?lon>180
TODO fix or define P376 (Help)
Violations query: {{{sparql}}}
List of this constraint violations: Database reports/Complex constraint violations/P625#Coordinates from Earth with ?lon>180
Coordinates from Earth with ?lat>90
TODO fix or define P376 (Help)
Violations query: {{{sparql}}}
List of this constraint violations: Database reports/Complex constraint violations/P625#Coordinates from Earth with ?lat>90
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Properties for locations
Location
Coordinates
Maps
Areas
Administrative
territorial
entities
Government
Administrative divisions
Icons
Diplomacy
Borders
Mountains
Bodies of water
Buildings
Lighthouses
Linear features
Roads
Railways and stations
Bridges
History

Charts[edit]


Discussion[edit]

Temporarily deleted[edit]

Sven has deleted this until bug 49415 gets fixed, after a brief discussion in #wikidata-adminconnect. I'd post the logs here, but the channel's no-public-logging, so just noting that I support the decision. — PinkAmpers&(Je vous invite à me parler) 02:18, 11 June 2013 (UTC)Reply[reply]

Bug was fixed. -- TZorn (talk) 08:18, 14 June 2013 (UTC)Reply[reply]

Use Property[edit]

I would like to know if this property is definitive. I've already applied Infovox in the Spanish Wikipedia (es:Plantilla:Ficha de localidad).

  • In the location map.
  • coordinates values in infobox using template:coord
Tips how.

regards --Miguillen (talk) 11:52, 24 June 2013 (UTC)Reply[reply]

I think it is definitive in the sense that it wont be deleted, and it there is no reasaon why it should break in the future, but it will probably be added some feature (like precision or planet). --Zolo (talk) 07:12, 9 July 2013 (UTC)Reply[reply]

Celestial coordinates[edit]

Is it possible to expand use of the coordinates for Astronomical coordinate systems (Q86394) with celestial sphere (Q12134) as a globe and h, m and s markers? Other similar coordinate system could be galactic coordinate system (Q385487) with The Sun (Q590761). Paweł Ziemian (talk) 20:04, 7 July 2013 (UTC)Reply[reply]

  • I do not know answer to your question. But there are two currently unused parameters (altitude and globe) in internal coordinate presentation (this is request for Barton (Q2614168)). — Ivan A. Krestinin (talk)
    • Nice example :) Changing the globe is easy extension. The main question/problem is however the 360° vs 24h and the internal format of the coordinates. The easiest solution is always using ° as latitude value, and converting it to corresponding hms format with Lua, using the globe parameter as hint for presentation format. Paweł Ziemian (talk) 21:47, 7 July 2013 (UTC)Reply[reply]
    • I got an idea about other solution with new set of precision values:
      15,00000000000000 - h
      0,25000000000000 - hm
      0,00416666666667 - hms
      0,00041666666667 - hms.f
      0,00004166666667 - hms.ff
      0,00000416666667 - hms.fff
      0,00000041666667 - hms.ffff
    • Paweł Ziemian (talk) 21:58, 7 July 2013 (UTC)Reply[reply]

Main type[edit]

Coordinates can be also meaningful for the main type event (Q1656682), creative work (Q386724 - location of the work) and organization (Q43229), not only for place (Q618123, geographical feature). --ŠJů (talk) 12:08, 13 July 2013 (UTC)Reply[reply]

Switch from 40°25'8"N to decimal[edit]

Why use the 40°25'8"N, 3°41'31"W format?

It is a very cumbersome format, and not very usable as most geo tools out there use the decimal format. I see there has been almost no discussion prior to the adoption of this property, and in particuliar zero discussion about the format.

To encourage reuse outside of our wikis, let's switch to the decimal format! It is not too late to make the change. What is everyone's opinion about this? Nicolas1981 (talk) 02:12, 29 August 2013 (UTC)Reply[reply]

Personally, I find it a bit odd that a rounded input of (e.g. 40.75,-3.5) is displayed as coordinates with minutes and seconds (40°45'0"N, 3°30'0"W). I prefer that display matches the input. I'm aware that some prefer to see D/M/S, others always decimals.
For a comparison of the precision of coordinates, see en:WP:GEO#Precision_guidelines. I know I need to learn how to make use of the "advanced adjustments".
For re-use, I don't think it matters which format we make available as long as we don't add artificial precision. --  Docu  at 02:34, 29 August 2013 (UTC) (edited)Reply[reply]
And it only looks like "40°25'8"N" in the User Interface. As far as I can see, is it always stored as decimal. -- Lavallentalk(block) 06:37, 30 August 2013 (UTC)Reply[reply]
The precision is also a matter of how you regard the item. I am currently working with Swedish municipalities, and I regard them as administrative entities, not as geographic. To me it makes sense to locate the administrative office, not the geographic area. My wife works for the municipality and her employee is located to one single address, not to a hundreds of km2 wide area, where large parts are inhabited. -- Lavallentalk(block) 06:48, 30 August 2013 (UTC)Reply[reply]
There will propably be more geographical properites in the future that is not limited to a single point, that would be more apropriate to use for municipalities and the like. However, I prefer to keep the DMS-system since it is more readable than decimal format. /Esquilo (talk) 08:18, 3 October 2013 (UTC)Reply[reply]
I don't think the format is cumbersome. More importantly, the format makes it obvious that more accuracy than the size of a room isn't needed for most objects. --80.114.178.7 23:35, 10 January 2014 (UTC)Reply[reply]

Strange error[edit]

Can someone explain the error I see in e.g. Sint Maarten (Q2501604)? The value does not comply with the property's definition. The value's data value type "ununserializable" does not match the property's data type's data value type "globecoordinate". Did something change, since in the past these coordinates were correctly shown (see e.g. http://www.wikidata.org/w/index.php?title=Q2501604&oldid=52924016 ) Are these 'errors' automatically corrected? ) User:Michiel1972 20:35, 29 August 2013 (UTC)Reply[reply]

See Wikidata:Contact_the_development_team#Red_error_messages_for_coordinates. (BTW, please try to not use the bot when commenting on talk) --  Docu  at 21:07, 29 August 2013 (UTC)Reply[reply]

Wrong precision[edit]

Many many coordinates have wrong precision, not consistent with the input. See my edits. A null edit like change (delete a digit and reenter it) fixes the precision. They schould be corrected with a bot. Huwiki uses this precision for display and it breakes it if it is wrong. --JulesWinnfield-hu (talk) 12:38, 30 December 2013 (UTC)Reply[reply]

  • This happens after WD update. Looks like bug in coordinate editor. I suggest wait for resolution for bug 55971. — Ivan A. Krestinin (talk) 18:50, 30 December 2013 (UTC)Reply[reply]

This is not the case. The coordinate editor is OK. Many digits does not always mean very high precision because of 1/60 and others. Simply the stored precision doesn't match the input. The editor fixes it. --JulesWinnfield-hu (talk) 15:07, 31 December 2013 (UTC)Reply[reply]

It seems that all coordinates with not decimal precision (arcminutes, arcseconds etc.) imported with a bot are stored with wrong precision. It should be corrected for right display. Where to report it? --JulesWinnfield-hu (talk) 12:53, 2 January 2014 (UTC)Reply[reply]

Example edis for fixing the precision: [1], [2]. Apparently nothing changed. --JulesWinnfield-hu (talk) 13:09, 2 January 2014 (UTC)Reply[reply]

Example of wrongly stored precision: Hattusa (Q181007). Do not modify to document the problem. --JulesWinnfield-hu (talk) 20:59, 7 January 2014 (UTC)Reply[reply]

constraint report relating to Wikimedia disambiguation page (Q4167410)[edit]

If instance of (P31) is a Wikimedia disambiguation page (Q4167410) the presence of coordinate location (P625) is prohibited

see: Wikimedia disambiguation page (Q4167410) with coordinate location (P625) . Usualy there might be more possibilities:
a) Please identify the non - ambiguation page (WD item) where the property coordinate location should be moved;
"normally" no other statements should be left at the disambiguation page.
It can happen that a set of properties should be moved to another (a second) WD item, another set to a third WD item etc.
b) (recomended method:) Verify which language is a disambiguation page and separate it from the rest. Please use Gadget-labelLister.js can be activated at preferences#gadgets to remove all faulty (disambiguation) descriptions after the disambiguation page is separated: Verify the descriptions for the following languages: de, en, fr, es, pt, pt-br, ru, sv which where added by bots long time ago and take a short look at the other language descriptions.
c) If method b) can not be used because all linked WMF-project language pages are (local) disambiguation pages please create a new WD item and add a proper description in your native language and in English.

There are 1007 items today. Thanks in advance! gangLeri לערי ריינהארט (talk) 11:26, 4 June 2014 (UTC)Reply[reply]

There are still 835 items found by the query. לערי ריינהארט (talk) 05:58, 23 July 2014 (UTC)Reply[reply]

conflicts with companies[edit]

As of this moment, this page includes the line 

{{Constraint:Conflicts with|list={{P|31}}: {{Q|5}}, {{Q|783794}}, {{Q|4167410}}; {{P|247}}}}

I am a little confused over why this property is said to conflict with companies, i.e. items with the claim of instance of (P31):company (Q783794). Don't all companies have locations? At least, all legitimate companies... If a company does not have a location, it is probably doing something illegal, and it is very difficult to include it on your tax returns.

There are thousands of "conflicts with" violations, and a few that I looked at randomly were all companies. There seems to be a widespread usage of this property for companies already. This represents either widespread misuse of the property or a differing communal consensus about how it should be used. --Haplology (talk) 01:47, 6 January 2015 (UTC)Reply[reply]

Company is a juridical person, thus itself does not have coordinates. But yes, there may be coordinates of headquarter, factory or shop used by company. Thus coordinates have its place mostly as qualifier of headquater (Property:P159), but not as direct property. Unfortunately unlike coordinates locations of hq are not so widely imported, so fixing these mean to found and fill them manually first. I am working on that, also notifing of bot importers about that. Now there are 2500+ violations, but just 3 months ago there was 3000+ violations. Note that P625 is very widely used (1,854,004 as of 5 January 2015), so in my opinion 2,500 is just tiny fraction and not widspread usage. --Jklamo (talk) 03:59, 6 January 2015 (UTC)Reply[reply]
Agree with the above. A company shouldn't have coordinates. To show the location where a company operates, one should use e.g. headquarters location (P159) and an item (create a new one as necessary) about the company headquarters. Deryck Chan (talk) 16:26, 10 March 2017 (UTC)Reply[reply]

Special precision[edit]

There is Słowackiego Street (Q9365381) with ["precision"] = 0.014000802722428. The value is described as special in the editor. What is purpose of such values, which are outside from the predefined set of values used to describe the display format? Paweł Ziemian (talk) 21:38, 9 February 2015 (UTC)Reply[reply]

The coordinates was imported from Polish Wikipedia. I think precision "1 second" must be used for {{koordynaty|50|05|15|N|18|12|23|E|umieść=na górze}}. So this is looked as bug in bot from this point of view. Multichill can have more comments. — Ivan A. Krestinin (talk) 22:22, 9 February 2015 (UTC)Reply[reply]
Not a bug, it's a feature. Wikipedia uses dimension, Wikidata uses precision. If you convert a round dimension you get a precision like this. Just do the reverse calculation and you probably get a multiple of 10.
Tracked in phab:T89218. Multichill (talk) 07:31, 11 February 2015 (UTC)Reply[reply]
So the intention is 40,000 km × 0.014000802722428°/360° ≈ 1.6 km as far as Earth is concerned. Am I right? Paweł Ziemian (talk) 17:06, 11 February 2015 (UTC)Reply[reply]
No, how much a degree is depends on where you are on the globe. Would link to the code if my internet connection wasn't acting up. Multichill (talk) 05:28, 12 February 2015 (UTC)Reply[reply]
  • Currently I understand the following precisions:
value example format
10.00000000000000000000 50°N, 0°E
1.00000000000000000000 52°N, 0°W
0.10000000000000000000 51.6°N, 0.3°E
0.01666666666666670000 51°33'N, 0°17'46"W
0.01000000000000000000 51.56°N, 0.28°E
0.00100000000000000000 51.556°N, 0.280°E
0.00027777777777777800 51°33'20"N, 0°16'46"W
0.00010000000000000000 51.5558°N, 0.2797°E
0.00002777777777777780 51°33'20.0"N, 0°16'46.0"W
0.00001000000000000000 51.55583°N, 0.27972°E
0.00000277777777777778 51°33'20.02"N, 0°16'45.98"W
0.00000100000000000000 51.555833°N, 0.279722°E
0.00000027777777777778 51°33'20.020"N, 0°16'45.980"W
0.00000010000000000000 51.5558330°N, 0.2797220°E
0.00000002777777777778 51°33'20.0200"N, 0°16'45.9800"W

I expect that the special precision might be mapped to one of above display format using some lookup algorithm, but there is lack a formula for dimension (dim parameter for #coordinates), which is hidden behind the special value. Of course the known values can be put to the formula too to retrieve suggested dimension for typical cases. Paweł Ziemian (talk) 18:44, 12 February 2015 (UTC)Reply[reply]

“Wikipedia uses dimension” Where? Where is the source value for 0.014000802722428? Dimension is for map zoom instead of scale, not for coordinates precision. --JulesWinnfield-hu (talk) 11:01, 13 February 2015 (UTC)Reply[reply]

@Multichill: How we have to read ["precision"] = 0.014000802722428. Can you show us "reverse calculation". The same problem is in @PLbot: editions: ["precision"] = 0.0145212228501 in Q9350245. @Pasleim:, can you explain what this precision mean? Malarz pl (talk) 18:45, 6 March 2015 (UTC)Reply[reply]
Thanks for the ping, you can read the dim -> precision code (in Python) at this page. @Spider:, can you show off your math skills to go from precision and latitude to dim? Multichill (talk) 19:00, 6 March 2015 (UTC)Reply[reply]
Thanks for the link to precision calculation. Paweł Ziemian (talk) 20:51, 6 March 2015 (UTC)Reply[reply]
@Multichill: Thanks for link to code in python. I calculate dimensions for both objects and now I know, that Słowackiego Street (Q9365381) has 1000m (in real 1120m) and Q9350245 has 1000m too (in real ~50m). It's not a feauture. It's a BUG. It's mean, that your bots assume that all objects have size of 1000m. When bot will be calculating "special precision" for object with latitude of 57,3851462195636 (and dim of 1000m), the special precision will be 0.0166666666666667 (like "arcmin"). How will we know if this is a special precision for dim, or standard for arcmin? Malarz pl (talk) 21:29, 6 March 2015 (UTC)Reply[reply]
@Malarz pl: you can see the dimension using the api (2), you seem to have lost a zero, it's 10.000 instead of 1.000. When I look at the original article I see that type is set to city, you can see that if you click the coordinate link. According to the documentation that gives 10.000 as dimension. That seems to be a bug in the Polish Wikipedia. Multichill (talk) 23:53, 6 March 2015 (UTC)Reply[reply]
  1. Perhaps pl.wiki errors. Do not assume the dimensions indicated by the GeoData. In this situation, it is wrong to bots actions that transfer undefined dimension information from the Polish wiki to WD.
  2. Using equation (line 310): precision = math.degrees (self._dim / (radius * math.cos (math.radians (self.lat))))
    can be calculated:
    precision = degree (1000 / (6,378,137 * cos (radians (50.0875)))) = degree (1000 / (6,378,137 * cos (0.8741917891))) = degree (1000 / (6378137 * 0.6416169858)) = degree (1000 / 4092321.03680021) = degree (0.0002443601) = 0.0140008027
  3. But the main problem in specific situations is undistinctive precision value. You cann't identify whether the information relates to the precision whether "pecial value" - dimension. Using the above formula for the facility located at latitude 57.3851462195636 and the same dimension as above, precision equal to 0.0166666666666667, the same as that used to encode precision "arcmin". Malarz pl (talk) 10:09, 7 March 2015 (UTC)Reply[reply]
  • Simple conversion of the python code gives me the following Lua script to calculate dimension:
local dim = false -- TODO maybe someday "dim = value.dim"
if (value.globe == "http://www.wikidata.org/entity/Q2") and value.precision then
	dim = math.ceil(math.rad(value.precision) * math.cos(math.rad(value.latitude)) * 6378137)
end
And for Słowackiego Street (Q9365381) the result is exactly 1000m, and for Q9350245 it is 20m. You can probe it on a page preview using the following infobox simulator in plwiki:
{| class="infobox" cellpadding="4"
|-
|+ Współrzędne
|-
{{Wikipedysta:Paweł Ziemian/Infobox Wikidane
 |cecha = P625
}}
|-
|}
Below is a table with example dimension values prepared in Calc:
precision example format Latitude 0 30 50 70 80 85 89 90
10.00000000000000000000 50°N, 0°E 1113195 964056 715548 380736 193305 97022 19428 1
1.00000000000000000000 52°N, 0°W 111320 96406 71555 38074 19331 9703 1943 1
0.10000000000000000000 51.6°N, 0.3°E 11132 9641 7156 3808 1934 971 195 1
0.01666666666666670000 51°33'N, 0°17'46"W 1856 1607 1193 635 323 162 33 1
0.01000000000000000000 51.56°N, 0.28°E 1114 965 716 381 194 98 20 1
0.00100000000000000000 51.556°N, 0.280°E 112 97 72 39 20 10 2 1
0.00027777777777777800 51°33'20"N, 0°16'46"W 31 27 20 11 6 3 1 1
0.00010000000000000000 51.5558°N, 0.2797°E 12 10 8 4 2 1 1 1
0.00002777777777777780 51°33'20.0"N, 0°16'46.0"W 4 3 2 2 1 1 1 1
0.00001000000000000000 51.55583°N, 0.27972°E 2 1 1 1 1 1 1 1
0.00000277777777777778 51°33'20.02"N, 0°16'45.98"W 1 1 1 1 1 1 1 1
Paweł Ziemian (talk) 10:42, 7 March 2015 (UTC)Reply[reply]
20m is after my change. Before was 1000m. Malarz pl (talk) 15:51, 7 March 2015 (UTC)Reply[reply]

I understood. "Special precision" is the dimension of the object (latitudinal), expressed as an angle with vertex at the center of the Earth. Meridional angular dimension is equal to (at the Equator) or greater, so it can be skipped. In some cases, the "standard precision" is the equivalent of the size, and it'snot a mistake. In that case the only problem is the treatment erroneously specified dimensions on pl.wiki as a basis for importing data to WD. Malarz pl (talk) 18:34, 7 March 2015 (UTC)Reply[reply]

Translations for N, E, S and W[edit]

N, E, S and W are for many languages not the right labels for coordinates. How can we translate these for the various languages? Romaine (talk) 16:22, 10 March 2015 (UTC)Reply[reply]

I created a bug for this: phab:T93084. Romaine (talk) 15:48, 18 March 2015 (UTC)Reply[reply]
See Phab:T51385. Multichill (talk) 18:38, 18 March 2015 (UTC)Reply[reply]

Mismatched display of location data[edit]

I'm a little unclear if is this is a formatting issue or not. Sorry didn't have time to look in depth. Example Q18288757: (Permalink to the referenced display: [3] added by JulesWinnfield-hu (talk))

  • displayed on wikidata 53°19'N, 9°47'E
  • geohack link param 53.3961_N_9.77778_E_globe:earth
  • displayed on geohack as WGS84 53°23′45.96″ N, 9°46′40.01″ E

At first sight the display of the location on wikidata is wrong and should match the geohack display, as the geohack param from wikidata is correct. --Aeroid (talk) 08:34, 8 July 2015 (UTC)Reply[reply]

This is because of the totally wrong precision added by Multichill. The precision should be 0.00001 or 1/3600. Also, if the precision is 1/3600 the value shouldn't be rounded to 5 decimals (see UI), should be rounded only for decimal precisions. Pinging Jc3s5h. --JulesWinnfield-hu (talk) 13:48, 8 July 2015 (UTC)Reply[reply]

The addition to wikidata gives the following values:
Latitude 53.3961
Longitude 9.77778
Precision 0.15065338562478
The next edit gives Wikipedia as a source; the edit was performed July 8, 2015. On that date the source stated:
|lat_deg = 53 |lat_min = 23 |lat_sec = 46
|lon_deg = 9 |lon_min = 46 |lon_sec = 40
Performing the conversion to decimal degrees with the highest precision available on a common pocket calculator:
Latitude 53.39611111
Longidude 9.777777778
The implied precision is a few arcseconds; the best possible precision that the value might represent is 1 arcsecond which is about 0.00028 degrees.
Geocoordinates are, according to Wikidata:Property proposal/Archive/9 represented by datatype GeoCoordinateValue. According to the conceptual document mw:Wikibase/DataModel#Geographic locations geocoordinates are represented with the value GlobeCoordinateValue, which contains for values: latitude, longidude, precision, and an IRI describing the coordinate system, which defaults to WGS84.
If editing with the user interface, I imagine many editors would choose precision "to an arcsecond" even though this will insert a precision of 0.00027777777777778. No engineer or scientist would ever write a precision that way; it would be written 0.0003 or perhaps 0.00028.
I cannot discern any justification for the precision 0.15065338562478 inserted by the bot.
Jc3s5h (talk) 14:37, 8 July 2015 (UTC)Reply[reply]

Constraint violations[edit]

Hi, Is conflicts with instance of (P31) and Single value violations are all exeptions ? --YanikB (talk) 15:25, 30 January 2016 (UTC)Reply[reply]

Sorry, I can not understand your question. --Jklamo (talk) 22:54, 31 January 2016 (UTC)Reply[reply]
@YanikB: I don't understand it either. Can you elaborate? Multichill (talk) 18:22, 2 February 2016 (UTC)Reply[reply]
OK, If I get it right, this property is suppose to have a single value, that's why the constraint report showes elements having more than one occurence. My question is : all elements reported are execptions ? Should we fix them ? If so, how ? I've asked Project river how to properly fill P625 when there is two coordinate locations. --YanikB (talk) 21:24, 2 February 2016 (UTC)Reply[reply]
@Ivan A. Krestinin: I also have discussion with Ivan. In my opinion we can drop single value violations completely or at least add exceptions for linear items (rivers, roads, streets). --Jklamo (talk) 22:31, 2 February 2016 (UTC)Reply[reply]
Ok, then we should use applies to part (P518) as qualifier for multiple values instead of instance of (P31). --YanikB (talk) 15:25, 4 February 2016 (UTC)Reply[reply]

Can this property have multiple values?[edit]

Hi all

I want to add in the following Wikidata items of World Heritage Sites which don't currently have a location (the only ones that don't)

  • wd:Q10649093 Mines of Rammelsberg, Historic Town of Goslar and Upper Harz Water Management System
  • wd:Q15278408 Gebel Barkal and the Sites of the Napatan Region
  • wd:Q15839111 Imperial Palaces of the Ming and Qing Dynasties in Beijing and Shenyang
  • wd:Q15839120 Old Town of Ávila with its Extra-Muros Churches
  • wd:Q15925953 Avatar Hallelujah Mountain
  • wd:Q16886870 Archaeological Site of Panamá Viejo and Historic District of Panamá
  • wd:Q19757864 Silk Roads: the Routes Network of Chang'an-Tianshan Corridor
  • wd:Q19852428 Tusi Sites
  • wd:Q20650612 Climats, terroirs of Burgundy
  • wd:Q22026170 Cathedral and Churches of Echmiatsin and the Archaeological Site of Zvartnots
  • wd:Q23042992 Upper German-Raetian Limes
  • wd:Q2326418 City of Graz – Historic Centre and Schloss Eggenberg
  • wd:Q6535830 Levoča, Spiš Castle and the associated cultural monuments
  • wd:Q9603543 Alhambra, Generalife and Albayzín, Granada

However they all have multiple locations because they cover more than one site, is it ok/is it possible to add multiple locations to one Wikidata item?

Thanks

John Cummings (talk) 08:53, 13 April 2016 (UTC)Reply[reply]

See the discussion above. Unfortunately there is no consensus about that. In my opinion in cases like this multiple values should be allowed. --Jklamo (talk) 15:15, 13 April 2016 (UTC)Reply[reply]
Thanks Jklamo, in the end I've gone with one coordinate location but I think it can be improved in future. Thanks again, John Cummings (talk) 09:47, 14 April 2016 (UTC)Reply[reply]
Ideally each site would have an item and these items would hold the corresponding coordinates. If you add all coordinates on one item, some applications might just pick the first one.
--- Jura 11:39, 14 April 2016 (UTC)Reply[reply]
A supplementary question: What about if the location has been changed? Institutions use to move and sometimes even temples ( e.g. Temples of Abu Simbel (Q134140)). Could it be accepted if qualifiers like start time (P580) or end time (P582) will be added? UJung (talk) 08:40, 13 May 2018 (UTC)Reply[reply]

West-positive longitude[edit]

On some celestial body like Mercuty, Io, Ganimede... the longitude is west positive (source), i.e. a 90.5 decimal longitude means 90°30'W.

Example : Gula crater is indicated as 12.3° W or 12°18'W on wikis, but 12°17'E on Wikidata. Internal Wikidata value (or at least the one I see with Lua) is correctly "12.3" with the correct indication globe = "http://www.wikidata.org/entity/Q3169".

lua table for Gula crater - P625 
= mw.dumpObject( mw.wikibase.getEntity( 'Q12766523' ).claims.P625[1].mainsnak )
table#1 {
  ["datatype"] = "globe-coordinate",
  ["datavalue"] = table#2 {
    ["type"] = "globecoordinate",
    ["value"] = table#3 {
      ["globe"] = "http://www.wikidata.org/entity/Q3169",
      ["latitude"] = 64.1,
      ["longitude"] = 12.3,
      ["precision"] = 0.020565741900381,
    },
  },
  ["property"] = "P625",
  ["snaktype"] = "value",
}

Is there a way to indicate to Wikidata to display west-positive longitude, or shoud a task be open for that ?

--Zebulon84 (talk) 02:17, 17 September 2016 (UTC)Reply[reply]

This isn't yet possible. You can open a new task on https://phabricator.wikimedia.org. --Pasleim (talk) 11:25, 19 September 2016 (UTC)Reply[reply]
I found an existing task related to this issue : phab:T136841 --Zebulon84 (talk) 13:38, 24 September 2016 (UTC)Reply[reply]

coordinates on instances of ship[edit]

There are many ship items which have a coordinate [4]. What's the meaning of this coordinate? --Pasleim (talk) 11:19, 19 September 2016 (UTC)Reply[reply]

@Pasleim: If you click on a couple of items you'll notice that it's the location of the ship. The first couple of items are all about ships that are either in a museum or sunk. Fairly static. I would qualify these coordinates with start time (P580) or maybe in some cases end time (P582). This is also how we do it with paintings and location (P276). Multichill (talk) 18:12, 19 September 2016 (UTC)Reply[reply]

Merging with coordinates stored on Commons[edit]

I implemented first iteration of several Commons Categories for comparing location coordinates between Commons and Wikidata:

  1. c:Category:Pages with local coordinates and missing wikidata coordinates - coordinates on Commons but not wikidata -> move them
  2. c:Category:Pages with local coordinates and matching wikidata coordinates - Coordinates on Commons and Wikidata match to within 20 meters
  3. c:Category:Pages with local coordinates and similar wikidata coordinates - Coordinates on Commons and Wikidata are more than 20 meters but less than 1 kilometer apart
  4. c:Category:Pages with local coordinates and mismatching wikidata coordinates - Coordinates on Commons and Wikidata are more than 1 kilometer apart

The categories or thresholds will likely change in the future. As I see categories fill up I can see that some mismatches are real, like a building with 2 sets of coordinates kilometers apart. Others are not so obvious like geometric center, roundest number near geometric center or the capital/central location should be used for countries or cities? So many of the pages in c:Category:Pages with local coordinates and mismatching wikidata coordinates might be both correct when we are dealing with cities, countries or regions. I might look into precision estimated from roundness of the numbers to find mismatches. Any other good ways? Any potential issues with just importing coordinates from Commons for pages in c:Category:Pages with local coordinates and missing wikidata coordinates? --Jarekt (talk) 18:07, 24 October 2016 (UTC)Reply[reply]

I just looked at my edit done with QuickStatements with format like Q13634479 P625 @55.792608/37.601073 S143 Q565 and noticed that my edit includes "precision" of 1.0E-6 of some units (degrees?), which was deduced somehow from my statement without me stating it. Anyway to edit that parameter from QuickStatements or from Wikidata interface. Also it seems like c:Module:Wikidata or does not give you the precision. --Jarekt (talk) 18:55, 24 October 2016 (UTC)Reply[reply]
There were some issues and the module was reverted so the categories will empty eventually. --Jarekt (talk) 19:06, 24 October 2016 (UTC)Reply[reply]

Why is 60 seconds possible?[edit]

Tracked in Phabricator
Task T153429
Resolved

Hi all, why is it allowed to have items like Q10023 that have as location coordinate 52°23'60"N, i. e. with 60 seconds? Actually, this value has been added by a bot to WD.[5] Interestingly, in the overview 52°23'59"N is displayed and only in edit mode you see the 60. From my understanding minutes and seconds are not allowed to be equal or bigger than 60. --Aschroet (talk) 19:59, 3 December 2016 (UTC)Reply[reply]

Seems that all those values have been added by KLBot2 in 2013. --Aschroet (talk) 20:06, 3 December 2016 (UTC)Reply[reply]
We can't see exactly what is in the database, but I understand the JSON is the closest to the database that can be seen by ordinary users. To look at the JSON, follow this link:
https://www.wikidata.org/wiki/Special:EntityData/Q10023.json
The JSON values associated with P625 are latitude":52.4,"longitude":6.7669444444444,"altitude":null,"precision":0.00027777777777778
Note that the precision corresponds to 1 arcsecond. It appears to me the problem is not in the data that is stored, but in the user interface code that displays it. It ought to be displayed as 52.4° 24″ 0′.Jc3s5h (talk) 00:02, 4 December 2016 (UTC)Reply[reply]
I guess it must have something to do with the data. For example on hywiki there is even an error message displayed when it uses these coordinates.[6]. --Aschroet (talk) 00:23, 4 December 2016 (UTC)Reply[reply]
For another item with this issue i made a null edit.[7] Interestingly, the precision is added in this case. When now watching or editing the item it correctly displays zero seconds and one more minute in coordiantes. I think what we need is (1) determine all items having this problem in WD and (2) run a bot make null edits on them. --Aschroet (talk) 09:55, 6 December 2016 (UTC)Reply[reply]
Aschroet, what was the actual precision of the measurement? I would be uncomfortable letting a bot do this kind of task because the bot does not know the actual precision of the measurement. Jc3s5h (talk) 16:14, 6 December 2016 (UTC)Reply[reply]
Jc3s5h, when KLBot2 2013 added the coordinates they had no precision.[8] --Aschroet (talk) 16:27, 6 December 2016 (UTC)Reply[reply]
Seems that several bots added such values, even including precision.[9] --Aschroet (talk) 14:13, 14 December 2016 (UTC)Reply[reply]

How we continue with this issue? --Aschroet (talk) 12:20, 14 December 2016 (UTC)Reply[reply]

I will mention this at Wikidata:Contact the development team. Jc3s5h (talk) 13:52, 14 December 2016 (UTC)Reply[reply]
This is a minor bug in the display code, namely GeoCoordinateFormatter. The data is correct. The bot did nothing wrong, as far as I can see. I believe this line of code is to blame, but I have not tested this yet. Thanks for the example, I will add it to the test cases for this class. --Thiemo Mättig (WMDE) 17:03, 14 December 2016 (UTC)Reply[reply]
Thank you for your reply, Thiemo. If this is only a display problem i wonder why on w:hy:Թուբերխեն (which uses P625 of the connected Wikidata item) a warning occurs on the top right. It says that second is >=60. I am not aware how the coordinates data are exposed by WD but it seems not correct. --Aschroet (talk) 19:12, 14 December 2016 (UTC)Reply[reply]
This is expected. The local wiki relies on the same formatter code, and gets the same value with 60 seconds, which it does not understand. We will fix this via phab:T153429. --Thiemo Mättig (WMDE) 10:38, 16 December 2016 (UTC)Reply[reply]
Tracked in Phabricator
Task T158772
Resolved

Thiemo Mättig (WMDE), the previously discussed problem was fixed by the ticket. However, i found another diplay problem (do not know if it is connected). In this item