Wikipedia talk:WikiProject Geographical coordinates/Archive 29

A geonewbie asks
I've just [//en.wikipedia.org/w/index.php?title=Issei_Suda&diff=587043618&oldid=581414349 added my first georef] (as far as I remember). Hope there's nothing obviously wrong in that. (Wikimedia shows no syntax error.) It produces a link to [//tools.wmflabs.org/geohack/geohack.php?pagename=Issei_Suda&params=35.0894_N_140.1016_E_type:isle_region:JP_scale:10000_source:Navitime&title=Suzumejima this page at Geohack]. The upper half of this is a list of "Global services" and another of "Japan". Looking at the latter: I scored seven out of nine. Should I be grateful (are glitches common), or does something need attention?
 * 1) watchizu.gsi.go.jp.... Excellent, and the tiny islet is already labelled, so I could replace "Navitime" within my link with this.
 * 2) portal.cyberjapan.jp.... Oops! This instead points to Toranomon, in central Tokyo.
 * 3) www.mapion.co.jp.... Oops! Japanese text tells the reader that the page has moved -- though not where it has moved to.
 * 4) mapfan.com.... Excellent. Again, the island is actually already labelled with its name.
 * 5) map.yahoo.co.jp map Fine.
 * 6) map.yahoo.co.jp topography Fine.
 * 7) map.goo.ne.jp.... Fine.
 * 8) its-mo.com.... Fine.
 * 9) map.livedoor.com..... Fine.

And a trivia (I think!) point: I provided the coordinates for a point that eyeballing suggests isn't far off the centre of the island. Is this good enough, or should I have instead chosen (i) the point halfway between the NSEW extremities, or (ii) the centre of the island imagined as a smoothly rotating mass of uniform material and thickness, or (iii) something else? (If the second, how would I determine it?) -- Hoary (talk) 06:00, 21 December 2013 (UTC)
 * The GeoHack page is prepared from Template:GeoTemplate; if there are problems with specific links, you can either raise the matter at Template talk:GeoTemplate, or amend them directly if you feel confident in doing so. Re the one that hits central Tokyo - this seems rather like Template talk:GeoTemplate/Archive 13 but I have come across other mapping services where the intended location was way off. Most probably, they've altered the parameter syntax, so that instead of giving it (say)  you should give it (say)  . But what the new parameter syntax for that specific website has become, I couldn't say.
 * For an island, I choose a point roughly halfway between the NSEW extremities, but it doesn't need to be exact - your coordinates of 35.0894 N, 140.1016 E having 4 decimal places of degrees, are accurate to 11 metres, which is possibly too precise (see WP:OPCOORD). -- Red rose64 (talk) 17:48, 21 December 2013 (UTC)
 * Thank you! When I have a few unrelated chores out of the way, I'll investigate the two dud links and perhaps bring up the matter at Template talk:GeoTemplate. As for precision, I understand what you're saying, but this really is a tiny islet: drop one decimal place, and the result (see this at Geographical Survey Institute) is that the cross-hairs are on the sea slightly to the southeast of what I want to identify. -- Hoary (talk) 01:48, 22 December 2013 (UTC)

Do we have any guidance on...?
Some coordinates on Wikipedia are listed in decimal degrees, some in degrees/minutes/seconds. There doesn't seem to be any pattern. I'm not surprised, as it's something of a personal preference. (If anything, my only surprise is not to have encountered a pointless flamewar over which format is "better".) Nevertheless, I think it'd be good to touch on this issue in the guidelines, if only to say, "there is no standard, use whichever you prefer, and if you want to see them all the same way across Wikipedia, use the display preferences in common.css, please don't start editing them all."

Similarly, I suspect there's no standard for the geodetic point we identify for cities (whether of the centroid, the central business district, city hall, that nice fountain in the middle of the park in the middle of downtown, etc.), but again, it'd be nice to touch on the issue, because the question comes up.

Finally, is there a preference to avoid redundant coordinates in articles? For example, some cities contain coordinates in the settlement infobox, and also an invocation of the Coord template, and sometimes the coordinates are different. I would have thought this was to be avoided (that is, that articles on entities with coordinates in the infobox should never contain explicit Coord invocations), but I noticed that the article we cite as an example, Los Angeles, does it this way, and with some extra markup for a "Geographic locale" boxlet which might or might not be important to someone to preserve. —Steve Summit (talk) 16:06, 1 January 2014 (UTC)


 * P.S. These questions are prompted, in part, by this thread at the administrator's noticeboard, which someone from this project might want to comment on.

