Wikipedia talk:WikiProject Geographical coordinates

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

To do[edit]

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

Find coordinates for[edit]

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

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

See also: Wikipedia:Obtaining geographic coordinates

Tag articles needing coordinates[edit]

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


As of January 31, 2015 05:38 (UTC) Refresh
User reported errors:

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

Formatting errors:

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


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

RFC: expressing coordinates as decimal vs. DMS[edit]

No consensus to favour the use of decimal co-ordinates. Number 57 12:18, 9 December 2014 (UTC)

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

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

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

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

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

Clarification: Should geographical coordinates be expressed in decimal? Specifically, should a migration path be established for de-emphasizing and eventually deprecating DMS coordinates? Unless a superior use for DMS is articulated.
    • Except articles specifically about a location associated with its DMS designation (example Fifty-Four Forty or Fight! which has about 20 similar redirects), coordinates should be displayed in decimal. This is immediately realized by altering {{coord}} and/or its module to ignore the format= parameter and assume it was specified as format=dec.
    • As an interim measure, allow a new override parameter to display the coordinate as encoded in {{coord}}. (keep_original=yes?) Support for this should eventually be dropped once DMS vs. decimal is not contentious.
    • The default precision of the decimal display should be associated with its dim:X (dimension) parameter, if any, or an explicit scale (if given). This is particularly important for not-nice-in-decimal coordinates like 45°20′N 123°20′W / 45.333°N 123.333°W / 45.333; -123.333.
    • As practical, enhance the mouse cursor hover feature so that a rendered coordinate displays in the tooltip to also show the degrees/minutes/seconds conversion. Currently it says Maps, aerial photos, and other data for this location.
    • The automatic precision display can assume a latitude like 40° which is good enough for the vast majority of locations. This can be refined later if anyone is interested.
    • I do not recommend anyone (be they bot or editor) be tasked to change wikitext coordinate parameters to decimal: leave them as they are. But if it were someday considered, the conversion should preserve the original format in the wikitext for sourcing purposes.
(end clarification)EncMstr (talk) 06:16, 10 November 2014 (UTC)
  • Favor neither. When I'm adding coordinates to articles that lack them, I use both formats (somewhat indiscriminately but sometimes for specific reasons involving precision or ease of entering in a specific kind of infobox). When I'm messing with coordinates that are already in an article, I almost always preserve the format that was originally used. In the {{coord}} template and most infoboxes, it's easy to change the formatting to display d/m/s even if the underlying coordinates are decimal; and I don't see why such displays should be discouraged, since they are after all the traditional format for expressing coordinates, and I'm a traditional guy. (I also like specifying d/m/s display for coordinates entered in decimal format that require five or more decimal places of precision, because of the rounding.) In short, I see no reason why we should try to suggest or enforce a specific format; most folks, I'm sure, just click through the coordinates to look at a map, and the format doesn't matter to them at all. A greater problem, it seems to me, is the prevalence of too-precise coordinates in articles, in both formats. Deor (talk) 19:17, 7 November 2014 (UTC)
Here's a good example I ran across this morning: Straža, Bosnia and Herzegovina. The Anomebot2 had added to the article coordinates taken from Wikidata, which were expressed to four decimal places. That was too precise—I could have trimmed them down to three places (trimming them down to two places would have put them outside the village), but in this case degrees and minutes were just as precise—if not more so—and more compact. I see no reason why in such a case the coords should have to be expressed in decimal form. Moreover, if the coordinates I added to the infobox (44°41′N, 18°35′E) should be forced into a decimal display, it would come out as 44.683333, 18.583333 or the like, which seems ridiculous to me. Deor (talk) 12:16, 8 November 2014 (UTC)
For object size ~850 m at 44° latitude, the tables at WP:OPCOORD give formats of d° m' s" or d.ddd°. In each format, that's as close as you can get to the suggested resolution of 1/10 of the object size, or 85 m. For d° m' format, you would have to have an object size of at least 7.5 km, as shown in the table. That town village isn't anywhere near that size. I get 44.683°N 18.583°E, although that could be tweaked to be consistent with the Wikidata. I don't see a problem with that, and the advantages to decimal have already been stated and have not been challenged. Given those advantages, in my view, the question is why the coords should have to be expressed in DMS form. ‑‑Mandruss  12:49, 8 November 2014 (UTC)
  • Yes - About five solid advantages to decimal were briefly presented above. Any of those can be elaborated in a discussion subsection, if needed. When I hear advantages to DMS that outweigh them, I'll reverse my !vote. I don't count "it's tradition" or "most readers don't care" as advantages to DMS. As for the specifics of the proposal, I don't know that I'd go as far as adding a tracking category, or even using the word "deprecated", as there are conceivably a few rare situations where DMS makes more sense. But I'd certainly make sure all of the related doc clearly states the house preference, and perhaps a brief mention of the reasons for the preference. ‑‑Mandruss  22:41, 7 November 2014 (UTC)
  • Favor decimal, in principle, but see the subheading below. Don't force users to enter decimal if their source is DMS, any conversion needs to be automatic. Oiyarbepsy (talk) 23:29, 7 November 2014 (UTC) - Changing my vote to decimal now that the intention is to have the templates convert DMS. Oiyarbepsy (talk) 23:47, 7 November 2014 (UTC)
  • Favor neither Coordinates should be entered, and displayed, in whatever format the user got them in. Jackmcbarn (talk) 01:13, 8 November 2014 (UTC)
  • Favor decimal if the template will convert from DMS to decimal. Robert McClenon (talk) 02:31, 8 November 2014 (UTC)
  • Question - Would it be possible to have coordinates display in both decimal and DMS? Robert McClenon (talk) 02:31, 8 November 2014 (UTC)
