Wikipedia talk:WikiProject Geographical coordinates/Archive 30

Archive 25

←

Archive 28

Archive 29

Archive 30

Removal of precision tables

Re: [1]

@Abductive: As stated below the tables, the target resolution is one-tenth of the object size. Let's look at the case you cited, object size 1 m at 45°, dms format. The table should recommend the precision that yields a resolution closest to one-tenth of 1 m, or 10 cm. The precisions to be compared are:

d° m' s.ss" = 22 cm resolution per WP:OPCOORD; 10 - 22 = -12, absolute value 12
d° m' s.sss" = 2.2 cm resolution; 10 - 2.2 = 7.8
d° m' s.ssss" = 0.22 cm resolution; 10 - 0.22 = 9.78

The lowest bolded value of the three is 7.8, so d° m' s.sss" is the best dms precision for that case, and that is the precision shown in the table.
I know you have voiced opposition to the tables before, but it was for reasons other than inaccuracy. Feel free to start a discussion about that, but please don't remove the tables without a substantial consensus to do so, and certainly not with the false rationale that "This usage table is profoundly wrong." The tables have been fairly widely used, and they are the only thing we currently have that makes application of the precision guidelines practical for the average editor. ―Mandruss ☎ 10:56, 28 January 2018 (UTC)

Dude, your math is wrong. There is no need to try to blind us with BS. As I stated in the edit summary, at 45 deg N, 0.1" spans 2.2 meters. This is smaller than the margin of error of the mapping services, as can be seen by switching between Google and Bing. Your made-up thing is overprecise by many orders of magnitude. Abductive (reasoning) 19:16, 28 January 2018 (UTC)

There is no need to try to try to blind us with BS. Per WP:AGF, please refrain from accusing me of bad faith without clear evidence. Thank you. With that out of the way...
Those tables are nothing more than derivatives of the tables at WP:OPCOORD and its longstanding recommendation for "precisions approximately one tenth the size of the object" (both existed for some time before I arrived on scene over 4 years ago). I now see that you removed that longstanding recommendation two days ago without discussion, so I assume you are not disputing my previous sentence but rather wishing to modify the longstanding guideline itself. I wouldn't have made such dramatic changes without prior consensus, but they aren't completely out of line per WP:BRD. Consider them reverted by me per WP:BRD—although I haven't yet taken the time to sort out what else needs reverting and done the actual reverts. If you wish to pursue this, we can now enter the discussion phase and see if there is a consensus for those changes. As this page doesn't get a lot of participation these days, it may require an RfC. Please advise. ―Mandruss ☎ 20:33, 28 January 2018 (UTC)

Even if the guideline changes, we will still need tables that allow an acceptable precision to be chosen via a simple lookup, as opposed to a mathematical calculation. That allows acceptable precisions to be chosen by editors who suck at mathematics or just lack the energy. It's either that or a script that accepts object size and latitude, and gives best precision in both formats. My feeling was that any such script should do the actual maths, including trigonometry, rather than simply encoding the existing tables. That would eliminate the "error holes" inherent in the tables. But (1) we've yet to find someone able and willing, and (2) we would then be dependent on them or some other JS-qualified editor to implement any improvements, whereas a table allows implementation of improvements by most editors. ―Mandruss ☎ 21:32, 28 January 2018 (UTC)

I think the section Precision guidelines should be revised to say that the precision should be based on the size of the object, or the accuracy to which the location is known, whichever is looser. Maybe some organization has adopted some internal procedure for stating the location of a thing with far more precision than justified by the precision table (such as deciding that a town is located right in the middle of the town hall). That doesn't mean Wikipedia should follow that procedure (especially if they never tell us about their procedure, and merely publish an over-precise position). Jc3s5h (talk) 20:54, 28 January 2018 (UTC)

I agree as to your uncertainty point, but I've always handled uncertainty by increasing the object size. Depending on the amount of the increase, that may reduce precision. It's useful to bear in mind that object size is nothing more than an mathematical abstract for the purpose of choosing a precision, and never seen by the reader. So it's not a problem to use an object size of, say, 300 m for an object we know to be 50 m, if its location is sufficiently uncertain. ―Mandruss ☎ 20:57, 28 January 2018 (UTC)

This page is a WikiProject, not a documentation page for a particular template. There may be a particular template parameter somewhere for object size that has to be used as a proxy for uncertainty of position, because the template lacks a parameter for uncertainty, but the project page should distinguish when it is describing a principle from when it is describing a template parameter. Jc3s5h (talk) 00:52, 29 January 2018 (UTC)

I don't follow. I'm not talking about a template. ―Mandruss ☎ 02:03, 29 January 2018 (UTC)

I'm afraid that the table is WP:OR and has to go. For many many years, the consensus at this Wikiproject was that going to the nearest arcsecond or four digit decimal degrees was more than adequate. It is your table that breaks this consensus. In fact, I noticed an increase in overprecision in coordinates in articles and came here to see if somebody had altered the intructions, and lo and behold, you had. Abductive (reasoning) 09:39, 29 January 2018 (UTC)

There is both accuracy and precision to consider. Abductive (reasoning) 09:39, 29 January 2018 (UTC)

Even the idea of larger objects such as cities needing less precision is not the consensus. In actual practice, people either tag the historic center of the city, or the city hall. Abductive (reasoning) 09:39, 29 January 2018 (UTC)