For larger objects like cities, the current guidance is to to reduce precision to something appropriate to the size of the object, and then pick something vaguely "near the middle". Rather than precisely specifying an official center or canonical point in the city. There's a bit on that at WP:OPCOORD. There's been on and off discussion of supporting some way of specifying actual areas for non-point locations, possibly through Wikidata, and/or possibly by pulling in the outline from OpenStreetMap, in cases where they have one. --Delirium (talk) 02:19, 2 January 2014 (UTC)


 * I agree with Delirium. Doing it better than our current set of conventions is actually quite hard without going all the way to a proper GIS system, and there's no point in building another free content/free software GIS system when OpenStreetMap and its surrounding ecosystem already exists. I think that expanding this project to fuller integration with OpenStreetMap via Wikidata is the way to go, and we should try to foster stronger links with the OpenStreetMap community to make this happen. In the meantime, we should continue adding point coordinates with approximate size information in our existing manner, as it is both useful in itself as a crowdsourced data source independent of OpenStreetMap, and also as a large database of seed points for the eventual integration with OpenStreetMap data. -- The Anome (talk) 12:53, 2 January 2014 (UTC)
 * We certainly should have better links with OSM. See, for instance, my proposal for tagging objects there with Wikipedia links.  Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 13:30, 2 January 2014 (UTC)


 * That looks excellent, and I'm convinced this is the way to go for the future; starting with our existing ad-hoc single-point coding here, and then upgrading the data to full georeferenced data via automated/semi-automated processes such as the ones you are proposing. While we're at it, perhaps we can also take a fresh look at using OpenStreetMap integration to deal with the perennial issue of adding geodata to Wikipedia articles on linear features such as railway lines and roads? -- The Anome (talk) 13:47, 2 January 2014 (UTC)
 * Attached KML is available for linear features. --Bamyers99 (talk) 16:30, 2 January 2014 (UTC)

"To do" section transcluded at top of this page
A few days ago the boxed category links under "Fix", such as "Talk pages requiring geodata verification" for user-reported coord problems, stopped showing the "There are no pages in this category" message (or whatever it was; I can't recall exactly) under each link when the categories were empty; and I've just discovered that they don't now show links to the pages needing attention when there are items in a category. (Yes, I'm aware that one used to have to do a null edit to Wikipedia talk:WikiProject Geographical coordinates/to do to update the page. I used to check for problems regularly by doing that, but now one has to click on each link separately to see whether there are any pages in the categories.) I don't know enough about how such things work to identify what exactly was changed; can anyone here figure it out? Deor (talk) 20:03, 9 January 2014 (UTC)
 * I have submitted a bug report to MediaWiki. The . It produces a string which includes . The second number can be captured with  Test output: . I haven't examined whether all coord calls with valid parameters will output the expected string. If we use this in templates then we should make a separate template like extract longd so the code can be adapted in a single place. PrimeHunter (talk) 12:08, 24 January 2017 (UTC)
 * Jonesey95 and PrimeHunter, try  and  . Frietjes (talk) 15:59, 24 January 2017 (UTC)
 * That works. I didn't know we already had this. No need for me to reinvent the wheel. PrimeHunter (talk) 16:14, 24 January 2017 (UTC)
 * Thank you! As far as I can tell, it works great. I put that code into two templates after testing it in my sandbox and in the sandbox for one of the templates. Ironically, it appears that the longd test is not actually being used in any live pages, but I didn't want to remove it and silently break some obscure page that I could not find. – Jonesey95 (talk) 05:21, 25 January 2017 (UTC)
 * Is this going to be added to the coords documentation so we can find it in future?--ClemRutter (talk) 09:32, 25 January 2017 (UTC)
 * ClemRutter, as far as I can tell two new functions were added to the module on behalf of Jc86035, namely  and  .  I would think that they place to document these would be in the documentation for Module:Coordinates, perhaps with a pointer from Template:coord? Frietjes (talk) 14:26, 25 January 2017 (UTC)
 * I took a stab at a rough draft at Module:Coordinates, with a link from Template:coord. I probably used words like "function" wrong, so feel free to correct my text; I figured that something was better than nothing. I think there are specific parameters (type/scale/dim/globe/region/source) that can and can't be inserted with coordinsert, but I don't remember what they are. – Jonesey95 (talk) 22:11, 25 January 2017 (UTC)
 * I have added a little too. --ClemRutter (talk) 01:14, 26 January 2017 (UTC)

