Wikipedia talk:WikiProject Geographical coordinates/Archive 29

Archive 25

←

Archive 27

Archive 28

Archive 29

Archive 30

A geonewbie asks

I've just 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 this page at Geohack. The upper half of this is a list of "Global services" and another of "Japan". Looking at the latter:

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.

I scored seven out of nine. Should I be grateful (are glitches common), or does something need attention?

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#maps.mail.ru 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) &x=ppp&y=qqq you should give it (say) &lat=ppp&lon=qqq. 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). --Redrose64 (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 <categorytree> software was modified and there are a couple of bugs. --Bamyers99 (talk) 23:17, 9 January 2014 (UTC)

Thanks. Deor (talk) 23:27, 9 January 2014 (UTC)

Oops, there was already a bug report. --Bamyers99 (talk) 15:32, 11 January 2014 (UTC)

 Fixed The wiki configuration change that caused this has been reverted. --Bamyers99 (talk) 00:18, 12 January 2014 (UTC)

Excellent. Thanks again, since it looks as though they were ready to close the bug before your second report alerted them that the problem wasn't completely corrected. Deor (talk) 01:01, 12 January 2014 (UTC)

It seems that I spoke too soon; it was working yesterday but seems to have stopped working today. Deor (talk) 18:44, 13 January 2014 (UTC)

The configuration revert was reverted because it had only reverted part of the original change and caused performance issues on some wikis. --Bamyers99 (talk) 20:23, 13 January 2014 (UTC)

I have implemented a temporary fix until categorytree is working again. --Bamyers99 (talk) 02:55, 14 January 2014 (UTC)

Google Earth not showing every coordinate

I know that there are many articles that I have worked on that will not show coordinates on Google Earth, even if the information on it has been there for a year. Do we know why this might be? Thanks! Kevin Rutherford (talk) 22:06, 12 January 2014 (UTC)