It is your table that breaks this consensus. That is simply false. The "one-tenth of object size" rule-of-thumb has been on the page in some form since November 2005.[2] I clearly showed above that the tables do nothing but save the editor the calculation. The tables give the precision closest to a resolution of one-tenth of object size, full stop. You are free to show a case where that doesn't hold true, you have yet to do so, and I can't prove a negative. If the tables are WP:OR, then so is 2+2=4.
I added the disputed tables in July 2014,[3] and I did so without prior consensus precisely because they did not change the guidance but only made it more accessible. There has been no objection until now, presumably because they did not change the guidance but only made it more accessible. To the contrary, what feedback I have received before now has been positive feedback. Not one editor has hinted that the tables changed the guidance one iota. If you are still doubting my integrity, I can spend an hour or two of my life hunting down that feedback (it was not all on this page, and I don't recall which other pages were involved). ―Mandruss ☎ 21:12, 29 January 2018 (UTC)

I think we can and should agree that the disputed tables are consistent with the guidance that has been on the page since 2005. I hear you saying that it does not reflect actual practice, and that it has flaws that you feel are unacceptable. I don't doubt that you have been doing precision your way for a long time and have received no objection, so you see that as unwritten consensus. The thing is that I've been doing it the written way for a long time (over three years) and have likewise received no objection. I also have the positive feedback I mentioned above; do you have any supporting your view? The fact is that few editors care about coordinates, and even fewer about their precision.
The only reasonable solution in my view: Go by what is written. If you disagree with what is written, seek a consensus to change it. Once we agree on that, I'm happy to hear your argument for changes and give it serious and fair consideration (not that my agreement would be enough, but I would change my position and get behind you in your proposal for change). I am all for improvement, but I also oppose unjustified complication. I also feel that the project is not served by changing direction every time somebody has a better idea, which is why wide community involvement is needed. And finally I feel that perfect is the enemy of good, that there is a point of diminishing returns where stability and consistency become more important than further improvement to guidelines.
So let's talk about it, calmly and with mutual AGF.
Alternatively, you can continue to do precision your way, I and others will continue to do it the written way, and the project will continue to suffer for lack of coherence or consistency in precision. In some cases you will be changing our work without even knowing it, and vice versa. Occasionally you will encounter an editor who believes in following written guidelines for the sake of consistency, and you can have this same drawn-out debate at article level, possibly complete with edit warring. I don't think that's a good solution, but it's an alternative. ―Mandruss ☎ 23:20, 29 January 2018 (UTC)

You fail to address my central arguments. Let's just look at the most important one. At 45° N, 0.1" spans 2.2 m. Do you agree? Then, in your table, you say for an object that is 1 m, one should use d° m' s.sss". Do you agree that that is what the table says? So, here is the question; what does 0.001" span? Because according to your reasoning, it should be 1/10th the size of the desired object, yes? Abductive (reasoning) 04:28, 30 January 2018 (UTC)

You keep comparing 2.2 m to 1 m. The more useful comparison is 2.2 m (220 cm) to 10 cm, one-tenth of the object size. In other words, the table values at WP:OPCOORD correspond not to object sizes but to one-tenth of object sizes. You do understand that, right? If you do, and you still see a discrepancy...
here is the question; what does 0.001" span? The answer: At 45°, it spans (has a resolution of) 2.2 cm—as I said in my opening comment.
d° m' s.sss" is closer to 10 cm resolution than any other dms precision. Do you disagree? If I were a mathematician, I could articulate why the apparent discrepancy is not a discrepancy. But, sadly, I am not one. It's simply an artifact of the way numbers work. d° m' s.sss" is not a "great" precision for 1 m objects at 45°, it's just the best (least bad) dms precision available to us. The ideal precision would be somewhere between d° m' s.sss" and d° m' s.ss". ―Mandruss ☎ 05:22, 30 January 2018 (UTC)

I've alluded to "error holes" in the tables, and this is addressed in note 2 below the tables. These are the inevitable result of using a table format, something like the errors produced when you project a globe onto a flat map. The errors occur only near the precision boundaries and are limited to one level of precision. It's possible these holes play a part in the apparent discrepancy. As I said, they could be eliminated with a script that does the maths, which would eliminate the need for the tables. As I also said, that has a downside, and my current view is that the tables are good enough for Wikipedia purposes. ―Mandruss ☎ 05:40, 30 January 2018 (UTC)

"It's useful to bear in mind that object size is nothing more than an mathematical abstract for the purpose of choosing a precision, and never seen by the reader. So it's not a problem to use an object size of, say, 300 m for an object we know to be 50 m, if its location is sufficiently uncertain." An object with a size of 50 m has a size of 50 m, full stop. If the uncertainty in position is 300 m, then the uncertainty of position is 300 m. If I want to display to the reader a precision of 0.01′ because the object is at 30° N longitude, and that is most consistent with 300 m, I are using the uncertainty of position and not considering the size of the object. I am not using an object size of 300 m, in the abstract. In principle, a template could exist in which I specify the object size, the uncertainty of position, or both.

But the template being described on the project page, {{coord}}, does not have any such parameters, it simply allow the invoker to write the latitude and longitude with varying number of digits. The number of significant digits in the template invocation will be preserved in the displayed value, even if the last few digits are zero. So it is folly to speak of inflating the object size to allow for position inaccuracy; the invoker is simply indicating the number of significant figures; the reason for the choice cannot be encoded. Jc3s5h (talk) 09:24, 30 January 2018 (UTC)

Well I still don't follow. I know the reason can't be encoded; regardless of how you arrive at the precision, there is no way to communicate to the reader how or why you arrived at it. To some extent, barring some change to {{coord}}, the information hidden in precision will always be understood only by a few Wikipedia editors. Even object size will remain largely hidden until there is a lot more site-wide consistency in the implementation, and even then apparent only to readers who really pay attention to precision vs. object size and deduce what precision must mean. That is to say, perhaps one reader in a thousand. And how would that one-in-a-thousand reader know how much of the precision comes from object size and how much comes from location uncertainty, if any?
I have wondered whether precision is really worth all the trouble in the first place, and wouldn't strongly object to a fixed precision for everything. I started down this path years ago only because of the longstanding statement in the guidance: "Overly precise coordinates can be misleading by implying that the geographic area is smaller than it truly is." To my mind, (1) most readers wouldn't read that into the precision, having no understanding of coordinates in the first place, and (2) so what if they did? Are they really going to be misled by a 1-meter precision for Algeria? If all precisions were the same, precision couldn't "imply" anything at all. ―Mandruss ☎ 09:35, 30 January 2018 (UTC)

As you say, so few editors really understand precision that the reader can garner very little from the precision of a set of coordinates. But I would be opposed to imposing a fixed precision because there could be an article that discusses a group of objects that are close to each other, and with well-established positions, and it would be useful to use high-precision coordinates. For example, Royal Observatory, Greenwich currently describes in prose the position of various historical transit circles that served to locate 0° longitude. If a future precision survey resulted in precise coordinates for these, they could be incorporated in the article. Or, there are a number of geodetic markers in Washington, DC, that were relied upon for mapping and navigation, which have been accurately located, and could be described in an article. Jc3s5h (talk) 15:14, 30 January 2018 (UTC)

so few editors really understand precision that the reader can garner very little from the precision of a set of coordinates. That part of the problem is not about editors' shortage of understanding. If every editor were a precision expert, the information implicit in the precision would still be almost completely opaque to almost all readers except those editors. It's little different from a situation where almost all readers have vision problems and we don't have Wikipedia:Manual of Style/Accessibility!
If a fixed precision were used, it would be the highest precision needed for, say, 9,999 out of 10,000 cases, and the last one could be a WP:IAR case. For decimal-degrees format, I wouldn't have a problem with d.dddddd, which would give a resolution no larger than 11 cm. Dms format is a little trickier, just because it requires more space (an issue for infoboxes, albeit relatively minor), but d° m' s.ss" would give a resolution no larger than 31 cm. If a smaller resolution were really needed, it might justify a switch to d.dddddd, or you could invoke IAR and use whatever precision you needed. I think such a methodology would address any cases like what you've described. ―Mandruss ☎ 15:51, 30 January 2018 (UTC)

I'm concerned that as soon as a guideline is created for a fixed precision, somebody would write a bot that changes all the precisions to match the guideline. So I would oppose it unless you, in parallel, can gain consensus to update the Wikipedia:Bot policy to forbid bots that change the precision of coordinates. Jc3s5h (talk) 18:04, 30 January 2018 (UTC)

You guys talk too much. Here's what I'm saying: 0.001" degrees spans 2.2 cm, which is 4.84 square cm. A square meter object is 10,000 square cm. 10,000/4:.84 = 2066. So going to 0.001" gets you to over 2000 times smaller than the object, not 10 times! Abductive (reasoning) 19:19, 30 January 2018 (UTC)

There's no such thing as talking too much, provided it's constructive and civil. These are not simple concepts and issues, and the future of the encyclopedia is a bit more important than brevity I think. I would be interested to hear your opinion about fixed precision, if you have one. Fixed precision would moot this entire debate and all others like it, for eternity.
Object size is linear, one-dimensional. It has to be because precision resolution describes a one-dimensional line across the surface of the globe. So it makes no sense to speak of two-dimensional area. Beyond that, I honestly can't do any better than my replies at 05:22, 30 January 2018 (UTC) and 05:40, 30 January 2018 (UTC) (the first being the most important). Lord knows I spent a ton of time on them. ―Mandruss ☎ 00:31, 31 January 2018 (UTC)

Please provide a reliable secondary source source that says that object sizes are one dimensional when coordinates are given in two dimensions. Abductive (reasoning) 00:37, 31 January 2018 (UTC)

Latitude coord precision has its resolution. Longitude coord precision has a separate resolution. Per WP:OPCOORD, we actually use only the longitude part for choosing the precision, and assume that the latitude part is close enough to simply copy the longitude precision. The values in the table give distances in the east-west direction corresponding to a small change in longitude, at different latitudes. You can also take the equator columns of the table as a rough guide to distances in the north-south direction that correspond to a small change in latitude, since they vary only a little bit at different latitudes.
There is no "secondary source" that describes how Wikipedia chooses coordinates precision. ―Mandruss ☎ 00:45, 31 January 2018 (UTC)

Actually, that last sentence in green does not describe actual practice, as it suggests that we calculate a latitude precision separately from the longitude precision. Nobody does that, the added benefit wouldn't be worth the added effort, and that probably should be changed. But that doesn't change the essential point. ―Mandruss ☎ 00:56, 31 January 2018 (UTC)

Come to think of it, if you chose separate precisions for latitude and longitude, you would then describe two "object sizes", one N-S and the other E-W. Maybe that's what the original author(s) of OPCOORD intended, I don't know, but I shudder to think of taking this effort and complexity and doubling it. It seems to me that many authors of guidelines are very much disconnected from what is reasonable to ask of ordinary editors. ―Mandruss ☎ 01:41, 31 January 2018 (UTC)

And the fixed-precision idea continues to grow on me. ―Mandruss ☎ 01:50, 31 January 2018 (UTC)

So, your WP:OR trumps any secondary source on, say, accuracy and precision in mapping? And you are perfectly okay with requiring people to map a one meter object to one inch of precision? Also, you are demanding that one inch of precision even though there is no known method for obtaining coordinates that precise for our editors? Remember that civilian GPS can only get 2 or 3 meters of accuracy. One may also note that Bing and Google maps don't line up all that well. Abductive (reasoning) 03:58, 31 January 2018 (UTC)

We appear to be speaking different languages, and you keep reiterating points that I have already responded to. I wish you would give some thought to the fixed-precision idea, which would eliminate this debate, but I can't force you to do so. Jc3s5h, do you have any opinions related to this disagreement? Anybody else watching? ―Mandruss ☎ 04:40, 31 January 2018 (UTC)

You appear to be trying to improve accuracy by increasing precision. What I am asking is, can you read the accuracy and precision article with an eye towards mapping and coordinates? Abductive (reasoning) 06:38, 31 January 2018 (UTC)

As for fixed precision, I can show that if one follows Wikipedia policy and guidelines, that is, requiring either reliable secondary sources for the data, or recognizing that user-added civilian GPS data cannot be more accurate than 2-3 meters (and the commercial Google and Bing maps are also at least this erroneous too), one is largely restricted to either 1" or 0.0001°. For example, in my recent edit to Mount Kusatsu-Shirane I corrected a 2.716 kilometer error. I pointed the coordinates at a cairn marker of the summit. I had to use 36.6438°N 138.5279°E  rather than 36°38′38″N 138°31′40″E because the 0.0001° coordinates were closer. Now, if you, like me, have never visited this particular Japanese volcano, how could you be more certain of your accuracy even if you added digits to the precision? Abductive (reasoning) 06:38, 31 January 2018 (UTC)

Are you saying you would support fixed precision using d° m' s" and d.dddd°? Just for fun, I've gone ahead and sandboxed a proposal, here. ―Mandruss ☎ 07:22, 31 January 2018 (UTC)

Anyway. I think most editors would place markers somewhere near the center of the subject object, in that case the volcano, and d° m' s" would have easily gotten you close enough to that center. There is little to no reader benefit in choosing some other marker location known only to you (cairn marker of the summit). Even if you do that consistently, it's useless to readers unless (1) it has been widely implemented site-wide, and (2) readers somehow divine that's what we're doing. In other words, for all practical purposes, it's useless to readers. In that particular case, in my view, the problem was your desire to do that, not the guidance. ―Mandruss ☎ 21:06, 31 January 2018 (UTC)

Before I got there the coordinates pointed at no mountain at all. If you look at Google Maps (the map, not the satellite view) you will see that there pin for the mountain is quite close to my coordinates. Abductive (reasoning) 06:51, 1 February 2018 (UTC)

As for accuracy of GPS and mapping services, I understand what you're saying. I'm not convinced that we need to go as low as d° m' s" and d.dddd° if the 3 major mapping services are consistent within 2–3 m. In many cases in the kinds of articles where I do a lot of my editing (ex. Shooting of Michael Brown), there is significant reader benefit in placing the marker fairly precisely, and I don't think d° m' s" and d.dddd° would be enough in many cases. The width of a street is way smaller than the diameter of a volcano. As long as I can get a good marker placement in the 3 major services, I can live with the fact that the accuracy of civilian GPS and the services is exceeded a little. I could meet you halfway at d° m' s.s" and d.ddddd° for fixed precision, and I would cite your point in the proposal. ―Mandruss ☎ 21:06, 31 January 2018 (UTC)

I, for one, oppose fixed-precision for all geographical coordinates. Consider a mountain range. In {{Infobox mountain range}}, we allow two different coordinates: one for the highest peak, and the other for the overall range. There is no correct coordinates for a range known to 0.0001°: any such a choice would probably be original research. Instead, the Mountains WikiProject suggests using coordinates to the nearest 1', which can be precise enough to land on a ridge, but not make a more specific choice. —hike395 (talk) 07:42, 31 January 2018 (UTC)

@Hike395: Thanks for joining. I don't know if you have read the sandboxed proposal, but its fixed-precision proposal provides for exception cases. Do you feel that's insufficient for the cases you're describing? ―Mandruss ☎ 07:47, 31 January 2018 (UTC)

@Mandruss: I think by either suggesting high-precision coordinates, or failing to give any guidance, we will invite original research that will be difficult to fix. I think the current guidance supports editors (such as myself) that remove excess precision when they find it. —hike395 (talk) 07:58, 31 January 2018 (UTC)

@Hike395: I'm not sure what you consider OR. IIRC, GNIS gives all coordinates to 7 decimal positions, and a really OR-anal editor might say it's OR to reduce that per our current guidance. So there is some wiggle room here, and that's just the start of it. I and others routinely do far more OR-like things in current events articles, where we don't even have coordinates to start with, simply because that's the only way we can provide online mapping. In one case I had to follow the narrative description of a foot chase in the news reports and deduce the location of the end of it by referring to a map. None of this has ever met with objection. It's hard to imagine that, given RS for d.ddd, someone would see OR in extending it to d.ddddd—especially if it were extended to d.ddd00! ―Mandruss ☎ 08:32, 31 January 2018 (UTC)

I also don't know how you define "excess precision". If you mean precision that implies too small an object, that's exactly the principle that I propose to change because it means nothing to readers. As far as I can tell, most of our thinking about precision doesn't actually serve readers. I think I make this case in the sandboxed proposal; if I decide to go forward with it I think most of the opposition will be because editors simply can't open their minds and think outside the current box. ―Mandruss ☎ 08:55, 31 January 2018 (UTC)

@Mandruss: Scientists have a notion of significant figures and conversely false precision. The values we report are limited in precision by both measurement error and ambiguity of definition. I claim we shouldn't mislead our readers or make up extra digits of precision, even if 99.9% of users and and 90% of editors don't appreciate this issue. Note that these notions are supported at MOS:UNCERTAINTY, beyond WP:OPCOORD. —hike395 (talk) 10:09, 1 February 2018 (UTC)

Well, offending scientists is not original research. We're here to serve readers, not scientists and not ourselves. ―Mandruss ☎ 03:09, 2 February 2018 (UTC)

OPCOORD compromise option

If I decide not to go forward with the fixed-precision proposal, or it fails, I will support the following changes to the existing guidance per discussion in the parent section.

• At WP:OPCOORD, remove the last rows of both tables, 0.01" and 0.000001°.
• At OPCOORD, add the following immediately below the tables: "Higher precisions should be avoided, as they greatly exceed the accuracy of civilian GPS and online mapping services. (Using 4 m accuracy as a conservative estimate for civilian GPS: Depending on the coordinates format and the latitude, the next-higher precisions exceed the accuracy by a factor of somewhere between 13 and 72.)"
• At WP:COORDPREC, remove all cells containing d° m' s.sss", d° m' s.ss", or d.dddddd°. This will make the left table one row shorter than the right table.
• At COORDPREC, in the left table, on the 10 m row, use colspan to place the following text across the first 3 columns: Use decimal degrees format.
• At COORDPREC, in the right table, on the 5 m row, in the first 2 cells, change d.dddddd° to d.ddddd°.

I greatly favor fixed precision over this option, but I also recognize that its chances are below 50% because too many editors oppose dramatic changes regardless of the strength of the arguments for them. Many opposers don't even take the time to fully understand the rationale of the proposal, and that's apparent in their !votes. ―Mandruss ☎ 21:47, 31 January 2018 (UTC)

I support the idea of having the guidance recommend using d° m' s" or d.dddd° in nearly all cases, with d° m' s.s" or d.ddddd° reserved for smaller objects that cannot be pointed to by d° m' s" or d.dddd°. In other words, instruct people to try d° m' s" or d.dddd°. Then, if they can't pinpoint their object, then it's fine if they have to use higher precision. The instructions could emphasize that this is guidance to avoid the problem that excessive precision makes it look like somebody has some sort of reliable source or has taken a GPS reading. Abductive (reasoning) 02:04, 1 February 2018 (UTC)

Good, that makes 4 options on the table, not including status quo. That has a completely different rationale from my fixed precision proposal, so it's not really suitable to include as an OPTION 3 there. In my opinion the higher precisions would work well enough for those "nearly all cases".
People always have to throw in new wrinkles and complications, thereby preventing a consensus on anything. Perfect is the enemy of good, as evidenced time and time again at Wikipedia. ―Mandruss ☎ 02:55, 1 February 2018 (UTC)

More participation on this page would be nice, as it might allow us to narrow the options to a manageable number. This page has 333 watchers, if you can believe it; surely 30 or so are active today? Is anybody out there??? ―Mandruss ☎ 03:05, 1 February 2018 (UTC)

@Abductive: I know I'm waffling, but now I'm leaning toward the option at the top of this subsection. I think it addresses most of your point about accuracy, it would be the smallest change of the 4 options, therefore far less controversial, and I think it could be justified with a far smaller consensus on this page. We could just summon a few knowledgeable people on their user talk pages. ―Mandruss ☎ 03:29, 1 February 2018 (UTC)

Added a bullet to the above option. ―Mandruss ☎ 03:47, 1 February 2018 (UTC)

@Abductive: And I've sandboxed changes to the COORDPREC tables, slightly different from what I described above, here. Let me know what you think. ―Mandruss ☎ 04:14, 1 February 2018 (UTC)

The guidance should be geared towards how people actually obtain and put coordinates into articles. For example, I wonder if the average user knows how to determine if an object is 10 meters or whatever. Here's how I think people obtain coordinates: 1. They look at whatever coordinates are in the photograph on WikiMedia and use those, even though that is the location of the camera, not the building half a block away. 2. Some erroriffic dusty old government website. 3. Whatever Google Maps says. Abductive (reasoning) 06:43, 1 February 2018 (UTC)

So, you will often see x.6667" or y.00001" because one database was converted from dms to decimal and maybe back again, introducing a rounding error, and the user is too stupid was betrayed by the modern education system to be able to recognize this. That's why I think it would be better to give the simplest possible instructions. Editors such as hike395 who know what they are doing are not the ones that need guidance. Abductive (reasoning) 06:43, 1 February 2018 (UTC)

@Abductive: Editors such as hike395 who know what they are doing are not the ones that need guidance. I agree with that statement 100%. For example I created the COORDPREC tables precisely (no pun) because the guidance was largely inaccessible to the average editor. But how does this bear on the questions we already have before us? If it doesn't, could we defer that until they are resolved? ―Mandruss ☎ 07:11, 1 February 2018 (UTC)

@Abductive: That's why I think it would be better to give the simplest possible instructions. Ah, now I think I see the connection. You're saying that having the guidance recommend using d° m' s" or d.dddd° in nearly all cases, with d° m' s.s" or d.ddddd° reserved for smaller objects that cannot be pointed to by d° m' s" or d.dddd°. is simpler than following the 4-step table lookup instructions. Well I don't know, I think some minimum competence should be expected if an editor works with coordinates, such as maybe knowing how to use Google Maps or some other tool to determine the approximate size of an object. (That could be explained on the project page, if it isn't already. The entire page is about teaching editors how to work with coordinates.) Not all editors will have that level of competence, but then editors routinely work above their competence level and others have to clean up after them; that's just part of the business. As a practical matter your idea puts us back into the situation of requiring wide community involvement. I don't like your idea enough to propose it to the community myself...do you care to do that? ―Mandruss ☎ 07:34, 1 February 2018 (UTC)

I see the page as densely packed and intimidating to the average user. You have a far more optimistic view of the average user than I. As for what to do right now, you do not have to wait for community approval to simplify the table that you added. Just go ahead and do it. Abductive (reasoning) 09:17, 1 February 2018 (UTC)

The page is a mess and could use reduction by 2 or 3 times. As it is, hardly anyone will read it. Regarding the issue at hand, as a scientist I have always been bothered by excess precision, which is when more digits are written than have actually been measured. Another way of saying "excess precision" is "pretended accuracy". As a rule we can measure to 0.0001 degrees or 1 arc second with tools readily available, but more digits than that should require a reliable source. Zero^talk 12:03, 1 February 2018 (UTC)

Thank you. In time the page will hopefully get edited into better shape. Abductive (reasoning) 17:37, 1 February 2018 (UTC)

@Abductive, Hike395, Zero0000, and Jc3s5h: I suppose it's inevitable that these discussions go in 6 different directions at the same time. Yes, "the page is a mess", I think we can all agree on that. As for a 50%–66% reduction, I don't know as I haven't studied the page that closely. As far as I'm concerned, any editor is free to do BOLD edits to the page provided they don't significantly change longstanding methodology. More discussions might be needed/helpful, and I generally feel that this wikiproject needs revitalization (an increase in ongoing involvement).
you do not have to wait for community approval to simplify the table that you added. Just go ahead and do it. If you're referring to the option at the top of this subsection, (1) it doesn't "simplify" the tables I added, it merely reduces them slightly, (2) I added them over 3 years ago and I think that passage of time gives them at least some de facto consensus, and (3) the option would change more than the tables I added. So no, I'm not comfortable with a purely BOLD edit there, and I'm seeking a thumbs up from a majority of the 5 of us. My thumb is up so we need two more thumbs pointed skyward. I reiterate that I have sandboxed changes to the COORDPREC tables here. For the OPCOORD changes, see the top of this subsection. ―Mandruss ☎ 20:30, 1 February 2018 (UTC)

