Documentation

coordinate location
geocoordinates of the subject. For Earth, please note that only WGS84 coordinating system is supported at the moment

Represents geographic coordinates (Q104224919)

Data type Geographic coordinates

Corresponding template Template:Coord (Q6294369)

Template parameter |coordinates= in en:template:infobox stadium

Domain place, event (note: this should be moved to the property statements)

Usage notes only WGS84 coordinate system is supported at the moment
value is of a complex data type, see documentation for details.

Example Mount Everest (Q513) → 27° 59′ 17.00″ N 86° 55′ 31.00″ E
Mont Blanc → 45° N, 359° E

Formatter URL https://geohack.toolforge.org/geohack.php?params=$1

Robot and gadget jobs mw: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: same Category:Pages with local object coordinates and matching Wikidata coordinates (Q20119568)

Tracking: differences Category:Pages with local object coordinates and mismatching Wikidata coordinates (Q15961075)

Tracking: usage Category:Pages using Wikidata property P625 (Q18199220)

Tracking: local yes, WD no Category:Coordinates not on Wikidata (Q15181099)

Tracking: avail. both Category:Coordinates on Wikidata (Q15181105)

See also location (P276), KML file (P3096), location of the point of view (P7108), coordinates of the point of view (P1259), coordinates of depicted place (P9149), 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 discussion Proposal discussion

Current uses

Total	11,906,154
Main statement	11,574,052	97.2% of uses
Qualifier	331,560	2.8% of uses
Reference	542	<0.1% of uses

[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), organization (Q43229)”: 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): female given name (Q11879590), given name (Q202444), male 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

Conflicts with “instance of (P31): Wikimedia category (Q4167836), Wikimedia list article (Q13406463), Wikimedia disambiguation page (Q4167410), Wikimedia project page (Q14204246)”: 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): 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)

List of violations of this constraint: Database reports/Constraint violations/P625#Entity types, hourly updated report

Conflicts with “instance of (P31): artillery (Q1116728), coastal artillery (Q1358324)”: 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

Item “instance of (P31)”: Items with this property should also have “instance of (P31)”. (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#Item P31, SPARQL

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 entity (P625) is used by Wikimedia's setting of Wikidata. Please contact the development team or file a bug on Phabricator before big changes (renaming, deletion, merging, etc.).

This property is being used by:

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

Charts

Discussion

Temporarily deleted

Sven has deleted this until bug 49415 gets fixed, after a brief discussion in #wikidata-admin^connect. 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]

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

Use Property

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.

es:Wikipedia:Wikidata/Zona de pruebas Usage examples
es:Módulo:Wikidata I've adapted
es:Plantilla:Propiedad Template using the module: Wikidata. The documentation shows examples.

regards --Miguillen (talk) 11:52, 24 June 2013 (UTC)[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]

Celestial coordinates

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]

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 24^h 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]
- 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]

Main type

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]

Please see my discussion with Zolo: User talk:Ivan A. Krestinin#The list IS the problem. — Ivan A. Krestinin (talk) 13:39, 13 July 2013 (UTC)[reply]

Switch from 40°25'8"N to decimal

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]

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]

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. -- Lavallen^talk(block) 06:37, 30 August 2013 (UTC)[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. -- Lavallen^talk(block) 06:48, 30 August 2013 (UTC)[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]

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]

Strange error

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]

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]

Wrong precision

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]

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]

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]

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]

Example edis for fixing the precision: [1], [2]. Apparently nothing changed. --JulesWinnfield-hu (talk) 13:09, 2 January 2014 (UTC)[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]

constraint report relating to Wikimedia disambiguation page (Q4167410)

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]

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

conflicts with companies

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]

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]

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]

Special precision

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]

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]

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]

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]

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]

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]

“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]

@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]

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]

Thanks for the link to precision calculation. Paweł Ziemian (talk) 20:51, 6 March 2015 (UTC)[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]

@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]

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.
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
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]

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]

20m is after my change. Before was 1000m. Malarz pl (talk) 15:51, 7 March 2015 (UTC)[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]

