Wikipedia talk:WikiProject Geographical coordinates

From Wikipedia, the free encyclopedia
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 February 11, 2016 00:20 (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.
  • Make better examples, also showing use of decimals and scale.
  • Create an export to OpenStreetmap of all points in the database
  • 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


New GeoHack page[edit]

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)

"Prime" symbols vs straight apostrophes[edit]

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 / 0.00000°N 0.00000°E / 0.00000; 0.00000 (Example coordinate). 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]

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
30° 45° 60°
d° m′ s.sss″
d° m′ s.ss″
d° m′ s.s″
d° m′ s″
d° m′
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
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
30° 45° 60°
d.dddddd°
d.ddddd°
d.dddd°
d.ddd°
d.dd°
d.d°
For all larger objects, use d°
  1. 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 110 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×10k 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/k0.1, where k is the size of the following jump, 10 or 60.
  • The minimum ratio for a jump of 10 is 7/1010 = 5.5603, at which point it jumps to the maximum ratio of 55.603. The minimum ratio for a jump of 60 is 7/1060 = 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
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
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
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, 110 is closer to 1120 than to 12; 0.1 is far closer to 0.0083 than to 0.5. Thus you would opt for 1120. 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, 110 is closer to 1120 than to 12; 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 1101120 = 11120 < 12110 = 410 = 48120.
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. 12010 = 1/10/1/120 = 12 > 102 = 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 x110 = 110x60, then x = 1259 = 14.91666 = 0.20338983. (And x = 29 = 14.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 1120 and 12? 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. Zerotalk 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. Zerotalk 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. Zerotalk 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[edit]

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
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
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)

Accuracy versus number of digits[edit]

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 [1]. 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. Zerotalk 03:38, 23 January 2016 (UTC)

See false precision for an article on this topic. Zerotalk 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.) Zerotalk 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. Zerotalk 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. Zerotalk 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 24°37′33.117″S 70°24′11.642″W / 24.62586583°S 70.40323389°W / -24.62586583; -70.40323389 (VLT Unit Telescope 1),[2]:45 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. Zerotalk 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. Zerotalk 08:25, 23 January 2016 (UTC)

Coords for small linear topics[edit]

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)