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.


As of July 27, 2016 10:22 (UTC) Refresh
User reported errors:

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

Formatting errors:

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


  • 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

"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.) (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
For objects no larger than
30° 45° 60°
d° m′ s.sss″
d° m′″
d° m′ s.s″
d° m′ s″
d° m′ (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
30° 45° 60°
d° m′ s.sss″
d° m′″
d° m′ s.s″
d° m′ s″
d° m′
For all larger objects, use d°
Decimal degrees format
For objects no larger than Use
30° 45° 60°
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? (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
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′″
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
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? (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
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′″
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° (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? (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? (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)


  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
30° 45° 60°
17 m 15 m 12 m 9 m d° m′″
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
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)

Signpost Followup[edit]

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

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)