Translations for N, E, S and W

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]

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

See Phab:T51385. Multichill (talk) 18:38, 18 March 2015 (UTC)[reply]

Mismatched display of location data

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]

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]

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]

Constraint violations

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

Sorry, I can not understand your question. --Jklamo (talk) 22:54, 31 January 2016 (UTC)[reply]

@YanikB: I don't understand it either. Can you elaborate? Multichill (talk) 18:22, 2 February 2016 (UTC)[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]

@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]

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]

Can this property have multiple values?

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]

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]

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]

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]

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]

West-positive longitude

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".

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]

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]

I found an existing task related to this issue : phab:T136841 --Zebulon84 (talk) 13:38, 24 September 2016 (UTC)[reply]

coordinates on instances of ship

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]

@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]

Merging with coordinates stored on Commons

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

c:Category:Pages with local coordinates and missing wikidata coordinates - coordinates on Commons but not wikidata -> move them
c:Category:Pages with local coordinates and matching wikidata coordinates - Coordinates on Commons and Wikidata match to within 20 meters
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
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]

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]

There were some issues and the module was reverted so the categories will empty eventually. --Jarekt (talk) 19:06, 24 October 2016 (UTC)[reply]

Why is 60 seconds possible?

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]

Seems that all those values have been added by KLBot2 in 2013. --Aschroet (talk) 20:06, 3 December 2016 (UTC)[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]

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]

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]

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]

Jc3s5h, when KLBot2 2013 added the coordinates they had no precision.[8] --Aschroet (talk) 16:27, 6 December 2016 (UTC)[reply]

Seems that several bots added such values, even including precision.[9] --Aschroet (talk) 14:13, 14 December 2016 (UTC)[reply]

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

I will mention this at Wikidata:Contact the development team. Jc3s5h (talk) 13:52, 14 December 2016 (UTC)[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]

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]

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]

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 Q4118348 the second P625 is displayed to be 36°N, 36°E but when clicking on it, it links to 36.5867, 37.0458. This does not seem to be correct. --Aschroet (talk) 16:52, 21 February 2017 (UTC)[reply]

That's a very helpful report, thank you. I was able to track this down and uploaded an other patch that does not interfere with what we did before. --Thiemo Mättig (WMDE) 15:35, 22 February 2017 (UTC)[reply]

Thiemo Mättig (WMDE), sorry for bothering you again but please take a look into Q8512675 with the coordinates 49°54'N, 21°28'E. It links to 49.8731, 21.4011 (which is 49° 52′ 23.16″ N, 21° 24′ 3.96″ E). The rounding seems not to be correct. One the other hand the related Armenian article which uses WD links to 49.9, 21.466667. I am confused. --Aschroet (talk) 06:45, 9 May 2017 (UTC)[reply]

The coordinate internally stored is 49.8731, 21.4011 with a precision of 0.1394 (which is probably wrong for a cemetery, because this precision describes an object ~15 km big). During formatting the values are "rounded" to the next full multiple of the precision, which is 49.9052, 21.4676, which is then displayed as 49°54'N, 21°28'E. We are still refining this "rounding" because it causes to many confusion like the one you experienced. But for the moment this is how our coordinate formatting is defined. --Thiemo Mättig (WMDE) 15:56, 9 May 2017 (UTC)[reply]

The precision could be correct if the value was read off a map that covers a lot of ground, making it difficult to determine the value with better precision. Jc3s5h (talk) 23:00, 11 May 2017 (UTC)[reply]

How to specify globe

How do you indicate what planet should be used in the GeoHack link for this property? I see that Olympus Mons (Q520) is correctly going to the Mars GeoHack page, but when editing that value there is no place to indicate planet. --Arctic.gnome (talk) 01:40, 3 February 2017 (UTC)[reply]

There is a globe setting, unfortunately not accessible and editable in UI. See task.

Tracked in Phabricator
Task T56097

--Jklamo (talk) 22:43, 22 February 2017 (UTC)[reply]