@User:Ktr101: probably part of the wider abandonment of Wikipedia support by Google Maps. See here for context. Nobody seems to care, not even here :( --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 15:21, 20 January 2014 (UTC)

Wow, this really does put a damper on things, as this seems to be the only way to advertise our wares in certain instances. Kevin Rutherford (talk) 17:29, 20 January 2014 (UTC)

I don't know whether there's a firm horizon but GE for Windows or for Android usually shows me a W for my locations from more than three years ago, and usually not those from less than two years ago. It makes me dispair of Google for this purpose and wish for a more robust Open Street Maps including an OSM mobile app. Jim.henderson (talk) 13:02, 22 January 2014 (UTC)

USGS GNIS requires login?

To my surprise, it seems that GNIS queries now require a login. Fortunately, existing GNIS links are not broken, Has anyone tried to get an account? —hike395 (talk) 13:49, 28 January 2014 (UTC)

"Coordinates not on Wikidata"

I added coordinates to Pinnacles National Forest, so it's no longer categorized as missing coordinates; but now is under category:Coordinates not on Wikidata. I'm not clear on whether anything further ought to be done. The terse instructions at Wikidata:Coordinates tracking ("import it") are pretty unclear to me. TJRC (talk) 21:54, 17 February 2014 (UTC)

Don't worry about it. A bot might sort it out. --Redrose64 (talk) 23:38, 17 February 2014 (UTC)

GPS, MOS and events

I tried to find guidelines about whether and how GPS coordinates should be used in articles about events. Wikipedia:Manual_of_Style/Dates_and_numbers#Geographical_coordinates does not have anything to say about this. This project's page offers some more information:

• in Wikipedia:WikiProject_Geographical_coordinates#Usage_guidelines, which is tagged as a advice (so not binding, unlike MoS), it is stated: "Coordinates should also be added to articles about events that are associated with a single location, for example, the Ufa train disaster. "
• the description of the coord template event parameter states: "one-time or regular events and incidents that occurred at a specific location, including battles, earthquakes, festivals, and shipwrecks"

My concern is two fold:

• first, MoS should contain an entry about events, which should be discussed and advanced beyond a mere advice;
• second - as far as I know, no tool that uses Wikipedia GPS overlay offers the ability to turn off events (or otherwise sort GPS by type). This means that the maps by default are confusingly spammed with all GPS coordinates, which can make the Wikipedia layer confusing. One one level, I appreciate the ability to find out what historical or recurring events take place nearby, but I think we should try to figure out how to turn it off by default and leave it as an extra option. As such, I suggest we implement a filter in the Wikipedia:WikiMiniAtlas as well as Wikipedia:Nearby, and set them both to default to not display non-landmarks unless such an option is chosen. Thoughts? PS. I noticed that a lot of events use keyword landmark; this is probably people don't realize what it means - because the keyword doesn't do anything at this point... --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 13:01, 13 January 2014 (UTC)

The keyword is rather important. Apart from landmark we would want to display city, country, adm*, mountain etc. etc. So I absolutely advise against "to not display non-landmarks" (but that is probably not really your intention anyways). And yes, those keywords actually mean something! The map symbols and the way the labels are formatted depend on them. --Dschwen 18:20, 3 March 2014 (UTC)

Unlike you, I want to see events included in Wikipedia layers on maps. Calling them "spam" is unnecessary hyperbole. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 3 March 2014 (UTC)

coords for top-level country articles

I've just noticed that rather few of our articles on the world's countries actually have coordinates for the countries. Is this deliberate? (Part of the reason may be that the {{Infobox country}} template has lat and long parameters that seem to have been usurped for the coordinates of the capital city, so they can't be used for the whole country. I've also raised this question on the template talk page.) —Steve Summit (talk) 02:33, 3 March 2014 (UTC)

How can one point represent an entire country? The coordinates of the capital are still a point within the country, so I don't understand why you say they can't be used for the whole of it. As an alternative, what coordinates should be used instead? The country's geographical centre? Or a random point somewhere? We also need to be careful about WP:OPCOORD - for example, a point representing the Vatican should be a reasonable representation of its location, at the right scale. But a point representing Russia wouldn't really work at any scale. Bazonka (talk) 17:44, 3 March 2014 (UTC)

It's a mistake to assume that the coordinates are of "one point [to] represent an entire country"; any more than the coordinates of a US state or English county do. They represent the approximate centre of the map that shows the entity under discussion, and we make nor assert no other claim about them. The coordinates of near-coastal Washington DC do not represent the map of the USA. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:17, 3 March 2014 (UTC)

There are 200-odd countries in the world, and most of them are small enough that their area is pretty small on a large-scale map, so it's not unreasonable to represent them as a single dot. And then, yes, for the larger countries, a point near the center of the country is appropriate. That point will indeed have low precision: see our France article for one example, and Russia for an even better one -- note that not only do the latitude and longitude both end in 0, but they have multiples of 3 in the 10's place. —Steve Summit (talk) 22:40, 3 March 2014 (UTC)

US - 22,295 coord missing

If anyone's interested, I've tabulated the numbers of US articles needing coordinates at Category talk:United States articles missing geocoordinate data by ripping off the UK equivalent - previously there was no easy way to eg see that there were 3,309 articles needing geotagging in California, as it was spread over 59 subcategories. Hopefully that might inspire some people to have a go at reducing the backlog - at least the US doesn't have the medieval lost buildings/events that the UK does, which take a lot of research to locate! Each state has typically only a couple of hundred, so it makes for a nice finite little sub-project; CA Wikpedians can tackle it a county at a time. I've also knocked a load of UK/Wales/US coord missings down into their respective subcats. Le Deluge (talk) 13:11, 16 March 2014 (UTC)

As a small addendum, I've now cleaned out that top United States category (for the first time in at least 5 years AFAICT) - but I'll leave it to someone else to keep it that way! Le Deluge (talk) 20:19, 17 March 2014 (UTC)

@Le Deluge: Splendid work, thank you! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:25, 17 March 2014 (UTC)

Should Extension:GeoData store non-mainspace coordinates?

Hi, I was wondering if there's any point in storing coordinates for something other than articles? What can be the use cases for searching outside of mainspace? Currently, there are some pages mostly in userspace with a lot of coordinate templates and I was thinking of not storing their coordinates in database. Here is the list of 100 pages with most coordinates. Thoughts? Max Semenik (talk) 20:33, 22 March 2014 (UTC)

Coordinates for Sevastopol's location map

Hi guys,

I have been breaking my head trying to get the coordinates right for the location map we are using for Sevastopol: {{Location map Sevastopol}}

Can someone lend a hand? I can't figure it out correctly and when we invoke it on infoboxes the pushpins are placed incorrectly on the map.

—Ahnoneemoos (talk) 17:10, 29 March 2014 (UTC)

I've added the coordinates to the infobox, along with a pushpin map. I've omitted the region code, since the controlling nation is currently in dispute (I've noticed a lot of back-and-forth regarding region codes in Crimea-related articles lately). It might be thought that the image map currently in the infobox is unnecessary with the location map there. Deor (talk) 18:49, 29 March 2014 (UTC)

@Ahnoneemoos: I obviously read your message too hastily; I thought you were referring to the Sevastopol article rather than to {{Location map Sevastopol}}. It will take someone more adept with templates than I to fix that (though I will note that the longitude range in the template appears to be too wide). Deor (talk) 19:33, 29 March 2014 (UTC)

Template:Circle of latitude

Hi, please see:

http://en.wikipedia.org/wiki/Template_talk:Convert#Template:Circle_of_latitude — Preceding unsigned comment added by 86.176.208.33 (talk) 11:09, 8 May 2014 (UTC)

{{Lunar coords and quad cat}}

Template:Lunar coords and quad cat (edit | talk | history | links | watch | logs) has been nominated for merger. -- 65.94.171.206 (talk) 06:36, 9 May 2014 (UTC)

Chinese coordinates

I've been having some snafus with Chinese coordinates, particularly for the city of Nanjing seeing differences between where the coordinate lands in Google earth vs. Google map mode.

For Qingliangshan Park, the article has the {{coord|32|03|07|N|118|45|24|E|region:CN-32_type:mountain_source:kolossus-dewiki|display=title}} coordinate... but it does not show up in the right place in Google or Baidu maps. It does, though, in Map Quest.

Do you know how I can verify if this is the right coordinate? And, if it doesn't display correctly, it is wise to use the coor template?

Thanks!--CaroleHenson (talk) 00:30, 16 May 2014 (UTC)

@CaroleHenson: I'm not sure what the issue is here and I'm assuming that you are accessing these sites via Geohack. For me, the coordinates show the correct location in GoogleMaps and OpenStreetMap, which are the two most commonly used mapping sites in the West, while the later is the basis for the Wiki MiniAtlas (i.e. the inline map). Similarly, GoogleEarth takes me right to the park. I don't known why it's showing up slightly to the west on Baidu maps, possible because they don't use a USGS grid. MapQuest on the other hand is telling me "We could not find "Qingliangshan Park" Please try your search again." There is nothing wrong with the {{coord}} template AFAIK.  Philg88 ^♦talk 04:36, 16 May 2014 (UTC)

@Philg88: Thanks for your reply. Yes, I used Geohack. I'm scratching my head about Google and I think I mixed up 2 searches:

• Baidu I'm having the same result.
• Google maps, now map view shows just west of Huju Road in Stone City. It was way off before, as was earth view, but earth and map view were in slightly different places. In earth view, the map screen goes green and it now says it cannot access the coordinates. Before it was so far off that I wasn't able to easily find the park, so I gave up trying. (As an aside, earth and map view have been varying for me for Nanjing. Anything I've needed to verify, I've been checking on Biadu once I have the Chinese characters. I think that JohnB?? that was also working on the North River Avenue, etc articles had the same problem with Google.)
• I must have mixed up the explanation of my MapQuest and OpenStreetView results - because I'm now seeing what you saw. For MapQuest I tried changing the labels (Quingliang Park, Quingliang Temple, 清凉山公园, etc. but still didn't get it). For me, OpenStreetView is the only one that is accurate.

I'm not sure what the next step should be. Thanks again for your help! You are multi-talented!--CaroleHenson (talk) 05:20, 16 May 2014 (UTC)

You're welcome. With Google it might be a browser cache issue, try clearing that and see if it helps.  Philg88 ^♦talk 05:58, 16 May 2014 (UTC)

Good idea! I cleared the cache, but am still having the same issue for Qingliangshan Park.

And for Gulin Park, too. (Baidu off to the right -- Google in the vicinity but not correct in map mode, not able to access earth mode -- OpenStreetMap is right on -- unable to access MapQuest).--CaroleHenson (talk)

Maps appear to be shifted a few hundred meters compared to sattelite images. You can see that clearly by simply switching from one mode to the other in Bing or Google. The direction of the shift does not appear to be the same for all map providers. I think I have read somewhere that it wasimposed by the Chinese government. Satellite images seem to be more consistent across map providers, and I should imagine that, as opposed to map, they are not tweaked. --Superzoulou (talk) 12:14, 17 May 2014 (UTC)

Ok, interesting. So, it would seem that there's nothing we can do about it. Thanks!--CaroleHenson (talk) 17:12, 17 May 2014 (UTC)

Progress

For some time, I've been tracking the progress of geocoding on enwiki, and I just thought that I should let you all know that we are making excellent progress.

As of today, roughly 85% of all potentially geocodeable articles now have coordinates, and most new geocodeable articles are typically geocoded either on creation, or within a month of creation. The backlog is now at the lowest level ever since I started monitoring it in late 2010, measured as a ratio of the size of the backlog to the number of articles on Wikipedia, and is also very nearly at its lowest ever in absolute terms. (See User:The Anome/Number of articles needing coordinates for details.)

Kudos to all involved. -- The Anome (talk) 11:24, 22 May 2014 (UTC)

And kudos to you; thank you for your invaluable work on this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:18, 22 May 2014 (UTC)

The 20-20 Vision of Wales Challenge

A call has been made for other languages to write on Welsh themes. A great start today with many new articles. Any help in running this would be appreciated - grab the reins and to the wind! Llywelyn2000 (talk) 22:02, 24 May 2014 (UTC)

Toolserver shutdown

As I understand it, all Toolserver tools are scheduled to be deleted at the end of this month. I, for one, find tools such as coord-enwiki.log and glupt.log invaluable for identifiying formatting and other errors in the geotagging of WP articles, though Dispenser has apparently no interest in migrating the tools to Wikimedia Labs. I fear the inevitable degradation of geocoding on WP articles in the absense of such tools; is there really nothing that can be done to forestall this? Deor (talk) 16:33, 9 June 2014 (UTC)

Over the weekend I was contacted by someone looking for old geo dumps. I barely have space (5 GB) for a logs archive, let alone old compressed dumps. I've asked for 24 TB for all my tools the last half year and every WMF employee/contractor at last week's WikiConference. "You did not have that on Toolserver" and "Write me a proposal" were the responses. You are of course welcomed to write that proposal. — Dispenser 17:57, 9 June 2014 (UTC)

{{Lunar coords and quad cat}}

Template:Lunar coords and quad cat (edit | talk | history | links | watch | logs) has been nominated for merger. -- 65.94.171.126 (talk) 05:42, 13 June 2014 (UTC)

Rivers layer

I'm curious, where does the layer that marks a river (e.g in the WikiMiniAtlas at Yarmouk River) comes from? What in the page links to it? trespassers william (talk) 13:39, 11 June 2014 (UTC)

The raw data comes from OpenStreetMap (OSM). OSM allows the addition of special Wikipedia tags as part of the markup data, which is cross-referenced via Wikidata.  Philg88 ^♦talk 16:16, 11 June 2014 (UTC)

Here's my proposal on the OSM wiki for a bot-job to add more of the tags referred to by User:Philg88. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:42, 26 June 2014 (UTC)

Leaflet for Wikiproject Geographical Coordinates at Wikimania 2014

Hi all,

My name is Adi Khajuria and I am helping out with Wikimania 2014 in London.

One of our initiatives is to create leaflets to increase the discoverability of various wikimedia projects, and showcase the breadth of activity within wikimedia. Any kind of project can have a physical paper leaflet designed - for free - as a tool to help recruit new contributors. These leaflets will be printed at Wikimania 2014, and the designs can be re-used in the future at other events and locations.

This is particularly aimed at highlighting less discoverable but successful projects, e.g:

• Active Wikiprojects: Wikiproject Medicine, WikiProject Video Games, Wikiproject Film

• Tech projects/Tools, which may be looking for either users or developers.

• Less known major projects: Wikinews, Wikidata, Wikivoyage, etc.

• Wiki Loves Parliaments, Wiki Loves Monuments, Wiki Loves ____

• Wikimedia thematic organisations, Wikiwomen’s Collaborative, The Signpost

The deadline for submissions is 1st July 2014

For more information or to sign up for one for your project, go to:

Project leaflets
Adikhajuria (talk) 17:45, 27 June 2014 (UTC)

'Nearby' feature removed from app

I'm sorry to have to report that the very useful 'nearby' feature, which used the coordinates added by our hard work to display the tagged articles nearest to the user's location, has been removed from the official Wikipedia app for Android, in today's upgrade. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 01:30, 26 June 2014 (UTC)

I hope similar map features can be made to work well eventually. It would have been handy yesterday while bicycling with my camera. Time ran short and without the map I couldn't quickly find and fill missing picture slots in National Register of Historic Places listings in Yonkers, New York.Jim.henderson (talk) 11:44, 29 June 2014 (UTC)

The Wikimedia Foundation is creating a Maps & Geo team. --Bamyers99 (talk) 14:01, 29 June 2014 (UTC)

What does that have to do with the removal of the 'nearby' feature? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:03, 29 June 2014 (UTC)

"Next the'll work with the Mobile Web and App team to empower our users to use mapping resources." --Bamyers99 (talk) 19:10, 29 June 2014 (UTC)

The feature already worked well. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:03, 29 June 2014 (UTC)

I hope all these mobile mapping things can be brought together nicely. That would allow going from article to its map whether one location or a list. And from map to article that's on the map. And between photo and map that shows all the photos in that place or in the place I'm in. And from Wikipedia's map to Google's map and back. All the mobile mapping things now are separate instead of working together, and they don't always even work well separately. Jim.henderson (talk) 15:58, 1 July 2014 (UTC)

WP:OPCOORD tables

I have studied the tables at WP:OPCOORD on this page, and I would like to inquire as to the value of rows 3 and 5 of the left-hand table. They provide precisions for one-tenth of a minute and one-hundredth of a minute, respectively. Is it possible to show fractional minutes in coordinates (e.g. 34°27.3'N)? If it's possible, would anyone actually do that rather than use the seconds value (34°27'18"N)? If not, what would one do with that information? To me it seems to only get in the way of one's understanding of the table and the concepts represented therein. Any comments? Cheers, Mandruss (talk) 12:06, 5 July 2014 (UTC)

Yes, fractions may be given for any of degrees, minutes or seconds, provided that smaller subdivisions are not used as well. So {{coord|34|27.3|N|1|0.5|W}} is valid, but {{coord|34|27.05|15|N|1|0.25|15|W}}, whilst mathematically the same (15 seconds = 0.25 minutes) is not valid - notice that it throws an error. --Redrose64 (talk) 12:47, 5 July 2014 (UTC)

Suggested precision help tables

After struggling with coordinates precision for awhile, I created some tables that I think would be useful to other editors. Do you see a place for these in existing help files? If so, where? Mandruss (talk) 11:35, 6 July 2014 (UTC)

Good job, Mandruss, these will improve editor's understanding of the importance of coordinate precision. I think the tables would be useful either on the project page or in the documentation for {{coord}}. Or both, but let's see what others think.  Philg88 ^♦talk 13:55, 6 July 2014 (UTC)

This may seem a trivial point, but maybe not to some. The first three cells of the first row of the dms table would more correctly contain d° m' s.sss". I used d° m' s.ss" there because (1) I've never seen anyone use seconds to three decimal positions, (2) the table at WP:OPCOORD only goes to two decimal positions, and (3) the difference isn't all that significant at that level. I'm willing to change that if anyone wants me to. Mandruss (talk) 14:33, 6 July 2014 (UTC)
I went ahead and made the above change because (1) I decided it's not appropriate for the table to suggest an arbitrary upper limit on precision, and (2) I wanted something to do. I'm willing to change it back if anyone wants me to. Mandruss (talk) 08:01, 7 July 2014 (UTC)

I have added the tables to the project page following the existing info at WP:OPCOORD. Although they might be of interest to some people using Template:Coord, they're not about how to code that template. That doc links once to WP:OPCOORD in its Quick guide section, saying "Avoid excessive precision." Hopefully, people who use the new tables and think they're useful will link to WP:OPCOORD in related edit summaries. There might be a case to be made for a new shortcut, if enough people start using the tables. Mandruss (talk) 13:07, 8 July 2014 (UTC)

Seeking coordinates advice

I asked this question in Teahouse and was directed here. This article is catted as needing coordinates. It is about an outbreak of wildfires across two states. It refers to locations using city and county names which are all linked. Looking for advice as to how to approach.

• Do nothing except remove the {{coord missing}}, since each of the linked cities and counties has its own coordinates
• Add title coordinates that approximate the center of ALL the fires with a low precision per WP:OPCOORD
• Add coordinates to this article for each of the named cities and counties (specifically where and in what form?)
• Research to try to establish more specific burn areas for each fire, estimate the center of each burn area, and add the resulting coordinates (ugh)
• Something else

Thanks! Mandruss (talk) 22:39, 15 July 2014 (UTC)

Usage guidelines say coordinates are for "events that are associated with a single location" (that is "more or less fixed in one place"). Since the article refers to multiple events over a widespread area, I don't think coordinates are really necessary. Cheers, Spencer^T♦C 01:32, 16 July 2014 (UTC)

Articles for each meridian/parallel

Are these really necessary? All they have is a list of cities that pass through them, so they don't seem to have much useful information. (except, of course, the Prime Meridian and Equator, Tropic of Cancer, etc.) See Template:Geographical coordinates for the whole list of lat/long articles.

Maybe all the minor articles could be merged into a "Lines of Latitude" and "Lines of Longitude" article, with a table with famous cities that pass through each line. Llightex (talk) 21:38, 2 September 2014 (UTC)

Most of the edits were made by Bazonka (talk · contribs), so sending a notification. --Redrose64 (talk) 23:08, 2 September 2014 (UTC)

I don't know which articles you've been looking at Llightex, but none of them only list cities. They contain lists of countries, territories, seas, and oceans through which the lines pass - much more information than just cities. Anyway, who are we to define what is and isn't useful to the readers of Wikipedia? The rule for inclusion in Wikipedia is notability, not usefulness. Some of these latitude/longitude articles have been raised at AFD before, and they have all sailed through as Keep due to their notability. Feel free to raise them again, but you will probably get the same outcome. Your suggestion about combining them all into one article would result in something that is extremely long, because of course, they don't just list cities. Bazonka (talk) 06:56, 3 September 2014 (UTC)

Yes, they are necessary. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 21 September 2014 (UTC)

Template

We need a new template (like template:Coord/Wikidata) which give its parameter from Wikidata, d:Property:P625. Thank you.--Çalak (talk) 11:55, 30 July 2014 (UTC)

We certainly need to migrate our activities to Wikidata and internationalize the geocoding work across Wikipedia editions, and automatically pulling coordinates from Wikidata will be an essential part of it. How exactly to go about this while maintaining forward and backward compatibility, preserving, and preventing loops in, data provenance, and detecting interference from vandalism on Wikidata, is a complex problem. One possibility would be to add this capability to {{coord}} itself. Whichever way we do it, it's going to be tricky, and will need a lot of thought. -- The Anome (talk) 23:25, 20 September 2014 (UTC)

Since Çalak's comment, {{Coord}} has been updated to fetch values form Wikidata. The documentation was updated in this edit. However, AFAICT, only latitude and longitude are fetched, not |region=, nor |type=. These still need to be set locally, according to this discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:45, 21 September 2014 (UTC)

Comment on the WikiProject X proposal

Hello there! As you may already know, most WikiProjects here on Wikipedia struggle to stay active after they've been founded. I believe there is a lot of potential for WikiProjects to facilitate collaboration across subject areas, so I have submitted a grant proposal with the Wikimedia Foundation for the "WikiProject X" project. WikiProject X will study what makes WikiProjects succeed in retaining editors and then design a prototype WikiProject system that will recruit contributors to WikiProjects and help them run effectively. Please review the proposal here and leave feedback. If you have any questions, you can ask on the proposal page or leave a message on my talk page. Thank you for your time! (Also, sorry about the posting mistake earlier. If someone already moved my message to the talk page, feel free to remove this posting.) Harej (talk) 22:47, 1 October 2014 (UTC)

Improved progress

This new and, I hope, exciting graph shows the apparent recent improvement in progress as of September/October 2014, after a recent period of having settled down to just keeping pace with Wikipedia's growth (although that itself is a significant achievement, given the vastness of Wikipedia and its rapid growth rate). The new trend seems to be have kept steady for two months, so I suspect this is a real trend, not just data fluctuation.

If (entirely hypothetically) this rate of straight-line improvement were to be kept up indefinitely, we would hit 100% somewhere in 2021-2022. Whether the apparent improvement in the rate of progress can be sustained (I would expect something more like a logistic curve in practice), and whether it was caused by the start of transwiki copying from Wikidata, is an interesting question -- The Anome (talk) 14:06, 19 October 2014 (UTC)

Category:Iran articles missing geocoordinate data

There are currently over 13,000 articles outstanding in Category:Iran articles missing geocoordinate data. It would be a big win if we could geocode these. Does anyone have access to either better machine-readable coordinates than are stored in GNIS, or (perhaps) a better approach to string-matching Arabic place-names than mere string comparison?

In addition, since I don't speak Farsi and thus can't do it myself, is anyone here an editor on fawiki, or a Farsi speaker willing to work with me on somehow cross-connecting geocoding efforts between the two projects? A look at the Google translation of fa:ویکی‌پدیا:ویکی‌پروژه_مختصات‌دهی seems to show that there is a local community already there working on the problem. -- The Anome (talk) 14:35, 19 October 2014 (UTC)

@The Anome:

Some or all of these may have occurred to you; but in case not:

• Import from Wikidata
• Import from OSM (see [1] and replies)
• Ask at Wikipedia talk:WikiProject Iran
• Ask at Wikipedia:Local_Embassy#فارسی (fa)
• Ask at meta:Wikimedia Embassy#F

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:30, 19 October 2014 (UTC)

Hi -- I've successfully imported everything I can from Wikidata, with quite a lot of success, but I've exhausted that source for the time being. Using OpenStreetMap data sounds really interesting, but I don't yet know how to get a sufficiently filtered OpenStreetMap dump that will allow me to download just place coordinates, instead of the full geodata for the entire map: I just haven't got the resources to wade through terabytes of map data to find what I need. The WikiProject and embassies sound like a good idea -- why didn't I think of that?

Also, a huge number of these Iranian-place articles seem to have been autogenerated using (among other things) Iranian state-published census data, but I don't know of any matching coordinates file that cross-correlates to the gazetter data set. If there were, and surely they must have them somewhere, this would be a trivial task. -- The Anome (talk) 21:27, 19 October 2014 (UTC)

Update: I've just posted to Wikipedia talk:WikiProject Iran asking for help on this. -- The Anome (talk) 23:43, 19 October 2014 (UTC)

Coordinate precision

Hello,

The Bool, Tagbilaran article currently has coordinates 9°37′58.80″N 123°52′48.00″E which I hear may be overly precise per WP:OPCOORD. A suggested change is 9°37′N 123°52′E, but that is then on another island.

(I am used to using a coordinate template, generated from geolocator, which doesn't work on the settlement Infobox. And, have never come upon this issue of over-precision before.)

Do you think that the 9°37′58.80″N 123°52′48.00″E could be used? If not, how do we get to coordinates that are not overly precise, but are at least in the correct general area of Tagbilaran? Thanks!--CaroleHenson (talk) 09:13, 30 October 2014 (UTC)

Personally, I usually find that coordinates expressed to the nearest 10 seconds are sufficient to indicate the location of a small village or a neighborhood. In this case, I'd go with something like 9°37′50″N 123°52′50″E. Hundredths of a second, which indicate a precision of about a foot, are far too precise. (9°38′N 123°53′E would also work, as they appear to indicate a point in the barangay, but rather outside the most-settled area.) Deor (talk) 09:29, 30 October 2014 (UTC)

Ok, great! It's now at the bottom edge of Bool, instead of the center, but it's at least it's in Bool. Thanks a lot!--CaroleHenson (talk) 09:46, 30 October 2014 (UTC)

Sorry, it's better than I first realized, taking into account the most settled areas! Actually, perfect! Thanks again!--CaroleHenson (talk) 09:52, 30 October 2014 (UTC)

There's no way to show that the trailing zero is not part of the precision, that what is meant is five-sixths of a minute, not fifty-sixtieths. If one cared about that, one could use decimal instead, with three decimal positions (object size ~2 km). 9.631°N 123.881°E would give a point about 220 m SW 70 m NE of the current point. But many people seem to prefer dms format, and I assume there are good reasons for it in some cases, such as when you're using a map that has grid lines in dms format. ‑‑Mandruss ☎ 17:22, 30 October 2014 (UTC)

Decimal-formatted coordinates have many advantages versus DMS: intuitive precision, easier and less error prone to transcribe (say to a GPS device), easier to use in arithmetic, less undue weight to a position, etc. I suspect DMS persists not because of a distinct preference but due to superstition, fear, and hubris. Many people I observe consider a coordinate to be close to a magic cookie in which they do not do the most elementary of inspections for reasonableness. Instead, they treat it as sacrosanct, unable to conceive of transforming it to be more simply expressed. This may also involve concern over violating ancient traditions and a vague fear that precision is lost if the same position is expressed with fewer symbols. Nevermind that in the 21st century almost all coordinates are handled electronically and actual lookup using a map resource via DMS is a scant minority. There be dragons in the mind here! —EncMstr (talk) 04:20, 31 October 2014 (UTC)

Sounds like good RfC fodder to me. Excise the demons and be done with it. But then everything sounds like good RfC fodder to me. ‑‑Mandruss ☎ 04:41, 31 October 2014 (UTC)

Btw, you omitted one item from your list of advantages to decimal: the situation in the above case. This could be expressed as "finer control of precision", I guess. The precision difference between dms and dm is a factor of 60; as is the difference between dm and d; but that factor is always 10 in the decimal format. ‑‑Mandruss ☎ 08:17, 31 October 2014 (UTC)

I was misinterpreting what Google Maps was telling me earlier, and I have corrected the above text accordingly. ‑‑Mandruss ☎ 05:15, 31 October 2014 (UTC)

The conversation after my 09:52, 30 October 2014 (UTC) posting is pretty much over my head. I used 9°37′50″N 123°52′50″E. Is that good, or should something else be used? Thanks!--CaroleHenson (talk) 22:11, 31 October 2014 (UTC)

I'd use 9.631°N 123.881°E, for multiple reasons, and I gather EncMstr agrees. 50 seconds is no better than 48 or 58 seconds when it comes to precision, and my decimal coords are only 70 meters—three-fourths of an American football field—from what you have now. Deor hasn't responded to our arguments. At this point, I guess it comes down to who do you trust, one experienced editor or another experienced editor and a former Adopt-a-user adoptee of yours? :) ‑‑Mandruss ☎ 22:36, 31 October 2014 (UTC)

Re-pinging EncMstr and Deor because I forgot to sign the first time. ‑‑Mandruss ☎ 22:36, 31 October 2014 (UTC)

• Just a little note, modern surveying instruments can geolocate to within about 2cm, so the question starts to be what precision is useful rather than accurate. All the best: Rich Farmbrough, 00:21, 12 November 2014 (UTC).
  

I have no idea what that means. Precision never had anything to do with accuracy, and it's very easy to be ten times as precise and half as accurate. Some elaboration might be in order. ‑‑Mandruss ☎ 00:30, 12 November 2014 (UTC)

Google Maps and {{GeoGroupTemplate}}

Please see this page from Google; we're about to be losing KML support for Google Maps classic, and apparently KML files can't be hosted on the ugly new version of Google Maps either. Cross-posting to the technical village pump. Nyttend (talk) 04:28, 17 November 2014 (UTC)

This was also brought up over at WT:USRD regarding KMLs more directly used in articles. Another editor has brought this up at meta:Tech#Google Maps changes to bring this to the attention of the WMF. We should consolidate these discussions in one place going forward. Imzadi 1979 → 20:47, 17 November 2014 (UTC)

I don't see any active discussion on this. Is anyone looking into this?

From what I can see (mostly this), one easy solution is to create a simple mostly-Javascript page which takes a KML file parameter and displays it just like Google Maps would.

Is that best done on a Wikipedia page? Or should it be on an external server? —EncMstr (talk) 01:03, 21 November 2014 (UTC)

The value of importing coordinates from Wikidata

As many of you know, The Anomebot2 has recently been importing coordinates from Wikidata into en.wikipedia articles. The rationale for this is clear—adding coordinates to articles that previously lacked them is certainly a positive contribution. There are, however, certain aspects of this activity that give me pause:

1. All of the imported coordinates are expressed to four decimal places of precision, regardless of whether they are for a building, a town, a province, or an entire country.
2. In the absence of any "type" or "dim" or "scale" parameter, all of them link to map resources displayed at the default 1:300,000 scale. (I admit that this isn't really much of a problem, but it is a bit of inconvenience for readers.) Other potenially useful parameters, such as region, are also not present.
3. Whereas some of the coordinates seem to be exactly correct (particularly those for buildings and other small-scale objects), many of them are off by varying distances. (In the bot's last pass, for instance, it imported coordinates for a whole bunch of Bulgarian villages, almost all of which were off by distances varying from a few hundred meters to a number of kilometers.)
4. A few of the coordinates are wildly incorrect. I realize that the same problem exists with coordinates added here by hand—but I question whether it's a good idea to indiscriminately import coordinates with no human review to catch errors.

The obvious response to this is that adding the coordinates is a Good Thing and that any problems can be corrected by Wikipedia editors in the normal course of work. On the other hand, the number of editors who deal with coordinates is not great, and it's extremely difficult for human editors to keep up with the pace at which a bot can import them. (I spent roughly 20 hours emending the Bulgarian-village coordinates and moving them into the articles' infoboxes so that location maps would display for the places.) Do any of the readers of this page have thoughts on the matter? Deor (talk) 11:26, 17 November 2014 (UTC)

I recall there was some discussion that coordinates could, in the future, pulled live directly from Wikidata, rather than manually mirrored between Wikipedia and Wikidata. I believe some (non-en) wikis are already using a system like that for some infobox elements. Is that something in the works in the medium-term future? If so, the problem might solve itself eventually. Wikidata itself ought to include most of the needed information: 1) entries are slowly getting a 'country' property, which can serve a similar role as the 'region' parameter; and 2) Wikidata coordinates explicitly have a precision along with the value, although admittedly this precision is not always set to a sensible value at the moment. --Delirium (talk) 12:24, 17 November 2014 (UTC)

Hi, and thanks for the comments. I have plans to address many of these issues. No bot-driven editing is ever perfect, and no data source is perfect either, so my overall criterion for doing anything with the bot is "does this improve or reduce the overall level of quality, and are any mistakes it makes as easily fixed as a manual edit?" Regarding the four decimal places: given that the Wikidata scale/precision values are only very rarely in any way sensible, this is a pragmatic compromise between too much and too little precision. Regarding the wildly incorrect values, yes, as you say, I think that adding the coordinates is a Good Thing and that any problems can be corrected by Wikipedia editors in the normal course of work -- and many thanks for your efforts on fixing the Bulgarian village coordinates. I'm also working on assigning regions to coordinates (something which Wikidata's coordinates lack) and also inferring approximate scale values, both using the enwiki category tree.

I am very enthusiastic about eventual total Wikidata integration for "primary" coordinates, as well as cross-linking to OpenStreetMap resources, but we need to move slowly on both of these to make sure we get it right. I see this sort of bot-copying only as a very first stage toward closer integration, using bulk copying instead of transclusion: I'm particularly interested to see what, and how many, changes get made to the Wikidata coordinates over the next few months. I'm currently dubious about on-the-fly use of Wikidata coordinates, because there's very little oversight over them on Wikidata, and no easy way for normal Wikipedia editors to apply quality control to them locally, as the Bulgarian village example demonstrates. What I'd really like is for Wikidata transclusion to be more closely integrated into Wikipedia's changes and watchlist system, so that editors here can both track page changes made by Wikidata updates, and also edit the transcluded Wikidata values easily from within the local Wikipedia interface. If we can crack that problem, however, then we'd be a long way along towards real-time transclusion being both practical and desirable, at least for the "primary" coordinate for articles. -- The Anome (talk) 13:06, 17 November 2014 (UTC)

Staying on the topic of Bulgarian villages, since those are freshest in my mind: The coordinates for them on Wikidata all seem to exist in the format xx°xx'0" (or the nonsensical xx°xx'60"), in which, I assume, the seconds figures are just there for show and they are actually just degrees-and-minutes coordinates—which, when they're not even more imprecise, are usually too imprecise for a place that may measure only one or two hundred meters from end to end. (They're all apparently taken from ru.wikipedia, though I have a suspicion what the ultimate source is, and it's not necessarily a reliable source.) Now, having dealt with them here to the best of my ability, I have no stomach for going to Wikidata and trying to emend all of them there, so I applaud your vision of a time when "editors here can ... edit the transcluded Wikidata values easily from within the local Wikipedia interface"; but that time is not yet. As long as we have useful infobox functionalities (like location maps, default "type" parameters, and automatic supplying of "region" parameters) that these imported coordinates can't make use of and no way to effectively emend the coordinates at the source, I guess I still wonder whether at present the work the bot may be creating outweighs the work it's perfoming. I have no settled opinion myself, and I thought of just discussing this on your talk page; but on reflection I decided that a wider range of opinions might be helpful. Deor (talk) 13:59, 17 November 2014 (UTC)

[ec with Deor] When a bot's adding coordinates, more precision is better than less in my mind. A bot can't know how precise or not-precise to make things, absurd precision can always be refined to a reasonable generalisation, but the contrary is not true. Yes, it's silly to specify that Alaska is located at {{coord|64|12|16.488|N|149|30|22.824|W}} when {{coord|65|N|150|W}} will work, but for my wikiproject, most locations need a lot of precision (sometimes ½ second separates two locations, e.g. the James M. Amoss Building and the Solomon Wilson Building at this list, adjacent buildings just fifteen feet wide), and a bot ought not be set up to assume that a couple of decimal digits are sufficient. We definitely need precision down to four decimal digits or individual seconds, and tenths of a second would be helpful. Nyttend (talk) 14:06, 17 November 2014 (UTC)

Thanks for the comments on "total Wikidata integration" in the 2nd paragraph, The Anome (and thanks for your work on this!). Everything you say here seems sensible to me. --Delirium (talk) 17:55, 17 November 2014 (UTC)

There is currently a bug in Wikdiata, relating to coordinates; I'd wait for that to be resolved. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:09, 27 November 2014 (UTC)

The bug is only about the rendering of ccoordinates in the Wikidata interface, that does not seem to affect the rendering of coordiantes in client websites.

I really think pulling data directly from Wikidata would make things simpler. Yes, it is slightly less convenient to watch Wikidata edits than Wikipedia edits, but still there is a "show Wikidata" option that works. The only way we can get more people to watch Wikidata is to use more data from Wikidata.

Taking the Bulgarian example, it seems much better to use Wikidata's data directly than have a bot copy them. It is not really more difficult to correct coordinates in Wikidata than in Wikipedia. You have to load a different page, but the interface is actually more intuitive there. More importantly, you benefit from editors from other languages as well. I have fixed quite a few wrong French coordinates in Wikidata that were imported from English Wikipedia, but I was lazy about fixing them here as well. So now the data are right in Wikidata, and remain wrong here. Coordinates in non-English speaking countries are often better maintained in local-language Wikipedia than in English. If we want it to work, we need to have as many languages switching to Wikidata as possible. If English did, that would be a strong boost in that respect.

I do not think the lack of Wikidata support for "type" , "region" etc is really an issue, at least for primary coordinates added through infoboxes. It would be if infoboxes worked like

|coordinates = {{coord|55.752222|N|37.615556|E|format=dec|name=Moscow}}

but what we actually have is

|latitude=
|longitude= 

format, name, etc. are either in a different parameter or somewhere deeper in the code. It does not really make any difference wether latitude and longitude are stored locally or pulled from Wikidata. --Superzoulou (talk) 14:51, 28 November 2014 (UTC)

--Superzoulou (talk) 14:51, 28 November 2014 (UTC)

RFC: expressing coordinates as decimal vs. DMS

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should we favor displaying geographic coordinates in decimal notation—versus DMS (degrees, minutes, seconds)? —EncMstr (talk) 18:15, 7 November 2014 (UTC)

Here are my comments duplicated from above (which seem lost in other comments):

Decimal-formatted coordinates have many advantages versus DMS: intuitive precision, easier and less error prone to transcribe (say to a GPS device), easier to use in arithmetic, less undue weight to a position, etc. I suspect DMS persists not because of a distinct preference but due to superstition, fear, and hubris. Many people I observe consider a coordinate to be close to a magic cookie in which they do not do the most elementary of inspections for reasonableness. Instead, they treat it as sacrosanct, unable to conceive of transforming it to be more simply expressed. This may also involve concern over violating ancient traditions and a vague fear that precision is lost if the same position is expressed with fewer symbols. Nevermind that in the 21st century almost all coordinates are handled electronically and actual lookup using a map resource via DMS is a scant minority. There be dragons in the mind here!

Mandruss adds "[Decimal has] finer control of precision... The precision difference between dms and dm is a factor of 60; as is the difference between dm and d; but that factor is always 10 in the decimal format."

—EncMstr (talk) 18:15, 7 November 2014 (UTC)

Clarification: Should geographical coordinates be expressed in decimal? Specifically, should a migration path be established for de-emphasizing and eventually deprecating DMS coordinates? Unless a superior use for DMS is articulated.

• • Except articles specifically about a location associated with its DMS designation (example Fifty-Four Forty or Fight! which has about 20 similar redirects), coordinates should be displayed in decimal. This is immediately realized by altering {{coord}} and/or its module to ignore the format= parameter and assume it was specified as format=dec.
  • As an interim measure, allow a new override parameter to display the coordinate as encoded in {{coord}}. (keep_original=yes?) Support for this should eventually be dropped once DMS vs. decimal is not contentious.
  • The default precision of the decimal display should be associated with its dim:X (dimension) parameter, if any, or an explicit scale (if given). This is particularly important for not-nice-in-decimal coordinates like {{coord|45|20|N|123|20|W}}.
  • As practical, enhance the mouse cursor hover feature so that a rendered coordinate displays in the tooltip to also show the degrees/minutes/seconds conversion. Currently it says Maps, aerial photos, and other data for this location.
  • The automatic precision display can assume a latitude like 40° which is good enough for the vast majority of locations. This can be refined later if anyone is interested.
  • I do not recommend anyone (be they bot or editor) be tasked to change wikitext coordinate parameters to decimal: leave them as they are. But if it were someday considered, the conversion should preserve the original format in the wikitext for sourcing purposes.

(end clarification) —EncMstr (talk) 06:16, 10 November 2014 (UTC)

• Favor neither. When I'm adding coordinates to articles that lack them, I use both formats (somewhat indiscriminately but sometimes for specific reasons involving precision or ease of entering in a specific kind of infobox). When I'm messing with coordinates that are already in an article, I almost always preserve the format that was originally used. In the {{coord}} template and most infoboxes, it's easy to change the formatting to display d/m/s even if the underlying coordinates are decimal; and I don't see why such displays should be discouraged, since they are after all the traditional format for expressing coordinates, and I'm a traditional guy. (I also like specifying d/m/s display for coordinates entered in decimal format that require five or more decimal places of precision, because of the rounding.) In short, I see no reason why we should try to suggest or enforce a specific format; most folks, I'm sure, just click through the coordinates to look at a map, and the format doesn't matter to them at all. A greater problem, it seems to me, is the prevalence of too-precise coordinates in articles, in both formats. Deor (talk) 19:17, 7 November 2014 (UTC)

Here's a good example I ran across this morning: Straža, Bosnia and Herzegovina. The Anomebot2 had added to the article coordinates taken from Wikidata, which were expressed to four decimal places. That was too precise—I could have trimmed them down to three places (trimming them down to two places would have put them outside the village), but in this case degrees and minutes were just as precise—if not more so—and more compact. I see no reason why in such a case the coords should have to be expressed in decimal form. Moreover, if the coordinates I added to the infobox (44°41′N, 18°35′E) should be forced into a decimal display, it would come out as 44.683333, 18.583333 or the like, which seems ridiculous to me. Deor (talk) 12:16, 8 November 2014 (UTC)

For object size ~850 m at 44° latitude, the tables at WP:OPCOORD give formats of d° m' s" or d.ddd°. In each format, that's as close as you can get to the suggested resolution of 1/10 of the object size, or 85 m. For d° m' format, you would have to have an object size of at least 7.5 km, as shown in the table. That town village isn't anywhere near that size. I get 44.683°N 18.583°E, although that could be tweaked to be consistent with the Wikidata. I don't see a problem with that, and the advantages to decimal have already been stated and have not been challenged. Given those advantages, in my view, the question is why the coords should have to be expressed in DMS form. ‑‑Mandruss ☎ 12:49, 8 November 2014 (UTC)

• Yes - About five solid advantages to decimal were briefly presented above. Any of those can be elaborated in a discussion subsection, if needed. When I hear advantages to DMS that outweigh them, I'll reverse my !vote. I don't count "it's tradition" or "most readers don't care" as advantages to DMS. As for the specifics of the proposal, I don't know that I'd go as far as adding a tracking category, or even using the word "deprecated", as there are conceivably a few rare situations where DMS makes more sense. But I'd certainly make sure all of the related doc clearly states the house preference, and perhaps a brief mention of the reasons for the preference. ‑‑Mandruss ☎ 22:41, 7 November 2014 (UTC)
• Favor decimal, in principle, but see the subheading below. Don't force users to enter decimal if their source is DMS, any conversion needs to be automatic. Oiyarbepsy (talk) 23:29, 7 November 2014 (UTC) - Changing my vote to decimal now that the intention is to have the templates convert DMS. Oiyarbepsy (talk) 23:47, 7 November 2014 (UTC)
• Favor neither Coordinates should be entered, and displayed, in whatever format the user got them in. Jackmcbarn (talk) 01:13, 8 November 2014 (UTC)
• Favor decimal if the template will convert from DMS to decimal. Robert McClenon (talk) 02:31, 8 November 2014 (UTC)
• Question - Would it be possible to have coordinates display in both decimal and DMS? Robert McClenon (talk) 02:31, 8 November 2014 (UTC)

Yes, there is already a mechanism to do that, but it only for logged in users who edit their style sheet. See template:coord#Per-user display customization. —EncMstr (talk) 03:05, 8 November 2014 (UTC)

• Favor neither—both are acceptable options depending on circumstances, and we shouldn't use the templates to force only one output option. They should be displayed in their input format in some cases (templates used in direct quotes, for example), so I can't support any change from the status quo. Imzadi 1979 → 02:57, 8 November 2014 (UTC)

Favour neither Displaying coords giving in one notation in the other introduces either inaccuracies, false impressions of precision, or both. I do, however, favour anyone who can be bothered reverting existing conversions. All the best: Rich Farmbrough, 00:17, 12 November 2014 (UTC).

• Favor DMS - DMS is the traditional way to write coordinates. And as said above, coordinates should be added as they are referenced. I would also add that changing DMS to decimal would be like replacing miles with kilometers without mentioning the former. ミーラー強斗武 (StG88ぬ会話) 20:34, 24 November 2014 (UTC)
• Favor DMS As a sea sailor i can verify the practical usefulness of the DMS system for people who actually use coordinates for navigating. I won't go into the technical details as to why the DMS system is used, but it has to do with using a compass (drawing tool) and the curvature of the earth. The people who know coordinates by heart and use coordinates in irl communication use DMS. At least this goes for sailors and i'm pretty sure pilots. So for the sake of the people to whom a coordinate will actually ring a bell, rather than just form a clickable or copy-pasteable number, let's use DMS.PizzaMan (♨♨) 15:00, 27 November 2014 (UTC)
• Oppose forcing a default to decimal. DMS is still widely used and in many respects much more easily recognizable that decimals. older ≠ wiser 15:30, 27 November 2014 (UTC)

This is why we have templates

There is an element of pointlessness to this discussion, in a way. Let users enter the coordinates however they like, and the templates then change it to decimal if required. I'm opposed if users will be forced to convert coordinates, and in favor if templates will do it for them. Oiyarbepsy (talk) 23:29, 7 November 2014 (UTC)

Comment: I do not intend to suggest that the input be limited to decimal, only that the default display be decimal. I sometimes see an editor adding format=dms to the {{coord}} parameters. —EncMstr (talk) 23:44, 7 November 2014 (UTC)

I just asked the Village Pump Technical to provide input as to whether this is doable. Oiyarbepsy (talk) 23:49, 7 November 2014 (UTC)

I'm confused, as {{coord}} already supports |format=dec. As I understand it, we're only talking about changing the default, from "the format used to specify them" to decimal format. Of course that's doable. ‑‑Mandruss ☎ 00:05, 8 November 2014 (UTC)

EncMstr, should the proposition be clarified before more discussion? ‑‑Mandruss ☎ 23:54, 7 November 2014 (UTC)

The question left at Wikipedia:Village pump (technical)/Archive 131#Technical input requested about coordinates was "Could the coordinate templates convert DMS coordinates to decimal?" The answer is yes, they can, and have been able to do this for many years. The input format may be either decimal or DMS - if there are two figures, decimal is assumed; if four or six, it's DMS. By default, the output format mirrors the input format, unless either |format=dms or |format=dec is used; these force that output format regardless of the input format - which may still be either one. --Redrose64 (talk) 00:25, 8 November 2014 (UTC)

Mandruss, I haven't been involved in an RFC before, but my question is whether there should be a system wide preference for decimal notation. Making that the default of {{coord}} regardless of parameters is about twice as far as I had imagined—at least initially. Changing it so that format=dms is ignored is about as far as I was thinking; instead display DMS only if the coordinates are given in DMS. If there is community buy in on that much, and no one can give a compelling reason to regard DMS on an equal footing to decimal, then perhaps in a year or two, ignoring the original format and always displaying decimal would be in order. —EncMstr (talk) 02:37, 8 November 2014 (UTC)

Free-form discussions are one thing, but an RfC needs to start with a precisely worded question that can be answered with Yes or No, Support or Oppose. Otherwise things get so muddled that it's extremely difficult to reach a discernible consensus (and it's often extremely difficult anyway, since so many people lack the self-discipline to avoid tangential discussion and stick to the stated proposition). My take is that "should we favor" is too vague, and it even had me going down the wrong path in my !vote. It will be hard for anyone to !vote either way without knowing exactly what they're !voting for. ‑‑Mandruss ☎ 02:48, 8 November 2014 (UTC)

