WikiProject Geographical coordinates is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Wikipedia. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.Geographical coordinatesWikipedia:WikiProject Geographical coordinatesTemplate:WikiProject Geographical coordinatesGeographical coordinates
WikiProject Geographical coordinates is part of, or of interest to, WikiProject Microformats, which encourages the deployment of microformats in Wikipedia, and documents them in the article space. If you would like to participate, visit the project page.MicroformatsWikipedia:WikiProject MicroformatsTemplate:WikiProject MicroformatsMicroformats
Discuss, summarise and specify a set of changes to geohack, such as type list revision, support for linear features, bug fixes, &c
bot to add the coordinates from wikidata to enwiki article
A few weeks ago, there was a request at WP:BOTREQ for a bot to go through Category:Articles missing coordinates with coordinates on Wikidata, add the coordinates from wikidata to enwiki article, and remove the {{coord missing}} template permalink. I had created a program to do that but I was notified that there was no clear consensus for the automation of the task. So here I am, trying the gauge the waters: would it be okay to automate the process? If yes, then what should be avoided, be careful of, and what format of the coordinates should be used? I believe if planned properly, this task could be safely automated. Courtesy ping @Deor, Dawnseeker2000, and Suntooooth: —usernamekiran (talk)02:59, 31 October 2024 (UTC)[reply]
I've previously expressed an opposition to the indiscriminate importation of coordinates from Wikidata, and my opinion has not changed. A bot's doing it is by definition indiscriminate. Deor (talk) 16:07, 31 October 2024 (UTC)[reply]
@Deor I am neutral about the bot run. But I think we should discuss what should be, and shouldn't be done by the bot, and what are the risks. Maybe we can find solution for problematic cases, or skip such cases. I am currently running a very simpler similar task, of removing wikidata QID from enwiki infobox, if it matches with wikidata, in case any doubt, the bot skips the removal and adds such doubtful cases to User:KiranBOT/List of mismatched QID. Maybe we can approach the coords task similarly? —usernamekiran (talk)12:40, 1 November 2024 (UTC)[reply]
We now have more than 19,000 articles missing coordinates on enwiki that have coordinates on Wikidata. It would seem silly not to do something with that data. But what? Should we manually review all of them and add them bit by bit by hand? Or is there some way to automate the process - for example by comparison with OSM data, where available, to check if the two coordinates are close? — The Anome (talk) 16:49, 16 April 2025 (UTC)[reply]
I am under the impression that the usual way to get Wikidata coord data into a Wikipedia article is by infobox template in the article, pulling the data from the item. This suggests to me an infobox bot putting a location map into the article, thus attracting the attention of any reader who happens to know where the object is, and leading to a WD correction. Incidentally yes, adding WikiShootMe dots to an OpenStreetMaps display would also help. Jim.henderson (talk) 13:48, 20 April 2025 (UTC)[reply]
Comparing with OSM sounds workable, as I've found OSM to be generally reliable. One problem is that OSM may not have locations for individual buildings and such, and its coordinates are frequently overprecise (as are Wikidata coords). A problem with indiscriminately pulling coords from Wikidata is that they will lack type and region parameters. For that reason and others, my opinion is that coordinates almost always benefit from human review. Maybe I just don't trust bots as much as other folk seem to. Deor (talk) 16:12, 20 April 2025 (UTC)[reply]
Article titles including co-ords as a disambiguator
Original heading: "Article titles including co-ords as a disambiguator should be strongly, strongly discouraged unless it really is the only way of disambiguating (and even then...)" ―Mandruss☎16:05, 5 December 2024 (UTC)[reply]
I've going through some articles and, sheesh, those locations are very often just wrong, and not only that, almost always, if it's a real place, there's at least something that can be used to disambiguate other than the co-ords.
I think we should give some advice somewhere that we should always disambiguate a location with anything but co-ords if there's a better way of doing (e.g., county, district, province, etc.), and that if you find a map with two places with the same name close together, please consider that there may have been a mistake made somewhere because people aren't normally dumb enough to give their village the same name as one 5 minutes drive away. FOARP (talk) 14:53, 5 December 2024 (UTC)[reply]
Yes, it isn't a good look. The only time coordinates should be used if there is several places of the same name within the same municipality and there is no way to distinguish them.♦ Dr. Blofeld15:07, 5 December 2024 (UTC)[reply]
Lunar coordinate error message
The coord template currently displays an error when the longitude exceeds 180°, as one might expect for the selenographic coordinate system. In lunar science, however, that is not the only coordinate system in popular use. The selenocentric coordinate system in the sense of easting-only longitude values has overtaken the conventional +180°E/-180°W, thanks to becoming the standard for lunar datasets in 2006.[1]
For example, the coordinate {{coord|23.7537|312.2210|globe:moon}} displays the message "{{#coordinates:}}: invalid longitude". But the longitude is not invalid, and is understood perfectly by GeoHack. Conversion is easy (subtraction from 360°), but converting entire tables of planetocentric coordinates is tedious when all that has to be done to accommodate what is now the standard practice is to remove an error message carried over from geographic (Earth) standards in the case of globe:moon.
Can anyone with an understanding of the template/module system responsible for producing these error warnings point me to the proper channel for making the desired change? Thank you. Ivan (talk) 02:57, 20 December 2024 (UTC)[reply]
As you may know, there are a number of good reasons to avoid false precision in every field of endeavor. In coordinates, we have to be aware that GPS and online mapping services have an inherent error rate of about 0.1". I just randomly chose Statue of John Carroll and the coordinates were off by 0.1", probably due to a new aerial photo. One can compare Google Maps, Bing Maps, Yahoo Maps, and Yandex and find many instances where they are off by that much or more. Additionally, some of those mapping services display the best zoom level when D°M′S″ is the input. At present, the vast majority of articles use D°M′S″ or D.dddd°, with rare exceptions such as D°M" and D.dd° for entities such as large islands or counties. The most common error is D.dddddd°, usually because users copy-and-paste. Worse yet is D°M′S.ss″ which comes from converting those six digits of false precision. Any improvement to the guidance here should be embraced. Abductive (reasoning)20:58, 16 August 2025 (UTC)[reply]
Any improvement to the guidance here should be embraced. We can agree on that. Give me a day or two to contemplate. ―Mandruss☎ IMO. 21:02, 16 August 2025 (UTC)[reply]
The purpose of coordinates on Wikipedia and its sister sites is to allow users to go from articles to mapping services, and vice versa, in various forms (geohack, mapframes, etc). The purpose is not to act as scientific/numerical data. To best serve the user, the coordinates should be within (and ideally close to the center of) the object. If they're within the object, excessively precise coordinates are essentially invisible to the user. For an object spanning 45.12341° to 45.12349°, the difference between a marked point at 45.123456789° and one at 45.12345° will not be perceptible on a mapping service. (Conversely, it will be obvious when a marked point at 45.1235° misses the object entirely.)
The result is that false precision is not actually an inherent problem for the purpose that coordinates are used for. Yes, it's mildly misleading/confusing if there are significantly more digits than needed, but five decimal digits versus four is not the issue you make it out to be. Even with the inherent error rate of about 0.1" or 0.00003°, coords with precision of d°m's.s" or d.ddddd° will still end up closer on average to the exact location than d°m's" or d.dddd° will. Pi.1415926535 (talk) 05:49, 17 August 2025 (UTC)[reply]
Looks like Pi has a better grasp of this than I do, and I created WP:COORDPREC. All I did was convert the tables at WP:OPCOORD to a format accessible to/usable by the average editor. I don't think it needs to get more complicated than that. And I've been out of the coordinates business for years. I'll probably sit out the rest of this unless one of the parties says something to convince me to take a firmer position (or someone addresses me directly). ―Mandruss☎ IMO. 11:58, 17 August 2025 (UTC)[reply]