The current workaround is to add located on astronomical body (P376) and then wait for LocatorBot. I think there is also a script that also to change it through the api.
--- Jura 18:00, 25 February 2017 (UTC)[reply]

To make a coherent documentation I've now compiled the facts found in various discussions into Help:Data type#Globe-coordinate. Please help me review the info before it is marked for translation. I hope the documentation can be kept up to date and referred to in the future. I also tried to make this Property Documentation better as mentioned in Documentation update thread. Jagulin (talk) 09:23, 16 September 2019 (UTC)[reply]

Should be 'degrees-minutes-seconds' not 'gms' and 'stellar' isn't right, not sure how to rewrite that part. Jc3s5h (talk) 16:26, 16 September 2019 (UTC)[reply]

macro regions but not part of ATE

Should we discard P625 for macro regions?

I.e. parts of country, parts of continent.

Coordinate seems weird when scale of objects is in 1000km d1g (talk) 05:53, 29 August 2017 (UTC)[reply]

There should be a applies to part (P518) qualifier on this property when used on large objects

Hello,

When this property is used on large objects (country, sea, mountain), there should always be a applies to part (P518) qualifier: we need to know if the point is centered on the barycenter, on the capital city (e.g. for a country), on a summit (for a mountain), on a kilometer zero (Q329477), etc. -Ash Crow (talk) 20:09, 28 October 2017 (UTC)[reply]

Hi,

Using one geodata to qualify a large area is incorrect. If we made that we have to add a qualifier for the point. I'm ok with you. Ludo29 (talk) 20:22, 28 October 2017 (UTC)[reply]

Mandatory qualifer for watercourses

Is it possible to set applies to part (P518) as a mandatory qualifer for coordinate statements in watercourse items (rivers, streams etc.)? There are occasional messy bot imports that omit this data. Setting some constraint in order to track this would be appreciated. 90.191.81.65 07:28, 11 March 2018 (UTC)[reply]

Q13134060

Q13134060 has two Entries, one for source, one for mouth in other river and has a "!"-mark--Francis McLloyd (talk) 19:57, 17 April 2018 (UTC)[reply]

Unfortunately support for separator (P4155) parameter hasn’t been implemented yet, see phabricator:T173594.--Jklamo (talk) 20:51, 17 April 2018 (UTC)[reply]

strange input field behavior

There is a funny input field behavior when adding a coordinate: I enter a coordinate like 27.35763386031722, 105.1534762972066 and remove unnecessary digits just to get a precision of 4 digits to get an entry of 27.3576, 105.1534. The so created coordinate shows as 27°21'27.36000"N, 105°9'12.60000"E with unneccessary zeros being added whereas 27.3576, 105.1534 entered directly into the input field reveals as 27°21'27.4"N, 105°9'12.6"E. --Katpatuka (talk) 07:50, 27 May 2018 (UTC)[reply]

camera/object position

Can a bot user handle coordinates of commons pictures and differ position of camera to position of object in the wikidata items? Commons has details on this, because of different templates (c:Template:Location versus c:Template:Object location). Regards, Conny (talk) 14:22, 14 July 2018 (UTC).[reply]

@Conny: this looks rather out of scope for Wikidata, but very much in scope for structured data on Commons. At the moment a consultation about properties is running. This should be one of the new properties. Multichill (talk) 18:45, 14 July 2018 (UTC)[reply]

Update: We already have coordinates of the point of view (P1259) so we don't even have to create a new property. Multichill (talk) 18:47, 14 July 2018 (UTC)[reply]

@Multichill: Thank you. I think, when we Import Coordinate Data from commons zu Wikidata, we should have focus on this. The result are unsharp generated maps for example, when creators think, the coordinates in the items represent the position of the items... Regards, Conny (talk) 21:05, 14 July 2018 (UTC).[reply]

@Multichill: Maybe not to choose an different property for this, but insert additional information (qualifier?) like this on these coordinates from commonspictures? Regards, Conny (talk) 04:15, 18 July 2018 (UTC).[reply]