Yes, there is already a mechanism to do that, but it only for logged in users who edit their style sheet. See template:coord#Per-user display customization. —EncMstr (talk) 03:05, 8 November 2014 (UTC)
  • Favor neither—both are acceptable options depending on circumstances, and we shouldn't use the templates to force only one output option. They should be displayed in their input format in some cases (templates used in direct quotes, for example), so I can't support any change from the status quo. Imzadi 1979  02:57, 8 November 2014 (UTC)
Favour neither Displaying coords giving in one notation in the other introduces either inaccuracies, false impressions of precision, or both. I do, however, favour anyone who can be bothered reverting existing conversions. All the best: Rich Farmbrough00:17, 12 November 2014 (UTC).
  • Favor DMS - DMS is the traditional way to write coordinates. And as said above, coordinates should be added as they are referenced. I would also add that changing DMS to decimal would be like replacing miles with kilometers without mentioning the former. ミーラー強斗武 (StG88ぬ会話) 20:34, 24 November 2014 (UTC)
  • Favor DMS As a sea sailor i can verify the practical usefulness of the DMS system for people who actually use coordinates for navigating. I won't go into the technical details as to why the DMS system is used, but it has to do with using a compass (drawing tool) and the curvature of the earth. The people who know coordinates by heart and use coordinates in irl communication use DMS. At least this goes for sailors and i'm pretty sure pilots. So for the sake of the people to whom a coordinate will actually ring a bell, rather than just form a clickable or copy-pasteable number, let's use DMS.PizzaMan (♨♨) 15:00, 27 November 2014 (UTC)
  • Oppose forcing a default to decimal. DMS is still widely used and in many respects much more easily recognizable that decimals. olderwiser 15:30, 27 November 2014 (UTC)

This is why we have templates[edit]

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

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

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

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

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