For the purposes of the prose at OPCOORD, I did some Googling and I think 2–3 m is not a best estimate for accuracy of civilian GPS. One page said the U.S. Government suggests 4 m; other estimates go as high as 10 m. I'm therefore using 4 m as an estimate in the proposed prose above. This could be revised if we find better sources; I've yet to look into what our articles on GPS say, for example. ―Mandruss ☎ 23:12, 1 February 2018 (UTC)

I give a 👍 to using User:Mandruss/sandbox4 at WP:COORDPREC —hike395 (talk) 03:04, 2 February 2018 (UTC)

Thanks. We'll take that as approval for the OPCOORD changes as well, unless you say otherwise. COORDPREC is derivative of OPCOORD. ―Mandruss ☎ 03:13, 2 February 2018 (UTC)

I think the changes in the box at the top of this subsection are probably appropriate, but the links WP:OPCOORD and WP:COORDPREC do not lead to spots that make it absolutely clear what sections of the page you want to change. I found the shortcut markers, but had to page up quite a bit in my browser to find them. Jc3s5h (talk) 16:04, 2 February 2018 (UTC)

@Jc3s5h: I found the shortcut markers, but had to page up quite a bit in my browser to find them. Right, that's a known site-wide problem with links to sections that are below collapsed content. AFAIK it's unfixable—it's been to WP:VPT multiple times—and the workaround is to place the cursor in the address/URL field and press Enter (or scroll up until you see the shortcut or section heading).
Ok, I'm taking your comment as the 3rd thumb up and going ahead with the implementation. ―Mandruss ☎ 19:28, 2 February 2018 (UTC)

GPS accuracy

Now I've read what Global Positioning System has to say about accuracy, at least the part I can understand. This relates to the new prose at WP:OPCOORD:

Higher precisions should be avoided, as they greatly exceed the accuracy of civilian GPS and online mapping services. (Using 4 m accuracy as a conservative estimate for civilian GPS: Depending on the coordinates format and the latitude, the next-higher precisions exceed the accuracy by a factor of somewhere between 13 and 72.)

Although not strongly, I feel that the part in parentheses is important support for the preceding sentence.

As seen at Global Positioning System#Augmentation, GPS accuracy varies by roughly a factor of 5 depending on what augmentation system is present, if any, with non-augmented accuracy at 15 m. That being the case, in my opinion, about all we can say about accuracy is that 4 m is not necessarily a "conservative" estimate as the above prose states, and I'm removing that word.

Comments welcome of course; I'm far from an expert on GPS. ―Mandruss ☎ 01:34, 3 February 2018 (UTC)

You're making an assumption that all geographic coordinates must be limited to the same accuracy as static GPS. That's not necessarily true: the position of an geodetic marker could be determined via differential GPS or Real Time Kinematic GPS. The accuracy would then be limited by the accumulation of errors in the survey. These errors are minimized via multiple measurements in a mesh.

The amount of error is also dependent on the location on the globe. In some countries, geodetic markers are poorly surveyed, and may be substantially worse than GPS error.

This is a very deep subject, of which I only have passing familiarity. We should do more research (unless an expert in geodesy is reading this). —hike395 (talk) 01:59, 3 February 2018 (UTC)

You're making an assumption that all geographic coordinates must be limited to the same accuracy as static GPS. I am? I'm the guy who opposed further reduction of max precision for reasons other than GPS accuracy, leaving us with precision as high as 55.7 cm. And the estimate in my prose is 4 m, not 15 m. In any case, how would said research affect the above prose? Would we somehow determine the total area coverage of each augmentation system and calculate an average accuracy to use within the parentheses in the above prose? I'd sooner remove the sentence. ―Mandruss ☎ 02:11, 3 February 2018 (UTC)

I don't think that Wikipedia users are obtaining their coordinates by GPS all that much. Abductive (reasoning) 05:54, 3 February 2018 (UTC)

@Mandruss: I would not include this sentence in a guideline. I would also advocate understanding the precision of NGS horizontal coordinates and using that as the highest precision in any table. I did some preliminary research, but cannot find estimates of current coordinate precision. —hike395 (talk) 06:10, 3 February 2018 (UTC)

@Hike395: I would not include this sentence in a guideline. To be clear, are you referring to the first sentence talkquoted above, the second sentence, or both? ―Mandruss ☎ 06:23, 3 February 2018 (UTC)

@Mandruss: Both the main sentence and the parenthetical sentence. —hike395 (talk) 06:33, 3 February 2018 (UTC)

@Hike395: I feel that if we are going to limit precision (especially if we advise against using the commonly seen d.dddddd°), we need to explain why we're doing it. Do you disagree, or would you replace those sentences with some other explanation? ―Mandruss ☎ 06:38, 3 February 2018 (UTC)

I would also advocate understanding the precision of NGS horizontal coordinates and using that as the highest precision in any table. Can we agree that the tables should include all precisions editors should be able to use in articles? I (and others) would object to losing the ability to place a marker as precisely as that in Shooting of Michael Brown without wide community consensus (most likely RfC), and barring that I (and others) need guideline support for that precision. ―Mandruss ☎ 06:23, 3 February 2018 (UTC)

@Hike395: Yes, higher precision in the table is probably required. Differential GPS can give locations as accurate as 1 cm (See [4]), which I find to be amazing. I don't know, however, whether the coordinates of geodetic markers (or other coordinates in WP) are generated with this technology, or something less sophisticated. Still poking around. —hike395 (talk) 06:33, 3 February 2018 (UTC)

Yes, higher precision in the table is probably required. Hold on. Just after we've spent 5 days and 6,500 words negotiating a reduction in max precision, now you're saying we probably need to increase it again? ―Mandruss ☎ 06:44, 3 February 2018 (UTC)

@Mandruss: I think we are all getting confused because multiple topics have been discussed and confounded. To my mind, there's the main topic ("what guidance do we give editors for precision of coordinates?"), and a more specific topic ("what is the maximum precision that we should consider reasonable and put into a table?"). I'm trying to answer the latter based on maximum reasonable precision of geodetic data. Unfortunately, I still haven't finished my research. I would beg all editors to slow down and not make edits without gathering information on what precisions we're dealing with. —hike395 (talk) 07:12, 3 February 2018 (UTC)

We had agreement among 3 editors for the edits described at the top of the preceding subsection. I waited for that agreement despite Abductive telling me I should just do a bold edit. I'm sorry you weren't around to disagree with it. I don't expect any more substantive edits like that without at least that much agreement. ―Mandruss ☎ 07:19, 3 February 2018 (UTC)

@Hike395: To my mind, the tables are the guidance we give to editors, particularly the WP:COORDPREC tables. They are not "multiple topics". For most cases by most editors, they can go directly to COORDPREC, do the quick table lookup, and leave. All the rest just provides the basis for COORDPREC, and they don't even need to read the basis to use an acceptable precision. That's why I've said that COORDPREC is derivative of OPCOORD. ―Mandruss ☎ 07:42, 3 February 2018 (UTC)

I say that a section, Using your own GPS data be made and kept very simple: "You may use GPS coordinates that you obtained but you should know the accuracy limitations of your equipment. Low-cost GPS units may have errors in the 4 m range." Abductive (reasoning) 06:48, 3 February 2018 (UTC)

@Abductive: Adding your own GPS data to WP is original research: "no reliable, published sources exist.". Personal GPS coordinates cannot be verified without redoing the measurement. I strongly object to any such section. —hike395 (talk) 07:12, 3 February 2018 (UTC)

No, it's using a primary source. As you know, Wikipedia Policy states that primary sources are acceptable for non-controversial data such as birthdays, but can be challenged by any editor. Abductive (reasoning) 07:19, 3 February 2018 (UTC)

Even primary sources are subject to WP:V. ―Mandruss ☎ 07:22, 3 February 2018 (UTC)

That's the "challenge" bit. Look at 100 articles with coordinates. What percent have a suitable source? The rest can be challenged, which I have done at least 693 times, according to the edit summary search tool. Abductive (reasoning) 07:47, 3 February 2018 (UTC)

So it's ok to use coordinates obtained from a GPS receiver, but don't be surprised if somebody removes them for lack of a citation? What kind of guidance is that? ―Mandruss ☎ 08:13, 3 February 2018 (UTC)

Find me any coordinate with a citation using random article and I will show that it doesn't point to the object. Abductive (reasoning) 01:02, 4 February 2018 (UTC)

Otherwise, all mention of GPS can be removed from the page. Why else are we discussing it? Abductive (reasoning) 07:21, 3 February 2018 (UTC)

I admit to being completely confused at why we are discussing GPS at all. GPS shouldn't be an allowed primary source, because WP:NOR says "primary sources that have been reputably published may be used in Wikipedia", but GPS isn't published. —hike395 (talk) 07:45, 3 February 2018 (UTC)

Well I thought we were discussing GPS because multiple editors have insisted that max precision should be tied to GPS accuracy. Me, I was happy enough with the status quo we had a week ago, but we had an edit that wiped out the COORDPREC table without discussion. ―Mandruss ☎ 08:04, 3 February 2018 (UTC)

I think that precision should normally be restricted to the accuracy of sources like Google and also restricted to about 1/10 of the target size (whichever has fewer digits). The only things for which greater precision makes sense are such as geodetic markers, for which we would be able to cite sources. (But who would care? Wikipedia is not a reference text for surveyors.) Personal GPS usage is original research, as has been pointed out. Zero^talk 10:26, 3 February 2018 (UTC)

Using unpublished values from a recreation-grade GPS is original research. But it's possible that such values might be published, in which case they would probably be more reliable than a Wikipedia editor reading the value off a map. (In the case of the map, accuracy is likely to be worse than the recreation-grade GPS, and there is a greater risk of a Wikipedia identifying the wrong feature on a map, versus a published author with boots on the ground misidentifying the feature.)

In most cases where sub-meter accuracy is justified, the published source is likely to have statements about the accuracy which can be cited. A Wikipedia editor capable of reading and understanding such a source and its accuracy metadata is likely to be capable of choosing an appropriate number of significant figures for the latitude and longitude without the aid of the tables on this project page. Jc3s5h (talk) 14:56, 3 February 2018 (UTC)

So, Open Street Map and Wikimapia and people who "publish" their mapping on Google Maps through Google's Map Maker program without much oversight are a-okay? Abductive (reasoning) 20:11, 3 February 2018 (UTC)

A Wikipedia editor capable of reading and understanding such a source and its accuracy metadata is likely to be capable of choosing an appropriate number of significant figures for the latitude and longitude without the aid of the tables on this project page. If you say so, but what about the other 90% of editors who may want to add coordinates to an article? ―Mandruss ☎ 20:20, 3 February 2018 (UTC)

Tendentious editing by user Mandruss

I for one am beginning to think that user Mandruss is exhibiting WP:OWNERSHIP and WP:tendentious editing on this Wikiproject. I urge him to stop. Abductive (reasoning) 02:01, 4 February 2018 (UTC)

From the start of the discussion I started on 28 January, you have repeatedly shown failure to assume good faith and engaged in disruptive, impulsive, angry, and combative behavior (first example). In contrast, the changes made to date to OPCOORD and COORDPREC were the result of my flexibility in hearing, fairly considering, and responding to your concerns. I think you've been around long enough to know the correct way to resolve editing disputes.
Your editsum in this latest display is simply false; there is no consensus as you state, only a disagreement between the two of us. "There were no objections, not even from you" is also patently false, as my comments here and here clearly showed objection to removal of that content.
Please modify your behavior and collaborate constructively, or I fear we may end up with a WP:ANI complaint. I don't have the time, and I don't like ANI. Any disputes between us can and should be resolved by calm discussion and consensus as described in Wikipedia policy and guideline. ―Mandruss ☎ 02:13, 4 February 2018 (UTC)

No, that's all just you Wikilawyering. Abductive (reasoning) 07:09, 4 February 2018 (UTC)

Page too complex?

Does anybody disagree that the instructions on the page are too complex? Abductive (reasoning) 05:53, 3 February 2018 (UTC)

I couldn't answer without knowing specifically which instructions you are referring to. ―Mandruss ☎ 06:12, 3 February 2018 (UTC)

People can't be expected to measure the objects, then map them. We don't know enough about how people find coordinates, but the page needs to be geared towards the best practice, not some mathematical reasoning. Example; why is there a bunch of raw math "you can also calculate the kilometers per degree of longitude, k, using one of the following formulas (θ is the latitude, 6378.14 km is the equatorial radius, and 6356.8 km is the polar radius):

Accurate, assuming a spheroid:

   k = π 180 cos ⁡ ( θ ) ( 6378.14 2 cos ⁡ θ ) 2 + ( 6356.8 2 sin ⁡ θ ) 2 ( 6378.14 cos ⁡ θ ) 2 + ( 6356.8 sin ⁡ θ ) 2 {\displaystyle k={\frac {\pi }{180}}\cos(\theta ){\sqrt {\frac {(6378.14^{2}\cos \theta )^{2}+(6356.8^{2}\sin \theta )^{2}}{(6378.14\cos \theta )^{2}+(6356.8\sin \theta )^{2}}}}} {\displaystyle k={\frac {\pi }{180}}\cos(\theta ){\sqrt {\frac {(6378.14^{2}\cos \theta )^{2}+(6356.8^{2}\sin \theta )^{2}}{(6378.14\cos \theta )^{2}+(6356.8\sin \theta )^{2}}}}}

Approximate:

   k = 111.3 cos ⁡ θ {\displaystyle k=111.3\cos \theta \,} {\displaystyle k=111.3\cos \theta \,} Equator to latitude 25° (north or south)
   k = 111.2 cos ⁡ θ {\displaystyle k=111.2\cos \theta \,} {\displaystyle k=111.2\cos \theta \,} Latitude 30° to 40°
   k = 111.1 cos ⁡ θ {\displaystyle k=111.1\cos \theta \,} {\displaystyle k=111.1\cos \theta \,} Latitude 45° to pole

This material must go. Perhaps you can make it a private essay. Abductive (reasoning) 06:33, 3 February 2018 (UTC)

Perhaps you can make it a private essay. If you're under the impression I added that, I didn't. I agree that it's useless to 99.99% of editors. On the other hand, if somebody ever decided to put the calculation into software and drop the COORDPREC tables, the necessary formulae would be there for them, already worked out and ready to code in the software. Maybe we could just collapse it to avoid undue distraction? And/or move it down out of the way, while remaining within the "Precision guidelines" section? ―Mandruss ☎ 06:52, 3 February 2018 (UTC)

I put it in a separate subsection at the bottom of the parent section. I don't think it needs collapsing there, especially since it begins with "You can also". It's pretty clear its use is optional. Is that better? ―Mandruss ☎ 07:07, 3 February 2018 (UTC)

