Wikipedia talk:WikiProject Geographical coordinates

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia talk:GEO)
Jump to: navigation, search
WikiProject Geographical coordinates
WikiProject icon WikiProject Geographical coordinates is of interest to WikiProject Geographical coordinates, which encourages the use of geographical coordinates in Wikipedia. If you would like to participate, please visit the project page, where you can join the project and see a list of open tasks.
 
WikiProject Microformats
WikiProject Geographical coordinates is part of, or of interest to, WikiProject Microformats, which encourages the deployment of microformats in Wikipedia, and documents them in the article space. If you would like to participate, visit the project page.
 

To do[edit]

edit·history·watch·refresh Stock post message.svg To-do list for Wikipedia:WikiProject Geographical coordinates:

Find coordinates for[edit]

Use Maybe-Checker: verify and/or add coordinates to articles in categories likely to need coordinates.

Articles are also listed on WolterBot's cleanup listings (User:WolterBot/Cleanup statistics)

See also: Wikipedia:Obtaining geographic coordinates

Tag articles needing coordinates[edit]

{{coord missing|country name}} is added to articles needing coordinates. This makes them available for the previous step.

Fix[edit]

As of August 21, 2017 14:44 (UTC) Refresh
User reported errors:

no pages or subcategories
0 pages
no pages or subcategories
0 pages
no pages or subcategories
0 pages

Formatting errors:

no pages or subcategories
0 pages
no pages or subcategories
0 pages

More[edit]

  • Provide advice on the use of {{Attached KML}} on the WP:GEO page. KML means Keyhole Markup Language, using XML
  • Make better examples, also showing use of decimals and scale.
  • Add an attribute for other planets and the moon and probably also star maps.
  • Extend NASA World Wind support to include layers (by type) and labels.
  • Rewrite the article Geographic coordinate system linked from many coordinates. Related articles: latitude, longitude.
  • Convert existing data to templates
    • Identify special formats not yet converted, e.g. E12 23 54 N23 34 52
  • Clean up / reduce redundancy in U.S. city articles (rambot/smackbot generated), see past discussion
  • Suggestions for extensions at mw:Summer of Code 2009#MediaWiki core and new extensions
  • Discuss, summarise and specify a set of changes to geohack, such as type list revision, support for linear features, bug fixes, &c

Need another location map for Japan[edit]

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[edit]

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[edit]

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[edit]

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?[edit]

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[edit]

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?[edit]

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 110 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 (51°28′40.1″N 0°0′5.3″W / 51.477806°N 0.001472°W / 51.477806; -0.001472 (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[edit]

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?[edit]

Is there any consensus as to whether 12°3′45″N 67°8′9″W / 12.06250°N 67.13583°W / 12.06250; -67.13583 or 12°03′45″N 67°08′09″W / 12.06250°N 67.13583°W / 12.06250; -67.13583 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)