The question left at Wikipedia:Village pump (technical)/Archive 131#Technical input requested about coordinates was "Could the coordinate templates convert DMS coordinates to decimal?" The answer is yes, they can, and have been able to do this for many years. The input format may be either decimal or DMS - if there are two figures, decimal is assumed; if four or six, it's DMS. By default, the output format mirrors the input format, unless either |format=dms or |format=dec is used; these force that output format regardless of the input format - which may still be either one. --Redrose64 (talk) 00:25, 8 November 2014 (UTC)
Mandruss, I haven't been involved in an RFC before, but my question is whether there should be a system wide preference for decimal notation. Making that the default of {{coord}} regardless of parameters is about twice as far as I had imagined—at least initially. Changing it so that format=dms is ignored is about as far as I was thinking; instead display DMS only if the coordinates are given in DMS. If there is community buy in on that much, and no one can give a compelling reason to regard DMS on an equal footing to decimal, then perhaps in a year or two, ignoring the original format and always displaying decimal would be in order. —EncMstr (talk) 02:37, 8 November 2014 (UTC)
Free-form discussions are one thing, but an RfC needs to start with a precisely worded question that can be answered with Yes or No, Support or Oppose. Otherwise things get so muddled that it's extremely difficult to reach a discernible consensus (and it's often extremely difficult anyway, since so many people lack the self-discipline to avoid tangential discussion and stick to the stated proposition). My take is that "should we favor" is too vague, and it even had me going down the wrong path in my !vote. It will be hard for anyone to !vote either way without knowing exactly what they're !voting for. ‑‑Mandruss  02:48, 8 November 2014 (UTC)
Point taken. Should I revise my question above, or open a new RFC? —EncMstr (talk) 03:05, 8 November 2014 (UTC)
That's new ground for me, but I think I'd start a new one. Insert an explanatory comment at the top of this one, with a link to the new one. Maybe someone else knows something else that would need to be done to this one. And then, from within the new one, you could ping each of the responders to this one so far. A lot of work, but seems necessary as this is a topic that is likely to attract a lot of attention. ‑‑Mandruss  03:14, 8 November 2014 (UTC)
Don't start a new one. Just post Clarification below your original proposal with exact wording. How about "Coordinates should always be displayed as decimal degrees. Editors may enter coordinates as degrees/minutes/seconds if they choose and the templates will convert this to decimal degrees, without needing to instruct the template to do so." Oiyarbepsy (talk) 04:24, 8 November 2014 (UTC)
Ok, but many responders will have to refactor their responses, and much of this discussion will be confusing and time-wasting for new arrivals. And I don't think that's the proposal, in any case. As I understand it the proposal is to make decimal the default presentation when |format=dms is not coded. ‑‑Mandruss  04:34, 8 November 2014 (UTC)
Upon review I'm not clear as to what the proposal is, but I'm pretty sure it doesn't include "Coordinates should always be displayed as decimal degrees." It seems there are three or four possible proposals, and maybe this needs free-form discussion to establish what the proposition should be. At this point, I'd still be for what I described in my !vote—no change to any software, simply declare decimal as the house preference (for coding as well as presentation). This would prevent DMS in most new coordinates, after the word got out, and we could gradually convert existing template transclusions to decimal, the kind of thing we're already doing in many other areas. Or, you could do that relatively easily with a bot. It could be viewed as a semi-deprecation of DMS, but support for DMS as an option would never go away. One problem with depending on the template to convert to decimal is that you lose the "finer control" advantage—the control could never be any finer than is provided by DMS. ‑‑Mandruss  05:08, 8 November 2014 (UTC)
Coords ought not be automatically converted. Many of our sources are full of errors including simple typos. Those errors are much more easily analyzed in the original. Bots don't notice when coords are putting a skyscraper in a lake or otherwise producing unlikely results; that's a human job. Conversion, even of correct data, also either degrades precision or, more often, introduces false precision. This also needs a human mind. Jim.henderson (talk) 14:20, 8 November 2014 (UTC)

Post-clarification discussion[edit]

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

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

The value of importing coordinates from Wikidata[edit]

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

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

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