Nomination for merging of Template:Infobox map
Template:Infobox map has been nominated for merging with Template:Location map. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. —hike395 (talk) 03:40, 20 February 2017 (UTC)

Geocoding images through machine learning
This article about using machine learning to geocode photographs is fascinating. -- The Anome (talk) 15:20, 28 February 2017 (UTC)

The one million article milestone approaches
We are now up to 996,644 geocoded articles. Within the next few months, we will reach the point where [en:] Wikipedia has 1,000,000 geocoded articles. We should start thinking about how we can use this milestone event to publicize this project, with the goal of recruiting new contributors and securing and improving collaboration with other projects. -- The Anome (talk) 10:54, 28 February 2017 (UTC)


 * My ghel parser says "1,633,865 coordinates in 1,030,522 articles" for enwiki back in June 2016. — Dispenser 17:21, 28 February 2017 (UTC)


 * Interesting. I'm using to get my figure above: am I missing something? -- The Anome (talk) 19:53, 28 February 2017 (UTC)


 * I speculate you're missing those pages which have neither category, but which have a coordinate. 35k pages using some formulation which does not cause an appropriate category to be appended to the article seems not altogether unlikely. Now we just need to find an example. --Tagishsimon (talk) 22:27, 28 February 2017 (UTC)


 * That's interesting! Yes, it would be very interesting to track some of those down, so we can see what is happening. since you probably have the best tools for this, is this something you could do? -- The Anome (talk) 14:28, 2 March 2017 (UTC)


 * The full query takes about 20 minutes to run resulting in 500,000 coordinates on ~65,000 pages. There's a variety where people will stick random GeoHack links: Île-de-France tramway Line 6 (station listing), Çaykavak Pass (GeoHack link in text), Äiwoo language (missing category!?), and India–Bangladesh enclaves (locating image). I've added several to domains to the To Do list that we need to cull from the External links section. I've already done several thousand of the various Microsoft properties which already have coordinates.  — Dispenser 19:59, 3 March 2017 (UTC)

Debugging geotagged pages
I have just changed jobs and being a keen editor used "special:near" to see what articles were around me. I noticed that a number of articles were are being missed despite containing coordinates, is there a role for a debugging tool to catch these and figure out the issues?

Back ache (talk) 18:52, 14 March 2017 (UTC)

help with precision
I placed a citation needed Minute and second of arc about the precision of minutes and degrees which doesn't match the mentioned in WikiProject Geographical coordinates. Can anyone check this? ※ Sobreira ◣◥ (parlez) 09:35, 21 March 2017 (UTC)
 * Corrected and cleared by User:mwtoews. ※ Sobreira ◣◥ (parlez) 09:16, 24 March 2017 (UTC)

Added coords to table, but no pin in google map
I've added coords to the table in California Historical Landmarks in Fresno County, California for the site of the first junior college, but it won't appear in the map all coordinates using google. What have I done wrong? I have waited as suggested. Trilotat (talk) 19:21, 29 April 2017 (UTC)
 * You changed the coordinates for that after you added the other coordinates. Often in such cases it takes a day or two for Google Maps to show the pushpin in the correct position. Be patient and it will happen. Deor (talk) 20:04, 29 April 2017 (UTC)

Need another location map for Japan
Right now we have, which can be called in infoboxes by entering "Japan" as the map name. This produces the top map to the right. It can not be used for smaller locations such as Iwo Jima, however. For that, we would need to use the bottom map to the right. Can someone make a new (or whatever it should be named) so we can have a location map showing all of Japan? I would do it, but I don't understand the equations at the top of the templates. ··· 日本穣 ·  投稿  · Talk to Nihonjoe ·  Join WP Japan ! 23:17, 5 April 2017 (UTC)


 * Anyone? I would do this myself, but I don't know how. I'd rather someone who knows how create the map so I don't waste my time trying to figure it out. ··· 日本穣 ·  投稿  · Talk to Nihonjoe ·  Join WP Japan ! 22:44, 30 April 2017 (UTC)