Point taken. Should I revise my question above, or open a new RFC? —EncMstr (talk) 03:05, 8 November 2014 (UTC)

That's new ground for me, but I think I'd start a new one. Insert an explanatory comment at the top of this one, with a link to the new one. Maybe someone else knows something else that would need to be done to this one. And then, from within the new one, you could ping each of the responders to this one so far. A lot of work, but seems necessary as this is a topic that is likely to attract a lot of attention. ‑‑Mandruss ☎ 03:14, 8 November 2014 (UTC)

Don't start a new one. Just post Clarification below your original proposal with exact wording. How about "Coordinates should always be displayed as decimal degrees. Editors may enter coordinates as degrees/minutes/seconds if they choose and the templates will convert this to decimal degrees, without needing to instruct the template to do so." Oiyarbepsy (talk) 04:24, 8 November 2014 (UTC)

Ok, but many responders will have to refactor their responses, and much of this discussion will be confusing and time-wasting for new arrivals. And I don't think that's the proposal, in any case. As I understand it the proposal is to make decimal the default presentation when |format=dms is not coded. ‑‑Mandruss ☎ 04:34, 8 November 2014 (UTC)

Upon review I'm not clear as to what the proposal is, but I'm pretty sure it doesn't include "Coordinates should always be displayed as decimal degrees." It seems there are three or four possible proposals, and maybe this needs free-form discussion to establish what the proposition should be. At this point, I'd still be for what I described in my !vote—no change to any software, simply declare decimal as the house preference (for coding as well as presentation). This would prevent DMS in most new coordinates, after the word got out, and we could gradually convert existing template transclusions to decimal, the kind of thing we're already doing in many other areas. Or, you could do that relatively easily with a bot. It could be viewed as a semi-deprecation of DMS, but support for DMS as an option would never go away. One problem with depending on the template to convert to decimal is that you lose the "finer control" advantage—the control could never be any finer than is provided by DMS. ‑‑Mandruss ☎ 05:08, 8 November 2014 (UTC)