I still don't have any clue what you want. Please do an example edit in the main namespace on a property. Multichill (talk) 19:27, 18 July 2018 (UTC)[reply]

In general wikidata deals with object locations not camera locations. The only case camera locations would be of use would be if we have items for specific photographs or landscape paintings, and for most of those we do not have coordinates. We could add coordinates of the point of view (P1259) as qualifier of image (P18) but I am not sure if it is usefull, and the data might be accesible anyway after Structured data for commons goes live. --Jarekt (talk) 19:51, 18 July 2018 (UTC)[reply]

Problem using output of coordinates

If there is someone who knows template script and lua, would welcome assistance with using this value. Working on converting to decimal for Wikivoyage but getting strange results. Please take a look at voy:Travellers' pub#need template syntax help --Traveler100 (talk) 04:57, 27 July 2018 (UTC)[reply]

Linear features

How to store the start and end points of linear features, such as an avenue? Is that possible? If not, how do I chose a single point to represent the whole avenue? I noticed the property terminus (P559), but it doesn't ask for coordinates as input. —capmo (talk) 17:03, 12 August 2018 (UTC)[reply]

@Capmo: I don't think such a property exists, so I have proposed one at Wikidata:Property proposal/end point. Jc86035 (talk) 14:13, 15 August 2018 (UTC)[reply]

Changing locations

I added start time and end time as separators in the single value constraint, for items that have relocated such as Temples of Abu Simbel (Q134140) mentioned above and Cooks' Cottage (Q1129647). Ghouston (talk) 04:29, 16 August 2018 (UTC)[reply]

Display of Wikimedia map

Is that new? I think it's great! Trilotat (talk) 18:09, 12 December 2018 (UTC)[reply]

Perimeter of this property

Hi,

For years, this property has been used for property on any globe. Mainly it's for Earth (Q2) but we also have 7033 values with a different globe (Venus (Q313) Moon (Q405) Mars (Q111) having almost 2000 each). This practice is common and ancient (2013 for Olympus Mons (Q520) Special:Diff/53213688) so in accordance to that, I've been bold did a test on Andromeda Galaxy (Q2469) with globe = celestial sphere (Q12134) for celestial coordinates (which also has been discuss at length since 2013 but no tool allowed the change the globe back then and it is now possible but still uneasy).

Jc3s5h disagree and think that coordinate location (P625) should only be used on Earth and removed my statement (Special:Diff/867297467).

So what do you think? Should this property be specific for Earth or should we use the full extent of the coordinates datatype? And in the first case, should we create a new property to store the same data? (there has been several proposal in the past).

PS: I also changed the description of this property and removed the « please note that only WGS84 coordinating system is supported at the moment » part (Special:Diff/869324745, same for Lde and Dit)

Notified participants of WikiProject Astronomy

Cdlt, VIGNERON (talk) 14:17, 28 February 2019 (UTC)[reply]

First, the topic of this thread makes no sense. "Perimeter" has nothing to do with this sort of coordinates.

Next, the property proposal says the datatype is "GeoCoordinateValue" which is now, through a few links, points to mediawikiwiki:Wikibase/DataModel which has no specific information, but points to mediawikiwiki:Wikibase/DataModel/JSON] and mediawikiwiki:Wikibase/Indexing/RDF Dump Format. The later takes a geoGlobe field with no precise specification of what that means, just a URL that is supposed to somehow explain the meaning of the coordinates. The JSON data model takes a globe field which is specifically allowed to be a planetary body, or a URL for a more specific coordinate system, such as WGS84. So it appears that the description of the coordinates property was inaccurate. Jc3s5h (talk) 15:24, 28 February 2019 (UTC)[reply]

I'll add that there is a significant difference in meaning between specifying a feature on the surface of a celestial body with an appropriate coordinate system for that body, and specifying the location of a celestial body as located in a coordinate system where the center of the coordinate system is located light years away from the celestial body.