I recall there was some discussion that coordinates could, in the future, pulled live directly from Wikidata, rather than manually mirrored between Wikipedia and Wikidata. I believe some (non-en) wikis are already using a system like that for some infobox elements. Is that something in the works in the medium-term future? If so, the problem might solve itself eventually. Wikidata itself ought to include most of the needed information: 1) entries are slowly getting a 'country' property, which can serve a similar role as the 'region' parameter; and 2) Wikidata coordinates explicitly have a precision along with the value, although admittedly this precision is not always set to a sensible value at the moment. --Delirium (talk) 12:24, 17 November 2014 (UTC)
Hi, and thanks for the comments. I have plans to address many of these issues. No bot-driven editing is ever perfect, and no data source is perfect either, so my overall criterion for doing anything with the bot is "does this improve or reduce the overall level of quality, and are any mistakes it makes as easily fixed as a manual edit?" Regarding the four decimal places: given that the Wikidata scale/precision values are only very rarely in any way sensible, this is a pragmatic compromise between too much and too little precision. Regarding the wildly incorrect values, yes, as you say, I think that adding the coordinates is a Good Thing and that any problems can be corrected by Wikipedia editors in the normal course of work -- and many thanks for your efforts on fixing the Bulgarian village coordinates. I'm also working on assigning regions to coordinates (something which Wikidata's coordinates lack) and also inferring approximate scale values, both using the enwiki category tree.
I am very enthusiastic about eventual total Wikidata integration for "primary" coordinates, as well as cross-linking to OpenStreetMap resources, but we need to move slowly on both of these to make sure we get it right. I see this sort of bot-copying only as a very first stage toward closer integration, using bulk copying instead of transclusion: I'm particularly interested to see what, and how many, changes get made to the Wikidata coordinates over the next few months. I'm currently dubious about on-the-fly use of Wikidata coordinates, because there's very little oversight over them on Wikidata, and no easy way for normal Wikipedia editors to apply quality control to them locally, as the Bulgarian village example demonstrates. What I'd really like is for Wikidata transclusion to be more closely integrated into Wikipedia's changes and watchlist system, so that editors here can both track page changes made by Wikidata updates, and also edit the transcluded Wikidata values easily from within the local Wikipedia interface. If we can crack that problem, however, then we'd be a long way along towards real-time transclusion being both practical and desirable, at least for the "primary" coordinate for articles. -- The Anome (talk) 13:06, 17 November 2014 (UTC)
Staying on the topic of Bulgarian villages, since those are freshest in my mind: The coordinates for them on Wikidata all seem to exist in the format xx°xx'0" (or the nonsensical xx°xx'60"), in which, I assume, the seconds figures are just there for show and they are actually just degrees-and-minutes coordinates—which, when they're not even more imprecise, are usually too imprecise for a place that may measure only one or two hundred meters from end to end. (They're all apparently taken from ru.wikipedia, though I have a suspicion what the ultimate source is, and it's not necessarily a reliable source.) Now, having dealt with them here to the best of my ability, I have no stomach for going to Wikidata and trying to emend all of them there, so I applaud your vision of a time when "editors here can ... edit the transcluded Wikidata values easily from within the local Wikipedia interface"; but that time is not yet. As long as we have useful infobox functionalities (like location maps, default "type" parameters, and automatic supplying of "region" parameters) that these imported coordinates can't make use of and no way to effectively emend the coordinates at the source, I guess I still wonder whether at present the work the bot may be creating outweighs the work it's perfoming. I have no settled opinion myself, and I thought of just discussing this on your talk page; but on reflection I decided that a wider range of opinions might be helpful. Deor (talk) 13:59, 17 November 2014 (UTC)
[ec with Deor] When a bot's adding coordinates, more precision is better than less in my mind. A bot can't know how precise or not-precise to make things, absurd precision can always be refined to a reasonable generalisation, but the contrary is not true. Yes, it's silly to specify that Alaska is located at 64°12′16.488″N 149°30′22.824″W / 64.20458000°N 149.50634000°W / 64.20458000; -149.50634000 when 65°N 150°W / 65°N 150°W / 65; -150 will work, but for my wikiproject, most locations need a lot of precision (sometimes ½ second separates two locations, e.g. the James M. Amoss Building and the Solomon Wilson Building at this list, adjacent buildings just fifteen feet wide), and a bot ought not be set up to assume that a couple of decimal digits are sufficient. We definitely need precision down to four decimal digits or individual seconds, and tenths of a second would be helpful. Nyttend (talk) 14:06, 17 November 2014 (UTC)
Thanks for the comments on "total Wikidata integration" in the 2nd paragraph, The Anome (and thanks for your work on this!). Everything you say here seems sensible to me. --Delirium (talk) 17:55, 17 November 2014 (UTC)

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

The bug is only about the rendering of ccoordinates in the Wikidata interface, that does not seem to affect the rendering of coordiantes in client websites.
I really think pulling data directly from Wikidata would make things simpler. Yes, it is slightly less convenient to watch Wikidata edits than Wikipedia edits, but still there is a "show Wikidata" option that works. The only way we can get more people to watch Wikidata is to use more data from Wikidata.
Taking the Bulgarian example, it seems much better to use Wikidata's data directly than have a bot copy them. It is not really more difficult to correct coordinates in Wikidata than in Wikipedia. You have to load a different page, but the interface is actually more intuitive there. More importantly, you benefit from editors from other languages as well. I have fixed quite a few wrong French coordinates in Wikidata that were imported from English Wikipedia, but I was lazy about fixing them here as well. So now the data are right in Wikidata, and remain wrong here. Coordinates in non-English speaking countries are often better maintained in local-language Wikipedia than in English. If we want it to work, we need to have as many languages switching to Wikidata as possible. If English did, that would be a strong boost in that respect.
I do not think the lack of Wikidata support for "type" , "region" etc is really an issue, at least for primary coordinates added through infoboxes. It would be if infoboxes worked like
|coordinates = {{coord|55.752222|N|37.615556|E|format=dec|name=Moscow}}
but what we actually have is
format, name, etc. are either in a different parameter or somewhere deeper in the code. It does not really make any difference wether latitude and longitude are stored locally or pulled from Wikidata. --Superzoulou (talk) 14:51, 28 November 2014 (UTC)

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

WikiProject X is live![edit]

WikiProject X icon.svg

Hello everyone!

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

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

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

Google maps as a reference[edit]

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

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

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

I'm not comfortable with this because:

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

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

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