Geographic coordinate system
An IP editor is making disruptive edits to Geographic coordinate system, making many ungrammatical edits. I urge editors to monitor this article. Jc3s5h (talk) 20:51, 16 June 2017 (UTC)

Rounding of summit elevations
There is a discussion at Template talk:Infobox mountain: should we follow sources for rounding of elevation, or is rounding covered by the MoS? Feel free to join the discussion. —hike395 (talk) 21:56, 3 July 2017 (UTC)

Sports teams
Is "Do not add coordinates to the following types of articles: [...] Sports teams (add to the stadium article instead)" a Wikipedia policy, or just advice for members of this wikiproject? If the former, should templates like infobox football club have their "coordinates=" field removed? --Gapfall (talk) 17:43, 6 July 2017 (UTC)


 * For what it's worth, another editor added coordinates back after I removed them from one football team article, saying "There is no stadium article for clubs at this level, so this is the only place coords can go. Almost all clubs I have seen in this situation have them, so perhaps best to ignore the essay to improve Wikipedia?" --Gapfall (talk) 08:12, 7 July 2017 (UTC)

Should fictional articles have coordinates?
Perhaps a silly question, but should they, if they have an unambiguous real-world location within the fiction? This project page doesn't seem to say anything either way. (Digging around for an example, The 4400 Center has a street address and is represented on the TV show by the building which is at that location.) --Gapfall (talk) 09:29, 7 July 2017 (UTC)
 * If it's an obviously real location, I don't see why not. ··· 日本穣 ·  投稿  · Talk to Nihonjoe ·  Join WP Japan ! 22:39, 7 July 2017 (UTC)

Semi-active wikiproject
Greetings, Today I added the WP Semi-active notice to the project page. If enough editors feel this is not warranted, then it is okay with me to remove the tag. Any discussion is welcome. Regards, — JoeHebda • (talk) 18:12, 25 July 2017 (UTC)