In addition to the fundamental difference in meaning, celestial sphere (Q12134) should never be used as a globe for this purpose. The celestial sphere in this sense an imaginary sphere, concentric with the observer, on which we pretend celestial bodies are located. "Celestial sphere", by itself, does not connote any particular coordinate system. The exact choice of coordinate system is so important that Explanatory Supplement to the Astronomical Almanac 3rd ed. (Q20668025) summarizes 10 different choices inside the front cover, and chapter 4 (18 pages) is devoted to the topic. If one makes a chart of all the naked eye stars visible from Earth on a convenient size map you can hold in your hands, the difference between some of the choices would be glaringly obvious to the naked eye; this isn't a tiny difference in the 5th decimal place we're talking about. Jc3s5h (talk) 15:38, 28 February 2019 (UTC)[reply]

I agree to use this property for different coordinate system, including galaxies and other celestial objects. What it's important is to qualify the reference system as long as different ones are possible (see en:Celestial_coordinate_system).--Ysogo (talk) 21:38, 28 February 2019 (UTC)[reply]

The data type stores: latitude, longitude, precision and globe, so I always assumed that any globe is OK, as long as you specify it. That said, when inputing coordinates I no longer seem to be able to change the globe. Did something changed? --Jarekt (talk) 20:42, 1 March 2019 (UTC)[reply]

Personally I'd limit this to Earth (99.9% of uses?). I don't see much benefit if uses for other bodies are being combined. It's more likely to lead to errors than anything else. --- Jura 12:15, 3 March 2019 (UTC)[reply]