Coords ought not be automatically converted. Many of our sources are full of errors including simple typos. Those errors are much more easily analyzed in the original. Bots don't notice when coords are putting a skyscraper in a lake or otherwise producing unlikely results; that's a human job. Conversion, even of correct data, also either degrades precision or, more often, introduces false precision. This also needs a human mind. Jim.henderson (talk) 14:20, 8 November 2014 (UTC)

Post-clarification discussion

I would suggest dropping the item about assuming 40 degrees, as it doesn't gain anything. The code would still have to calculate the precision based on 40 degrees (object size would still be a variable). The tooltip change would be a nice touch, but we should bear in mind that the reader will be one click away from the DMS equivalent anyway, since GeoHack gives both formats up at the top of the page. I would Support it even as currently written, as I think it would be a substantial improvement, but I'll wait a bit before I bother to refactor my !vote. ‑‑Mandruss ☎ 08:49, 10 November 2014 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WikiProject X is live!

Hello everyone!

You may have received a message from me earlier asking you to comment on my WikiProject X proposal. The good news is that WikiProject X is now live! In our first phase, we are focusing on research. At this time, we are looking for people to share their experiences with WikiProjects: good, bad, or neutral. We are also looking for WikiProjects that may be interested in trying out new tools and layouts that will make participating easier and projects easier to maintain. If you or your WikiProject are interested, check us out! Note that this is an opt-in program; no WikiProject will be required to change anything against its wishes. Please let me know if you have any questions. Thank you!

Note: To receive additional notifications about WikiProject X on this talk page, please add this page to Wikipedia:WikiProject X/Newsletter. Otherwise, this will be the last notification sent about WikiProject X.

Harej (talk) 16:57, 14 January 2015 (UTC)

Google maps as a reference

@Pigsonthewing, Chris857, Imzadi1979, and Justlettersandnumbers: I saw Wikipedia talk:WikiProject Geographical coordinates/Archive 28#Links to Google Maps and it looks like you are the best ones I found to ask the question. I've got a user insisting on using Google and only Google maps as a reference.

An example article is Allevard. This Google maps is referencing these three statements:

1. "There are also some minor roads such as the D9 parallel to the D525 going to the north and the D108 which accesses the village from the D525. There is a tortuous mountain road - the D109 - which goes east of the village and eventually circles back to the north of the commune. The town has quite a large urban area in the west of the commune however the rest of the commune is mountainous and heavily forested."
2. "The Bourg stream forms the southern boundary of the commune flowing west and the Buisson forms the northern boundary also flowing west. These streams together with numerous other streams flow into the Breda which flows north through the commune then west to join the Isère near Pontcharra"
3. The maps/section "Neighbouring communes and villages".

I'm not comfortable with this because:

1. There is already the {{coord}} link in the article. Especially true for looking at the "Neighbouring communes and villages" map.
2. It appears as original research, especially when some streams don't appear on Google maps or saying "heavily forested".
3. It appears as a primary source and the user has to find the material.

Bgwhite (talk) 07:42, 16 January 2015 (UTC)

From the point of view of verifiability, any source citation is better than none. However, if these claims were challenged, the Google Maps cite wouldn't prevent removal. So it might worthwhile to look for better sources.—Stepheng3 (talk) 00:15, 20 January 2015 (UTC)

Viewing KML data in Google Maps

It appears that links to https://maps.google.com/ - such as the one titled "Map all microformatted coordinates" in {{GeoGroup}} - will stop working soon. I've started a thread at Template talk:GeoGroup#Viewing KML data in Google Maps. --Redrose64 (talk) 19:57, 25 February 2015 (UTC)

"Too big" title coordinates

In the four articles I've added coordinates to (so far) today—Embassy of Uruguay, Washington, D.C.; Nkamba; Apeejay School, Mahavir Marg; and Ferdinand I National College—the title-position coordinates are displaying fine for me in the first two, whereas in the second two they are displaying in an increased size. Is anyone else seeing this? Can anyone figure out what might be the cause? Deor (talk) 15:06, 12 March 2015 (UTC)

Crap, now all title coordinates are appearing too large to me. Has someone messed with a template somewhere? Deor (talk) 15:28, 12 March 2015 (UTC)

Yes; I'm pretty certain that it was due to these three edits by Frietjes (talk · contribs). See Module talk:Coordinates#Flummoxed, last two posts. --Redrose64 (talk) 15:49, 12 March 2015 (UTC)

@Deor, Redrose64, and PC-XT: should be fixed now, undid that particular part of the update. Frietjes (talk) 15:56, 12 March 2015 (UTC)

Dispenser's tools

After about 9 months, is it finally time to delete the links to Dispenser's tools ("coord-enwiki.log", "Coordinate check tallies", "Red link prefix search", and "Coordinates around 0°,0°") in the "Fix" section of the project's to-do list (transcluded at the top of this page)? It doesn't look as though they will ever be migrated to, or recreated at, Tool Labs. A damn shame, in my opinion, since they were quite useful in identifying coordinate problems, but I seem to have been a lone voice crying in the wilderness when I brought the matter up at the time. Deor (talk) 11:22, 9 April 2015 (UTC)

That's sad!—Stepheng3 (talk) 16:45, 9 April 2015 (UTC)

API function?

Is there any way to add or update coordinates in an article remotely? Via some webservice or other API ? ♆ CUSH ♆ 21:02, 19 April 2015 (UTC)

We're beginning to see coordinates imported from Wikidata; and bots can update Wikidata using an API. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:07, 19 April 2015 (UTC)

Hmm, are there any examples available? I find the documentation somewhat confusing. ♆ CUSH ♆ 08:41, 20 April 2015 (UTC)

Coordinates for airports

User:Dthomsen8 has been doing some excellent work on geolocating articles on airports/airfields that are currently missing coordinates. I've generated a list at User:The Anome/Airports missing coordinates to help them in this process: if any other editors want to help geocode more articles on that list, I'd greatly appreciate it. -- The Anome (talk) 13:15, 24 September 2015 (UTC)

Coordinates for public services

Are there any guidelines for public services like Annapolis Valley Regional Library and Halifax Regional Fire and Emergency? Should the coordinates be for the headquarters or the approximate center of the area they serve? Derek Andrews (talk) 12:23, 1 October 2015 (UTC)

Conversion between DD and DMS

Would it be good to have {{convert}} support coordinate angle-unit conversions between decimal degrees and degrees-minutes-seconds? template talk:convert has a discussion going on -- 70.51.202.113 (talk) 04:04, 2 October 2015 (UTC)

I, for one, would be pleased. Jim.henderson (talk) 15:04, 4 October 2015 (UTC)

@Jim.henderson: Per WP:MULTI, please discuss at Template talk:Convert#Angle conversions, not here. --Redrose64 (talk) 15:33, 4 October 2015 (UTC)

Elevation?

It is not clear to me how elevation should be included in the coord markup. The SNO detector is more than a mile underground, so elevation is required for an accurate position. Could someone please tell me how to include elevation in the markup? Thanks. Boardhead (talk) 13:55, 13 October 2015 (UTC)

Like this ... but it is not a supported (or, not a well supported) parameter - see User:EncMstr/Coord. Which seems a shame. --Tagishsimon (talk) 23:42, 13 October 2015 (UTC)

New GeoHack page