Bot for rounding overprecise coordinates?
Hi all, I was wondering if there was a need or desire for a bot that rounds overprecise 8 or 7 digit coordinates down to 6, because there's a huge backlog of these (>11k), and I feel like writing a bot. While working on this WikiProject I have seen that other bots have contributed to this project, but I'm not sure if there's a list of them somewhere or an existing bot or tool I could run a batch job on. And if this discussion is better suited for a different location, I would be happy to move it. Brubsby (talk) 21:30, 2 August 2017 (UTC)


 * If you read Bots and some of the pages it links to, you will know more than I do about bots at Wikipedia. I think you would first need a community consensus that this would be worthwhile, which you would seek at WP:VPR. Wherever you're getting your >11k number, you would need to link to that in the proposal. &#8213; Mandruss  &#9742;  21:53, 2 August 2017 (UTC)


 * Thanks! I'll head in that direction and get reading. And for reference, the >11k figure was from the Coordinate check tallies from the to do list, I just wasn't sure if this talk page was the best place for discussion about this backlog as I'm relatively new. Brubsby (talk) 22:18, 2 August 2017 (UTC)


 * The place for bots to be approved is at Bots/Requests for approval. Having the discussion here about whether this is something the community wants is fine, but I recommend doing it as an RfC. If you go that route, we can add it to the centralized discussion template, which will bring in a lot more people. ··· 日本穣 ·  投稿  · Talk to Nihonjoe ·  Join WP Japan ! 22:25, 2 August 2017 (UTC)


 * Nobody has suggested seeking community consensus here. I suggested VPR since that's where the successful Coordinates in infoboxes initiative got its community approval, and it had a lot in common with this (mass changes with a bot, albeit to templates not articles). I had forgotten that it was an RfC. &#8213; Mandruss  &#9742;  22:43, 2 August 2017 (UTC)


 * The location of the discussion is irrelevant as long as it's advertised in the right places. I never said anyone suggested that it be held here. I merely stated that having the discussion here was fine. ··· 日本穣 ·  投稿  · Talk to Nihonjoe ·  Join WP Japan ! 22:46, 2 August 2017 (UTC)


 * Ah, ok. Thanks. &#8213; Mandruss  &#9742;  22:47, 2 August 2017 (UTC)


 * I'm skeptical of a bot rounding precision automatically, because the normal expectation is that the coordinate will fall within the feature it's associated with. But for oddly shaped features, such as rivers, this could be a problem. A 7 digit longitude might be 359.1234°, and a change of 1 in the least significant digit would be 11.1 meters, which should be ok for almost all features. But a change of 1 in the sixth significant figure would be 111 meters, which could be enough to move the point outside the boundary of the feature. Jc3s5h (talk) 23:09, 2 August 2017 (UTC)


 * I thought we were talking about number of positions to the right of the decimal point, rounding 35.67732888 to 35.677329. I guess I got that from the OP's word "overprecise". Per WP:COORDPREC, 6 to the right is good for objects around one meter. &#8213; Mandruss  &#9742;  23:15, 2 August 2017 (UTC)


 * Yes, I only meant rounding coordinates with 8 or 7 digits to the right of the decimal point down to 6. I can't think of any cases where 7-8 decimals of precision is necessary for an article (as that's less than one meter), but it goes without saying that I'll go and seek approval and opinions on whether this pursuit is a good idea or not before starting. I suppose if there are enough cases where it shouldn't be rounded to 6 places, we could propose a change to the coord template to note this for specific instances that shouldn't be corrected. Brubsby (talk) 00:38, 3 August 2017 (UTC)


 * Seven would be recommended for objects around $1/10$ of a meter, or 10 cm, and eight for 1 cm. I'm pretty sure even 10 cm is more precise than online mapping tools (what's the represented distance between adjacent pixels at max zoom?), GPS devices (what's the accuracy of consumer GPS?), etc, and therefore would be a false precision if we used it. Even if devices and software become precise enough, what would be the practical benefit to distinguishing one point on the planet from another 10 cm away? I wouldn't complicate/clutter a proposal with such a sub-proposal. &#8213; Mandruss  &#9742;  01:05, 3 August 2017 (UTC)


 * There could be a need to be precise to the centimeter or even the millimeter on rare occasions. For example, our article Prime meridian (Greenwich) explains that the meridian is defined by the Airy transit circle ( 51.47781°N, -0.00147°W ). If in the future, the location of this instrument is defined more precisely in the ITRF I'm sure we would like to state it to the full known precision. Similarly, our article Washington meridians describes a number of historic prime meridians that pass through Washington, D.C. and are defined by monuments that still exist and have been measured to high precision by the U.S. National Geodetic Survey. (Admittedly, that article could do with some additional historical research to clarify which monument goes with which meridian.) Jc3s5h (talk) 09:37, 3 August 2017 (UTC)


 * Even 6 decimal places needs to be monitored for the effects of continental drift on objects small enough that level of precision is appropriate. For some objects, that digit would have changed over the life of Wikipedia already. --Scott Davis Talk 14:47, 3 August 2017 (UTC)


 * Thanks for pointing out these cases, they are excellent corner cases, fortunately they fall out of the intended scope of actions for the proposed bot. It seems all Washington meridians measurements are not using the Coord template, so they wouldn't get edited. Also, they (along with the prime meridian coords) are not in decimal degrees format, which would also fall out of the intended scope for the bot. Rounding overprecise coordinates in degrees minutes seconds format might be a worthy pursuit, but we currently don't seem to be tracking those cases anywhere. So it's hard to say whether the backlog of those would be so large that making a bot fix them would be a good use of time, especially if there are more corner cases than decimal degree Coords. If there are a significant number of corner cases for decimal degree Coords, there are multiple ways we could mark them. For instance, if there's only a small number of corner cases we could add a nobots template to each one aimed at just this bot, or if there are certain categories that have precise coordinates the bot could ignore those. Finally, as I mentioned before, if there are a lot of these such cases, amending the Coord template to be able to mark intended high precision coordinates might be worthwhile, for the bots operation and for tracking maintenance metrics about coordinates in general. Brubsby (talk) 16:23, 3 August 2017 (UTC)


 * I have proven there is a case for giving high precision coordinates. The proponents have not shown high precision coordinates are harmful. It seems to me it is up to the proponents of the bot to prove that the bot will not remove any valuable information. The fact that the high precision use cases I was able to come up with off the top of my head happen to not use this particular template, or happen to use degrees, minutes, and seconds rather than decimal degrees, does not diminish the likelyhood that other useful high precision coordinates in the format addressed by this bot exist. Jc3s5h (talk) 16:34, 3 August 2017 (UTC)


 * Good points! I'll get to work investigating more cases to attempt to prove the bot would not remove unreasonable amount of valuable information. I've learned that with other bots, sometimes the community has agreed to approve the bot's mission if there is a guaranteed bound on the false positive rate, so that may be something to consider here in the discussion. (e.g. the bot is okay if only every 1 in 200 edits is in error and has to be manually reverted) I think this rate is usually agreed upon by the community and then tested during the bot's trial period as part of the bot approval process. In addition, I would be more than willing to work with other editors to minimize the bot's false positive rate throughout the life cycle of the bot. As for evidence that high precision coordinates are harmful WP:OPCOORD, seems to imply that overprecise coordinates are at least against guidelines, and the existence of a pseudo maintenance category in the to do list under [|Coordinate check tallies], makes me believe there was consensus at one point that overprecise coordinates were harmful enough to track (and therefore be fixed/reduced). I would posit that if the high precision maintenance category has a certain percentage of overprecise coordinates (e.g. 99%), then that would seem to me that high precision coordinates are, in general, harmful. Insofar as they are generally likely to be overprecise. Brubsby (talk) 19:45, 3 August 2017 (UTC)

I think the harmfulness of needlessly precise coordinates needs to be judged differently for geographic coordinates than for most other numbers. If I write the equatorial radius of Pluto is 1,195,634 m, that is false precision, because according to page K7 in the Astronomical Almanac for the Year 2017 the value is 1,195 ± 5 km. I'm making up digits that no one actually knows. But if I give a geographic position, it's probably understood that I'm giving a point that falls within the associated feature. If I increase the precision, the point still falls within the feature, so it's still true (although not elegant).

Also keep in mind that the bot can't make the value elegant. An elegant value would be just precise enough to guarantee the point falls within the feature. That's way beyond the ability of the bot. The bot can only make many values less-inelegant, at the risk of throwing away meaningful precision. Jc3s5h (talk) 20:16, 3 August 2017 (UTC)


 * I think that making "many values less-inelegant," is a worthwhile pursuit, and my aim to begin with. Especially as there are >33k (I had the number wrong earlier) likely very inelegant values. The risk of throwing away meaningful precision will be mitigated by the bot approval process via trials and humans reviewing the bots actions. If the bot makes too many false positive edits it will not be allowed to continue and there will be nothing to worry about.


 * I don't think the creation of a bot is necessarily incumbent upon it changing something that is harmful in Wikipedia, but whether it does a laborious task that humans are otherwise wasting their time on. If you think we shouldn't waste time making the coordinates more appropriately precise, then I think we should have a discussion about whether the list of overprecise coordinates should be on the to do list to begin with. Brubsby (talk) 22:32, 3 August 2017 (UTC)

Even if a hidden comment is used in an attempt to protect a high precision, in my experience those comments are routinely missed or ignored (and they are often used inappropriately, so editors tend to have little respect for them in general). What's needed is a whitelist for the bot, easily found via a link in the bot's edit summary. It could be started even before the bot's first run, and expanded as new cases were identified. &#8213; Mandruss  &#9742;  04:18, 4 August 2017 (UTC)
 * A bot would likely make a very few bad calls. Human editors make bad calls too. In both cases, the error is expected to be corrected by a human editor who knows better.

Overprecise Bot Research
Hi all, I've gathered some data with the help of User:Dispenser, and have taken a random sample from all of the likely candidates for this bot. I'll describe my methodology a little, and report my findings.

Methodology

One of the easiest paths to gathering the necessary data was by looking at all external links to geohack, and then applying successive filters to get down to only the cases I am intending to change (overprecise dec coordinates). The filters I used were these:
 * The geohack link has lat and lon parameters (some links have only one or the other).
 * The link has no minute or second parameters specified for lat or lon whatsoever.
 * The link has at least one match with this regular expression "\.[0-9]{7,}" (7 or more decimal places of precision).
 * The link is from article space. (This wasn't included in the data, so I had to call the wikimedia query API during sampling)

The first three filters applied gave me a total count of 84,922 links, but this includes all links from every namespace (I believe). And I do not yet have an official count of all cases just in article space, but glupt should be a strong estimate.

Open Questions

So, after conducting this research I'm still confident in my proposal for this bot, but would like to request comments from the community.


 * What is the standing consensus for the precision of imported GNIS coordinates? GNIS often (if not always) specifies a precision higher than our project's precision guidelines, but it does feel a bit weird to round the original source down. ✅
 * Are cases with extreme decimal precision, but format=dms, worth rounding down? My vote is yes, as the analytics from geohack data are still affected. (And I have seen examples of wikidata projects attempting to use precision of coordinates in their projects)
 * Am I missing something with the lat/lon templates (e.g. Grade II* listed buildings in Anglesey), I thought there was action taken to correct these non-Coord cases. Or was that only infoboxes with lat/lon? They should be easy to avoid with this bot, but seem as though they should be fixed.
 * Has this sampling been sufficient to appease concerns about bot error rate? If no, would a larger sample size convince you? I limited it to 100 because it is a pretty labor intensive process.

Thanks! Brubsby (talk) 17:43, 11 August 2017 (UTC)


 * I can think of one more case: attempting to reduce the precision of the coordinates of the tip of the Washington Monument, which I believe has ridiculously over-precise coordinates, resulted in a big talk page row about that precision, with another editor asserting that the position was known to incredibly high precision, and that this mattered deeply. I couldn't be bothered to dispute the point, so I went away. -- The Anome (talk) 22:14, 12 August 2017 (UTC)
 * If you want to argue that the coordinates of the Washington Monument are more precise than the Wikipedia reading audience needs, perhaps you could make that point. But if you read our article Position resection you will see high precision coordinates would be quite useful for a person trying to find the precise coordinates of a point in Washington DC, if the person is equipped with a theodolite. Jc3s5h (talk) 09:52, 14 August 2017 (UTC)
 * Thanks for the heads up, that'll definitely fall into the "pages to blacklist" category. Brubsby (talk) 20:18, 14 August 2017 (UTC)


 * We routinely round GNIS coordinates per our guidelines, and I haven't seen an objection to that. To my knowledge GNIS always shows d.ddddddd and ddmmss precisions. But Yosemite National Park, for example, rounds that to ddmm while citing GNIS. I assume the same would apply to other sources of coords; their needs and constraints are different from ours and WP:V does not require us to match their precision. &#8213; Mandruss  &#9742;  01:32, 14 August 2017 (UTC)
 * Good to hear, this is what I had anticipated was consensus. Good to know for when I'm manually adding coords from GNIS, but also makes the bot simpler to not have to treat GNIS sources specially. Brubsby (talk) 20:18, 14 August 2017 (UTC)

leading zeroes in D:M:S format?
Is there any consensus as to whether 12.0625°N, -67.13583°W or 12.0625°N, -67.13583°W is preferable? By analogy with HH:MM:SS, I've been using leading zeroes on single-digit degrees and seconds, but I see many examples that don't. —Steve Summit (talk) 02:16, 21 August 2017 (UTC)


 * I've never noticed any consensus, either within Wikipedia or without. Jc3s5h (talk) 04:01, 21 August 2017 (UTC)

Standardising map parameters in infoboxes
I'm proposing to standardise the map parameter names in infoboxes; please see, and comment at, Village pump (technical). Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 14:10, 28 August 2017 (UTC)

Change to precision tables
I'm mulling the idea of removing the 0° columns from the tables at WP:COORDPREC, but I wanted to seek some comments first. A close look at the tables reveals that this change would affect only one narrow set of cases: DMS format coordinates, object size ~300km-750km, latitude 0°-15°. The table currently suggests d° m' for those cases and that would become d°. So I wonder whether the 0° columns earn their keep. While removing the 0° column from the decimal-format table alone would have no effect at all, I'd prefer to keep the table formats consistent with each other. ― Mandruss  &#9742;  13:44, 2 October 2017 (UTC)


 * I have been concerned about the practice of rounding off the location of objects based on the size of the object, instead of the precision with which the data was gathered, or if that is unknown, the precision with which the data was stated in the source. While studying this, I used ARCGIS to make a map of Vermont with town and city boundaries downloaded from the VCGI's Open Geodata Portal. I then added green diamonds that represent the full-precision latitude and longitude of Vermont towns and cities from the US Census Bureau. Finally, I selected some of these towns and rounded the latitude and longitude as directed by the table that Mandruss is asking about in this thread, and plotted the results with orange triangles. Here is the result:




 * I found that the US Census lat and long were not necessarily centered in the boundary. When I rounded, I found the magnitude of the shift was large enough to move the point outside the boundary of the town. However, in the examples I tried, the shift was in a lucky direction and the point didn't move outside the boundary. But I feel safe in saying if this procedure was repeated on a large enough sample, there would be cases where the point ends up outside the boundary. Jc3s5h (talk) 15:42, 2 October 2017 (UTC)


 * I was afraid this would segue into a discussion of coordinates precision. I don't like to use the word "hijack", but maybe we could keep that separate? &#8213; Mandruss  &#9742;  15:47, 2 October 2017 (UTC)


 * Well, since I've demonstrated the rounding is already too loose, any change that promotes rougher rounding would be bad. Jc3s5h (talk) 15:55, 2 October 2017 (UTC)


 * Have you demonstrated that rounding is too loose for object size ~300km-750km, latitude 0°-15°? Anyway, 1. I don't think anybody would object to using one level more precision than the tables recommend if that's necessary to keep the marker within the boundaries. 2. I don't think any source of coordinates is inherently more authoritative than Google Maps and the human eyeball, for locations that are not disputed, controversial, or ambiguous. If the source's coordinates create a problem, we don't have to use that source. &#8213; Mandruss  &#9742;  16:02, 2 October 2017 (UTC)


 * I have not examined the case of object size ~300km-750km, latitude 0°-15°. The table is not restricted to any particular source of coordinates. We can expect that bot authors might use the table to control the rounding behavior of the bots. Bots would typically obtain latitudes and longitudes that make that readily available in text or database form. Such sources may not have a goal of centering the point in the shape. Their goal may be to place the point at the capital of a country, courthouse in the county seat of a county, city hall of a city, etc. And bots certainly don't have eyeballs. And when bots make mistakes, they make a large number of mistakes. Jc3s5h (talk) 16:40, 2≥ October 2017 (UTC)

Overprecision
I think you guys might be being overprecise by several orders of magnitude. I have never needed to go more precise than 0.5" to mark even such objects as statues. I was told at here at WP:Geographical_coordinates many years ago to stick to arcseconds or to dd.dddd° (four digits) for the most precision one would ever need. Abductive  (reasoning) 05:29, 3 October 2017 (UTC)
 * I do more camera locations, and for those I like one more digit especially when using DMS. Of course, it also depends on source. Google Earth aerial photography is usually consistent to a meter or three in the New York metro area but Pittsburgh is often ten times as rough. Historic site databases often add several digits precision when converting to decimal degrees, thus misleading the unwary. So, be wary. Jim.henderson (talk) 17:44, 17 November 2017 (UTC)

180th meridian listed at Requested moves
A requested move discussion has been initiated for 180th meridian to be moved to Antimeridian. This page is of interest to this WikiProject and interested members may want to participate in the discussion here. —RMCD bot 20:45, 28 November 2017 (UTC)
 * To opt out of RM notifications on this page, transclude, or set up Article alerts for this WikiProject.

Schools w/ multiple campuses
How do I attach more than one set of coordinates to an article? Several schools for example have multiple campuses and I want to add the data for all campuses.

Thanks WhisperToMe (talk) 01:09, 3 December 2017 (UTC)


 * You can put coordinates anywhere you want in an article. Just code a with inline (that's the default, so you can alternatively omit the display parameter). Pioneer Library System shows one method using a table. Norman, Oklahoma includes coordinates within the text. Optionally, you can include a  in "External links" to allow display of all the article's coordinates on one map; see Pioneer Library System. &#8213; Mandruss   &#9742;  04:24, 3 December 2017 (UTC)
 * Thank you so much! WhisperToMe (talk) 06:36, 4 December 2017 (UTC)

Proposed merge
There is a proposal to merge Vertical metre into Metres above sea level. Please feel free to join in the discussion at Talk:Metres above sea level. —hike395 (talk) 13:29, 29 December 2017 (UTC)

Template:GeoGroup
I made some changes to the GeoGroup template. See discussion on template talk page - Samuel Wiki (talk) 07:44, 20 January 2018 (UTC)

Whitlingham Geohack link
The Geohack link arrived at by clicking on the coordinates on the Whitlingham article has 'Wikimedia maps' on the RHS rather than 'Great Britain', I have noticed that the region parameter in the panel at the top is missing, it should be 'GB', any ideas ? Thanks GrahamHardy (talk) 09:10, 28 January 2018 (UTC)
 * I added region and type. Is that better? &#8213; Mandruss  &#9742;  10:07, 28 January 2018 (UTC)
 * Brilliant, Thanks GrahamHardy (talk)