If you want it changed, it should be done as one fell swoop. Change the description here, the JSON data model, and the RDF data model all at the same time. When disagreement exists among these 3 all Wikidata coordinates are false. – The preceding unsigned comment was added by Jc3s5h (talk • contribs).
- @Jura1: what kind of error are you thinking of? and how would you deal with non-terrestrial coordinates? Create a duplicate property of coordinate location (P625) for each globe? (this seems very redundant as the globe parameter would be useless and it means create at least thousands new properties, the globe parameter has already 39 different values and the number is low only because the interface doesn't allow to select this parameter ; @Jarekt: AFAIK globe selection has never been possible in the interface) or are you thinking about something else? @Jc3s5h: it seems you are speaking of the datatype but Jura seems to be speaking about this property (no need to change the JSON or RDF model in this latter case). Cdlt, VIGNERON (talk) 13:50, 5 March 2019 (UTC)[reply]

Tracked in Phabricator
Task T56097

Tracked in Phabricator
Task T53373
Resolved

We are storing coordinates for locations on other globe somehow and will like do more in the future. On Commons we have hundreds of photographs geotagged with coordinates on the moon, mars, etc. Many of them are famous photographs, which will likely have their own items. We have a lot of items related to Moon or Mars geography and they have coordinates. For example Olympus Mons (Q520) has coordinate location (P625) with coordinates and Globe set to Mars (Q111). I knew you can state globe but did not realized you could not edit it in the GUI, only through API. I do not think we need other properties to store locations on other globes. --Jarekt (talk) 04:03, 6 March 2019 (UTC)[reply]

To answer VIGNERON's question: I'd do a separate property for these. The likely error is that globe is ignored and places are considered to be on Earth. --- Jura 10:45, 10 March 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Seeing that this property is complex I've now compiled the facts found in various discussions into Help:Data type#Globe-coordinate. Please help me review the info before it is marked for translation. I hope the documentation can be kept up to date and referred to in the future. I also tried to make this Property Documentation better as mentioned in Documentation update thread. Jagulin (talk) 09:35, 16 September 2019 (UTC)[reply]

@Jagulin, Jarekt, Ysogo: to sort this out, please see the proposal at Wikidata:Property proposal/planetary coordinates and help complete it. --- Jura 10:11, 10 October 2020 (UTC)[reply]

Can we please, as I'm crying with tears to request, STOP using this property for roads?

There's nearly no roads that can be only a point, and using one coordinate for a roadside area, means that other roadside areas of a certain road don't think that they're real roadsiders, do we really wanna add one billion billion billion (1*10^27) coordinates for just one road? Please, just STOP it, thx. --117.15.55.99 08:31, 19 April 2019 (UTC)[reply]

While I don't know whether roads should use this property, most physical objects aren't single points either, so the argument is fundamentally flawed. Jc86035 (talk) 10:27, 19 April 2019 (UTC)[reply]

Support I hate to admit that why @Jklamo: removed conflicts-with constraint (Q21502838) subvalue for this. --Liuxinyu970226 (talk) 03:13, 20 April 2019 (UTC)[reply]

Oppose Most geographic features aren't single points, and yet we use the property because we indeed choose one coordinate point, be it for a building, for a mountain range or for a road. We even use it for the Atlantic Ocean (Q97) and I don't hear hurr, durr, do we really wanna add one billion billion billion (1*10^27) coordinates for just one ocean?--Asqueladd (talk) 00:30, 27 April 2019 (UTC)[reply]

@Asqueladd: Using for ocean, like all other kinds of ground-level staffs, are the world's most misleading, please consider removing them, thx. Just remember, there's no reason, fully No reason, to describe a big set of grounds via coordinates. --125.38.13.34 08:17, 29 April 2019 (UTC)[reply]

Comment Rivers have the same problem, of course, and yet, we survive. (Qualifiers like applies to part (P518) help, of course.) Annoying though it can be to have but a single point for a linear feature, I believe it's far better than having none, and single points are typically all we have to import from the wikipedias, I think. If everybody knew how to create, and display, shapefiles or kml files, it'd be a different story (and, indeed, I believe we're moving in that direction). Scs (talk) 02:42, 27 April 2019 (UTC)[reply]

Comment And, please, if you want people not to use single-point coordinates for roads and other linear features, by all means, provide suggestions and examples of what should be used! Scs (talk) 14:12, 27 April 2019 (UTC)[reply]

Oppose Nothing is truly a single point, yet points are an acceptable construct to describe where something is. However, I would be in favour of encouraging the use of determination method or standard (P459) qualifiers (e.g. midpoint (Q1645406)). --SilentSpike (talk)

I suppose applies to part (P518) would be more appropriate for a midpoint --SilentSpike (talk)

Oppose - the information is not wrong, because other data is also not wrong. Still this property, that is widely used, serves a lot of purposes. And we share knowledge for these purposes, not to create a database without discussions. Edoderoo (talk) 08:04, 28 April 2019 (UTC)[reply]

@Edoderoo: It can result maintenance problem in Thai Wikipedia, as we really don't welcome coordinates in some article cases. --125.38.13.34 08:22, 29 April 2019 (UTC)[reply]

Wikidata is bigger than "some articles" on one wiki. Edoderoo (talk) 08:27, 29 April 2019 (UTC)[reply]

Support There are too many Oppose users which think that every thing can be points, they're misleading the meaning of points. --125.38.13.34 02:01, 29 April 2019 (UTC)[reply]

I doubt anyone here misunderstands what a point (Q44946) is. I doubt anyone here believes that Russia (Q159), or New York City (Q60), or the Amazon (Q3783), or le avenue des Champs-Élysées (Q550), can be properly described by a point. But in point of fact (a) nothing in the world that has a geographical position can be properly described as a point, and yet (b) all of these examples do have coordinate location (P625) in Wikidata, and this is because (c) they all have coordinate locations on one or more Wikipedias, and this is because (d) people find these coordinate locations generally useful, even though they're necessarily incomplete, even though they describe just a point, not a proper shape.

It will be marvelous when more geographical entities have geoshape (P3896) and/or KML file (P3096) -- as in fact at least Russia (Q159) and avenue des Champs-Élysées (Q550) already do. (It would be even more marvelous if we could settle on one or the other of P3896 and P3096.} --Scs (talk) 14:24, 5 May 2019 (UTC)[reply]

Perhaps it would be acceptable (optionally, per road or river) to replace coordinate location (P625) usages with coordinates of westernmost point (P1335) and its three friends. Or should coordinate location (P625) be left in place regardless? Ghouston (talk) 02:41, 6 May 2019 (UTC)[reply]

Oppose this is not even wrong. Ad absurdum if we removed it from linear element based on "a line is not a point", then we should delete all coordinates everywhere as nothing is never just a point. Obviously, a road is not a point, but it's equally obvious that a road (or any geometry) can be "represented" by a point (or several with applies to part (P518) in qualifiers, but never billion billion billion, that's non-sensical, if there is a lot of points then we use geoshape (P3896) and not P625). Cheers, VIGNERON (talk) 09:58, 10 May 2019 (UTC)[reply]

@VIGNERON: It can also be wrong pointed, e.g. European route E95 (Q1165682), its "coordinate value" pointed to a settlement in Russia, but under which evidence that settlement is a part of E95 road? --Liuxinyu970226 (talk) 10:37, 18 May 2019 (UTC)[reply]

The fact that coordinates can be wrong is hardly a reason to not use, or remove them. (Anything can be wrong!) To your example, I've added a coordinate pair that's actually on the road, qualified by applies to part (P518) midpoint (Q1645406) as suggested by @SilentSpike:. Scs (talk) 11:06, 23 May 2019 (UTC)[reply]

Oppose per above, coordinates are the abstraction to a point. Also I do notice that only one user and multiple ip's from China seem the only ones to support this. Not sure to how many natural persons this boils down. Multichill (talk) 16:28, 23 May 2019 (UTC)[reply]

single value constraint when there are two values

This property has a single-value constraint (Q19474404), meaning that only one value can be used. Today I added the coordinates of the river mouth (Q1233637) of Schuitenbeek (Q22986477). This river has two river mouth (Q1233637), and not just one. Any solution? Romaine (talk) 01:08, 19 July 2019 (UTC)[reply]

Romaine, See Property_talk:P605#Single_value_constraint for discussion on how to use separator (P4155) property. --Jarekt (talk) 12:59, 19 July 2019 (UTC)[reply]

more flexible encoding for "+"

Hi, it's the second time this year I copy and paste a coordinate from a url, something like "44°02'49.7"N+11°09'10.8"E". it's not a big deal to fix it before clicking the enter key or after the error warning, but could it be flexible to accept it? It looks to me quite clear that the plus indicates the second coordinate. Just a siggestion. Bye.--Alexmar983 (talk) 16:03, 7 September 2019 (UTC)[reply]

Documentation update

I've updated the "robot and tools" section of the documentation. Template:Property_documentation doesn't say how DeltaBot is added to the list, so if anyone knows, please update it.

I added value is of a complex data type, see documentation for details to the (English) Usage notes. Wikidata usage instructions (P2559) doesn't forbid multiple values, and it seems to work fine. I'm however not so sure how translations will handle this. I think WD maybe should have extended the existing meta-feature for translation rather than to blend it into the statements.

I'm considering further updates:

place, event (note: this should be moved to the property statements)
Template:Property_documentation indicates to use subject type constraint (Q21503250). Any ideas? The current restrictions seems to be excluding rather than including types.
|coordinates= in en:template:infobox stadium
This is hardly the only example. Does it add value to the WD documentation? I think it is better removed.
Data type
There is already a link to data type documentation, but to me it wasn't clear that this link had valuable info. Should a note about it be automatically generated by the template, rather than to have it explicitly mentioned in Wikidata usage instructions (P2559)?

Let me know what you think. Jagulin (talk) 09:19, 16 September 2019 (UTC)[reply]

Thanks for doing the update. I think it's an overall improvement.

P2559 is currently somewhat redundant, as we still need to include the text in the description of the entity (generally items).

As for the template, I don't see why we should remove a sample only because we don't include all other uses. --- Jura 09:43, 16 September 2019 (UTC)[reply]

Being a bit of a dummy

Help, i forgot how to show coordinates on Google Maps --Trade (talk) 20:07, 22 January 2021 (UTC)[reply]

My understanding is that copying coordinates from Google Maps (or even from OpenStreetMap) is not OK because of their different licenses. Fortunately there are many public domain databases with coordinates. If the object is nearby, you can also go with a GPS device. Syced (talk) 07:11, 19 October 2021 (UTC)[reply]

How to get only latitude or longitude for use with Kartographer?

I'm trying to get only the longitude/latitude of an item using the property parser function to use with the Kartographer. How is it possible to get decimal output only of latitude or longitude? --YavBav09 (talk) 11:48, 26 June 2021 (UTC)[reply]

How to set by Geo URI? Why not?

The Geo URI is the in fact standart to copy/paste lat/long coordinates in nowadays (2021), not degreees. The user interface must offer Geo URI as an option to set coordinates. Wikidata is losing data, confirmations and precision without Geo URI input format to input data. --Krauss (talk) 09:38, 11 August 2021 (UTC)[reply]

Try Wikidata:Report a technical problem. --- Jura 09:51, 11 August 2021 (UTC)[reply]

I just made a ticket for this - phab:T372705 - Nikki (talk) 13:27, 17 August 2024 (UTC)[reply]

Subclass as conflicts-with constraint

@Jklamo: I reverted your edit and re-removed "subclass of" from "conflicts-with constraint" (constraint added at 03:02, 13 July 2017). In my view, a subclass of occurrence (e.g., an instance of recurring event) may occur in the same place and can have "coordinate location" (P625), can't it? --Neo-Jay (talk) 08:19, 9 May 2022 (UTC)[reply]

@Neo-Jay: IMHO the constraint is useful, as it prevents coordinates from being added to subclass(es) rather than (each) instance of items. In a case of repeated occurrence location (P276) (like Wimbledon Championships (Q41520)) is better, as they usually take place at a specific venue rather than an exact coordinate spot.--Jklamo (talk) 09:54, 9 May 2022 (UTC)[reply]

Identify >=2 statements

Hello, the query given in the doc at § Meilleure valeur unique : cette propriété contient généralement une seule valeur. S’il y en a plusieurs, un rang préféré doit être utilisé (Aide) Des exceptions sont possibles car des valeurs rares peuvent exister. Exceptions can be specified using sauf (P2303). Exceptions connues : Schuitenbeek (Q22986477), Kloster Megingaudshausen (Q81829291), Squaxin Island Reservation (Q106928756) Liste des éléments ne respectant pas cette contrainte : Database reports/Constraint violations/P625#single best value, SPARQL

does not appear to be working. But this simple one should work :

select distinct ?item where {
  ?item wdt:P81 wd:Q16926803;
        wdt:P625 ?a,?b.
  filter(?a != ?b)
}

Try it!

Bouzinac ^{💬●✒️●💛} 14:45, 20 August 2022 (UTC)[reply]

Yeah, it times out, but you can find a list at Wikidata:Database_reports/Constraint_violations/P625#"Single_value"_violations. Multichill (talk) 08:57, 21 August 2022 (UTC)[reply]

Coordinates with a vertical bar between

Kia ora! Is it possible for P625 to transform coordinate values with a | between them into the correct format? Often when I'm copying coordinates from Wikipedia they're formatted with a vertical bar in the code (e.g. {{coord|-36.90574|174.63965}}). If I could copy-paste this without needing to change the | to a comma, it'd save a little time. --Prosperosity (talk) 21:18, 14 March 2023 (UTC)[reply]

Milembeni

Milembeni itsandra grand comores Ahmed Abdallahs (talk) 11:45, 2 April 2024 (UTC)[reply]

Meridians and parallels

Meridians and parallels have only longitude and latitude, respectively. I'd like to propose separate properties for each coordinate. "Latitude" and "longitude" currently redirect here. These are also needed to define the tropics. Fgnievinski (talk) 13:54, 15 March 2025 (UTC)[reply]

One alternative would be uploading a geojson file discretizing the circles storing it as a geoshape Property:P3896. Fgnievinski (talk) 03:15, 19 March 2025 (UTC)[reply]

Bounding box

It'd be useful to define a geographic bounding box or minimum bounding rectangle (Q1134256). Fgnievinski (talk) 16:26, 17 March 2025 (UTC)[reply]