Recently, the GeoHack page that readers are sent to when they click on coordinates in articles has been changed. It now displays a big "Wikimedia maps beta" map (similar, but not identical, to an Open Street Map) at top left and a data table at top right. One wonders why the relevant, linked region code (when one is used in the article) does not appear in the latter, as it did on the old GeoHack pages. Is including a region parameter in {{coord}} no longer useful? (Also, in some cases, where there used to be a displayed WikiMiniAtlas map, all I'm getting now is a big gray box with "JavaScript disabled" at the top. This looks pretty clunky, especially since the WikiMiniAtlas map seems to have been made redundant by the "Wikimedia maps beta" map.) Deor (talk) 16:17, 11 January 2016 (UTC)

@Deor: This should have been fixed, see Template talk:GeoTemplate#Recent changes. --Redrose64 (talk) 20:09, 11 January 2016 (UTC)

I see that the template was changed so that the region-specific map links now appear properly, but, as I said, the region code itself still doesn't appear anywhere on the page. On this page, for instance, there's no obvious indication that Beelitz is in Germany, whereas on the old-style GeoHack page one saw "Region: DE-BB" in addition to "Type: City" and "Scale: 1:100000". Deor (talk) 00:17, 12 January 2016 (UTC)

Hmmm. A reader can't get to that page without viewing Beelitz first, which states in the first sentence that it's in Germany. And how many readers know that region DE-BB means Germany? I can't seem to muster much concern about this loss of cryptic information, which was intended for consumption by computers, not humans. The handful who want to know that ISO code could learn to look in their browser's address bar; it's right there at (or very near) the end of the URL. ―Mandruss ☎ 01:36, 12 January 2016 (UTC)

So what's the point of still displaying the type and scale parameters on the new GeoHack page, which are likewise of little use to the casual reader? Why was only the region dropped? Deor (talk) 01:53, 12 January 2016 (UTC)

Unknown (to me). ―Mandruss ☎ 01:59, 12 January 2016 (UTC)

Well, I, at least, used to use that feature of the GeoHack page. If I clicked on an article's coordinates and the GeoHack page had a blank (or something incorrect) after "region" or "type", I'd usually go back to the article and add (or emend) the relevant parameter. Combined with the loss of Dispenser's tools, this sort of unexplained change just has the effect of ensuring that our geocoding will probably tend to degrade, or to remain uncorrected, over time. Deor (talk) 17:35, 12 January 2016 (UTC)

Notifying Legoktm (talk · contribs). --Redrose64 (talk) 17:39, 12 January 2016 (UTC)

It was unintentional, the design was copied from the Russian Wikipedia, which didn't include that information. We can definitely add it back into the right infobox though. If you could post any other missing fields/info at Template_talk:GeoTemplate#Recent_changes, that would be appreciated. Legoktm (talk) 18:31, 13 January 2016 (UTC)

Accuracy versus number of digits

The tables whose format is being debated above have a far worse problem. The first line says that objects of 1m size should be given to 0.001 second precision. This translates to a location with 3 cm (1 inch). In fact, very few points on the entire Earth are known to that accuracy, which means that almost all the coordinates given in Wikipedia to that number of digits are lies! If we really knew locations that accurately we would have to adjust them every year for continental drift. A location stated to that precision pretends that we know where something is about 100 times as accurately as a modern expensive GPS receiver can provide. The table actively encourages people to mindlessly copy meaningless extra digits from Google Maps, even though the typical accuracy of Google Maps is 5–10 meters [2]. As a scientifically trained person I find this embarrassing. I propose that only places whose location has been professionally measured to higher accuracy (the top layer of surveying points in a recently-surveyed country, for example) should have more than one digit after the decimal point for seconds. Even that one digit will be uncertain in most cases. Zero^talk 03:38, 23 January 2016 (UTC)

See false precision for an article on this topic. Zero^talk 03:47, 23 January 2016 (UTC)

(This section does not appear left-adjusted. Can anyone see why? If you can fix it, please feel free to delete this question.) Zero^talk 03:42, 23 January 2016 (UTC)

This translates to a location with 3 cm (1 inch). In fact, very few points on the entire Earth are known to that accuracy.

Actually, that's bog-standard surveying accuracy these days. A cheap GPS recevier can't do it, but drop a total station down on any point on the planet, record for a few hours, and post-process the RINEX data, and you'll have a location that accurate. Remember, folks are monitoring mm/year of continental drift. with GPS.

These days, standard surveying is done by plunking down a total station, collecting differential points relative to that station (which can be done quickly to high accuracy if the location difference is small), then solving for the station location, and boom, your entire survey is high accuracy.

Here's a map of shifts in Seattle after a 2001 earthquake. Observe the 10 mm scale bar at the bottom of the picture, and the much smaller shifts measured by GPS.

However, I do see your point about deleting the highest-precision formats as unlikely to be useful, and it's obvious how to extrapolate by factors of 10 if people want.

71.41.210.146 (talk) 03:58, 23 January 2016 (UTC)

I didn't say that location can't be done to that precision; you are quite right that it can be done. What I meant was that for most places for which we give that level of precision, no such measurement has been done and in any case is not available to us. People usually get locations by clicking on Google maps or other similar tool. Zero^talk 05:45, 23 January 2016 (UTC)

I fail to see that point. If we have some objects that are 1 m in size, we need that precision in order to reflect that size. Any issues with location accuracy have nothing to do with size. I'm also stumped by this indentation, I've never seen that. ―Mandruss ☎ 04:06, 23 January 2016 (UTC)

The point is that for Wikipedia's purposes, such accuracies are basically never needed. Look at satellite imagery? Walk there and find it? The need for a location better than ±50 cm is extremely rare. Once you get that close, the object of interest is usually plainly visible. More precision only matters if you are comparing to the location of some other point which is surveyed with equal accuracy.

Although "real surveying" routinely works to such accuracy, I can see leaving it out of the table to discourage people. As I said, it's not like extrapolating by a factor of 10 is hard if someone actually has a need. 71.41.210.146 (talk) 06:15, 23 January 2016 (UTC)

Ok, take it out and see how long it takes before somebody complains. It can always be put back. So much the simpler. And we're only talking about row 1 of the dms table as I understand it. ―Mandruss ☎ 07:26, 23 January 2016 (UTC)

This translates to a location with 3 cm (1 inch). - No, the 3 cm you refer to is the resolution of that precision, not the object size. The object size is 1 m. In any case, you seem to be saying that the tables are bad because they can be misused, with which I disagree. All guidance on anything can be misused. People need to use appropriate object sizes if they wish to use the tables.
I could discuss object sizes for hours, which are in some situations a matter of editorial judgment. As an example, 2014 Isla Vista killings involved multiple events across that small town. For the title coordinates, I imagined the smallest circle that enclosed all of the events, and I pointed the coordinates at the center of that circle. The object size was the diameter of the circle. Many times "objects" for our purposes are not discrete physical objects. ―Mandruss ☎ 04:22, 23 January 2016 (UTC)

You seem to have missed the point. You want to give the location of the center of the circle; I'm fine with that. The question is how you know what the coordinates of the center of the circle are. The precision in that article is 0.001°, which is fine because location within 100m is easily obtained and I assume you did it correctly. However if the circle got smaller and smaller, it doesn't entitle you to add more and more digits unless you have a way to know what those extra digits are. A tool like Google Maps will rarely get more than 4 digits after the decimal point for degrees correct; any further digits it displays are just artefacts of the software. Zero^talk 05:45, 23 January 2016 (UTC)

I'm ok with the far-from-perfect way things are in this area, but I'd suggest you open an RfC with a clear and concrete proposition/proposal if you feel strongly about it. ―Mandruss ☎ 06:22, 23 January 2016 (UTC)

I agree it's awkward to find coordinates with the required degree of accuracy, but they're definitely available for many things. For example, the location of the Very Large Telescope UT1 is {{Coord|24|37|33.117|S|70|24|11.642|W|type:landmark|name=VLT Unit Telescope 1}},[3] and the other telescopes' locations are known with equal precision. (Specifically, that's the azimuth axis.) 71.41.210.146 (talk) 07:08, 23 January 2016 (UTC)

The formatting problem disappears if I comment out the tables above with the red heading "DRAFT values for discussion...". I'm not too good at tables but I suspect some syntax error there. If someone can see the problem, we'll appreciate it. Zero^talk 05:31, 23 January 2016 (UTC)

Yes, I narrowed it down to there too, but couldn't see anything wrong with the markup. It is kind of tricks, but I couldn't see the mistake. We probably should figure it out before copying any tables to mainspace! 71.41.210.146 (talk) 06:15, 23 January 2016 (UTC)

The problem goes away if you remove the tables' indentation (::::). ―Mandruss ☎ 06:25, 23 January 2016 (UTC)

Looking at some outdents that follow that, I think the table is unclosed, and we're still in it. ―Mandruss ☎ 06:27, 23 January 2016 (UTC)

I thought so too, but there are equal numbers of left and right braces {} in the table, so it's not completely obvious. 71.41.210.146 (talk) 06:57, 23 January 2016 (UTC)

Isolated at User:Mandruss/sandbox4 if you'd find it easier to play with it there. ―Mandruss ☎ 07:10, 23 January 2016 (UTC)

Great. I asked at the Help Desk. Zero^talk 08:25, 23 January 2016 (UTC)

Coords for small linear topics

In general, what should be the focus of coords for small linear subjects? I'm trying to reduce the size of Category:Ohio articles missing geocoordinate data, but many of the articles are topics such as streams and bicycle trails: they're too minimal and too poorly defined to warrant something like the KML files used for highways, they're too short to warrant multiple coords (most of them don't have any significant locations except source and mouth), and I'm not sure whether the mouth of a stream or some other spot should be used. Nyttend (talk) 16:36, 23 January 2016 (UTC)

For streams, when one point is used, it's usually the mouth. (In Infobox river, one can enter coordinates for both the source and the mouth, which will display in the infobox, but it's the mouth coordinates that will display in the title position in the article.) For bicycle and hiking trails, there's a "trailheads" field in the infobox, and one can add inline coordinates for each after the location, without a title display; or one can also include the coordinates of an approximate midpoint to display in the title position, as here. (If there's no infobox, one can add inline coordinates where the trail's endpoints are mentioned in the article.) Different people do these things differently, and basically anything that makes sense is OK, but there is a general discussion at Wikipedia:WikiProject Geographical coordinates/Linear. Deor (talk) 23:54, 23 January 2016 (UTC)

Consistent location of coordinates in articles having a single coordinate

I'm a bit nonplussed at an article such as Northampton Castle which has a coordinate in the infobox, below the fold, but lacks a coord in the top right. I'm used to & prefer coords at the top right of the page (i.e. display=title) & hate having to hunt for them. (I have no objection to their being in the infobox as well, even if this amounts to duplication.) I tend to think that users are better served by a consistent position in the article for singular coords. Would anyone like to weigh in on the subject of whether we should care & if so whether we might do something about this? --Tagishsimon (talk) 04:07, 19 February 2016 (UTC)

It looks like {{Infobox military installation}} supports |coordinates_display=both to say whether the coordinates should be in the title, and that page just doesn't have it set (I guess that is so articles can have multiple boxes). --Scott Davis ^Talk 06:13, 19 February 2016 (UTC)

"Both" is not universal, but it's close. I added |coordinates_display=both, |coordinates_type=landmark, and |coordinates_region=GB-NTH. ―Mandruss ☎ 06:29, 19 February 2016 (UTC)

NYC coord missing

I have the New York City missing cooordinates list down to 99 articles, but I have some questions:

1. Columbia University Libraries has dozens of libraries in a list. To remove the tag, must I add coordinates for every library that has an article?
2. same question for NYU residence halls. — Preceding unsigned comment added by Dthomsen8 (talk • contribs) 18:08, 7 March 2016 (UTC)

There are no established rules & not very much useful precedent, afaik. Arguments can be made that coordinates on discrete library articles would suffice and that the coord missing tag on the CUL page is not required (whether or not the discrete library articles have coords). Arguments can be made that the list of libraries in the CUL article might be made into a table, with coordinates added as one column, and that the coord missing tag should stay until that is done. (And fwiw, I'd tend to the second of these arguments). What we do know is that the coord missing tag will not be re-added if removed; I'd hesitate to remove it merely because you want to clear out the NYC coords required category. (And btw, good work on getting it down to 99 ... sounds a low number to me). Sorry that there isn't clearer guidance :( -Tagishsimon (talk) 23:30, 7 March 2016 (UTC)

Category:New York City articles missing geocoordinate data now down to 98, but a few more questions:

1. Berrien's Island is long gone, but from descriptions I can make an approximation. I am guessing that is OK.
2. Apex Studios many other articles are very brief, poor referencing, defunct for 60 years or even two centuri and therefore very difficult to locate. Most of the easy ones are done, except for transit stops. Any advice on the hard ones?--DThomsen8 (talk) 23:54, 7 March 2016 (UTC)

Berrien's Island - yup, if you can work out where it was, that's good. Again, there's not afaik an established standard for pointing to reliable sources for the estimation of positions of things. I sometimes include indications of how I arrived at coords in the edit summary. Sometimes not.

Apex Studios. Yup. Difficult ones are difficult. I think they retain the coord missing until they're solved (which may be never). In the UK, we're plagued with priories for which there is good documentation but no accessible location info. I see Category:New York articles missing geocoordinate data is looking quite fat & has NYC articles in it. I've coorded a few NYCs by way of a foreign holiday :) --Tagishsimon (talk) 00:16, 8 March 2016 (UTC)

Map dot type

Note: A request to change the map indicator type is ongoing at Module_talk:Location_map. Please comment there if interested. — xaosflux ^Talk 14:35, 25 March 2016 (UTC)

WikiProject Oregon collaboration

Greetings, project members. In case you are interested in contributing, WikiProject Oregon's current collaboration is adding coordinates to the 200 articles in Category:Oregon articles missing geocoordinate data. See here for the talk page discussion. (You'll also see a related pushpin map discussion in the section above.) If you are able to pitch in, any help would be appreciated! ---Another Believer _(Talk) 00:54, 4 April 2016 (UTC)

Dynamic coordinates for ships etc?