@Mandruss and Abductive: I have a suggestion for a simplification for the "Precision guidelines". I suspect that many coordinates in Wikipedia come from a small number of sources (in the U.S: NGS, USGS topo maps, GNIS, etc.). How about we just supply a suggested precision for each source? Editors would just follow the advice.

Conversely, if the coordinate doesn't come from a major source, then we can caution against original research (as in using one own's GPS coordinates). —hike395 (talk) 07:22, 3 February 2018 (UTC)

I'm not opposed to advice against increasing the precision of the source. Otherwise it doesn't make any sense to consider the source at all in selecting a precision. ―Mandruss ☎ 07:26, 3 February 2018 (UTC)

There will never come a day in which increasing the precision improves the accuracy. Abzductive (reasoning) 07:49, 3 February 2018 (UTC)

Good, then I take it we agree. ―Mandruss ☎ 07:58, 3 February 2018 (UTC)

You are attempting to use rhetoric to win arguments. Abductive (reasoning) 20:13, 3 February 2018 (UTC)

A particular source agency, such as USGS or NGS, will have several kinds of data available, and each kind of data will have its own accuracy. For example, the accuracy of a USGS map will depend on whether the scale is 1:24,000 or 1:100,000. Each NGS geodetic marker has a different accuracy, which is stated in the individual datasheet for that marker. Jc3s5h (talk) 15:19, 3 February 2018 (UTC)

Crusty gubmint databases riddled with errors.... Abductive (reasoning) 01:03, 4 February 2018 (UTC)

Thanks, Jc3s5h, I had come to the same conclusion -- that there is no single accuracy for all geodetic benchmarks. Worse, as I understand it, the scale accuracy seems to be related to distance to other benchmarks, which is difficult to find. I give up --- there's no data-driven way to supply a source-wide accuracy. —hike395 (talk) 18:58, 4 February 2018 (UTC)

Ask for help: Broken GeoGroup links on cswiki

Hello, on Czech Wikipedia we have an issue with our GeoGroup template. The template is correct, urls are correct, but sometimes (only sometimes) both the osm4wiki tool (OSM link) and the wp-world tool (Google Maps link) give broken output, as you can see here or here. If you find a GeoGroup template on these pages and click on OSM link, you get broken encoding, but map shows correctly. If you click on Google Maps link, there is no map shown. If you click on Export... link (kmlexport tool), the link is also correct, but the resulting KML is blank. Do you know, what could be the problem? Is there some bug in kmlexport tool (used by all three links)? It happens only for some Czech Wikipedia pages, not for all pages using our GeoGroup template. --Dvorapa (talk) 15:41, 4 February 2018 (UTC)

@Dvorapa: I haven't a clue, and this page is relatively low-activity. I'd suggest you try Template talk:GeoGroup or, failing that, Wikipedia:Village pump (technical). Hodně štěstí. ―Mandruss ☎ 22:17, 4 February 2018 (UTC)

Thank you, I'll try. --Dvorapa (talk) 23:06, 4 February 2018 (UTC)

Lovell Telescope co-ordinates

Hi, I am trying to add region:GB to the co-ordinates on this article, but am struggling to find them, can someone help? GrahamHardy (talk) 16:44, 14 April 2018 (UTC)

@GrahamHardy: The coordinates were being pulled from Wikidata. Since they were a bit off anyway, I've just added a {{coord}} template in the infobox, containing the region code. Deor (talk) 17:04, 14 April 2018 (UTC)

Lovely job, Thanks GrahamHardy (talk) 23:48, 14 April 2018 (UTC)

Just noticed Mark II (radio telescope), Mark III (radio telescope) and Jodrell Bank Observatory need similar treatment, can you oblige ? GrahamHardy (talk) 23:55, 14 April 2018 (UTC)

 Done Deor (talk) 05:45, 15 April 2018 (UTC)

@GrahamHardy and Deor: and all: I've been working on templates like {{Infobox telescope}} to pull coordinates from Wikidata (along with the rest of the infobox). I haven't been including things like "region:GB" in that code as I thought those things were deprecated, particularly as we head towards Kartographer integration. Is that not the case? If not, then I can look into automatically adding them based on the Wikidata info. Thanks. Mike Peel (talk) 22:03, 16 April 2018 (UTC)

@Mike Peel: I am not aware of _region being deprecated. The map resources page produced from {{GeoTemplate}} relies on the region to show the most relevant map links and omit the useless links. —EncMstr (talk) 02:09, 17 April 2018 (UTC)

Username or other source identification for coords from Google satellite view

Hi to WikiProject Geographical coordinates. Could you possibly please provide some advice on attribution for geo-locations? I have recently advocated within WikiProject NRHP for use of the "source:" option within {{coord}} to be used to give an editor's username, when an editor has figured out coordinates using Google satellite view or other means. So I have been putting in "source:Doncram" for coordinates I have figured out, including recently going out of the U.S. with construction of Registered Buildings of the Isle of Man.

WikiProject NRHP wp:NRHP covers historic sites in the U.S., with currently 64,925 separate articles covering majority now of 92,401 current listings (per wp:NRHPPROGRESS), most having coordinates in their individual articles and/or in the corresponding county-level list-articles. Coordinates often originally were provided by NRIS database, and often were inaccurate, due to gross error in the database or to the North American Datum change of 1983. I and one or a few editors, including User:ProprioMe OW (shows redlink though very active), have agreed i think that it seems wrong or inefficient to record no source at all. If we record something then eventually we can sort out which ones have been verified by a competent editor vs. which ones need to be checked.

Is this wise? Is this a proper way to indicate coordinates have been checked. And, is there any way to get any reports out of {{coord}} template calls, e.g. any way to get a bot run to count or list occurences of various editors, vs. unverified ones. What is a poor sod to do? --Doncram (talk) 20:38, 18 April 2018 (UTC)

Internet standards for geographic coordinates

Is there any except ISO 6709? Jim.henderson (talk) 01:13, 22 April 2018 (UTC)

A lot depends on what you're calling a "standard". In addition to ISO standards and IETF RFCs there are lots of de-facto standards. You might want to look at:

• LOC records (RFC 1876)
• Geo (microformat)
• ICBM address
• Geo URI scheme (RFC 5870)

and possibly other things listed under Category:Geocodes. Geotagging has lots of useful information, too.

-- The Anome (talk) 14:59, 30 April 2018 (UTC)

So, what shall we say to clarify "Adhere to existing Internet standards for geographic coordinates as far as possible"? Jim.henderson (talk) 10:20, 4 May 2018 (UTC)

WikiProject collaboration notice from the Portals WikiProject

The reason I am contacting you is because there are one or more portals that fall under this subject, and the Portals WikiProject is currently undertaking a major drive to automate portals that may affect them.

Portals are being redesigned.

The new design features are being applied to existing portals.

At present, we are gearing up for a maintenance pass of portals in which the introduction section will be upgraded to no longer need a subpage. In place of static copied and pasted excerpts will be self-updating excerpts displayed through selective transclusion, using the template {{Transclude lead excerpt}}.

The discussion about this can be found here.

Maintainers of specific portals are encouraged to sign up as project members here, noting the portals they maintain, so that those portals are skipped by the maintenance pass. Currently, we are interested in upgrading neglected and abandoned portals. There will be opportunity for maintained portals to opt-in later, or the portal maintainers can handle upgrading (the portals they maintain) personally at any time.

Background

On April 8th, 2018, an RfC ("Request for comment") proposal was made to eliminate all portals and the portal namespace. On April 17th, the Portals WikiProject was rebooted to handle the revitalization of the portal system. On May 12th, the RfC was closed with the result to keep portals, by a margin of about 2 to 1 in favor of keeping portals.

There's an article in the current edition of the Signpost interviewing project members about the RfC and the Portals WikiProject.

Since the reboot, the Portals WikiProject has been busy building tools and components to upgrade portals.

So far, 84 editors have joined.

If you would like to keep abreast of what is happening with portals, see the newsletter archive.

If you have any questions about what is happening with portals or the Portals WikiProject, please post them on the WikiProject's talk page.

Thank you.    — The Transhumanist   10:57, 31 May 2018 (UTC)

{{OSM Location map}} problem