Apologies if this has been brought up before, I've had a rummage through the archive and didn't see anything. My mind has been wandering as it does, and it occurred to me, that through the magic of Automatic Identification System it is possible to access the position of ships in near-realtime via a web API. This is one example but this map only requires a ship's IMO number (and although it's not visible on the map, one can extract the coordinates from the source if you search for "latitude", it's in the script at the end). So in theory one could grab that location and present it on a ship's article. I appreciate that there's plenty of work may be needed to make this happen - not least having a conversation with one of providers of AIS data. There's quite a few, ranging from comprehensive ones that track from space, to cooperatives of people who own land-based detectors who exchange data between themselves but don't have such good coverage. The space ones are better, but they charge for API access, at least, so we'd need to do a bit of fluttering of eyelashes to get one of those on board. You could get away with hitting the API say once an hour and then caching it on Wikidata - the average merchant ship is only going to move 10-20 miles in that time, if people want a more recent update they could go to the partner site (which means there's something in it for the partner site assuming they have adverts or sell more subscriptions). All passenger ships, and all cargo ships over 300t, have to squawk AIS when travelling internationally (and in many domestic jurisdictions); military ships aren't obliged to squawk but generally do in peacetime, certainly in busy shipping lanes. I'd imagine there's similar APIs to access the position of spacecraft and the like.
It's not just of theoretical interest, there are some practical uses. For instance, the available sources suggest that the first Tide-class tanker was meant to be leaving a Korean shipyard by the end of 2015 for delivery to the UK, but the above map shows that it is still undergoing sea trials in Korea, so one puts less weight on what the sources say about planned delivery dates. Any thoughts? Le Deluge (talk) 23:11, 8 April 2016 (UTC)

@Le Deluge: Any thoughts? - This strikes me as a feature with nonzero benefit but greater cost. I also question whether real-time ship tracking, essentially a maritime flightradar24.com, is within the mission of an encyclopedia. I don't know who would implement this, but it seems likely that there would always be something more pressing on their plates. If you wish to pursue this, I think WP:VPI would be a more suitable venue, as well as giving it more exposure. ―Mandruss ☎ 01:43, 9 April 2016 (UTC)

@Le Deluge and Mandruss: Importing IMO ids into ship infoboxes would be a good start to make this possible. However, I think the actual live tracking is best performed elsewhere, with Wikipedia providing a launching-point to external live-mapping services in the same way that we do for geographical coordinates. -- The Anome (talk) 12:22, 18 April 2016 (UTC)

Improvement of scale and country data for geocoded articles

I see that Flickr have a large database of outline polygons for geographical entities, generated from their own internal data and released under a CC-BY license. (See http://code.flickr.net/2011/01/08/flickr-shapefiles-public-dataset-2-0/ for details.) I'm planning to use this to set both the scale and region parameters for all Wikipedia articles which use {{coord}} to generate their coordinates, and have both names and existing coordinates that match the Flickr dataset.

This will touch several tens of thousands of articles at the very least, and should represent a substantial improvement in the quality of our data, but will make no difference to the actual appearance of any article, so there will be zero disruption. Where existing scale or country data is present, I will not override it, but instead log it for later analysis. Once this is done, I can also look at the possibility of doing the same to articles with coordinates generated by infobox parameters.

I'm also considering the possibility of importing WOEIDs from this dataset into the Wikidata items for these articles. See https://www.wikidata.org/wiki/Wikidata:Property_proposal/Place#WOEID for more details. -- The Anome (talk) 08:34, 19 April 2016 (UTC)

Google Earth placemark updates

I asked this at the Village Pump but received no answers. Apologies if it's been asked before. It looks like Google has not updated the 'Wikipedia' layer in the Google Earth database in some time -- many of the placemarks are appearing at slightly (or significantly) different locations, that I know I and other editors have corrected.

Does anyone know who at Google is responsible for importing our dumps into their database layer, so that we can prod them into maybe doing a fresh update sometime?

(To cite one example, I corrected the coordinates in our article on the Buildings at 15-17 Lee Street a year and a half ago, but Google Earth is still displaying it at the old, less-accurate location. And I've found other examples that are even older.) —Steve Summit (talk) 13:14, 23 April 2016 (UTC)

Compare English and German Version

I see differences between de:Vorlage:Positionskarte Ukraine Oblast Kiew and Template:Location map Ukraine Kiev Oblast by using same coordinates. Can anybody explain these differences ? I want to use a map in de:Woodpecker (Kurzwellensignal) like in Duga radar. --Fmrauch (Talk) 22:17, 26. Apr. 2016 (CEST)

The positions on Duga radar are transmitter: {{coord|51|18|19.06|N|30|3|57.35|E|display=inline}}, receiver: {{coord|51|38|15.98|N|30|42|10.41|E|display=inline}}. That translates in decimal to:

• Transmitter - 51.305294, 30.065931
• Receiver- 51.637772, 30.702892

The first coordinate matches your string:

• {{Positionskarte~|Ukraine Oblast Kiew|label=Sender|lat=51.305294|long=30.065931|region=UA-32|mark=Location dot red.svg}}

The second coordinate does NOT match either of the other two strings:

• {{Positionskarte~|Ukraine Oblast Kiew|label=Kernkraftwerk|lat=51.389778|long=30.099706|region=UA-32|mark=Location dot blue.svg}}
• {{Positionskarte~|Ukraine Oblast Kiew|label=Empfänger|lat=51.56|long=30.702892|region=UA-32|mark=Location dot red.svg}}

You have not specified what the difference that you see is ... I'm hoping this is it: Fmrauch, one of your coordinates may be wrong. --Tagishsimon (talk) 22:26, 26 April 2016 (UTC)

Perhaps it depends on the browser - I don't know. Today it looks different from yesterday. --Fmrauch (talk) 20:39, 27 April 2016 (UTC)

It would be helpful if you could describe the difference you observe, and point to the de version of the map-with-coordinates - your version of the map in Duga radar. --Tagishsimon (talk) 20:46, 27 April 2016 (UTC)

Now I see: there was a mistake Diff. The problem in the German version is that I can't use a position outside the boarder of the map without getting an error message. So I used lat=51.56 instead. --Fmrauch (talk) 20:50, 27 April 2016 (UTC)

Template:coord and Template:Gbmapping

just thought I'd drop you folks a line wasn't sure if you've had a look at Template:Gbmapping - there are some obvious overlaps with template:coord EdwardLane (talk) 22:41, 23 April 2016 (UTC)

Gbmapping doesn't accept coordinates of latitude and longitude; it is for grid references of the Ordnance Survey National Grid. (It's often used in addition to, not instead of, {{coord}} in articles about UK places.) There's no real overlap. Deor (talk) 23:19, 23 April 2016 (UTC)

Shouldn't gbmapping auto generate coord values too ? if not that's fine but I only stumbled onto gb mapping when I couldn't find coords for somewhere. EdwardLane (talk) 16:14, 28 April 2016 (UTC)

It cannot do it to a high enough resolution. A 6 digit grid reference is a 100m^2 area, iirc. You can pack a whole lot of distinct locations within an area of that size. It's ideal if coordinates point to the actual thing, rather than to a point up to 141m away. --Tagishsimon (talk) 16:30, 28 April 2016 (UTC)

One of your project's articles has been selected for improvement!

Hello, Please note that Pecan pie, which is within this project's scope, has been selected as one of Today's articles for improvement. The article was scheduled to appear on Wikipedia's Community portal in the "Today's articles for improvement" section for one week, beginning today. Everyone is encouraged to collaborate to improve the article. Thanks, and happy editing! Delivered by — MusikBot talk 00:08, 4 April 2016 (UTC) on behalf of the TAFI team

Odd bot. Have asked why on its talk page.--Tagishsimon (talk) 00:13, 4 April 2016 (UTC)

You know, I have long wondered why this WikProject has not got around to fixing that article. I am glad there is a bot to pester you guys. ;-) —EncMstr (talk) 00:39, 4 April 2016 (UTC)

Yes, you should be thanking MusikBot! Pecan Pie and geographic coordinates, duh! =P Seriously though, the bot scans the WikiProject banners of the article talk page for links to Wikipedia:WikiProject_whatever, and here it looks like a link this project was in the Louisiana to-do's. It was implemented this way because categories and the names of the templates vary greatly. I had not considered the to-do's, though. That could have links to all sorts of WikiProjects! I will work on a fix, but hey, glad we got a kick out this hilarious bug. I have blacklisted this WikiProject from being notified for the time being. Cheers — MusikAnimal ^talk 04:03, 4 April 2016 (UTC)

Mmmmmm, pie.... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:36, 28 April 2016 (UTC)

Signpost Followup

Hi! It's been a few years since your project was featured in the Signpost. Would anyone be interested in talking about new additions/technology, etc? I'd love to interview a few of you. Please ping me! Megalibrarygirl (talk) 20:30, 8 June 2016 (UTC)

Adding more than one geotag

How can I add two (or more) geotags to a single article? I'm sure I've seen it before somewhere...--الدبوني (talk) 12:36, 21 June 2016 (UTC)

It depends on what exactly you're trying to do. In general, since only one set of coordinates can appear in the title position, one uses "display=inline,title" in the {{coord}} template for the coordinates (if any) that one wants to be displayed there and "display=inline" for the others. It gets a bit more complicated with coordinates in multiple infoboxes. If you tell us what particular situation you want to address, we can probably give a better answer. Deor (talk) 13:18, 21 June 2016 (UTC)

Oh, and if you use multiple sets of coordinates in an article, it's often useful to include a {{GeoGroup}} template in the article so that readers can see all the locations pinpointed on a single map. Deor (talk) 13:21, 21 June 2016 (UTC)

Thanks. I started this article about a cafe, which has two branches, one in Qatar and the other in London. I wanted to include geotags for both. I managed to go it using "display=inline" but I still get a geotag at the top of the page?--الدبوني (talk) 09:50, 24 June 2016 (UTC)

@الدبوني: You have display=title, not display=inline - and only a single coordinate in the article, so far. Change title to inline and you should then be able to add the second coordinate. --Tagishsimon (talk) 18:12, 24 June 2016 (UTC)

Coordinate formats

Please join a discussion of geographic coordinate formats. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 2 August 2016 (UTC)

Discussion at Template talk:Attached KML#Proposal: Use Wikidata and new module

You are invited to join the discussion at Template talk:Attached KML#Proposal: Use Wikidata and new module. Evad37 [talk] 12:37, 24 August 2016 (UTC)

"globe:earth"? Seriously??

For Spock's sake, don't encourage "globe:earth". It's the default, and will remain so even after humans have colonized Europa (or gone extinct). -A876 (talk) 04:19, 26 August 2016 (UTC)

Rounding of elevation and prominences in mountain infoboxes

Droll and I are having a disagreement about how to round metric values for elevations and prominences in articles that use {{Infobox mountain}}. Specifically, the disagreement focuses on articles that take these values from Peakbagger.

My position is based on MOS:UNCERTAINTY and MOS:CONVERSIONS. What I want to do is check the precision of each of the elevation and prominence values from the sources, and use the {{convert}} template to keep the same amount of precision in the metric as in the imperial. (This implies that we cannot use automated editing to put precision into infoboxes). For example, for Twin Sisters Mountain, the summit elevation is only known through 40' contour lines, so I want to present the elevation rounded to the nearest 10 meters: 7,000+ feet (2,130+ m)

Droll's position is based on verifiability. Peakbagger is a reliable source, so we should present the metric elevation that they present. Peakbagger presents metric elevations rounded to the nearest meter, so it's ok to use automated editing to set the precision. For Twin Sisters Mountain, the elevation should be 7,000+ feet (2,134+ m), the same as the elevation listed on the Peakbagger page.

What do other editors think? —hike395 (talk) 14:16, 28 August 2016 (UTC)

First, I am not convinced that PeakBagger is a solid reliable source. Its own statistics say that 11,092 of 64,385 peaks are unverified. Greg (the site owner) says that he verified and modified data by checking what I have against a wide variety of sources, including standard reference works as well as internet newsgroups and web sites.[4] So it may be no more a reliable source than Wikipedia.

However, the same may apply to GNIS. I have observed someone identifying an error in a GNIS coordinate and seeing it submitted and corrected. Probably someone in the DC suburbs looked at Google Maps satellite view to verify and updated the database. As far as I know, GNIS is considered a reliable source.

The GNIS entry ("Twin Sisters". Geographic Names Information System. United States Geological Survey, United States Department of the Interior.) for Twin Sisters shows 5764 feet. Maybe that is the wrong Twin Sisters? —EncMstr (talk) 16:36, 28 August 2016 (UTC)

The highest peak for Twin Sisters is South Twin, at South Twin, CalTopo link here. The reliability of Peakbagger has been a long-running debate (see, e.g., here, and here). Unfortunately, for prominence values, there is no rock-solid peer-reviewed secondary source that I know of. All of the prominence data in WP comes from primary sources such as Peakbagger. So, I don't think we can dodge the issue by saying that Peakbagger is unreliable. —hike395 (talk) 18:53, 28 August 2016 (UTC)

RfC notice

Please see related RfC (permalink), now closed. ―Mandruss ☎ 03:31, 1 September 2016 (UTC)

guidance for coordinates on reservoirs

Unless there are objections, I'm going to add this bullet under "Which coordinates to use":

• For lakes, reservoirs, islands, mountain ranges, deserts, and other 'area' features, use the rough geographic or visual center of the feature. (Remember not to specify artificially high precision for large areas; see Precision guidelines below.)

This seems mostly uncontroversial, but I'm bringing it up here because I've come across a number of reservoirs (example: Lake Elwell) which list the coordinates of the dam that impounds them. I don't know if this has been done as a matter of expediency by someone who already knew the dam coordinates, or because someone thought it was preferable.

While we're at it, is it worth adding any explicit guidance about features with a crescent or otherwise irregular outline? Consider Ross Island (Oregon). For such a feature, I'm always torn between using a coordinate that's at the approximate geometrical center (but in the case of Ross Island, in the water in the lagoon in the middle), versus offsetting the point significantly such that it's actually on the feature. (I guess one reason not to provide explicit guidance is that it's pretty hard to even describe the situation concisely!)

Any thoughts? —Steve Summit (talk) 15:58, 4 September 2016 (UTC)

For my part, I think your suggested addition is fine, though for mountain ranges I sometimes use the coordinates of the highest peak if it's relatively near the the geographic center of the range. I think that "explicit guidance about features with a crescent or otherwise irregular outline" is probably unnecessary. I too have trouble with these, though for simple crescent shapes, I usually use coordinates as central as possible but within the feature. There's also the cases in which features (like many national forests), consist of two or more noncontiguous regions. I take these on a case-by-case basis, sometime using a relatively central point that's within the feature and sometimes using a point that's technically outside the feature. (For Ross Island, I've just tweaked the coordinates a bit to put them on the island and make them less overprecise. The former coordinates could be misinterpreted—it might have been thought that Hardtack Island was part of Ross Island.) Deor (talk) 16:32, 4 September 2016 (UTC)

Yeah, you're right, mountain ranges are different, and don't belong in that list. Stricken. Thanks for your other observations (and for fixing Ross Island). —Steve Summit (talk) 16:17, 5 September 2016 (UTC)

I've made the change (but with a somewhat different wording). —Steve Summit (talk) 18:32, 9 September 2016 (UTC)

"Prime" symbols vs straight apostrophes

I am reverting this. My eyes can discern very little to no difference between the two characters, and the information is for visual reference only. Why switch to a character that no one has on their keyboard? Finally, the edit removed the spaces between the d, m, and s elements, which greatly aid readability. Not an improvement. ―Mandruss ☎ 08:53, 21 January 2016 (UTC)

@Mandruss: Thanks for the discussion! I did it to make the section consistent with the rest of the article, which uses the symbols (such as the immediately preceding Precision guidelines section), as well as the output of Template:Coord itself: 0°0′0″N 0°0′0″E. Yes, it's subtle visually, but one's technically correct and one is a crude ASCII approximation. Nobody has to type it (you use a vertical bar parameter separator when typing), so I couldn't see any downside.

I was wondering about the spaces, too. One selfish reason is that on my screen, the two side-by-side tables plus the standard Wikipedia sidebar result in my browser wrapping the first line of the table ("d° m' s.sss"" gets an ugly like break before the seconds), but the important one is again to match Template:Coord's output which does not include any spaces.

I really think using the prime symbols consistently in the article is desirable, but the spaces is much more of a judgement call.

(Actually, I think the whole table is not very useful. Better to have a table like the in the "precision guidelines" section above, but listing the size "break points" where you switch coordinate resolution. Fewer rows, and easier to apply to an arbirarily-sized object. But I wasn't quite bold enough to make that change.)

71.41.210.146 (talk) 11:17, 21 January 2016 (UTC)

• I didn't get your ping. The valid ping and your signature have to be added in the same edit, or no notification is generated.
• I'm not sure I see the rationale for matching the output of {{coord}}, considering how the tables are used. You use them to choose a precision, which you then use in coding {{coord}}'s positional parameters or infobox parameters such as |lat_d=, etc. The one thing you won't code is anything in the format of the output from {{coord}}.
• Re the wrapping, perhaps the second table should be below the first. Since the tables in the preceding section are wider, you must have some weird wrapping going on there, too.
• I'd like to see a rough sandboxed prototype of such a "break points" table. My guess is that it would be more difficult to understand and therefore less usable. But if I'm wrong, I'm 100% behind a change and I'd happily do the rest of the work implementing the new tables. If you don't have a personal sandbox, you could use User:Mandruss/sandbox4. (On second thought, I'd probably need someone to throw together some code to calculate all of the break points for me. They would have to use a language that provides trig functions, and they would have to know how to use them correctly for this purpose. A prototype could use fictional break points, as it would be just about format.) ―Mandruss ☎ 11:55, 21 January 2016 (UTC)

New format for the tables

Edit conflicts galore! Geez, make up your mind what you want to say! :-)

1. Right, I remember reading that. Oops.
2. The requirement isn't that strong, but I just figured that the output of {{coord}} was the preferred "official" form to present geographic coordinates. The values are presented in a form approximately like the output, and inconsequential differences seem pointless.
3. The tables are a bit narrow; placing them side by side definitely looks neater IMHO. I've done lots of edits reformatting tables to a reasonable width. The tables above have the column headings wrap to two lines, but the column entries all fit on one line. The ugly line breaks aren't a reason for the change, just what initially tickled me into looking at the formatting.
4. Sort of something like the following (entries to be filled in). The values could be computed with {{#expr}} if desired. An open question is how the advice should be phrased for objects exactly the size of the breakpoint. Also, the rows could be reversed, and say "for objects of size at least".

Degrees-minutes-seconds format

Use precision	For objects no larger than
	0°	30°	45°	60°
d° m′ s.sss″
d° m′ s.ss″
d° m′ s.s″
d° m′ s″
d° m′
d°

71.41.210.146 (talk) 12:58, 21 January 2016 (UTC)

Not bad. I tweaked it. I'd like to see it with some cell contents so I could "play user" with it. ―Mandruss ☎ 13:06, 21 January 2016 (UTC)

@Mandruss: You don't need to have the prime/double prime symbols on your keyboard in order to type them in. Below the edit window, you should see a drop-down menu; in that select either "Insert" or "Wiki markup" and they are the fourth and fifth clickable characters from the left, conveniently placed immediately after the degree sign (° ′ ″). The prime is also found in the "Math and logic" list, just before the integral symbols (′ ∫ ∬ ∭). --Redrose64 (talk) 14:09, 21 January 2016 (UTC)

Ok, thanks! ―Mandruss ☎ 22:05, 21 January 2016 (UTC)

Degrees-minutes-seconds format For objects no larger than Use precision 0° 30° 45° 60° d° m′ s.sss″ d° m′ s.ss″ d° m′ s.s″ d° m′ s″ d° m′ For all larger objects, use d°

Decimal degrees format For objects no larger than Use precision 0° 30° 45° 60° d.dddddd° d.ddddd° d.dddd° d.ddd° d.dd° d.d° For all larger objects, use d°

1. I suggest the above change. Input on the left, output on the right, more natural for those of us who read left-to-right. And I think the ascending object size choice is good and would be easier than descending object size.
2. The values could be computed with {{#expr}} if desired. - I hope and assume you mean doing that as a one-time, throw-away thing, rather than putting that in the table entries and doing the computations every time the page is downloaded.
3. An open question is how the advice should be phrased for objects exactly the size of the breakpoint. - There aren't likely to be many cases like that, as the break points won't be the round numbers that editors will use to estimate object sizes. But if I'm thinking correctly the "no larger than" advice would give the higher of the two precisions in that case, which is ok and probably better.
4. It's worth noting that these still aren't perfect tables, as they do not address the break points between the given latitudes. The usage has to assume that the break point between 0° and 30° is 15°, for example, and that is highly unlikely. Thus there will still be an acceptable error in some cases. The only perfect solution would require some kind of software computation using the exact size and latitude. But this eliminates one of the two potential errors, while making the tables far smaller, so at this point I think it's a change worth making.
5. I can't get my head around the required math, and I don't know how to use {{#expr}}. I'll need a smarter person for that part (you?). ―Mandruss ☎ 22:58, 21 January 2016 (UTC)

@Mandruss: (Partial response; more to come when I have more time later.)

I hope and assume you mean doing that as a one-time, throw-away thing, rather than putting that in the table entries and doing the computations every time the page is downloaded. Actually, I meant the opposite. Remember that mediawiki caches formatted pages, so it does not convert wikimarkup to HTML each time. Also, the cost of doing the computation is actually quite minimal, less than a normal template invocation. (Since the latter requires a database lookup which #expr does not.)

I like your table revisions. Oh, and I understand #expr just fine and have no problem making it behave.

The thing to figure out is what the thresholds should be. The table being more informative requires more precise information to fill it in. There are two kinds of jumps: a factor of 10 and a factor of 60. For each resolution jump, what should the object size threshold be? The text only gives approximate guidelines. It recommends a resolution no more than 1/10 the object size, but does that mean a resolution 5x the object size if the alternative is 1/12?

71.41.210.146 (talk) 06:21, 22 January 2016 (UTC)

Still oppose complicating and cluttering the table code, dramatically cutting the number of editors who understand it, for values that will never change unless there is a change to the geometry of the planet or in our geocoordinates system. To what end? If you feel it's important to document how you arrived at each cell value, there are other and better ways to do that (hidden comments outside the table code, for one).

I don't understand the issue as to thresholds. It seems to me the solution to any such issues should be part of the math and flow naturally from it, although I know that's problematic when I can't say exactly how. For any given size-latitude combination, there is one precision that is closer to the target 1⁄10 resolution than any other precision; the break point is the size where that precision changes. Thus there is no decision to be made; there is only one set of correct answers.
For each cell, one should be able to compute a very precise break point object-size value, say 62.4882 km. That's more precise than is needed or useful, so we would simply round it to 62 km, creating an inconsequential window of error between 62 and 62.4882 (no one is going to estimate their object size as 62.3 km). Proceed to next cell, repeat. You could use "rounder" numbers, but any usability benefit wouldn't be worth the increase in the size of the error windows, imo. ―Mandruss ☎ 06:43, 22 January 2016 (UTC)

Possible help here, if needed. ―Mandruss ☎ 10:55, 22 January 2016 (UTC)

Oh you're in that directory. Never mind. :D ―Mandruss ☎ 10:58, 22 January 2016 (UTC)

@Mandruss: Still oppose... I don't really care; it's just the software developer in me that prefers to embed things in executable code rather than comments that can go stale. Like I prefer to use {{convert}} where possible, even for measurements that aren't going to change. But the implementation techniques are a minor point not worth derailing the main discussion: what should the output look like.

The main thing I'm trying to figure out is the formula. As I mentioned before, it's never stated explicitly, so I have to derive one.

All of the really interesting stuff can be found in the 500 km row.

• The most interesting and informative entry is the 500 km row and the 30° latitude column. The decimal degrees table recommends one decimal place, making a resolution/size ratio of 51.86 (rather than dropping a digit for a ratio of 5.186). But the d-m-s table recommends degrees only, making a ratio of 5.186 (rather than adding minutes and making 311.186).
• That means that the formula is not simply "the lowest resolution that will provide a ratio of at least 5", or any such number.
• The lowest ratio at a jump of 10 (decimal degrees or decimal seconds) is 6.352, in the 500 km row (and all other 5×10^k rows) of the decimal degrees table at 45° latitude.
• The highest ratio is 269, in the 500 km row of the d-m-s table on the equator. (Degrees only would give a ratio of 4.492.)

So to be consistent with the current table, for a jump of 10, the ratio threshold must be between 5.186 and 6.352. For a jump of 60, it must be between 4.492 and 5.186.

One rule that appears to work is one of the following equivalent formulations:

• The minimum ratio is 7/k^0.1, where k is the size of the following jump, 10 or 60.
• The minimum ratio for a jump of 10 is 7/¹⁰√10 = 5.5603, at which point it jumps to the maximum ratio of 55.603. The minimum ratio for a jump of 60 is 7/¹⁰√60 = 4.6482, after which it jumps to the maximum ratio 268.89.

They're both two-parameter solutions, so they're equivalent in expressiveness. There is a range of plausible values; 7 and 0.1 are just round numbers I happened to stumble upon while playing with the figures. I haven't yet found a decent one-parameter solution. The middle of a factor-of-10 scale jump is √10 = 3.162, while √60 = 7.746. and those numbers don't fit the pre-existing table's ratios in any obvious way.

Using this formula, the tables work out to (rounding subject to negotiation):

DRAFT values for discussion, not final, repeat DRAFT

Degrees-minutes-seconds format For objects no larger than Use precision 0° 30° 45° 60° 1.72 m 1.49 m 1.22 m 0.86 m d° m′ s.sss″ 17.2 m 14.9 m 12.2 m 8.6 m d° m′ s.ss″ 172 m 149 m 122 m 86 m d° m′ s.s″ 8.6 km 7.5 km 6.1 km 4.3 km d° m′ s″ 520 km 450 km 370 km 260 km d° m′ For all larger objects, use d°

Decimal degrees format For objects no larger than Use precision 0° 30°N/S 45°N/S 60°N/S 6.2 m 5.4 m 4.4 m 3.1 m d.dddddd° 62 m 54 m 44 m 31 m d.ddddd° 620 km 540 m 440 m 310 m d.dddd° 6.2 km 5.4 km 4.4 km 3.1 km d.ddd° 62 km 54 km 44 km 31 km d.dd° 620 km 540 km 440 km 310 km d.d° For all larger objects, use d°

Do those numbers look right, or does the formula need adjusting? 71.41.210.146 (talk) 19:20, 22 January 2016 (UTC)

it's just the software developer in me that prefers to embed things in executable code Yeah, the software developer in me feels strongly about the KISS principle and gives it a high priority. As you said, shouldn't be a big point of contention. You're doing that part of the work, so you get to choose.
I dunno, it seems like you're using the tables at WP:COORDPREC as a guide, assuming some non-existent wisdom therein. I would have expected a mathematician to ignore those tables and develop a formula as if they didn't exist (a couple of years ago, they didn't). Perhaps I idealize mathematics and mathematicians. But most of what you said above is over my head; sorry I can't be more useful in this area. Have you considered bouncing the problem off some of the other people at the Math project?
The decimal table looks reasonable, the values increase by factors of 10 as expected. The first 620 km should be 620 m. Likewise the first three rows of the dms table. Beyond that, I couldn't say whether the numbers "look right"; all I could do would be to try some test cases and see if the new tables give the same answers as the old. Bearing in mind that the old tables have error windows that shouldn't exist in the new.
I think the N/S add unwarranted clutter. The usage instructions will refer to "latitude"; if the editor needs to be reminded that that refers to the N/S part of his coordinates, s/he's likely way below the level of understanding where one is concerned about coordinates precision. ―Mandruss ☎ 21:49, 22 January 2016 (UTC)

Why don't rows 3 and 4 of the dms table differ by a factor of 10? ―Mandruss ☎ 22:24, 22 January 2016 (UTC)

@Mandruss: Why don't rows 3 and 4 of the dms table differ by a factor of 10? Because row 4 is followed by a scale jump of 60×, while row 3 is followed by one of 10x. So we stay with seconds a bit longer (to objects of size larger than 1.72 km) to avoid having too little precision when we jump to minutes.

Er... there is no relevant formula at WP:OPCOORD. There is one for "how long is a degree of longitude as a function of latitude" (which I'm using), but what precision one should use is only vaguely specified. The latter forumula is the one I have to create, and to avoid pulling it completely out of my ass, I'm trying to make it consistent with the one at WP:COORDPREC.

All I have is "give precisions approximately one tenth the size of the object", and it's not clear if, when the choice is between 1/2 the size of the object and 1/120, which is preferred. The obvious thing to me to do is to set a goal of 1/10, but allow it to be missed by a factor of √60 = 7.746 on either side. That is, allow a precision as coarse as 0.7746 the size of the object before changing to a 60× finer resolution

One way I could reduce the 60x jumps would be to add intermediate levels in the form of d.d° and d°m.m′. Ignoring the previous WP:COORDPREC table and instead using sqrt(10) and sqrt(6) deviations from the ideal 1:10 ratio, I get:

Degrees-minutes-seconds format

For objects no larger than				Use precision
0°	30°	45°	60°
0.98 m	0.85 m	0.69 m	0.49 m	d° m′ s.sss″
9.8 m	8.5 m	6.9 m	4.9 m	d° m′ s.ss″
98 m	85 m	69 m	49 m	d° m′ s.s″
760 m	660 m	540 m	380 m	d° m′ s″
5.9 km	5.1 km	4.1 km	2.9 km	d° m.m′
45 km	39 km	32 km	23 km	d° m′
590 km	510 km	410 km	290 km	d.d°
For all larger objects, use d°

71.41.210.146 (talk) 23:11, 22 January 2016 (UTC)

Accept your judgment as to rows 3 and 4. The precision fell by a factor of 10, so my intuition said the break points should increase by the same factor. Shows what my intuition is worth in such things.
Er... there is no relevant formula at WP:OPCOORD. - Yeah, I realized same while you were writing, and edited that out before you saved. Still working on developing the ability to get things right the first time.
Using your example, 1⁄10 is closer to 1⁄120 than to 1⁄2; 0.1 is far closer to 0.0083 than to 0.5. Thus you would opt for 1⁄120. I don't understand the rest of what you said re that, but I don't know that one needs to go any further than that simple comparison. ―Mandruss ☎ 23:45, 22 January 2016 (UTC)

Opposed to any of what I would call "exotic" forms in the dms table, e.g. d° m.m′, as I don't think the need justifies the added complexity. Very few editors consider those possibilities, or even know that they are supported by the software. And precision isn't so critical that we need to go there, imo. ―Mandruss ☎ 00:15, 23 January 2016 (UTC)

Using your example, 1⁄10 is closer to 1⁄120 than to 1⁄2; 0.1 is far closer to 0.0083 than to 0.5. It's not obvious to me, actually!

IF you're using arithmetic distance, then obviously 1⁄10−1⁄120 = 11⁄120 < 1⁄2 − 1⁄10 = 4⁄10 = 48⁄120.

But if I consider the reciprocal ratios (precision/object rather than object/precision), then 10 is farther from 120 than it is from 2.

The normal way to handle that mathematically is to consider the ratios, which are the same no matter which numbers you take. 120⁄10 = 1/10/1/120 = 12 > 10⁄2 = 1/2/1/10 = 5.

That's what I was trying to show with that example; a factor of 12 is a much larger error than a factor of 5.

Opposed to any of what I would call "exotic" forms in the dms table Okay. It just makes the choice of a break point for the factor-of-60 jump more critical. If you actually want the point where x−1⁄10 = 1⁄10−x⁄60, then x = 12⁄59 = 1⁄4.91666 = 0.20338983. (And x = 2⁄9 = 1⁄4.5= 0.2222 for the jumps of 10.

Um... you know, that fits the previous table. How about I go and use those numbers?

71.41.210.146 (talk) 01:13, 23 January 2016 (UTC)

I think you're overthinking, as people with 140+ IQs are prone to do. One of the main objectives should be simplicity and ease-of-use for the common editor who has an IQ below 100, knows little of these underlying concepts, and has many more things to think about than coordinates precision. Otherwise, we'll end up with extremely accurate and precise tables that few people use. KISS, KISS, KISS. For this reason, I still oppose the exotics, and I'll defer to your judgment on things that don't increase complexity for the user. ―Mandruss ☎ 01:43, 23 January 2016 (UTC)

To expand and clarify, I think you're agonizing over mathematical details that have no significant effect for our purposes. For example, what is the effect on break points of the method in which you choose between 1⁄120 and 1⁄2? Is that effect significant in the big picture? If not, why not go with the simpler of the two methods? But I'm resigned to ending up with table code that is largely "black box", comprehensible to only an elite 1% of editors. I don't think that's in the long-term interest of the project, but this business requires give-and-take and that's part of my give. I'm less willing to give on matters affecting usability of the tables, as I expressed above. ―Mandruss ☎ 02:38, 23 January 2016 (UTC)

The difference between the 0° and 30° columns is entirely insignificant, because the aim at 1/10 of object size is entirely arbitrary. Zero^talk 03:10, 23 January 2016 (UTC)

Ah, another participant. Welcome. Why only 0°-30° and not 30°-45° and 45°-60° as well? The choices are (1) to give some rule of thumb and make it practical for the average, arithmetically-challenged editor to follow it, or (2) to throw out 99% of the precision section and simply say, "We suggest using less precise coordinates for larger objects." We have gone with (1) and chosen 1/10 as the rule of thumb (and this started long before I arrived on the scene a couple of years ago). Yes it's arbitrary, and there's nothing inherently wrong with that. And no one is forced to use the tables in any case. ―Mandruss ☎ 03:22, 23 January 2016 (UTC)

Having a more complicated table with lots of numbers in it is exactly the opposite to what an "average, arithmetically-challenged editor" needs. Zero^talk 03:43, 23 January 2016 (UTC)

As seen above, we are doing everything we can to make the tables accessible to the largest number of users. Even most arithmetically-challenged editors can compare two numbers to determine which is greater, which is the only skill required to use the tables. Obviously there will be instructions for use, carefully written for simplicity and clarity, which will also help. If that's not enough, the editor doesn't have to use the tables, as I said. But I wonder how many such editors are working with coordinates in the first place. ―Mandruss ☎ 04:38, 23 January 2016 (UTC)

The reason for the 0–30° jump is that the difference in cosine between 0° and 30° is quite small. The rate of change of circumference increases as you approach the pole (where the circumference becomes 0). Thus, it's pretty easy to interpolate.

If you divide the cosine into tenths, the corresponding angles (acos(1), acos(0.9), acos(0.8), etc.) are 0°, 25.84°, 36.87°, 45.57°, 53.13°, 60° (halfway!), 66.42°, 72.54°, 78.46°, 84.26°, 90°. The first tenth is more than 25°. The last tenth us less than 6°.

However, I had another thought. We want to encourage people to use resolution no finer than this advice. Going a bit coarser is not a problem; it's excessive precision we're warning against. Perhaps the table should be reordered to go from degrees down, and say "For objects no smaller than" size X use format Y. Same numbers, just rearranged.

Thoughts? 71.41.210.146 (talk) 03:58, 23 January 2016 (UTC)

However, I had another thought. If I'm reading you correctly, this would only affect the very few border cases, at or very close to the break. Do I have that right? If so, I don't feel it's worth switching to descending size, which I think would feel less natural to the user. In the real world, there are far more ascending lists (telephone directory) than descending ones (none comes to mind at the moment). ―Mandruss ☎ 04:14, 23 January 2016 (UTC)

Another problem with the section as it is now written is that people have to carefully read the fine print after the table to realise that it is only for longitude and not for latitude. This difference should be prominently displayed with the table. As an aside: are there any coordinates now in Wikipedia that use different precision for latitude and longitude? I would also ditch the larger formula, which is not going to be used by anyone at all. Perhaps it belongs in some article, properly sourced. Zero^talk 06:00, 23 January 2016 (UTC)

71:

1. Referring to the drafts marked DRAFT in red. I think all values should be rounded to whole numbers. This gives the best balance between simplicity/ease-of-use and accuracy, imo. The additional error windows will be 99% inconsequential and we can live with the small errors for the remaining 1%.
2. Once a draft is finalized, I would prefer to have some kind of "peer review" from the Math project, even if it's only one peer. Not a review of the details of the underlying math, necessarily, but just a sign-off on the break values. With due respect, I think this is too important to leave to one mind. Such a review would also have the effect of making the tables more durable, less vulnerable to casual modification.
   Although not strictly necessary, the ideal review would involve calculating the tables independently and then comparing results, ignoring insignificant differences resulting from differences in the math used.
   I did the existing tables on my own with little or no discussion, but that was different. I didn't use a mathematical formula but just hammered out each cell value using brute-force arithmetic and reasoning. That was more straightforward (and the consistency in the color patterns adds to the confidence in the accuracy).
   What think you? ―Mandruss ☎ 03:00, 24 January 2016 (UTC)

Interesting trivia. The comments at the bottom of the usage example at WP:COORDPREC, permalink involve a hypothetical case, 70 km and 30°. For that case, the existing tables give d.dd°, while the new tables give d.d°. Apparently that case is in one of the error windows closed by the new tables. ―Mandruss ☎ 05:55, 24 January 2016 (UTC)

Draft 2

The following tables assist in choosing a good precision for your object's latitude and size. Refer to the preceding section for more information about coordinates precision. To use these tables:

• Choose one of the tables depending on whether you want degrees-minutes-seconds format or decimal degrees format
• Find the column that is closest to the latitude of your object
• Starting at the top of the column, find the first value that is greater than or equal to the size of your object
• Note the coordinates precision at the end of that row
• If your object size is greater than the last value, use precision d° (whole degrees only)
• Resist the temptation to choose the value closest to your object size, as this may yield an incorrect result. For any 10-km object, for example, the best degrees-minutes-seconds precision is d° m′, not d° m′ s″.

[collapsed usage example here]

DRAFT2 values for discussion, not final, repeat DRAFT2

Degrees-minutes-seconds format For objects no larger than Use precision 0° 30° 45° 60° 17 m 15 m 12 m 9 m d° m′ s.ss″ 172 m 149 m 122 m 86 m d° m′ s.s″ 9 km 7 km 6 km 4 km d° m′ s″ 520 km 450 km 370 km 260 km d° m′ For all larger objects, use d°

Decimal degrees format For objects no larger than Use precision 0° 30° 45° 60° 6 m 5 m 4 m 3 m d.dddddd° 62 m 54 m 44 m 31 m d.ddddd° 620 m 540 m 440 m 310 m d.dddd° 6 km 5 km 4 km 3 km d.ddd° 62 km 54 km 44 km 31 km d.dd° 620 km 540 km 440 km 310 km d.d° For all larger objects, use d°

1. As suggested at § Precision guidelines, above, the tables use a target resolution of one-tenth of the object size.
2. The tables are not perfect. Some cases will yield a precision that is different from what you would get by doing the math (including trigonometry) for that specific case. This is because it is impossible to represent all cases correctly in a usable tabular format. The tables provide the correct precision for a large majority of cases. Any error will be limited to one level of precision (e.g., d° m' vs. d° m' s", or d.ddd° vs. d.dddd°), which is acceptable for the purposes of Wikipedia coordinates.

―Mandruss ☎ 06:36, 30 January 2016 (UTC)

RfC - Should coordinates be included in Wurdi Youang

There is an RfC at Talk:Wurdi Youang#RfC: should the coordinates be included in the article that may be of interest to participants in this project. --AussieLegend (✉) 14:14, 18 October 2016 (UTC)

Infobox problem

I'm aware of the RfC at Wikipedia:Village pump (proposals)#RfC: Deprecate named coordinates-related infobox parameters. As a result of the changes made, some articles have been popping up at Category:Pages with malformed coordinate tags as having duplicate coordinates—mainly articles using {{Infobox protected area}} and {{Infobox islands}}—which I've been removing from the category by deleting the named coordinate parameters and leaving the {{coord}}. This morning, when I did so in Chazy Fossil Reef, instead of the location map there appeared the error message "Lua error in Module:Location_map at line 362: No value was provided for longitude". This hasn't happened before—for instance, when I did the same thing to Calanques National Park yesterday. I've been unable to track down the source of the problem. Any help here? Deor (talk) 16:07, 17 November 2016 (UTC)

@Deor: Hi, suggest taking this to Wikipedia talk:Coordinates in infoboxes and, just to be sure, pinging the main player in the technical end of this, Jc86035. ―Mandruss ☎ 17:27, 17 November 2016 (UTC)

Done. Deor (talk) 17:59, 17 November 2016 (UTC)

Template:Infobox protected area has been fixed now. Deor (talk) 20:49, 17 November 2016 (UTC)

Lowest elevation in Antarctica?

There's an interesting puzzle at List of elevation extremes by country. IP User 202.87.162.173 (talk · contribs) listed Deep Lake, in the Vestfold Hills, as the lowest elevation in Antarctica, providing [5] as a reference. That reference is (IMO) reliable to verify that Deep Lake is at -50m elevation, but remains silent as to whether that is the lowest elevation in Antarctica. I have been unable to find any source that verifies that Deep Lake is the deepest in Antarctica, so the claim is probably original research. However, I have been unable to find a deeper verified elevation (which is weak support for the claim).

To make things more complex, various reliable sources (such as the CIA World Factbook) list the Bentley Subglacial Trench at −2,540 m (−8,330 ft) as the lowest point in Antarctica. Of course, that point is covered with thousands of meters of ice. Wikipedia consensus seems to define surface elevation above ice, rather than below. This seems to match the commonly-held definition of elevation.

What to do? I am stymied. Comments welcome at Talk:List of elevation extremes by country. —hike395 (talk) 03:32, 24 January 2017 (UTC)

How to extract longitude degrees from a Coord template?

I have been working on converting Infobox templates as part of Wikipedia:Coordinates in infoboxes. I have come across a technical issue that I need help with. A couple of infoboxes, such as Template:Infobox Municipality PT, test the value of |longd= (longitude degrees) in order to decide which map to display in the infobox. It's very clever, but I haven't figured out how to replicate it using {{Coord}}. Here's a simplified version of the current code:

| pushpin_map             = {{#if: {{{longd|}}} | {{#ifexpr: {{{longd}}} > -10 | Portugal  | {{#ifexpr: {{{longd}}} < -24 | Portugal Azores | Portugal Madeira }} }} }}

My question is: Assuming that we deprecate and remove the latd/longd parameters and replace them with the {{Coord}} template, how do I implement this test in the infobox? Any links, ideas, or tips are appreciated. I poked through the archives for this talk page, but it's a tricky thing to search for. – Jonesey95 (talk) 00:40, 23 January 2017 (UTC)

Special:ExpandTemplates can show the output of {{coord}} and then string search can be used, e.g. with Module:String#match. It relies on the exact output format of {{coord}}. I tested {{Coord|57|18|22|N|4|27|32|E}}. It produces a string which includes <span class="geo">57.30611; 4.45889</span>. The second number can be captured with {{#invoke:String|match|s={{{coordinates}}}|pattern=<span class="geo">.-; (.-)</span>}}Test output: 4.45889. 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 {{#invoke:coordinates|coord2text|{{Coord|57|18|22|N|4|27|32|E}}|lat}} and {{#invoke:coordinates|coord2text|{{Coord|57|18|22|N|4|27|32|E}}|long}}. 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 coord2text and coordinsert. 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)

@Dispenser: Interesting. I'm using {{#expr:{{PAGESINCATEGORY:Coordinates on Wikidata|R}}+{{PAGESINCATEGORY:Coordinates not on Wikidata|R}}}} 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. @Dispenser: since you probably have the best tools for this, is this something you could do? -- The Anome (talk) 14:28, 2 March 2017 (UTC)

SELECT page_title, gc_lat, gc_lon, gc_globe, gc_type, gc_region, gc_primary
FROM u2815__p.coord_enwiki 
JOIN page ON page_id=gc_from AND page_namespace=0
LEFT JOIN categorylinks ON cl_from=gc_from
     AND cl_to IN ("Coordinates_on_Wikidata", "Coordinates_not_on_Wikidata")
WHERE cl_from IS NULL AND gc_globe='' /* Earth */
LIMIT 100;

@The Anome and Tagishsimon: 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#Cartography about the precision of minutes and degrees which doesn't match the mentioned in Wikipedia:WikiProject Geographical coordinates#Precision guidelines. 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

Map of Japan showing only the main four islands and Okinawa

Map of Japan showing all locations within Japan

Right now we have {{Location map Japan}}, 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 {{Location map Japan full}} (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#Rounding elevation: 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)

@Brubsby: If you read Wikipedia: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. ―Mandruss ☎ 21:53, 2 August 2017 (UTC)

@Mandruss: 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)

@Brubsby: The place for bots to be approved is at Wikipedia: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)

@Nihonjoe: Nobody has suggested seeking community consensus here. I suggested VPR since that's where the successful Wikipedia: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. ―Mandruss ☎ 22:43, 2 August 2017 (UTC)

@Mandruss: 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. ―Mandruss ☎ 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)

@Jc3s5h: 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. ―Mandruss ☎ 23:15, 2 August 2017 (UTC)

@Jc3s5h and Mandruss: 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)

@Brubsby: 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. ―Mandruss ☎ 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 ({{coord|51|28|40.1|N|0|0|5.3|W|type:landmark_globe:earth_region:GB_scale:1000|name=Airy Transit}}). 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)

@Jc3s5h: 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 {{Coord}}s. If there are a significant number of corner cases for decimal degree {{Coord}}s, 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 [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)

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.
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. ―Mandruss ☎ 04:18, 4 August 2017 (UTC)

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.

Findings

Classification	Total	Notes	Example	Proposed action
overprec dec	50	Standard case where human editor simply over-specifies the precision	Adavi, Maharashtra	round
overprec GNIS	3	Like the standard case, but where there's a GNIS reference that has usually 7 decimals of precision, not sure what to do about these	Antelope Valley (Nevada)	unsure
overprec dec with format=dms	16	These are like the first case, but with format=dms, they appear nicely in the article due to this, but the geohack link is still overprecise. In addition, rounding these down would not altar the appearance of the links in the article at all, as 6 decimal places of precision is more than format=dms shows.	Hill Close Gardens, Warwick	round
overprec dec on lat/lon template (presented as dms)	27	These require more investigation I believe, as they're using lat/lon in a template instead of a {{coord}}. These cases are also somewhat oversampled, because my random distribution weights every link instead of every page with a link. And these pages had a lot of imported coordinates.	Grade II* listed buildings in Anglesey	ignore/address separately
transcluded from wikidata	1	Out of scope for this bot. If this bot is successful, running a similar bot on wikidata might be a good future task.	Itsukushima Shrine	ignore
articles I wouldn't touch	1	Articles that, as a human editor, I'm not sure if they should be this precise or not. The canonical "put on the blacklist" articles	List of WAAS reference stations	blacklist
rounding error dec	1	Articles that have floating point errors from previous bots and should be rounded down	Meșeni	round
transcluded from another list	1	This will be ignored by the bot, simply included because I was not looking at wikisource directly	List of National Monuments in Connacht	ignore

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.  Resolved
• 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#In surveying 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. ―Mandruss ☎ 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 {{coord|12|3|45|N|67|8|9|W}} or {{coord|12|03|45|N|67|08|09|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, Wikipedia:Village pump (technical)#Standardising map parameters in infoboxes. 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 ☎ 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:

Vermont city and town boundaries for discussion.

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)

@Jc3s5h: 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? ―Mandruss ☎ 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. ―Mandruss ☎ 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 {{bots|deny=RMCD bot}}, 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 {{Coord}} with |display=inline (that's the default, so you can alternatively omit the |display= parameter). Pioneer Library System shows one method using a table. Norman, Oklahoma#Geography includes coordinates within the text. Optionally, you can include a {{GeoGroup}} in "External links" to allow display of all the article's coordinates on one map; see Pioneer Library System#External links. ―Mandruss ☎ 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#Vertical metre merge. —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)

@GrahamHardy: I added region and type.[6] Is that better? ―Mandruss ☎ 10:07, 28 January 2018 (UTC)

Brilliant, Thanks GrahamHardy (talk)