An editor has been adding {{OSM Location map}} maps to a bunch of articles about West Bengal community development blocks (see Amdanga#Geography, for instance). All of these articles are showing up in Category:Pages with malformed coordinate tags, so I assume that there's something wrong with the syntax of at least one of the {{coord}}s used; but after looking pretty closely, I'm not spotting what the error is. Could someone else please try to ferret out the problem? Deor (talk) 03:39, 7 June 2018 (UTC)

|mark-coord19={{coord|22|37|37|N|88|31|77|E}}.

77 seconds, you say?

If you're looking for errors like this in a sea of information, sometimes what works is to cut half of the questionable material to your clipboard, then preview. If the error goes away, the error is likely to be in the half you removed. Replace the good text with the bad text that you cut, then preview again. If the error is there, cut in half again, etc. Keep cutting until you narrow down the location where the problem is. It doesn't always work, but in a long list of similar items, this technique is valuable. – Jonesey95 (talk) 05:24, 7 June 2018 (UTC)

Many thanks. Another of these maps turned out to have a minutes ≥ 60 error in the map's centering coordinates. I'm not sure why I wasn't seeing this stuff yesterday, even though these were exactly the sort of error I was looking for. Need more coffee, I guess. Deor (talk) 14:39, 7 June 2018 (UTC)

Pesky portals

Yesterday or the day before, about 20 portals showed up in Category:Pages with malformed coordinate tags. The portal pages themselves don't seem to be displaying any coordinates, and the articles linked on them aren't showing up in the maintenance category, so the underlying articles don't seem to be the problem. Can someone with better template/transclusion skills than me figure out what is going wrong here? Deor (talk) 15:14, 21 June 2018 (UTC)

I have narrowed down the problem to {{Transclude lead excerpt}}, which calls Module:Excerpt. If you put that template by itself in a sandbox, as in User:Jonesey95/sandbox3, the error is still there. That template has not changed recently, but the Module has changed. Pinging Certes and Evad37, who have been editing the module and may be able to help. – Jonesey95 (talk) 00:29, 22 June 2018 (UTC)

Yes, I've figured out that the problem occurs when the {{coord}} template is used at the top, rather than the bottom, of an article transluded on a portal page. For instance, when I moved the {{coord}} in Djibouti from the top to the bottom of the article and did a null edit to both User:Jonesey95/sandbox3 and Portal:Djibouti, both your sandbox and the portal disappeared from the maintenance category. I still don't know the cause of this behavior, though. I guess that tomorrow I'll just move the coord template in the relevant articles. Deor (talk) 00:50, 22 June 2018 (UTC)

I think the problem is the use of frame:expandTemplate in the module, which seems to not just provide the expanded output of a template, but also to actually process things like categories and magic words, even if the expanded output isn't actually returned by the module. It's also expensive, so maybe we can do without it (and then you would't need to move coord templates) - Evad37 [talk] 01:29, 22 June 2018 (UTC)

@Evad37: Yes, expanding some templates has side effects, and it's possible that {{Coord}} is such a template. I just added Coord and its aliases to the list of templates we strip out before doing such checks, and null edited the offending portals. That seems to have cleared them from the category. Thanks to you all for diagnosing the problem so accurately, and sorry for the inconvenience. Certes (talk) 01:40, 22 June 2018 (UTC)

Thanks, all. Deor (talk) 14:02, 22 June 2018 (UTC)

No coords needed? - better clarity for project docs

What's the tag template for "coordinates are irrelevant to this article"? Can we please improve the linkage from {{coord}} doc pages etc., to make this more visible. Andy Dingley (talk) 12:02, 31 July 2018 (UTC)

Mystery coordinates (dynamically migrated?)

Take a look at Nipigon. It's got coordinates, dispayed both in the infobox and at the top. No problem there. But where do the coordinates come from? They're nowhere in the wikitext! The coord template is just

coordinates = {{coord|format=dms|region:CA-ON|display=inline,title}}

The coordinates were removed in this edit, during which the category tag {{Commons category}} was added. Does that Commons category tag somehow cause the coordinates to be fetched from somewhere else? —Steve Summit (talk) 02:38, 5 August 2018 (UTC)

I think {{coord}} is reading property P625 of the associated Wikidata entry. Certes (talk) 12:31, 5 August 2018 (UTC)

And if you take a look at the reference informstion for those coordinstes at http://www.wikidata.org/wiki/Q1993247 , you can see that the coordinates were taken from the English-language Wikipedia; that is to say, from the article itself. This is all part of the progressive migration of the simpler cases of per-article geocoordinates from local wikitext to Wikidata. -- The Anome (talk) 12:37, 5 August 2018 (UTC)

Thanks, Certes and Anome. I suspected it was something like that. When was this implemented? Is it documented anywhere? Are there any plans to remove the (gazillions of) redundant, explicit coordinates in ordinary articles, now that this (vastly better) mechanism exists? —Steve Summit (talk) 12:51, 5 August 2018 (UTC)

Another, somewhat different example: South Ubian, Tawi-Tawi, which contains coordinates = {{PH wikidata|coordinates}}

• ...which raises the question, why is there this {{PH wikidata}} template specific to settlement infoboxes in the Phillippines, when this sort of thing is or ought to be appropriate for any infobox anywhere? —Steve Summit (talk) 13:08, 5 August 2018 (UTC)

And for those of us who like to add and/or correct coordinates, can the recommendation now be that we not do it in the article, but rather, do it in Wikidata, and point the article at Wikidata's data? (I've been waiting for this for a long time. Perhaps the geotagging guidelines have been updated, and I haven't noticed.) —Steve Summit (talk) 12:55, 5 August 2018 (UTC)

Ships?

Do boats and ships need coordinates?

In particular, a museum ship which is not making long journeys, but it still mobile and regularly so. It's linked to an article on its host museum, which does have coordinates.

I see this as a case where such coordinates are inappropriate. They are not stable (to the accuracy often used), as even its mooring position can change within that precision. Mostly though, it only has any persistent location as a result of being attached to a particular museum, for as long as it's an exhibit there. That museum is clearly linked. Andy Dingley (talk) 12:05, 31 July 2018 (UTC)

I agree coordinates on mobile, seaworthy ships are inappropriate, and I think I've removed them once or twice. I believe coordinates are appropriate only for permanently-berthed museum ships, and shipwrecks. —Steve Summit (talk) 02:39, 5 August 2018 (UTC)

Can you answer the question above, how to tag an article so that it stops getting treated as "missing"? (I note that someone has just added coords to this article anyway). Andy Dingley (talk) 20:59, 21 August 2018 (UTC)

Viz or dump of all tagged articles?

Is there a standard view of tagged articles B language, or across languages? Is there a regular dunno of geodata and associated articles? Thanks, – SJ + 18:58, 21 October 2018 (UTC)

Railway stations in Pomeranian Voivodeship

If anyone is interested in a geodata challenge, you might want to take a look at

Category:Pomeranian Voivodeship articles missing geocoordinate data,

where there are about 100 railway station articles missing coordinates. -- The Anome (talk) 15:58, 22 October 2018 (UTC)

Featured quality source review RFC

Editors in this WikiProject may be interested in the featured quality source review RFC that has been ongoing. It would change the featured article candidate process (FAC) so that source reviews would need to occur prior to any other reviews for FAC. Your comments are appreciated. --IznoRepeat (talk) 21:35, 11 November 2018 (UTC)

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

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

Proposal to merge Infobox beach into Infobox landform

The discussion is starting at Wikipedia:Templates for discussion/Log/2018 November 19#Template: Infobox beach. Please feel free to join in the discussion. —hike395 (talk) 16:59, 19 November 2018 (UTC)

Separate coord

It's possible to display only latitude or only longitude in the article? Display separate coordinates, display on different lines. Elilopes (talk) 20:08, 5 December 2018 (UTC)

Yes. Documentation here. – Jonesey95 (talk) 21:14, 5 December 2018 (UTC)

Israeli government map site stopped working

At some point last year, the meaning of the "?c" argument at https://www.govmap.gov.il/ changed. It used to be latitude and longitude, but now it is coordinates in the Israeli Transverse Mercator grid. For example, the 1940s map for Ni'ilya used to be at https://www.govmap.gov.il/?c=34.571667,31.646111&z=6&b=4 but now it is at https://www.govmap.gov.il/?c=159168,617029&z=6&b=4. I don't know if that site has an option for location by latitude and longitude. Zero^talk 01:07, 14 January 2019 (UTC)

Weird stuff going on in Rio de Janeiro location maps

The location map image in Rio de Janeiro metro station articles (such as Uruguaiana Station, Engenheiro Rubens Paiva Station and Pavuna Station) seems to be shrunken. I'm not sure what's going on; I've taken a cursory look, and can't see anything wrong in the source. I'm not a map template expert, but I would imagine that this might be the result of some sort of metadata error somewhere. However, I'm unable to find the source of the problem. Could someone more knowledgeable please take a look at this? -- The Anome (talk) 11:01, 13 January 2019 (UTC)

Pinging Jc86035. I'm guessing that this is an unexpected side effect of your recent change to {{infobox station}}, or possibly a case of GIGO in the target articles that used to work fine. One problem solved, another created, the template editor's work is never done. – Jonesey95 (talk) 16:00, 13 January 2019 (UTC)

@Jonesey95 and The Anome: I don't think my change would have affected it. What seems to be the issue is that {{Location map}} is used as a subtemplate in the deprecated |map_locator= parameter. I've tried fixing Uruguaiana Station; this also involved some other fixes. Jc86035 (talk) 16:18, 13 January 2019 (UTC)

(1) I agree that we shouldn't using |map_locator= to embed a location map, when we can just use |map_type= (2) if you do embed with |map_locator= you need to set the |float=center, |caption=, and |border=infobox for the best results. (3) since the aspect ratio of this map is wide, I added a defaultscale to make it wider than the normal default (feel free to remove or adjust). (4) even better would be to replace the low-quality "Brazil Rio de Janeiro" location map with a {{Infobox mapframe}} map. Frietjes (talk) 17:32, 13 January 2019 (UTC)

Switching to the (non-deprecated) map_type= appears to fix multiple problems. I added an explanatory note to Category:Articles using Infobox station with map locator to help editors with this conversion. Feel free to improve on my explanation if I missed some options. Thanks all. – Jonesey95 (talk) 10:11, 14 January 2019 (UTC)

A new newsletter directory is out!

A new Newsletter directory has been created to replace the old, out-of-date one. If your WikiProject and its taskforces have newsletters (even inactive ones), or if you know of a missing newsletter (including from sister projects like WikiSpecies), please include it in the directory! The template can be a bit tricky, so if you need help, just post the newsletter on the template's talk page and someone will add it for you.

– Sent on behalf of Headbomb. 03:11, 11 April 2019 (UTC)

Template:GeoTemplate listed at Requested moves

A requested move discussion has been initiated for Template:GeoTemplate to be moved to Wikipedia:GeoTemplate. This page is of interest to this WikiProject and interested members may want to participate in the discussion here. —RMCD bot 21:31, 4 May 2019 (UTC)

To opt out of RM notifications on this page, transclude {{bots|deny=RMCD bot}}, or set up Article alerts for this WikiProject.

Is it possible to limit namespaces for Category:Pages with malformed coordinate tags?

I have adjusted Module:Coordinates to limit the application of Category:Pages with malformed coordinate tags to main (article) space, but it appears that MediaWiki itself is applying the category in many cases. It appears that when GeoData was deployed in 2012, there was no discussion (that I could find) about limiting the error-tracking categories to specific namespaces. As with infobox error tracking, it is not useful to have User pages showing up in the error-tracking categories. Is there a way to limit the application of the category to the main (article) space? – Jonesey95 (talk) 07:52, 7 May 2019 (UTC)

I don't think the pages added automatically by mw:Extension:GeoData can omit some namespaces or sort by the namespace. The category name is determined by MediaWiki:Geodata-broken-tags-category. I have added a search link for articles in the category (currently none).[5] Module:Coordinates could add a different category but a split of the errors may be worse. The module could also give the errors a special sortkey like *{{PAGENAME}} so articles added by the module appear together at the start of the category. That would still leave extension-added articles spread out in the category. PrimeHunter (talk) 09:35, 25 May 2019 (UTC)

The category could be split into two by changing MediaWiki:Geodata-broken-tags-category to {{#ifeq:{{NAMESPACE}}|{{NS:0}}|Articles with malformed coordinate tags|Pages with malformed coordinate tags}} -- WOSlinker (talk) 19:03, 5 July 2019 (UTC)

Map/Coord issue help

Yellowstone Mesa Verde Grand Canyon Everglades Independence Hall Redwood San Antonio Missions Mammoth Cave Olympic Cahokia Great Smoky Mountains Statue of Liberty Yosemite Chaco Culture Monticello U. of Virginia Taos Pueblo Carlsbad Caverns Waterton-Glacier Poverty Point class=notpageimage| Location of World Heritage Sites within the contiguous United States up through 2018 So, until yesterday List of World Heritage Sites in the United States coord map worked great because each site was in one town or place. Yesterday, the multi-state The 20th-century Architecture of Frank Lloyd Wright was listed -- so any suggestions on how to do this, if maybe we put blue peg for each of eight sites -- unnamed on the map -- and an explanation for the blue pegs in the caption. But how to code? Or other ideas, thanks. Alanscottwalker (talk) 18:48, 8 July 2019 (UTC) Other Idea 1: Label the sites individually, followed by an asterisk, as Jacobs House*. Then add to the caption: * Part of The 20th-Century Architecture of Frank Lloyd Wright. UNESCO's grouping is entirely arbitrary and not very useful for purposes of the map; it wouldn't be very useful to know only that the site is part of the Wright group of eight. It would take some effort to determine which of the eight each peg represents. The larger problem is that the map is going to become so cluttered that it will be necessary to use numbers for the labels—and this addition may well get us there. ―Mandruss ☎ 19:41, 8 July 2019 (UTC) Thus. Also add a "Map ref" column to the table. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21* 22* 23* 24* 25* 26* 27* 28* class=notpageimage| Locations of World Heritage Sites within the contiguous United States * 21–28: The 20th-Century Architecture of Frank Lloyd Wright ―Mandruss ☎ 21:22, 8 July 2019 (UTC) Thanks for your feedback and work. Looks like someone tried your first suggestion. Alanscottwalker (talk) 12:11, 9 July 2019 (UTC) Yeah. That looks terrible. It also fails to identify the Wright group as such. ―Mandruss ☎ 15:41, 9 July 2019 (UTC) You could use a different marker (I've changed the map above to use green markers. -- WOSlinker (talk) 08:32, 10 July 2019 (UTC) OS Grid References Hi, the tool that generates a coordinate link from an OS Grid Reference as used in templates such as {{Gbmaprim}} (via {{OS coord}}) appears to have disappeared from the server. It used to be https://tools.wmflabs.org/os/coor_g/ any idea what has happened to it or is there a replacement. Keith D (talk) 12:05, 17 July 2019 (UTC) Google Earth Expert Requested Could someone who is knowledgeable in Google Earth KML file formats please take a look at the Talk:Tain & District_Museum page? I know it's flagged in the box up above, but at least one member of the project has already looked at it and not known what the problem actually is. The problem in brief is that this KML produces an error when opened in GE and does not reference the coordinates, although it opens fine in other links like Google Maps. Thanks in advance! — Srwalden (talk) 13:29, 29 August 2019 (UTC) I don't know Google Earth, but I do know XML (of which KML is a version). Line 23 has the title "Tain & District Museum". Ampersands need to be escaped in XML, so try replacing the ampersand with "&" and see if that works for you. —hike395 (talk) 14:23, 29 August 2019 (UTC) Inexplicable (by me) coordinate error This edit has put the article Arizona State Route 24 into Category:Pages with malformed coordinate tags, and I can't figure out why. As near as I can tell, the article contains no {{coord}} templates whatever, much less a malformed one. Can someone figure out what is going on here? Deor (talk) 19:54, 17 October 2019 (UTC) Deor, I narrowed it down to {{ADOT AADT}}. Not sure why. MB 20:21, 17 October 2019 (UTC) I don't know for sure, but that article has overly precise latitude and longitude in the maplink: frame-lat=33.3241758|frame-long=-111.6434102. The precision of the last digit in each corresponds to about 1cm. Maybe that is triggering it? --{{u|Mark viking}} {Talk} 20:27, 17 October 2019 (UTC) Nah, overprecise coords have never thrown articles into the "Pages with malformed coordinate tags" category. 20:49, 17 October 2019 (UTC) I commented out {{ADOT AADT}} and the article is no longer in the category. Will leave it for the author (it was just created yesterday) to resolve. @MatthewAnderson707: MB 20:59, 17 October 2019 (UTC) I personally have no idea why that issue occurred because of my template. The template is only for posting uniform references to ADOT Average Annual Daily Traffic reports. It has nothing to do with coordinates. I never included coordinates in the template programming nor did I add any coordinates to SR 24. I've read over my programming and can't figure out what could have caused the error. — MatthewAnderson707 (talk|sandbox) 21:50, 17 October 2019 (UTC) EDIT: I found what I believe was the issue and corrected the template programming. Hopefully, it should work error free now. — MatthewAnderson707 (talk|sandbox) 21:59, 17 October 2019 (UTC) Thanks, MB and MatthewAnderson707, for identifying and fixing the problem. Deor (talk) 14:02, 18 October 2019 (UTC) Wikidata coordinate extraction I'm considering a deep dive into Wikidata to find articles with {{coord missing}} that have coordinates on Wikidata, and then doing... something. Any suggestions? -- The Anome (talk) 21:01, 26 November 2019 (UTC) My only comment is that, in a number of cases, I've not found unsourced coordinates on Wikidata to be trustworthy. Deor (talk) 21:41, 26 November 2019 (UTC) Maybe make a list or a table first to see what the scale of the work is. 100 articles? 10,000 articles? Also check to see if the {{coord missing}} is telling the truth about the article. – Jonesey95 (talk) 21:44, 26 November 2019 (UTC) Certainly the coords should not simply, automatically be copied. A few times I've gone to a Wikidata location to discover that the thing isn't there, due to someone reversing two digits or some such error. Jim.henderson (talk) 21:56, 26 November 2019 (UTC) There are cases where articles have coords that differ from those in Wikidata. How about detecting those as a way of fixing errors and/or vandalism. Some templates use local coords for display but Wikidata coords for maps. They ought to be the same. MB 04:20, 27 November 2019 (UTC) Thanks! I'm going to go down the route of writing a Lua module (to be invoked by the {{coord missing}} template) that will check Wikidata for coordinates, and if coordinates are missing but available on Wikidata, add the article to a tracking category to mark it for editor attention. @Deor: If possible, I might also distinguish between the case where the Wikidata coordinates are sourced or unsourced.-- The Anome (talk) 09:46, 27 November 2019 (UTC) Meaning of colors What do the green and red colors indicate at the table at WP:COORDPREC? 4nn1l2 (talk) 04:40, 3 June 2020 (UTC) @4nn1l2: I think that they're to group together the row/column intersections that have the same coordinates precision. --Redrose64 🌹 (talk) 20:13, 3 June 2020 (UTC) Creating articles for New Guinea geo features What are some reliable sources for rivers, mountain ranges, and bays of Papua New Guinea and Indonesia? I'd like to import some Cebuano articles that were created by Lsjbot, but I've noticed that many of them cite only Geonames. A selection is listed at User:Sagotreespirit/New Guinea geography. — Sagotreespirit (talk) 01:11, 2 March 2020 (UTC) Damn near every one of the ceb.wiki coordinates are incorrect. Please check them before migrating a bunch of bad data over to en.wiki. Abductive (reasoning) 08:10, 22 June 2020 (UTC) Reducing Infobox size by removing duplicated coordinates I hoped the set of the coordinates at the top right of the page of my recent article would suffice and their duplicates in the infobox below the map could be removed and thus the infobox be reduced in size (and consequently be less intrusive on the text below) but it looks as though if you have that map version you get the general info line and the cordinates below it by default. Does anyone perhaps know of a map option that doesn't automatically insert a coordinates line? (I have searched but so far in vain) Horatius At The Bridge (talk) 14:09, 5 August 2020 (UTC) That is controlled by |display=inline,title. You can change that to |display=title, but it seems to be WP standard to always have coords in the infobox and at the title. MB 19:32, 5 August 2020 (UTC) Thank you for looking into the issue I guess there's nowhere to go from there Horatius At The Bridge (talk) 20:20, 5 August 2020 (UTC) "Lost" geodata in unused parameters in {{infobox settlement}} While datamining Wikidata for coordinates, I spotted an anomaly with the Bishunpur, Jaunpur article. The article contains an {{infobox settlement}} template with now-obsolete "latd" and "lond" parameters containing the geographical location of the place, but which is not rendered by the template. This is a big loss! I wonder how many other similar articles are actually invisibly geocoded, and their locations lost, like this. Looking at Category:Pages using infobox settlement with unknown parameters suggests that there may be a lot, perhaps even thousands. -- The Anome (talk) 10:24, 8 September 2020 (UTC) The answer appears to be "a few hundred articles at the most". See the Template Data monthly report (do a find for "lat"). Some of those articles may also have |coord= already filled in. – Jonesey95 (talk) 14:06, 8 September 2020 (UTC) Thank you! I've added this task to my long-term low-priority to-do list. -- The Anome (talk) 19:30, 8 September 2020 (UTC) Template:Coord listed at Requested moves A requested move discussion has been initiated for Template:Coord to be moved to Template:Coordinates. This page is of interest to this WikiProject and interested members may want to participate in the discussion here. —RMCD bot 15:33, 18 September 2020 (UTC) To opt out of RM notifications on this page, transclude {{bots|deny=RMCD bot}}, or set up Article alerts for this WikiProject. WikiProect Hospitals I have been cleaning up the articles on hospitals as part of the Wikipedia:WikiProject Hospitals. The coordinates are used in the "Infobox hospital". All of the articles with an "Infobox hospital" and parameter "needs-coord" now have coordinates. On the project tutorial page, I created guidelines for how to select coordinates for hospitals Wikipedia:WikiProject_Hospitals/Tutorials#Hospital_coordinates using your project guidance for military and industrial establishments. Would appreciate any comments from members of this WikiProject. -- Talk to G Moore 13:18, 23 September 2020 (UTC) Automatic infoboxes {{Infobox settlement/Wikidata}} is clearly not working as I expected: see Kroksjö, Lycksele Municipality. What should I be doing instead, if not just copying all this data in manually? -- The Anome (talk) 18:23, 15 January 2020 (UTC) That looks like a very immature implementation of wikidata in an infobox. For a better (though considerably more complicated) way to do it, see Template:Infobox person/Wikidata, which is being used in 2,000 articles. That said, it looks like the template may be working as designed. As you can see, coordinates, country, and subdivision are displayed in the rendered article, but they are not present in the wikicode. That means they are coming from Wikidata. Anything that is not being displayed is either not in Wikidata for that settlement, or it is not being requested by the infobox template. – Jonesey95 (talk) 22:25, 15 January 2020 (UTC) @Mike Peel and RexxS: in case this is of interest. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:55, 30 September 2020 (UTC) Geodata from Wikidata I've now extracted a large amount (about 200k entries) of coordinate data from Wikidata. Extrapolating from a short sample run suggests that this is likely to yield about 15,000 new coordinates for enwiki articles that do not yet have coordinates. Does anyone have any comments about the use of this data? -- The Anome (talk) 20:19, 8 September 2020 (UTC) @The Anome: rather than extracting this data from wikidata into Wikipedia, wouldn't it be better to do it in the other direction, and enable to infobox templates to pull the coordinates from wikidata? — Martin (MSGJ · talk) 08:05, 30 September 2020 (UTC) @MSGJ: In an ideal world, yes, and that's still my long term plan. But since there is not yet a consensus about how to go about doing this transclusion, it can't hurt to duplicate the data in the short term, provided the data is marked as being copied from Wikidata, which I would be doing anyway. -- The Anome (talk) 08:48, 30 September 2020 (UTC) @The Anome: I and assorted others have spent a considerable amount of effort, over a number of years, applying the precision guidance at WP:OPCOORD (and more specifically at the following WP:COORDPREC) to coordinates in en-wiki articles, and I wonder how much of that effort is being negated. If the community no longer cares about that guidance, we should get rid of it. ―Mandruss ☎ 09:00, 30 September 2020 (UTC) Perhaps I didn't read your opening comment carefully enough. If you're only pulling to articles that lack coords, my concern is unfounded. ―Mandruss ☎ 09:04, 30 September 2020 (UTC) You are correct, and you need not worry about this. I'm only planning on pulling in data for articles that currently lack coordinates. And I'm a strong supporter of WP:COORDPREC, as can be seen by my numerous edits to reduce overprecision from coordinates where I find it. I'm also well aware that some of the source wikis tend have lots of poor quality coordinates, and I'm still thinking about how best to filter the data to remove bad coordinates. Data quality matters to me. -- The Anome (talk) 09:08, 30 September 2020 (UTC) @The Anome: Thanks. I recently inquired about something related, here. There was no response, so maybe you could address that. You appear to know something about Wikidata and coords. ―Mandruss ☎ 09:17, 30 September 2020 (UTC) Please don't copy the coordinates, just use {{coord}} without the defined coordinates (i.e., just the display=inline,title and format=dms parameters) and it will auto-fetch them from Wikidata. Thanks. Mike Peel (talk) 10:18, 30 September 2020 (UTC) Has a mechanism yet been created to allow changes in Wikidata values to be seen in edit histories? If not, there's zero oversight for changes to these values, breaking the wiki principle, and this seems dangerous to me. If there is now general first-class support for tracking changes to templates that ripple through from Wikidata, then yes, I'll happily do this. -- The Anome (talk) 12:56, 30 September 2020 (UTC) No, it's the same as you don't see template and changes in article histories, you have to go to the template history page to see it (analogously here, you go to the Wikidata item history - also the same with file histories on Commons). You do see changes to the coordinates on your enwp watchlist, though, if you have Wikidata turned on there. And, of course, the wiki principle is kept as wikidata is a wiki. ;-) Thanks. Mike Peel (talk) 14:06, 30 September 2020 (UTC) @Mike Peel: Alas, I don't think that's enough. Firstly, there's no affordance or discoverability: it's completely unclear for enwiki contributors how to edit coordinates that are located on Wikidata; most of them don't even know Wikidata exists. Secondly, enwiki has a massive editor base that is likely to spot coordinate vandalism, but the Wikidata community is far smaller; I have been quite disappointed by the low quality of data pulled from some of the smaller wikis. In my opinion, moving all coordinates to Wikidata would be a retrograde step until there is full integration of alerts, histories, and template editing across Wikipedia and Wikidata (which is something which would be useful far beyond just geographic data). In the meantime, I will go with duplication in the short term: if the sourcing is clearly marked in templates, it should be a simple matter to de-duplicate this information when the time comes to move to full integration. It's not ideal, I know, since the ideal is full integration, but I think this would represent a step forward, not a step back. Regarding data quality, I've decided only to take coordinates for items with articles in at least one of the other top 10 Wikipedias by size: namely es, ru, it, pt, ja, de, fr, zh and pl, on the basis that only large wikis have sufficient oversight to prevent garbage data. -- The Anome (talk) 12:20, 4 October 2020 (UTC) That's a nice argument for why all images we use from Commons should be copied here - it's the exact same scenario, and unlikely to change in terms of integration for the same reasons. I'm sad that you think duplicating the information will help, as it means that any fix has to then take place in two places rather than just one. As for the accuracy of coordinates from different wikis, most of the incorrect coordinates I've spotted and fixed have actually come from the English Wikipedia. While on Wikidata, the coordinates are shown on a map, and there are tools like wikishootme to aid discovery, in articles here they are normally just displayed as a number string, which makes mistakes harder to spot. Thanks. Mike Peel (talk) 13:13, 4 October 2020 (UTC) Region parameter in coordinates Hi. Discussion at Template_talk:Coord#Region_parameter concerning the region parameter in GeoHack and its auto-detection via region.php. Thoughts appreciated! ProcrastinatingReader (talk) 15:15, 22 October 2020 (UTC) Auto use of OpenStreetMap? Is there a way for me to click on a set of geocoordinates in an article and go directly to OpenStreetMap, rather than being directed to GeoHack first? Thanks for any suggestions. Her Pegship (?) 01:43, 30 October 2020 (UTC) DNS LOC Records Hi! I am trying to figure out the Domain Name System LOC record for a server we are using that is located in the One Wilshire building (specifically the Meet-me room on the fourth floor; but I don't need to be anywhere near that precise). How do I find the altitude of the building at the ground floor?? Our article only lists latitude and longitude. 2600:1700:D0A0:21B0:8F3:3E88:67CC:D875 (talk) 16:34, 27 December 2020 (UTC) I don't know how reliable it is, but this Web page gives the building's elevation as 82 meters (269 feet). Deor (talk) Thanks! Here is the LOC entry I came up with: 34 2 52.44 N 118 15 20.16 W 82m 1000m 1000m 1000m I hope I got it right... Those last three I believe define a 1Km sphere big enough to encompass the entire building. 2600:1700:D0A0:21B0:8F3:3E88:67CC:D875 (talk) 20:54, 27 December 2020 (UTC) Wikipedia mapping tools? Is there a list somewhere of the (internal / official / approved) gadgets and tools which use Wikipedia article co-ordinates? (For example Special:Nearby, M:WikiShootMe) — GhostInTheMachine talk to me 12:33, 25 November 2020 (UTC) I will start making a list article... — GhostInTheMachine talk to me 09:26, 8 January 2021 (UTC) osm.js OpenStreetMap's Edgbaston Pool polygon, seen in Wikidata OpenStreetMap's River Sherbourne relation, seen in Wikidata Objects (ways, polygons and relations) in OpenStreetMap can be tagged with a Wikidata ID. Wikidata's excellent 'Abbe98/osm.js' user script can be used to display a zoomable, slippy map on the Wikidata page, like those in the screenshots above, with the relvant object in OSM highlighted. The scale of the background map is set automatically. Can the code be used in a template, for use in this project? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:01, 21 January 2021 (UTC) Issues with Template:Iem4ibx See the weird unformatted URL in the infobox of Galway... I don't know what exactly needs to be fixed. Cheers, RandomCanadian (talk / contribs) 00:19, 15 February 2021 (UTC) What weird unformatted URL? What is the name of the row is it in? If there isn't one, which row is above it? --Redrose64 🌹 (talk) 16:28, 15 February 2021 (UTC) Coords for historical regions Hi all, I'm knee-deep in the clean-up listing for Project Guyana, and there's a few "Coordinates Needed" that have been bothering me and I'm just not sure how to approach them: British America Guayana Province New Andalusia Province I looked through the general purpose and guide for choosing coordinates, but they seem to be more applicable to contemporary, high-accuracy subjects rather than these politically driven "I claim this land for Spain!" historical regions. Is there any sort of standard for such locales? Cheers, Estheim (talk) 12:38, 25 February 2021 (UTC) Linking articles to geoportals Hi! I'm mostly interested in physical geography topics and therefore typically rely on topo maps. Is there a way to make good use of the coordinates by pointing directly at them in an external geographical portal? More specifically, I'd like to have a template displaying something like: Jungfrau on the Swiss National Map (1:25'000), at the bottom of the Jungfrau page, and without having to enter any parameter, so that it could be easily added on thousands of pages. Any thoughts? Zach (Talk) 12:52, 3 April 2021 (UTC) Many article display co-ordinates on the right just under the title and often in the Infobox. Clicking either takes you to an external page with links to many mapping systems. The Jungfrau article links to GeoHack and the first link on the right is approximately your link — GhostInTheMachine talk to me 13:51, 3 April 2021 (UTC) Also, ... easily added on thousands of pages. will cause all sorts of problems — GhostInTheMachine talk to me 13:55, 3 April 2021 (UTC) Thank you! I always clicked on the left icon, thinking the interactive map was the only thing linked from the coordinates. Interesting, to say the least. Quite hard to find the link really quickly if you're not familiar with map.geo.admin though. Do you know if a separate template (to be displayed in the external links section) would work? Zach (Talk) 14:17, 3 April 2021 (UTC) See this discussion on Authority Control. A GEO link could be added in any rewrite. MB 15:33, 3 April 2021 (UTC) Celestial coordinate system listed at Requested moves A requested move discussion has been initiated for Celestial coordinate system to be moved to Astronomical coordinate systems. This page is of interest to this WikiProject and interested members may want to participate in the discussion here. —RMCD bot 06:17, 25 May 2021 (UTC) To opt out of RM notifications on this page, transclude {{bots|deny=RMCD bot}}, or set up Article alerts for this WikiProject. Template:Coord display formats Template:Coord currently supports only dms and dec display formats. Both the United States Geological Survey and the National Geodetic Survey provide degree coordinates to seven decimal places. If a user enters degree data with seven decimal places, Template:Coord currently can only display all seven decimal places or convert to dms format. Either of these display options implies far greater accuracy than normally desired. The user can round input data to fewer decimal places, but this makes checking source data difficult. If Template:Coord could provide its own decimal degree display rounding options, this problem could be completely eliminated. I suggest that in addition to the dms and dec format options, Template:Coord provide d2, d3, d4, and d5 format options to limit the implied accuracy of decimal degree displays without requiring user rounding. The GeoHack hyperlink could continue to use the full seven decimal degrees for high accuracy mapping. Yours aye,  Buaidh  talk e-mail 00:34, 16 May 2021 (UTC) If an editor finds it highly difficult to round a 7-digit number according to our established guidelines, my suggestion would be to leave coordinates to other editors. This is a trivial matter for anyone with a 4th grade grasp of rounding. However, truncation would be sufficient for our purposes. If they can't round 97.4465961 to 97.447, they are welcome to truncate it to 97.446. Surely anyone can handle that? In my opinion this certainly does not warrant a template change. 68.97.37.21 (talk) 05:37, 27 May 2021 (UTC) Dead links On the subpage Wikipedia talk:WikiProject Geographical coordinates/to do, under "Fix", the links to Dispenser's tools at coord-enwiki.log, Coordinate check tallies, and Coordinates around 0°,0° are no longer working. Should these links just be deleted, or do they need to be updated to different URLs? Deor (talk) 21:12, 4 August 2021 (UTC) Why are coordinate different per language? Shouldn’t the geocoords be the same for all languages? Arne Evertsson (talk) 09:56, 1 August 2021 (UTC) @Arneevertsson: Where are you seeing coords in different languages? --Redrose64 🌹 (talk) 18:26, 1 August 2021 (UTC) Coords are editable in the markup which means each language has its own coords tag. I even managed to add a second coords tag to an article that already had one. It all seems strange to me. Arne Evertsson (talk) 07:26, 4 August 2021 (UTC) This is why coordinates should, where possible, be drawn from our central data repository, Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:04, 18 August 2021 (UTC) Bring WMF map tile feature sets into line with OSM default feature sets This Phabricator ticket: T289101 may be of interest. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:06, 18 August 2021 (UTC) Requesting inputs Greetings Requesting (brainstorming) inputs regarding Manual of Style proposal @ Chronological listing of coastal townships Thanks and warm regards Bookku, 'Encyclopedias = expanding information & knowledge' (talk) 10:15, 29 August 2021 (UTC) Earth map at GeoTemplate FYI  – Pointer to relevant discussion elsewhere. Please see Template talk:GeoTemplate#Edit request: better Earth map. --Redrose64 🌹 (talk) 22:01, 11 December 2021 (UTC) Articles not needing coordinates I have just written Monmouth Coffee Company, which is a company with three sites. Is there a category to indicate that it does not need coordinates? The guidance suggests that the coordinates could be put in a table, please could somebody link an example? TSventon (talk) 15:23, 20 December 2021 (UTC Pinging The Anome as they tagged the article. TSventon (talk) 15:43, 20 December 2021 (UTC) Thanks for letting me know. Yes, removing the tag from an article about a multi-site entity is quite reasonable to do, unless you feel it makes sense for the article to be tagged with (for example) a headquarters location. If you've removed the tag from the article, the bot will not re-add it again. -- The Anome (talk) 15:51, 20 December 2021 (UTC) The Anome, I am afraid I last thought about coordinates just over a year ago. I have added HQ coordinates to Wikidata based on copying the approximate Google maps location into the Coordinates tool. I probably should do the same for Neal's Yard Dairy, which also has three branches including a headquarters in a neighbouring railway arch. Do you know an example of putting coordinates in a table? TSventon (talk) 16:37, 20 December 2021 (UTC) @TSventon: One way to handle multiple locations is to put the coordinates of each in parentheses after the mention of the site in the article's text (using "inline,title" display for the headquarters and just "inline" for the others). Deor (talk) 17:23, 20 December 2021 (UTC) Thanks @Deor:, so something like 27 Monmouth Street (coordinates 51°30′51.54″N 0°7′36.35″W), then? I'd omit the word coordinates in the parenthesis (and instead of the "scale" parameter just use "type:landmark_region:GB"). You can also add the template {{GeoGroup}} near the bottom of the article, so that readers can access a map showing all the locations at once. If you do, it's probably a good idea to insert an appropriate |name= parameter in each {{coord}} template. Deor (talk) 18:08, 20 December 2021 (UTC) Thanks @Deor:, now done, except I omitted "type:landmark_region:GB" as the default works quite well for Central London. TSventon (talk) 21:49, 20 December 2021 (UTC) New user script Chlod has just created a great userscript for adding coordinates, which you can see at User:Chlod/Scripts/Coordinator. It should be of interest to anyone who frequently adds coordinates. — Berrely • Talk∕Contribs 08:17, 12 January 2022 (UTC) Nomination for merger of Wikipedia:WikiProject Geographical coordinates/dim: Wikipedia:WikiProject Geographical coordinates/dim: has been nominated for merging with Template:Coord-doc-dim. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. 65.92.246.142 (talk) 15:40, 3 March 2022 (UTC) Globe:Mercury error I noticed that the quadrangle for Boethius (Mercurian crater) is coming up as Kuiper quadrangle in the infobox, when it should be Beethoven quadrangle. Perhaps one of them is not correctly defined. The quadrangle boundary is 72° west. Jstuby (talk) 16:27, 11 March 2022 (UTC) New tracking categories I've modified {{coord missing}} to generate two new tracking categories: Category:Articles missing coordinates with coordinates on Wikidata Category:Articles missing coordinates without coordinates on Wikidata They are still filling up, particularly the latter, which I only created a few minutes ago, but the results so far look promising, and I hope will at least be useful as a source of suggested coordinates for manual updating of articles. -- The Anome (talk) 10:16, 22 December 2021 (UTC) Pinging @Pigsonthewing and Deor: who I think might be interested in this. -- The Anome (talk) 10:20, 22 December 2021 (UTC) @Pigsonthewing and Deor: This is all looking good. The scan is not yet complete, but there are clearly over 10,000 articles that could be enhanced by interwiki copying of coordinates. Data quality is now an issue. For quality control purposes, I'm initally planning to only use Wikidata as a discovery resource to take data from Wikipedia pages, rather than Wikidata itself, and to limit this to pages from Wikipedia language editions that have over 1 million articles (with the exception of cebwiki, which was created largely by bots), to ensure some degree of human oversight. Note that these can include coordinates that have been automatically transcluded from Wikidata via templates; the important thing is that they should have been visible on a high-traffic Wikipedia edition, thus opening them to human scrutiny. I also plan to add various other sanity and provenance checks before I start copying; I am still thinking about what these might be. Please let me know your thoughts. -- The Anome (talk) 11:32, 23 December 2021 (UTC) Thank you for this impressive piece of work. It still saddens me that we don't use make more use of templates to transclude such data directly from Wikidata (DRY being pertinent), but that's an issue to resolve another day. Is there anything we can do to assist? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:33, 23 December 2021 (UTC) My long-term plan is to eventually reverse the flow, and move all the data to Wikidata. But first I want to migrate as much of the Wikidata coords as possible to enwiki, because we have a known good process here to manage them, before even contemplating the reverse move, which will be a massive endeavour that will need getting just right, including support from MediaWiki and cross-community cooperation; I see that as perhaps being at least a year or more away, perhaps a job for 2023 or 2024. And yes, please, I'd be grateful for any help you can give me, about which more later. -- The Anome (talk) 14:06, 23 December 2021 (UTC) Myself, I'll wait and see how this turns out. I'm on the record (multiple times) as being distrustful of the quality of coordinates on Wikidata. Deor (talk) 15:48, 30 December 2021 (UTC) I found this discussion because I was scraping Wikipedia pages for Fortification locations and then switched to Wikidata. It does seem very odd that you can't quote {{coord}} and pickup the wikidata item like you can for {{official website}}. I can see you have a big problem maintaining many large datasets and sweeping back and forth between them. What if the coordinates all differ between enwiki frwiki and wikidata for the Eiffel Tower, is this flagged if more than 10m, 100m? Wikidata seems the best repository, but users will be generally adding them to individual wikis. I think changing allowing {{coord}} doing a wikidata pull would be a help. It could be whenever the data is swept out of the wikis into wikidata. {{WikidataCoord{{ with its extra parameters seems entirely the wrong way to go. Vicarage (talk) 08:29, 17 March 2022 (UTC) D/M/S versus decimal degrees Is there a preference for one of these over the other on Wikipedia? Bubba73 You talkin' to me? 01:27, 26 February 2022 (UTC) No. But if there are two or more coords in one article - such as with lists of heritage sites - they should be consistent within the article. Usually, it's best to use the same format as the source that you obtain the coords from, and convert if necessary using |format=dec or |format=dms. --Redrose64 🌹 (talk) 11:03, 26 February 2022 (UTC) I have occasionally found errors in coords, especially those that came from old records. Many of those are typos, misread numbers, misscanned digits, or digits reversed during manual copying. Those can more easily be found if they are preserved in the original, than if they are converted without checking. Check, for example with Google Earth, to make sure you aren't converting a traceable error into an error that's more difficult to find. Jim.henderson (talk) 23:35, 19 March 2022 (UTC) I have found a lot of errors of the types you mention, plus many more that are just not accurate. I always check before I change them, then I click on the changed one to make sure it is correct. I prefer decimal degrees because that gives more accuracy per digit. These are mostly things on the National Register of Historic Places. For recent ones, people just use the location in the street for that address, when it is near up to four houses. Bubba73 You talkin' to me? 02:21, 20 March 2022 (UTC) Something that's been nagging at me This isn't important, but why is User:Guarapiranga/sandbox/4 showing up in Category:Pages with malformed coordinate tags? There doesn't seem to be any {{coord}} templates on the page (and it's difficult to see what relevance geographic coordinates would have to anything there), and I can't see anything in the edit screen that might link to or transclude malformed coordinates. I know that there are too many templates on the page for all of them to function correctly, but why coordinates specifically? Deor (talk) 14:33, 3 June 2022 (UTC) My suspicion is that two or more of the pages linked each have a {{coord}} specifying |display=title or |display=inline,title. If a page has two or more coords that are trying for the title position, there's clearly a clash, and so the page is categorised as you describe. --Redrose64 🌹 (talk) 22:32, 3 June 2022 (UTC) I don't think it can be that; only one page that is linked in the sandbox (National September 11 Memorial & Museum) has coordinates, and they're fine. Another weird thing: If you click "edit" and then preview the page, you get a bunch of error messages at the top of the preview, including "One or more {{cite journal}} templates have errors" (when there are no {{cite journal}} templates in the page at all) and "Display title "#invoke:WPSHIPS_utilities" was ignored since it is not equivalent to the page's actual title" (which also doesn't seem to correspond to anything on the page). I thought maybe I was missing something obvious, but I guess this one may have to remain a mystery. Deor (talk) 22:59, 3 June 2022 (UTC) Category:Pages where post-expand include size is exceeded is most likely the answer to your question. I commented out the parts of the page that were causing the errors. – Jonesey95 (talk) 22:14, 5 June 2022 (UTC) No, if I go back to the version as it stood when this thread was raised, the page isn't in Category:Pages with malformed coordinate tags any more (and nor is it in Category:Pages where post-expand include size is exceeded either). The real fix must have been in one of the transcluded pages, and I suspect that it was the removal of the {{: and }} by Aidan9382 (talk · contribs) in this sequence of edits by three different people. --Redrose64 🌹 (talk) 10:43, 6 June 2022 (UTC) And I've restored the sandbox to its state before Jonesey95's edit. There seems no reason to mess up someone's sandbox unnecessarily. Thanks to everyone who commented here for endeavoring to clear this up. Deor (talk) 13:58, 6 June 2022 (UTC) Progress! Here's an update on the overall rate of progress of adding coordinates to articles over the last eight years, based on the automatic categorization generated by to {{coord}} and {{coord missing}}, comparing the number of articles which have coordinates to the number which appear to be eligible for coordinates. Here's the graph: Remarkably, and unexpectedly, it shows sustained linear growth with seemingly no slowing down over time. At this rate, if this trend is sustained, we will hit 100% in about 10 years... Congratullations to all involved in this effort! — The Anome (talk) 16:23, 8 June 2022 (UTC) To have low precision in coords displayed in articles Could someone please tell me how I can code the location for a photograph taken in an area that I can only pin down to, say, 1.1 km x 1.1 km? I input appropriately -- for example as {{Location|-33.68|138.93}} -- but the output produced is excessively precise at 33°40′48″S, 138°55′48″E. Cheers, Simon – SCHolar44 🇦🇺 💬 at 12:46, 28 August 2022 (UTC) Can you show where this is happening. Your example works fine here: 33.68°S 138.93°E / -33.68; 138.93. MB 12:55, 28 August 2022 (UTC) Thank you, MB  :-)  Here -- and the Edit page. Cheers, Simon – SCHolar44 🇦🇺 💬 at 13:02, 28 August 2022 (UTC) Oh, you are talking about a template on Commons, not here. There is documentation there that shows there is a |prec= parameter. MB 13:56, 28 August 2022 (UTC) Ah!! Sorry I failed to mention the context, MB. Many thanks for taking the trouble to give me the lead. Exactly what I wanted. Cheers, Simon – SCHolar44 🇦🇺 💬 at 14:03, 28 August 2022 (UTC) Wikidata Do the majority of articles having geocoordinates keep them in Wikidata? Should this page mention that? Jim.henderson (talk) 09:21, 24 December 2022 (UTC) I'm not entirely sure what you mean by "keep them in Wikidata", but my sense is that most English WP articles with coordinates have their own {{coord}} templates, separate from (and not always agreeing with) the coordinates in the corresponding Wikidata items. I myself have often replaced coordinates drawn from Wikidata in our articles when the Wikidata ones were overprecise or otherwise problematic. I'm in general not a fan of the blind importation of Wikidata information into our articles. Deor (talk) 14:15, 24 December 2022 (UTC) Overriding default stroke colors in Commons Maps Hello, I'm trying to make the strokes in the following map different colors from their Commons GeoJSON defaults for various reasons (style and accessibility, mostly). I'm trying to make the strokes the colors in the comments. Please tell me this is technically possible. I asked the Help Desk, and all I got was a sort of "oh, change the caption to meet the map" response, which really kind of threw me. It would be a major deficiency of Commons maps if one couldn't change a desired characteristic upon implementation and instead had to make a different map altogether. Thanks! – John M Wolfson (talk • contribs) 18:22, 7 January 2023 (UTC) Discussion notification Would someone from this project care to weigh in on the discussion at Wikipedia talk:WikiProject Military history#Coordinates? Thanx. Hawkeye7 (discuss) 23:57, 24 January 2023 (UTC) As battles happened in phyical space, I think they should all have coords, preferably in wikidata. I dont have a problem with the Battle of the Atlantic being in an arbitrary spot in the middle of the ocean. Better that than no location at all. Indeed I have conflict pages in my system that show other battles within 20 miles, as that shows strategic importance eell Vicarage (talk) 22:47, 25 January 2023 (UTC) Unreferenced tags? I've noticed unreferenced template tags on the meridian articles, e.g. 151st meridian east. Is there any need for that tag, and/or finding references. Newystats (talk) 23:01, 30 January 2023 (UTC) I would think an article where you don't want to add citations would not be notable, because of the general notability guideline. If the 151st meridian east is notable, then surely there must references out there? It's not clear to me whether a map that contains the 151st meridian is "significant coverage" under WP:GNG — hike395 (talk) 05:12, 31 January 2023 (UTC) Later --- WP:GEOFEAT says The inclusion of a man-made geographical feature on maps or in directories is insufficient to establish topic notability. There should be references to support notability of meridians. I just spent a couple of minutes poking around the web, and cannot yet find any non-map sources. — hike395 (talk) 05:19, 31 January 2023 (UTC) I have a feeling that a few of the meridian articles were experimentally taken to AfD some years ago, with a result to keep all. --Redrose64 🌹 (talk) 14:45, 31 January 2023 (UTC) Redrose64 has a long memory. Wikipedia:Articles for deletion/104th meridian east (from 2008). Wikipedia:Articles for deletion/139th meridian west (from 2009). – Jonesey95 (talk) 17:09, 31 January 2023 (UTC) Both of those were before I joined (May 2009), so there's at least one more somewhere. --Redrose64 🌹 (talk) 18:05, 31 January 2023 (UTC) 2009 was a long time ago: back then, WP:GEOFEAT was a short essay, not a guideline. But I'm very cautious about bringing articles to AfD, until we're really quite confident there are no supporting sources. @Newystats and Bazonka: would you be willing to find non-map sources to support notability and add references to meridian and parallel articles? I'll keep looking around, also. — hike395 (talk) 05:01, 1 February 2023 (UTC) Later --- I'm still not finding any non-map sources, after trying a variety of Google and Google books queries. @Redrose64: I'm also not finding any AfD discussions post-2009. WP:GEOFEAT was established in 2012. It would be good to see if there were any AfD discussions after that date. — hike395 (talk) 09:00, 1 February 2023 (UTC) I appreciate that this isn't the normal way of doing it, but these articles are all referenced. They are essentially almanac tables which are sourced from cartography - the references are the Coord links, which point to a reliable source. (The articles used to directly reference a mapping site, but this had to be removed - see Wikipedia:Articles for deletion/139th meridian west for an explanation). By all means, take them to AFD again, but the articles have been through it multiple times before and the decision has always been to keep. Of course, consensus can change, and you could argue that WP:NGEO doesn't apply, but I will counter-argue that WP:INHERENT does apply. A more recent discussion about the articles can be found here. Bazonka (talk) 20:22, 1 February 2023 (UTC) Yep, I remember that one. --Redrose64 🌹 (talk) 23:00, 1 February 2023 (UTC) Thanks @Bazonka, that way of thinking about it makes sense to me. These are like List articles, with reliable references via their co-ordinates. Newystats (talk) 23:15, 1 February 2023 (UTC) I think relying on WP:INHERENT is not good for the long-term health of these articles, because consensus can change (too easily). Codifying the notability of a set of articles in AfD is fragile and could easily flip depending on which editors participate. Instead, if the multi-decade consensus is that individual integer meridians and parallels are inherently notable, then we should update WP:NGEO to say that the such notability is covered by an explicit guideline. Shall we bring it up at Wikipedia talk:Notability (geographic features) and see if we can codify the notability there? — hike395 (talk) 05:17, 2 February 2023 (UTC) Thanks @Hike395, let's do that. Newystats (talk) 08:37, 4 February 2023 (UTC) RFC on whether citing maps and graphs is original research Please see Wikipedia:Village pump (policy)#RFC on using maps and charts in Wikipedia articles. Rschen7754 15:21, 19 March 2023 (UTC) Add missing place in Google map how can I add my village name in Google map Imran khan 1989.11 (talk) 19:10, 24 March 2023 (UTC) Project-independent quality assessments Quality assessments by Wikipedia editors rate articles in terms of completeness, organization, prose quality, sourcing, etc. Most wikiprojects follow the general guidelines at Wikipedia:Content assessment, but some have specialized assessment guidelines. A recent Village pump proposal was approved and has been implemented to add a |class= parameter to {{WikiProject banner shell}}, which can display a general quality assessment for an article, and to let project banner templates "inherit" this assessment. No action is required if your wikiproject follows the standard assessment approach. Over time, quality assessments will be migrated up to {{WikiProject banner shell}}, and your project banner will automatically "inherit" any changes to the general assessments for the purpose of assigning categories. However, if your project has decided to "opt out" and follow a non-standard quality assessment approach, all you have to do is modify your wikiproject banner template to pass {{WPBannerMeta}} a new |QUALITY_CRITERIA=custom parameter. If this is done, changes to the general quality assessment will be ignored, and your project-level assessment will be displayed and used to create categories, as at present. Aymatth2 (talk) 14:08, 11 April 2023 (UTC) Infobox archive generating plain-text coordinates {{Infobox archive}} appears to pull coordinates from Wikidata (property P625), but the coordinates generated within the infoboxes are not linked to geohack pages. Is there a way of fixing this, preferably in a way that uses {{coord}} and can be easily added to any other similar cases, and requires minimal change to the template logic? — The Anome (talk) 13:35, 21 April 2023 (UTC) Can you give an example? I've looked at all of the few articles that use {{Infobox archive}}—which is a redirect to {{Infobox museum}}—and I'm not seeing the problem. Many of them already have {{coord}} templates in the |coordinates= field, and the articles that lack coordinates seem to lack them in Wikidata as well. (By the way, I absolutely hate infoboxes that automatically pull coordinates from Wikidata.) Deor (talk) 14:16, 21 April 2023 (UTC) You're quite right -- I must have been looking at a different template, and it's not in my browser history (different computer). I will try to remember which one I was looking at; it definitely had parameters like FROM_WIKIDATA within its internal logic. But it's clearly not that one. Sorry for wasting your time on this; if I find it, I'll raise it again here. — The Anome (talk) 14:36, 21 April 2023 (UTC) @The Anome: Please observe WP:MULTI, you raised the same issue at Template talk:Infobox museum#Template generating plain-text coordinates, which is a more appropriate place, if that is indeed the infobox with the issue concerned. But Thank you for this revert. --Redrose64 🌹 (talk) 08:57, 22 April 2023 (UTC) List of all Lebanon towns coords Nobody responded on the WP:RSN section I made so thought this was an appropriate WP for this. See this PalauanReich🗣️ 18:34, 25 April 2023 (UTC) This is driving me crazy Several days ago, an editor made this rather extensive edit to the "Switzerland" section of List of inclined elevators (the only section of the article that contains any coordinates) that caused the article to pop up in Category:Pages with malformed coordinate tags, which I monitor for coordinates that need fixing. In this case, I've repeatedly examined the {{coord}} templates that were added, and I'm dashed if I can see any malformatting. Can anyone here find where the problem lies? Deor (talk) 23:02, 6 May 2023 (UTC) It would be helpful if there were an explanation of what causes this categorization, and how to fix it, on the category page. I did not find an explanation on the Module or Template page either. – Jonesey95 (talk) 15:29, 7 May 2023 (UTC) Removing {{GeoGroup}} from the section appears to eliminate the error. I don't know if that helps. – Jonesey95 (talk) 15:44, 7 May 2023 (UTC) If I remove the {{GeoGroup}} and preview, the malformed-coordinates category still appears among the categories at the bottom of the preview page. I wish that people adding bunches of coordinates to an article would do it in a series of smaller edits so that it would be easier to spot problems. Most edits that introduce malformed coordinates produce red error messages at appropriate points in the displayed article—not so in this case, however. Deor (talk) Strange. When I edit the Switzerland section, the tracking category is there. If I remove the {{GeoGroup}} template from the section and Preview, the tracking category is not shown at the bottom of the preview. YMMV, I guess. – Jonesey95 (talk) 19:09, 7 May 2023 (UTC) I think I may have found it: removing the example template below "new entry with coordinates" in the HTML comment appears to resolve the problem. I wonder if {{GeoGroup}} is failing to ignore the malformed (no lat and long) example coord template inside the HTML comment. – Jonesey95 (talk) 19:14, 7 May 2023 (UTC) OK, I added dummy coordinates ("0000") to the example template and that seems to have eliminated the problem. Oddly, I had to remove the displayed GeoGroup map as well, since it was showing a pushpin at 0°, 0° even though the example is commented out. Anyone who wants to see a map with pushpins can just click on the OpenStreetMap link. Deor (talk) 21:39, 7 May 2023 (UTC) Sorry about that. If it's an issue, one can just scrap the comment. It's mainly there to simplify additions. Enhancing999 (talk) 12:42, 8 May 2023 (UTC) Another thing driving me crazy OK, I've run into another coordinates problem for which I've been unable to track down the source—it's detailed at Wikipedia talk:WikiProject Latter Day Saint movement#Coordinates problem—since the problem seems to lie somewhere in the complex system of LDS templates. The folks here have been helpful with such problems before, so I thought I'd bring it to your attention. Deor (talk) 23:51, 24 May 2023 (UTC) Ware, Hertfordshire Hi All, The co-ordinates at the top of the article are correct but the OS Grid Reference in the Infobox looks like Bishop's Stortford, How do I find the correct grid reference and correct it? GrahamHardy (talk) 16:09, 30 May 2023 (UTC) @GrahamHardy: Click on the coords at the bottom of the infobox (not those top right of the article, they're broken) and in the right-hand half, below the "Great Britain" heading, it says "OS Grid Reference: TL3569314353 (all-numeric format: 535694 214354)". TL3569314353 is to one-metre precision, so take out some digits - TL356143 is to 100-metre precision, TL3514 is to 1 km precision. Use whichever is most appropriate, see WP:OPCOORD. --Redrose64 🌹 (talk) 17:19, 30 May 2023 (UTC) @GrahamHardy: (edit conflict) I've fixed the grid reference (and the overprecise coordinates). I used the site www.nearby.org.uk, where you can enter coordinates and it will give you the OS grid reference, or vice versa. Deor (talk) 17:25, 30 May 2023 (UTC) New open geodata source Here's a substantial data release by the Overture Maps Foundation, an organization I'd never heard of until today: https://overturemaps.org/overture-maps-foundation-releases-first-world-wide-open-map-dataset/ Their proposed Global Entity Reference System, a unique identifier scheme, sounds particularly interesting. The licensing for this dataset is interesting: see https://overturemaps.org/download/ Are any of these licenses Wikipedia-compatible? — The Anome (talk) 21:26, 26 July 2023 (UTC) Coordinates duplicated in the lead (both inside and outside infobox) Please discuss at Wikipedia_talk:Manual_of_Style/Dates_and_numbers#Coordinates_duplicated_in_the_lead_(both_inside_and_outside_infobox). fgnievinski (talk) 03:16, 13 August 2023 (UTC) RFC: importing coordinates from other language editions There are over 20,000 articles missing coordinates that have coordinates on Wikidata. While I don't intend to import coordinates from Wikidata, as I don't believe it is well-curated at the moment, this is suggestive that a substantial number of articles will have coordinates on non-English Wikipedias, many of which have a sufficiently large user-base that they can be considered to be effectively curated by human beings. I propose that we start importing coordinates from the following Wikipedias, all of which have more than 1 million articles, and have not had articles mass-created by LSJbot: German 2,828,000+ articles French 2,546,000+ articles Russian 1,933,000+ articles Spanish 1,886,000+ articles Italian 1,823,000+ articles Japanese: 1,384,000+ articles Chinese 1,373,000+ articles Portuguese 1,107,000+ articles As part of this exercise. I plan first to generate lists of candidate coordinates from these that they can be assessed for quality before going any further. Yes, I know that in theory, Wikidata is the way to do this kind of cross-wiki syncing. But in practice, there's as yet no real cross-wiki integration to enable human curation, and thus Wikidata is not ready to be useful as a way to do this yet. And of course, if I do the interwiki copying, I intend to export any coordinates I find to Wikidata as part of the process, if they're not already present, so that as and when Wikidata is eventually usable for this purpose, we can easily migrate to using Wikidata as the master data source. I'd welcome any comments other editors have on this. In particular, please let me know now if you have any objections to this plan; I don't want to waste my time implementing this only to for the addition of these coordinates to be rejected by the community. — The Anome (talk) 17:25, 1 September 2023 (UTC) @Deor and Pigsonthewing: I'd be interested to hear your comments on this. — The Anome (talk) 09:35, 2 September 2023 (UTC) Though I think your concerns about Wikidata are unfounded, I support this import. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:12, 2 September 2023 (UTC) I've been thinking about this since I saw that you had posted it. Unlike Pigsonthewing, I share your doubt of Wikidata, and I've certainly run across incorrect coordinates in other-language WPs as well. I imagine that a great number of geocoded articles in other languages are already geocoded here, so I'm not sure how many sets of new coordinates you're going to come up with; but I'm willing to hold my judgment. (When I'm looking for coordinates to add to one of our articles, one of the things I usually do is check to see if they're present in a corresponding article in the relevant-language WP, and I can't say that I often find any that way.) Your plan "to generate lists of candidate coordinates from these [so] that they can be assessed for quality" seems a good first step, and I'd like to see how that turns out. Will you post the results somewhere so that others can inspect them? Deor (talk) 18:34, 2 September 2023 (UTC) I fairly often correct bad coords in WD; some of our large imports are indeed dirty. Probably coords that are mass-imported from any Wikipedia will be no dirtier than the average import; might even be cleaner. I'm comfortable with the notion that a load of coords with median errors of 10 or 50 meters are better than nothing. As it happens, a few minutes ago I corrected an error of 50 meters in my own coords for an urban photo, so no use my complaining about other moderately dirty suppliers. You might want to get into touch with whoever thinks they handle coords in WikiData; they might have something important to say, like, nevermind importing WPDE or other WP language coords into WPEN; just put it in WD and use a template to show it in English. Jim.henderson (talk) 01:14, 5 September 2023 (UTC) Kartographer, infoboxes and Wikidata I've noticed that some templates that use the Kartographer extension are pulling in coordinates from Wikidata by default. This is bad news, as it represents a slide toward treating Wikidata as the master source of geographic data without there being a robust system of editorial oversight; the coordinates are nowhere to be found in the body of the article, and there is no clear way to detect in edit logs that Wikidata coordinates have changed, or simple user interface for correcting them if they're wrong. This seems to me to break the entire wiki principle that drives Wikipedia. What to do about this? I'd be happy with using Wikidata coordinates in these if these problems could be fixed, but given the glacial rate of change in the Wikimedia software, I wouldn't hold out much hope of seeing this change. At least with mass-copying Wikidata to here, there's some chance of editorial oversight; this is worse that a mass import, because it's invisible. — The Anome (talk) 15:47, 5 November 2023 (UTC) Could you give one or two examples of "templates that use the Kartographer extension"? (With my limited technical skills, I'm not sure what this means.) I've noticed that a few infoboxes, such as {{Infobox power station}} are set up to pull coordinates from Wikidata by default; when I run across such, I've been leaving them alone if the coords look good but adding local coordinates if they need to be emended or otherwise adjusted (overprecise, a bit mislocated, etc.). They can be identified whenever an article is displaying coords but doesn't have a {{coord}} template in it. As you know by now, I don't think that indiscriminately pulling coordinates from Wikidata is a good idea, but I often feel like Dame Partington trying to push back the Atlantic with a mop. Deor (talk) 16:47, 5 November 2023 (UTC) I've mentioned your concerns in WD chat. I think the people there are happy with their quality control in this area. http://www.wikidata.org/wiki/Wikidata:Project_chat#Pushback_at_using_WD_coordinates_in_enwiki Vicarage (talk) 16:49, 5 November 2023 (UTC) Information imported into infoboxes from Wikidata must have a reliable source in Wikidata, per the 2018 Wikidata infobox RFC. If there are infoboxes that do not comply with that RFC, their code should be adjusted. – Jonesey95 (talk) 16:03, 6 November 2023 (UTC) Thanks for pointing out the RfC, which I was completely unaware of. If there's a requirement for a reliable source citation for the Wikidata coordinates, then I'm fine with it, and this is really good news. Do the templates check for the presence of a reference for the wikidata value? Is there some way in which this check can be done automatically and transparently as part of the value retrieval process? — The Anome (talk) 08:24, 11 December 2023 (UTC) {{Infobox bridge}} provides an example of how to retrieve only sourced values and allow local overrides in articles. See |official_name= in that template, for example. – Jonesey95 (talk) 13:55, 11 December 2023 (UTC) Fantastic. The syntax is a bit eye-watering, but I can see what's going on. This makes me feel a lot better. — The Anome (talk) 14:26, 11 December 2023 (UTC) I'm pretty happy with the theory of Wikidata as the master source of geographic data. As with figures for land area, population, and other geographical numbers, this method has the advantage that the data can be entered once for all languages. The same WD coords go into various maps including WikiShootMe and Wikmedia Commons Android App, both of which I use to find photographic targets, including those that are mentioned in articles but have no article of their own. This activity finds many erroneous coords that were imported on a mass basis from other databases. I make a rough WD coord adjustment in the field and finer upon getting to the big computer. No worry about how many languages are using that particular WD item. One problem is, many editors don't know about Wikidata, and the newbies whom I teach find the very idea difficult. I mean, even the infobox itself is difficult to learn, since the Visual Editor is not very helpful. I hope this can be fixed by designing a more direct and obvious way to edit WD from the infobox, and the infobox by VE. Alas, this is likely to take years but when it happens, we can expect faster cleanup of those dirty mass imports. Jim.henderson (talk) 01:25, 8 February 2024 (UTC)