Wikipedia talk:WikiProject Geographical coordinates/Archive 28

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

See

I'd go beyond that, and regard anything with 8 or more decimal places as being physically meaningless as absolute coordinates for a fixed location: 10^-8 degree of arc at the equator is roughly 1 millimetre -- the Earth's surface shifts more than that from day to day with natural processes such as rainfall expansion of soil and Earth tides, and continental drift motions run at about 10-160mm/year. I think most of them are either points picked off a mapping tool by hand, or dms coordinates converted to decimal. I've got a tool which detects the latter. In the first case, we should round to six decimal places, in the second, to degrees/minutes or degrees/minutes/seconds, depending on the relevant level of precision. This should be accurate enough for all practical purposes: in the first case, 10^-6 degree of arc at the equator is about 0.1m, and in the second, one second of arc is about 30 metres. -- The Anome (talk) 09:43, 27 February 2012 (UTC)

I get most my geotags by dragging an arrow in Google Picasa which yields degrees to ten to twelve digits precision. Probably pleasant offline methods exist to find and round off these silly molecular level numbers in EXIF but I manually round them online to four or five decimal point degrees (or second or tenth of second, or whatever) in the picture description or historic place infobox, or whatever. Jim.henderson (talk) 10:53, 27 February 2012 (UTC)

I disagree with arbitrarily rounding off co-ordinates in some situations. In the case where one manually identifies the location of an object from a map, it's "wrong" to specify co-ordinates with greater precision than the map scale allows. However, if we are re-publishing a location from another source, I believe we should reproduce it exactly as originally specified. If the original source format is DDDMMSS.SSS, it should be the same way here - not converted to decimal degrees rounded to some arbitrary precision.

There's little chance of any significant performance benefit to be gained by rounding from 12-15 decimals to 6-8 - both will require the same precision data types in many environments and, even if they don't, the time taken to process the higher-precision math is unlikely to be a significant part of the overall process - whatever it is. If it's just about human readability, fine - deal with that in the rendering - but I say the underlying data should be accurate. AlanM1 (talk) 02:03, 18 March 2012 (UTC)

I'm sympathetic with the desire to be true to the source of the coordinates. But when the source is blatantly overprecise, rounding serves the needs of our users. Excess precision can be misleading, and rounding is allowed per

WP:CALC as long as it is obvious, correct, and a meaningful reflection of the sources. Now if we could just get editors to consistently cite their source when they add coordinates ... —Stepheng3 (talk

) 16:41, 27 March 2012 (UTC)

We have a list of all railway stations in Wales on the Welsh Wiki-cy, here. The top line is {{GeoGroupTemplate|article=Rhestr o orsafoedd rheilffordd yng Nghymru}}, which should work, however it leads me to an error: "Error creating temporary file b4913502e66c5749ce36be10f7e0d496!" Why is this? Is it old info in Google's cache? Llywelyn2000 (talk) 06:51, 20 March 2012 (UTC)

This has nothing to do with Google. It is an error coming from the Toolserver that prepares a KML file from the coordinate data. --Dschwen 14:20, 20 March 2012 (UTC)

Thanks. Llywelyn2000 (talk) 03:01, 28 March 2012 (UTC)

I just finished implementing a new feature for the WikiMiniAtlas that allows users to superpose and drag around arbitrary geographic objects to any location on the map. This basically provides a more intuitive sense of scale. The screenshot on the right shows the outline of Texas (green) is superposed on the Democratic Republic of the Congo. The map projection is fully accounted for and overlay objects are shown at their true size irregardless of where on the map they are dragged. To try go to the WMA settings (downward triangle in top right corner) and select an object from the drop down at the bottom of the settings page, or select other and enter an article title. --Dschwen 04:59, 27 March 2012 (UTC)

Is that live? Why are there no globe icons on the inline coordinates at

COID#System? Is that an intentional change? —EncMstr (talk

) 05:42, 27 March 2012 (UTC)

It is live and just hover your mouse over the coordinates. The icons in prose text have been replaced with a tooltip, after some complaints at

WP:MOS/ICONS. --Dschwen

12:46, 27 March 2012 (UTC)

Hovering over a coordinate makes a globe icon popup appear, but it is against the left edge of the text area, not near the coordinate. When I move the mouse to the globe, it vanishes, even if I get it thre before vanishing. It's like it does not know it is there.... —EncMstr (talk) 18:08, 27 March 2012 (UTC)

That should not be happening. Which browser are you using? The popup should be right at the coordinate. --Dschwen 18:47, 27 March 2012 (UTC)

It is Firefox 10.0.1 on Linux 2.6.42.9-2.fc15.i686 #1 SMP Mon Mar 5 21:10:27 UTC 2012 i686 GNU/Linux

This looks like a firefox bug. The tooltip is a position:absolute div within the position:relative coordinate span. It should have its coordinate system in the coordinate span, and thus be placed right next to it. Chrome displays it correctly. Let me see if I can find a workaround. --Dschwen 19:18, 27 March 2012 (UTC)

Ok, purge cache and retry (I tested in FF11). I had to explicitly set the 'left' style to 0. Odd. --Dschwen 19:21, 27 March 2012 (UTC)

 Fixed Thanks! —EncMstr (talk) 19:50, 27 March 2012 (UTC)

Great timing. The WIWOSM project is currently broken (just returns garbled binary data, rather than GeoJSON for the overlay objects). --Dschwen 17:17, 27 March 2012 (UTC)

And should be working again. --Dschwen 17:56, 27 March 2012 (UTC)

P.S.: Wikimania 2012 talk

If anyone here is thinking about going to Wikimania in D.C., I submitted a talk about WMA. If it gets accepted I'll be there (finally after having missed so many Wikimanias)! --Dschwen 15:08, 27 March 2012 (UTC)

Quite frequently, I come across old ships. For these articles, should I use the coords of where the ship was built/home-ported, OR the ships final resting place? TiMike (talk) 00:57, 1 April 2012 (UTC)

If there is a guideline, it would be associated with WP:WikiProject Ships, though I don't see one obviously there. The current or final known location seems far more relevant than where it was made. —EncMstr (talk) 01:11, 1 April 2012 (UTC)

Agreed. In my experience it's their final resting place, whether they be the Cutty Sark or the Titanic. --Tagishsimon (talk) 01:12, 1 April 2012 (UTC)

What to do though with ships such as the Carnegie, which burned to the waterline and the remains went to salvage, so it has no 'resting place'? Mikenorton (talk) 08:27, 1 April 2012 (UTC)

There is no "current" location, so no title (nor infobox) coordinates should be used. Use inline coordinates in the article body, for places mentioned. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 2 April 2012 (UTC)

Hello. I wrote a little propose into the page Wikipedia talk:WikiProject Templates#Map templates in two series. What do you think about a merge of the two locator series? Greetings --Tlustulimu (talk) 21:42, 11 April 2012 (UTC)

I welcome your contributions to this discussion: Wikipedia talk:WikiProject Unreferenced articles#Can the Coord template act as a reference in geographical articles?. Regards, Bazonka (talk) 17:47, 12 April 2012 (UTC)

Discussion has arisen, about the accuracy of the coordinates on Birchandra Manu massacre. Please comment at Talk:Birchandra Manu massacre#Coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:23, 12 April 2012 (UTC)

I finished rendering a more detailed basemap, based on OpenStreetMap data last week. Accurate roads are now displayed at the higher zoomlevels (starting with highways, then secondary level roads, all the way down to residential streets and footpaths). The WikiMiniAtlas now has a little globe in the bottom right corner that is always rotated to the current location you are looking at. KML and WIWOSM overlays are also displayed on the globe. Note that this feature needs a WebGL-capable browser (degrades gracefully). lastly the WMA is now resizable through a handle in the bottom left corner (appears on mouseover). For right-to-left languages the handle is in the bottom right corner. --Dschwen 16:45, 11 April 2012 (UTC)

WikiMiniAtlas has stopped working for me entirely. If I click on a globe icon preceding the title coordinates in an article, an empty white box (with a "close" icon) is all that appears. Any idea what the problem is? (I'm using IE7 om Windows.) Deor (talk) 15:26, 16 April 2012 (UTC)

Hm, the oldest IE I have at hand for testing is IE9. Let me see if i can find an old VM. In the meantime could you pleas clear your browser cache and retry. I'm working heavily on WMA and had a syntax error or two slip through into the live version in the last few hours. --Dschwen 16:09, 16 April 2012 (UTC)

Broken for me now as well. I'm working on it. --Dschwen 16:24, 16 April 2012 (UTC)

Fixed. Sorry about that, had a missing en translation string break the whole thing. --Dschwen 16:33, 16 April 2012 (UTC)

Sorry, it's still not working for me (I misspoke, by the way—my IE version is 8; it's Windows that's 7). I've tried bypassing my cache, then purging it, according to the instructions at

WP:CLEAR CACHE. I've even restarted my computer. I've been having this problem for at least several days; I'm not sure exactly how long, though. Deor (talk

) 17:13, 16 April 2012 (UTC)

Ok, then I'll keep looking. Unfortunately it won't before late this evening (mountain time) that I get a chance to find an old IE version. Do you get a script error (yellow warning triangle in the bottom left corner)? If so, could you tell me the error message and line number? --Dschwen 17:32, 16 April 2012 (UTC)

Nope, just a blank white box where the map should be, as I said. Deor (talk) 17:50, 16 April 2012 (UTC)

I'm zeroing in on the bug. I added some checks so it degrades gracefully if the canavas element is not supported. --Dschwen 21:04, 16 April 2012 (UTC)

Ok, with a few more careful checks I managed to get it to work on IE6(!), albeit with quite a bit of feature degradation (but what do you expect from a rudimentary browser like that). So it should work in IE8 now as well. I'll test more carefully later. But if possible check out IE9 (since you have Win7), it is an improvement worth installing (if you insist on using an IE, or are forced to do so). --Dschwen 23:05, 16 April 2012 (UTC)

Hi. I'm sorry if this has been asked 100 times before but I'm wondering how we should handle things that are in two (or more) places. Two infoboxes gives two co-ordinates at the top right (which feels broken). Does each article have a primary (sole?) location and is this the thing in the top right of the article? I've seen separate articles for a site just to give the geodata which feels broken too. To give examples:

Krona space object recognition station - 3 geographical locations, 2 infoboxes. I think it's important to keep the geodata and the link to satellite imagery. How should I handle this?

Here each site has its own stub

Duga-3 (western) transmitter

. This needs to die I think.

One thing 6 locations Dunay radar. Nothing in the top right.

One thing 16 locations Daryal_radar. The click through to geohack satellite imagery is really great but nothing in top right.

15 installations of Dnestr_radar. The satellite photography from Google maps is so good that we can link to each individual radar and talk about it, even where there are five in one station.

Again with good public satellite photography we have 3 items of interest in Sohae Satellite Launching Station. We have a general co-ordinate in the infobox but it'd be nice to export the launchpad location, if we aren't already.

I'd love to have a steer from people on how to handle these issues. Secretlondon (talk) 02:51, 16 April 2012 (UTC)

You can use display=inline combine with name=Name_of_the_location_or_object. This will show coordinates in the text of the article and provide external users some meta data about the coordinate (for example it creates a map label in the WikiMiniAtlas). Better than using dummy articles. --Dschwen 02:55, 16 April 2012 (UTC)

The WikiMiniAtlas is now active on moon coordinates as well, opening up a moon topography map (albedo map available as well) with moon labels only (en.wp has >1100 moon coordinates, german wp has over 9000!). I have upgraded my database and scripts so that addition of further globe types will be easy. I just need base map data for the remaining celestial bodies, preferably in latlon projection already. So if you know of such data, let me know. --Dschwen 04:14, 16 April 2012 (UTC)

We have several suitable satellite images; e.g. {{GeoTemplate/mars}}; see: Category:GeoTemplates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:18, 16 April 2012 (UTC)

Mars is live now, too. Using the Viking images (mdis v1.0, there is a 2.1 with higher resoluition, but I still have to convert that from jpeg2000). --Dschwen 16:10, 16 April 2012 (UTC)

And Venus, and Mercury. --Dschwen 18:50, 17 April 2012 (UTC)

And Io (see Pele (volcano)). --Dschwen 15:19, 18 April 2012 (UTC)

The small size Io map works but when I clicked on full screen, it gave me a map of the Indian Ocean - on Earth. Rmhermen (talk) 01:04, 20 April 2012 (UTC)

Yeah, sorry about that, the full screen mode needs some more attention. I'll fix that in the coming days. --Dschwen 02:40, 20 April 2012 (UTC)

Fixed it. --Dschwen 03:21, 20 April 2012 (UTC)

I've taken up the Welsh GeoVation Challange: here, which is "How can we connect communities and visitors along the Wales Coast Path?" Take a look, and if you like it please vote! I may need your help!! Llywelyn2000 (talk) 16:01, 17 April 2012 (UTC)

I wonder if anyone here is interested in adding locations to these articles?

The concentration camp network in North Korea has been very poorly documented until recently. With the recent release of a report including satellite pictures of these locations (see http://hrnk.org/publications-2/ , http://gizmodo.com/5842124/north-korean-death-camps-shown-in-unprecedented-detail-by-google-earth , and in particular http://freekorea.us/camps ), it should now be possible to add coordinates to the following articles:

• Chungsan_concentration_camp
• Danchon_concentration_camp
• Hamhung_concentration_camp
• Hoeryong_reeducation_camp
• Onsong_concentration_camp
• Oro_concentration_camp
• Sunghori_concentration_camp
• Taehŭng_concentration_camp
• Yongdam_concentration_camp

-- The Anome (talk) 12:02, 20 April 2012 (UTC)

If I click on the coords in Buckbarrow, I get a GeoHack page which includes Ordnance Survey and other British maps. If I click on the coords in Whitfell, the GeoHack page ... I was going to say it didn't include the GB maps at all, but have just found, by scrolling down, that they're there along with many other countries. I can't see a difference in the way that the two pages have their coords listed in {{Infobox mountain}}. Can anyone suggest what's happening here? (And how to get Whitfell to behave like Buckbarrow!) PamD 11:41, 27 April 2012 (UTC)

Hmm, I'm seeing exactly the same sort of GeoHack display for both articles. Perhaps it's some sort of caching issue—have you tried clearing your cache? (In straight uses of {{coord}}, the "Great Britain" list of maps on the GeoHack page doesn't show up unless "region:GB" is included in the template, but that doesn't seem applicable in this case.) Deor (talk) 11:56, 27 April 2012 (UTC)

Please take a look at an example of one of the Welsh mountains here. It would be really good if we could generate this great map automatically, by just changing the Welsh Infobox; the coordinates are in place, so I can't see a problem. Can someone take this further, please? PS We have 700 such mountains (or peaks on the Welsh Wiki-cy), and adding a map to them all would be really good. They have been divided into two pages: north and south. Diolch yn fawr! Llywelyn2000 (talk) 20:15, 14 May 2012 (UTC)

just add the code to the template to display the map. If you want to display a marker then use {{

Template:Location map/Creating a new map template for {{location map}} to use. Keith D (talk

) 21:14, 15 May 2012 (UTC)

Thanks keith. The problem is that I have over 2,000 articles. To "pass in the coordinates from the article" manually would take weeks; can the new Template (e.g. "Template:Location map/Welshmountains) not pick up the coordinates automatically? Llywelyn2000 (talk) 09:01, 18 May 2012 (UTC)

May be the easiest way would be to get a BOT to move the co-ordinates from the {{coord}} template into 2 new fields in the template for the latitude & longitude. Use the 2 fields in the call to the {{location map}} and to {{coord}} (now inside the template rather than article). Keith D (talk) 11:53, 18 May 2012 (UTC)

Great! I've added the map, but I'll place it in {tl|locaton map}} as you suggest. So the bot would have to do the following within the template:

1. add the following line above 'map topograffig':
2. add {{coord}}.
3. Next run of bot: delete the existing line of coordinates <div align="right">{{coord|53|N|4.35|W|region:GB_source:enwiki-osgb36(SH612613)|display=title}}</div>

Will this do the trick? line 2 needs refining, I think.

I think that you need to add to the template something like the following to get the coords to display at top right assuming {{Coord}} operates similar on Welsh wiki.-

{{#if: {{{longitude|}}}|{{Coord|{{{latitude|}}}|{{{longitude|}}}|region:GB_type:mountain|display=title}}}}

For the location map then something similar to (may not have got syntax exactly correct) -

{{location map|Wales relief|label={{#if: {{{enw|}}}|{{enw}}}|{{PAGENAME}} }}|position={{#if: {{{label_position|}}}|{{{label_position}}}|right}}|width=240|lat={{{latitude|}}}|long={{{longitude|}}}|marksize=6}}

You will have to play with this to get best fit by tweaking the map width and the dot size.

The {{Mynydd2}} template blank will then have 3 additional fields (you will have to translate into Welsh) |latitude=, |longitude= and |label_position=. The last one is if you need to adjust the label it puts next to the dot to be top, below or left rather than the default right, that will be a case by case basis but should only affect those with a long name on the right hand edge of map.

The BOT then moves the lat/log from the {{coord}} template and populates the |latitude=, |longitude= and deletes the {{coord}} line. Keith D (talk) 22:45, 18 May 2012 (UTC)

Many thanks for your reply; sorry for not getting back earler! I've now left a reuest for a bot to automate what you suggest here. Many thanks. Llywelyn2000 (talk) 07:55, 27 May 2012 (UTC)

Some good news: TPBot has been approved for the task of adding a |title= parameter to the {{coord}} template in a large number of geographic stubs. the bot is also replacing deprecated coordinate templates at the same time; for example this edit. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:46, 16 May 2012 (UTC)

The source code indicates a lack of experience regex parsing wikitext. Useless flags are being set, it doesn't consider [.+-] as possible coord inputs just [0-9], Infobox coord detection is confused by trailing white-space and show be written broader, and it'll add display=inline,title to multiple coordinates. Finally, I'm unsure if title is always appropriate, once the Firefox article had a inline coordinate for the crop circle. — Dispenser 16:37, 27 May 2012 (UTC)

Within the past few days, the display of WP coordinates in Google Maps has changed for me. For instance, if I click on the coordinates in Monmouth War Memorial and go to Google Maps from the GeoHack page, Google displays the correct location, but with no green arrow marker indicating the spot; and instead of displaying just the decimal coordinates in the search bar, it displays "Monmouth War Memorial (51.813083,-2.711222)". The absence of the green arrow marker is occurring in all cases I have tested, and in some cases (Llangynllo railway station, for example), the Google Maps sidebar is giving a message like "We could not understand the location Llangynllo railway station" (even though the map is centered on the right spot). Does this reflect a change in the way GeoHack is passing coordinates to Google, or is it something on Google's end? Deor (talk) 12:12, 27 May 2012 (UTC)

{{GeoTemplate}} was changed by User:Voomie yesterday. I think the change was intended to show area boundaries which Google deduces from the title of the linked article. I've cross-posted at Template talk:GeoTemplate#Change in behavior of Google Maps drawing attention to your post. — Richardguk (talk) 15:04, 27 May 2012 (UTC)

Thanks for the explanation. Deor (talk) 23:58, 27 May 2012 (UTC)

Note: The change has now been reverted by User:Pigsonthewing. There seem to have been even bigger problems with Google not recognising coordinates for ambiguous placenames. More info at Template talk:GeoTemplate#Change in behavior of Google Maps. — Richardguk (talk) 01:42, 28 May 2012 (UTC)

I've been recording the number of articles with {{coord missing}} tags at User:The Anome/Number of articles needing coordinates. In the last few days, this count has suddenly reduced by about 8,000. This seems such a large change that it must either be the result of a glitch in the category accounting, some change in the template, or massive editing activity. Has anyone seen any recent editing activity, bot or otherwise, which might be responsible for this, in either a good or bad way? -- The Anome (talk) 22:25, 31 May 2012 (UTC)

There were about that many articles on chinese villages deleted. I'll try to find the link to the discussion. --Tagishsimon (talk) 22:55, 31 May 2012 (UTC)

Wikipedia:Administrators' noticeboard/Incidents/User:Jaguar#Deleted --Tagishsimon (talk) 22:57, 31 May 2012 (UTC)

That's a relief. I don't think any harm was done in deleting those stubs, since they seem to have had relatively poor data quality and no extra information other than that we already have in the form of the lists they seem to have been created from, and there shouldn't be any problem in eventually re-creating them when better data is available. -- The Anome (talk) 18:35, 1 June 2012 (UTC)

Maarzaf in Syria is currently the subject of international attention: the BBC describes it as "about 20km (12 miles) north-west of Hama" in an article containing a Google satellite map photo, but no coordinates. Can anyone gelocate this village, given the information in the BBC article? -- The Anome (talk) 21:56, 7 June 2012 (UTC)

The Google image in the news article is of this place: 35°12′14″N 36°33′18″E / 35.204°N 36.555°E / 35.204; 36.555. Whether that's in fact Maarzaf I have no idea. Deor (talk) 22:15, 7 June 2012 (UTC)

I see that TopoMapper does have it labeled as Maarzaf (in Cyrillic characters). I'll stick the coords in the article. Deor (talk) 22:24, 7 June 2012 (UTC)

Fantastic! How did you find it? -- The Anome (talk) 22:26, 7 June 2012 (UTC)

Just scanned around the Google satellite view in the general area northwest of Hama until I saw it. Deor (talk) 22:29, 7 June 2012 (UTC)

Your eyes are clearly better than mine! I've put a request at

al-Qubair. -- The Anome (talk

) 22:32, 7 June 2012 (UTC)

Just a note that Wikimapia now has the group of dwellings at 35°10′46″N 36°33′28″E / 35.1794°N 36.5578°E / 35.1794; 36.5578, south of Maarzaf, labeled as "Maarzaf Al-Qubair". I can't recall whether that label was there yesterday (but I think I would have noticed it), and I don't think we should use an open Wiki as a source; but I thought I'd mention it. Deor (talk) 10:42, 8 June 2012 (UTC)

I agree with you that we shouldn't use Wikimapia as a source, since there's no guarantee of reliability whatsoever, but, if correct, that's an amazing bit of crowdsourcing. -- The Anome (talk) 12:14, 8 June 2012 (UTC)

Update: There's now a second candidate on Wikimapia for the position of the farm: see

Talk:Al-Qubair for details. -- The Anome (talk

) 20:57, 8 June 2012 (UTC)

Perhaps somebody here will be able to help with my query at Talk:Google_Maps#Languages_on_Wikipedia_Layer. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 15:25, 18 June 2012 (UTC)

This one has me stumped (not a very difficult thing to do, I'm afraid). A post on

Would a hierarchy of values make more sense? 'Edu' would be retained to cover all educational facilities, but would include a number of sub-categories which may follow the International Standard Classification of Education and would indicate the level of education provided. Landmark would also be retained, but 'place of worship', 'industrial', 'geological features' etc etc would be introduced as sub-categories. Possibly 'transport' would become a new top level entry containing railwaystation, airport and road. Personally I would prefer Settlement to City as a top-level value, using city as well as town/ village/ suburb/ hamlet to indicate the size or significance of the settlement. It may also be useful to separate out the low-level administrative areas from city into its own category (these seem to be muddled in with city at present).

I realise that in many cases an infobox is available for the article which does contain useful detailed information. However, many articles contain multiple geocodes and geocodes may only be referring to something referred to by the article and not the subject of the article itself. Any thoughts?

-- PeterEastern (talk) 07:21, 7 July 2012 (UTC)

I have updated the above proposal with more detail. PeterEastern (talk) 06:06, 9 July 2012 (UTC)

Similar suggestions have been made periodically over the years, by me as well as others. Past efforts died of neglect or discouragement. Refer to the archives of this talk-page for details.

I agree that the type-system is of uneven precision and very arbitrary. And while it has only slight utility as it stands, it would be very difficult to modify in any way that would make it significantly more useful. As far as I know, type: has but two uses, the first being to establish a default map-scale when neither dim nor scale is specified; the other being to vary the markers used to indicate coordinates on a digital map. Neither use is vital at this time. The default map-scales, while better than nothing, are highly imperfect guesses, and since it is easy to manually adjust the scale of most online map services, the getting initial scale right is seldom crucial. While the Google Maps's Wikipedia layer seems to filter based on coordinate type, I can't point to any modern examples of type: being used to control map markers.

I'm not sure if you're aware that the type-system is used not only in the English Wikipedia, but also in many other Wikimedia projects. Coordinates are copied back and forth between projects by bots, and portions of GeoHack appear to be shared across many projects. Changes to the type-system would therefore impact other projects besides enwiki and so they should not be undertaken without inter-project consultation and (hopefully) consensus.

If the type-system were significantly expanded, it would be an enormous job to apply the changes to the million or so coordinates currently coded in enwiki -- let alone all the others. And if one argues that a bot could make most of the changes, then one must concede that the necessary information is already available to automated tools, in the form of categories, infoboxes, and so on. Which brings me to question of what you hope gain by making the type:s more precise.

So, what would be the benefit of the changes you're proposing? —Stepheng3 (talk) 05:38, 10 July 2012 (UTC)

I don't know what Peter Eastern was thinking, but here are some benefits:

• More intuitive detail description so when entering a new coordinate, I can better guess which feature type to use. For example, lake, sea, ocean, stream, fountain, or pool instead of waterbody. Or instead of "landmark": bike path, road intersection, reservoir, residence, office building, industrial park, city park, marina, neighborhood, public museum, zoo, aquarium, pub, parking lot ....
• More useful icons could automatically appear in
  Wiki Mini Atlas
  , and be associated with coords downloaded to a GPS
• Better granularity of coord type for sources with scrape Wikipedia.
• Better visual verification from a map display: If a barber shop appears in a forest, this is readily identified. But if a trail appears, all is well. But having to use "landmark" for both clutters verification.

—EncMstr (talk) 07:26, 10 July 2012 (UTC)

Thanks for the feedback. I have come to this from a mapping perspective, and am in particular looking at how to improve the cross-referencing between

Flikr introduced this concept in 2009.[1]

Regarding the issue of the hugeness of the task, evidence from OSM is that tasks that can neatly be split either by geography or by sector will motivate people will chew through there bit of the job as long as there is some nice mapping and analysis to show progress. I, for example would sort out all geocoded articles in Suffolk. I know other people who would do other parts of the job. What is interesting is how it could motivate wider cooperation between the huge number of Wikipedia editors and OpenStreetMap contributors (there are 600,000 people signed up to contribute to OSM now).

-- PeterEastern (talk) 10:06, 10 July 2012 (UTC)

The other big counter argument is that types should not mirror the wikipedia category system. And kept as simple as possible. But I agree there is some room for a few more types. Adding more mapicons to the WikiMiniAtlas should not be a problem. --Dschwen 13:22, 10 July 2012 (UTC)

Good news re mapicons. Regarding categories, the problem is that the categories for a coord don't necessarily match with the categories for the article. Personally I think a good solution would be to include a number of additional types, possibly as sub-types in a simple hierarchy and then use the osmid link to pick up all the tags from OSM should the down-stream user be interested. PeterEastern (talk) 16:30, 10 July 2012 (UTC)

As far as I know OSM IDs are not guaranteed to stay constant [2]! --Dschwen 23:28, 10 July 2012 (UTC)

You are correct, but that is a problem that the OSM community needs to address for a number of reasons and is not really a show-stopper. The main times that IDs change in OSM is when a point feature is refactored as a more detailed area feature, for example a school which was first modelled as a node and then later as an area; the other time is when a linear feature is split into two linear features in order to associate different tags with each section and one of them will get a new ID. It is worth noting that contributors to OSM are being encouraged to add wikipedia tags to OSM which link back to the appropriate WP article which will simplify the task of maintaining links between the data-sets if IDs change. I am confident that the issue is a minor one and one which can be addressed by the OSM community, possibly by including the concept of a 're-direct' from an old ID to the new one. PeterEastern (talk) 11:13, 11 July 2012 (UTC)

In response to the comment above about the legalities of deriving geocodes from various sources:

• I distinctly remember listening to a presentation by Ed Parsons of Google (formerly of the OS) at the AGI conference in 2010 where he asserted that it was entirely acceptable to derive geocodes from Google mapping and Google made no claims to those geocodes (as long as you were not doing so in order to create a map of course). He has strong ideas on the issue going back to his time at the OS.[3] If Wikipedia would benefit from a clear response on the issue from Google then Ed may well be able to provide it and someone should email him here.
• Regarding OSM, there is a clear use-case in the new ODBL license allowing people to derive an 'in-substantial' amount of data from OSM without licensing issues (see Geocoding moderate amounts of information using OSM data). If it would be helpful to have formal clarification that the sort amount of derived data for Wikipedia would be 'insubstantial' then we should ask the legal team. Personally I am very confident that it will be ok.
• Regarding use of Bing aerial imagery, there is a subtlety in Bing's arrangement with OSM in that they only give permission for their imagery to be used for creating maps in OSM, not for any other purpose. As such it would be entirely legal under that arrangement to create a node for a feature in OSM and then to derive the geocode for Wikipedia from OSM, but not to grab a geocode for Wikipedia directly from Bing imagery without putting it in OSM. Bing has hugely impressive imagery - I was just looking at some for parts of West Africa where I could see the minaret and domes on a small Mosque and cars on the road. As such there will often be considerable benefit to Wikipedia from Bing imagery, but only by adding the data to OSM (with appropriate tagging of course) which is exactly why Bing provided the imagery in the first place [4].

-- PeterEastern (talk) 07:21, 13 July 2012 (UTC)

In response to PeterEastern:

• On Google, if I'm not mistaken, the OSM FAQ appeard to state the exact opposite. An explicit release from Google for geo-code capture for both OSM and WMF projects would be VERY helpful. If Google allows WMF to perform geo-code capture, then that solves one of the major concerns. The important thing is that any release of that nature would need a formal confirmation in the OTRS permissions queue. Sfan00 IMG (talk) 09:57, 13 July 2012 (UTC)

OSM is a mapping project, and as such it is by its very nature in competition with Google Maps and Google are very unlikely to want that (even though they do support OSM in many ways). WP is different and as it is not a map and doesn't get caught by that issue. I remember Ed Parsons making a very clear statement on derived data at the AGI conference in 2010. Someone would however have to check if it was still valid, but let's not rush to ask him, but instead take a bit of time to discuss if it would be appropriate and the appropriate wording. I don't mind being the conduit, but only with consensus that it is necessary and useful to do so. PeterEastern (talk) 14:24, 13 July 2012 (UTC)

IIRC the Geo-Codes on Wikipedia are amongst other things used to make the WikiMediaMiniAtlas. So it's get slightly more complex. Sfan00 IMG (talk) 16:57, 13 July 2012 (UTC)

• On WikiMapia - It's been held by some in the OSM community that WikiMapia's licensing is also unclear (and in any case the Base Layer is Google), an attempt to clarify this was not resolved. WikiMapia is also user contributed, meaning a concern about
  WP:RS arises. Sfan00 IMG (talk
  ) 09:57, 13 July 2012 (UTC)

I have no views of knowledge of WikiMapia and it's licensing. I would however not recommend that anyone draws any firm conclusions in relation to WP from discussions made by the OSM community in relation to OSM licensing which has its own complexities which are different from WP. In addition, there are virtually no comments made by actual lawyers on OSM's legal talk lists and as such they may not be accurate. PeterEastern (talk) 14:24, 13 July 2012 (UTC)

Noted. In the meantime, It should be possible to find better sources (like the 'BingWashing' you recomend below. ) Sfan00 IMG (talk) 16:57, 13 July 2012 (UTC)

• On Bing, If someone is willing to ask Bing directly about Geo-Code capture, If they were willing to grant OSM a license for what is full blown polygon tracing, I really can't see them objecting to 'Geo-Code' capture limited to single 'pushpins'. Again an explict release from Bing lodged in the permissions queue would be desirable. Sfan00 IMG (talk) 09:57, 13 July 2012 (UTC)

Bing appear to be specifically supporting OSM for strategic reasons in the same way that Intel and Dell support Linux. Bing started their support for open mapping at a time that they may have been worried about not having a map source which didn't come with horrible terms; they may also have liked the depth of data being built in OSM. As such Bing have a business case for supporting OSM (but don't for WP). You can make everyone happy by adding the features first to OSM using Bing imagery and the Bing/OSM license agreement, and then derive positions in WP from OSM using the OSM ODBL license. PeterEastern (talk) 14:24, 13 July 2012 (UTC)

'BingWashing' coordinate data? Hmm.... Sfan00 IMG (talk) 16:53, 13 July 2012 (UTC) Sfan00 IMG (talk) 16:57, 13 July 2012 (UTC)

Can we avoid the term 'Bingwashing' which make it sound dodgy. There is nothing dodgy about using Bing imagery to add content to OSM and Bing are putting a lot of effect and resources into getting people to do just that, as such Bing will be delighted to have more people adding more content. PeterEastern (talk) 19:20, 13 July 2012 (UTC)

Noted... Sfan00 IMG (talk) 19:23, 13 July 2012 (UTC)

Following on from the above discussion, I'd like to suggest that {{Coord unsourced}} be amended so that, like {{coord missing}}, it yields nothing more on the page than a hidden category. Currently it plasters a banner at the top of the article, or else a note by an inline coord. Reason for change: it'd be handy to use the template to mark articles where there's a suspicion about the coord. But it would be a shame to degrade the general user experience by putting graffiti on the article. Wonks of this parish are very used to working from category lists to sort out coord issues. Please support, oppose, and/or discuss below.

I have mixed feelings about this. The current implementation feels overly obtrusive, especially when placed at the top of the page, but OTOH it's analogous to {{Unreferenced}} and that seems logical. Any solution which involves editing the article or its talk-page will generate watchlist noise. A periodic database report similar to Dispenser's or Wikipedia:Database reports/Articles containing overlapping coordinates would avoid this drawback. —Stepheng3 (talk) 12:54, 13 July 2012 (UTC)

As the creator of this template, I've got no objections to it being silent. The concern I had was the startegy of grouping it by date continues.. Sfan00 IMG (talk) 16:58, 13 July 2012 (UTC)

In what circumstances is it intended that this template be used? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 13 July 2012 (UTC)

It was to flag up concerns about {{coord}} use. Sfan00 IMG (talk) 17:55, 13 July 2012 (UTC)

Thank you; but I'm looking for a more specific answer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:26, 13 July 2012 (UTC)

No answer? See also my comment at Template talk:Coord#Unsourced Coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:15, 14 July 2012 (UTC)

Concern - Maybe {{Coord unsourced}} isn't the best term, as someone above mentioned geo-codes are possibly self-verifying.

{{Coord review}} was supposed to be a 'Can someone please check these, I'm not sure it's reliable?" tag, I'd have no objections to being reworked a 'silent' template, provided it grouped by date , and so on... Sfan00 IMG (talk) 19:32, 13 July 2012 (UTC)

I wouldn't mind an 'unsourced' kind of template as long as it was silent in the manner of "coord missing". But I would want there to be good documentation about how to add coord sources and which ways are deemed best. This documentation should be easy to find and easy for "non-template-savvy" people to understand. Among other places, it should be linked to from the edit summaries of the edits that added the template. I've added coords to many hundreds of articles but am still not sure about how best to source them. Usually I'm working on pages about places that are not marked on most maps, online or not (often historical places like

BCGNIS

but then used other references, like say a text description of the location in some book, to tweak the coords (BCGNIS's coords are usually rounded to the nearest minute and therefore often in obviously wrong places (coastal sites marked in the sea, sites along a river in a valley placed on mountaintops, etc)). GNIS coordinates are usually more precise but even so are frequently inaccurate to one degree or another. The coords of river sources in particular are often obviously off. What is needed, if this "coord unsourced" kind of template is going to be used, is clear and thorough documentation telling us how to source coords! Especially when the sourcing is not simply "GNIS". Can the kind of examples I gave above even be sourced within the coord template?

Furthermore, doesn't putting the source within the coord template hide it? Might readers not want to know the coords are sourced and what that source is, without having to edit the page and look inside the codes of the coord template? It is for reasons like this that I have often added coords without using the coord template's source field, instead adding a footnote elsewhere, if possible, or an external link to GNIS or BCGNIS or whatever. On a few occasions I've added a footnote onto the coord's title display, in order to explain a more complicated reference. You can add a footnote, as very briefly described at Template:Coord#Examples, but it is rather ugly, both in terms of the code and the way it looks on the page. It can also be done in geoboxes and at least some infoboxes, as far as I know. Anyway, my point is that if this template is implemented, please also provide easily found documentation about how to source coordinates in all these various ways, and recommend "best practices". Otherwise "coord wonks" like me will often not know how to fulfill the request and just be annoyed.

Also, are we sure it is not okay to use Google Maps and other tools that use Google Maps to acquire coordinates or tweak coords acquired elsewhere? If it really does appear to not be okay, shouldn't we contact Google and ask them about it? After all Google Maps offers a layer of geocoded Wikipedia articles, which, it seems to me, is one of the benefits Google Maps has over some other online mapping apps. I've looked at the terms of use links above and it is still not clear to me that they mean it is not okay to use Google Maps to get coords, or at least to tweak coords acquired elsewhere (like BCGNIS or GNIS). And if it really isn't okay, then tools like GeoLocator, which I've found very useful, are also not okay. I've often gotten coords from BCGNIS and entered them into GeoLocator, then tweaked them slightly because they are almost always obviously off by a bit. I'm skeptical that this practice is not okay. Personally I'd want to be told be Google themselves that it isn't before really believing it. Pfly (talk) 21:19, 13 July 2012 (UTC)

Hmm , Thats a lot of items to consider.. Sfan00 IMG (talk) 21:22, 13 July 2012 (UTC)

On the Google front, the only way to be absolutely sure is for the WMF's legal contact to formally contact their opposite number in Google asking for an explicit statement. That's the only way to be certain. Sfan00 IMG (talk) 21:46, 13 July 2012 (UTC)

See above section for current discussion about seeking clarification from Google. PeterEastern (talk) 02:15, 14 July 2012 (UTC)

As the initial basis of this was a concern that a specifc source wasn't accurate, I propose that {{coord check}} might also be a better alternative title. Sfan00 IMG (talk) 09:20, 14 July 2012 (UTC)

This was what I sent in an e-mail to the PastScape's site maintainer's earlier :

"(not for Publication)

To: English Heritage.

Dear Sir/Madam,

I note that that the following article at Wikipedia http://en.wikipedia.org/wiki/List_of_monastic_houses_in_Herefordshire (and others like it) reference the Pastcape database extensively. Currently this referencing is in the form of in-line citations.

What I would like to do is to do is add the National Monument Record alongside those citations, as this would help readers of the article and others identify specific resources, relating to those monuments. Another item of data stored in the NMR is the location details of the monuments concerned. Whilst the article concerned has location data it would be desirable to update it with the location given in the NMR (which is assumed to be definitive.).

I am reluctatnt however do this at present, because the Pastscape/NMR dataset held by you is not yet available under Open Government License terms, meaning that the current terms of use for the dataset are not necessarily compatible with the Creative Commons Attribution Share Alike style licensing used at Wikipedia.

By Way of comparsion the US NRHP (National Register of Historic Places) database is (as a work of the US Fedral Government) public domain, and because of this Wikipedia is able to make extensive use of it.

I would strongly urge you to consider changing the terms of use for the NMR records on PastScape to the Open Government License ( with the exception of the pictures, whose copyright is clearly held by an external third party in many cases). This would enable the use of a 'definitive' 'reliable' source to create and update articles in Wikipedia and other projects. This by encouraging interest in the heritage you manage is considered a good thing.

..."

Depending on the reply, it might be possible to get the dataset 'unlocked'.

The PastScape records contain OSGB Grid-references for a number of items of UK heratige. Sfan00 IMG (talk) 16:35, 14 July 2012 (UTC)

Courtesy notification: - Template_talk:Coord_missing#Extend_to_File:_namespace Sfan00 IMG (talk) 10:23, 15 July 2012 (UTC)

It's déjà vu all over again at Talk:Manchester_Ship_Canal#Table. Coords. You either love 'em or you hate 'em. --Tagishsimon (talk) 22:17, 19 July 2012 (UTC)

What are this project's thoughts on this new template (Coord unsourced) and its current use (Example: Alaska as of 19:13, 11 July 2012)? Also, what about coordinates currently sourced to Wikimapia being removed completely and replaced by Coord missing—rather than suggesting a reference improvement or something similar (Example: Tavistock Abbey as of 00:10, 12 July 2012)? Sfan00 IMG has been implementing both changes. Am I unaware of a policy or guideline requiring that all coordinates be sourced? I agree that it would be good practice, but it doesn't seem to be mentioned as a priority on any of the coordinate instruction pages. Is there an ongoing discussion somewhere? Thanks. Altairisfar (talk) 02:40, 12 July 2012 (UTC)

Okay, I have found two discussions concerning Wikimapia sourcing, initiated by Sfan00 IMG at Wikipedia:External links/Noticeboard#Wikimapia and Wikipedia:Reliable sources/Noticeboard#Wikimapia. Deleting the actual coordinates still seems to be overkill though. Maybe someone way more familiar than I with coordinate issues should give their two cents in the ongoing discussions? Altairisfar (talk) 03:41, 12 July 2012 (UTC)

I'm on vacation and don't have time to deal with this, especially given the speed at which Sfan00 IMG is working, but someone needs to halt his removal of geotags from articles. Despite the bee he has in his bonnet about Wikimapia, in most of these cases the feature in question is clearly visible in Google or Bing aerial views, and there's no reason to remove the coordinates completely just because the {{coord}} template contains the parameter "source:wikimapia". And here, for example, he broke the locator map in the article's infobox and botched the deletion of {{coord}}. He's working too fast and too sloppily, not even trying to confirm the geotags he's deleting. There needs to be a centralized discussion about this activity in a more visible forum, whether that be AN/I or elsewhere, or there's going to be a lot more {{coord missing}}s for this project to deal with. Deor (talk) 12:44, 12 July 2012 (UTC)

Most coordinates are easily verifiable by clicking through to a map or aerial photo. Coordinates should not be removed unless there is good reason to think they are inaccurate. —Stepheng3 (talk) 15:29, 12 July 2012 (UTC)

Wikimapia isn't necessarily reliable , which was the basis of the WP:RS/N disscussion. If anything directly sourced coordinates that are source:Wikimapia should really by Source:Google as that's the base layer that they come from.

However, Google's Terms of use claim you can't actually extract 'gecodes' from their imaging. Please see [5]. By deriving from WikIMapia (and thus Google) you could be albiet in all good faith be breaching Google's terms. Sfan00 IMG (talk) 15:47, 12 July 2012 (UTC)

I've stopped adding new tags for now as there is a backlog. I'll review the UK based ones I find as I might have a solution for those. 16:14, 12 July 2012 (UTC)

I note that OpenStreetMap got an official permission from Bing to get traces. If someone from Wikipedia was able to get an equivalent 'permission' to use Bing derived GeoCodes in Wikipedia, I wouldn't have an issue with using source:Bing, or equivalently for other imaging/map providers. Sfan00 IMG (talk) 16:14, 12 July 2012 (UTC)

Why not just look for the feature in OSM, where it likely exists as well, and cite OSM? If it's in the wrong place in OSM, perhaps correct it there as well :) —[AlanM1 (talk)]— 01:24, 20 July 2012 (UTC)

Such an action would fall foul of

blogs and open wikis. --Redrose64 (talk

) 13:20, 20 July 2012 (UTC)

Also {{derived geodata}} Sfan00 IMG (talk) 16:17, 12 July 2012 (UTC)

I doubt that Googles terms of use would hold up though. We are talking about obtaining singular coordinate points. That is hardly copying a data base arrangement or compilation. --Dschwen 16:22, 12 July 2012 (UTC)

Sfan00 IMG is IMO very wrong to remove geotags for the reason stated above: that clicking through to maps tends to verify the coord. Removal because wikimapia is not an RS is very pointy behaviour indeed. Whether or not we breach google's ToS is neither here nor there; not least, I question the enforcability of their terms. Bottom line is that Sfan00 IMG should pause his/her campaign and ensure that there is consensus before continuing. --Tagishsimon (talk) 16:24, 12 July 2012 (UTC)

If you think Google's terms are un-enforcable, ask them for permission directly :) Sfan00 IMG (talk) 18:47, 12 July 2012 (UTC)

I'd prefer not to get drawn into a side-issue of google, coords, copyright and fair use. I'm more concerned that you seem to be deleting coordinates because you're not satisfied with the source, when the preponderance of all our experience is that in the majority of cases, the maps to which the coords link verify the coordinate. Per

WP:RS, The guideline in this page discusses the reliability of various types of sources. The policy on sourcing is Wikipedia:Verifiability, which requires inline citations for any material challenged or likely to be challenged. Within the context of self-verifying coordinates, exactly what is the challenge to these coordinates that means they must have inline sources, let alone must be deleted? It's one thing to indulge an obsession for the inclusion of citations to RS, quite another to delete uncontroversial information which does not need a citation, because you're unhappy that the citation points to what you consider to be an unreliable source. --Tagishsimon (talk)

19:04, 12 July 2012 (UTC)

OK.. So you feel 'lazy sourcing' is acceptable? Sfan00 IMG (talk) 19:27, 12 July 2012 (UTC)

No, that's not it, Sfan00. From the top again. Citations are required to support information that might be challenged. Neither the absence of a citation for a geocoord, nor sourcing from wikimapia are sufficient reasons to delete a coord, in a situation in which the coord can be verified by clicking through to any of the tens or hundreds of maps available to us. So, now, tell us: exactly why do you think it is appropriate to remove coords under such circumstances? --Tagishsimon (talk) 22:06, 12 July 2012 (UTC)

For some of the UK items I'm reviewing in the tagging, I'm re-sourcing them based on the text to the OS OpenData StreetView mapping OpenStreetMap made a data layer for here :- http://os.openstreetmap.org. If someone can do a bounding box search on coordinates in the UK, that are technically unsourced. I'll look into using that layer to check them :)

The url structure for the layer, it seems is almost identical to that used for Opetreet Proper.

OpenStreetMap also seems to have created (for the UK) a selection of old maps (with a similiar URL structure) here: - http://ooc.openstreetmap.org

Examples : - Whiteley Village - Which I've just re-cited -

• http://ooc.openstreetmap.org/?lat=51.35037&lon=-0.42747&zoom=14&layers=00B00 - OS 7Th Series
• http://ooc.openstreetmap.org/?lat=51.35037&lon=-0.42747&zoom=14&layers=B0 - OS New Popular (Orthorectified)
• http://os.openstreetmap.org/?lat=51.35037&lon=-0.42747&zoom=14&layers=B0 -OS OpenData Streetview :)

If someone is able to add those to the GeoHack tool :)

Sfan00 IMG (talk) 16:57, 12 July 2012 (UTC)

After further consideration, I'm okay with {{

I'm thinking maybe {{coord unsourced}} also needs a companion {{coord review}} which would enable to me to flag up the WikiMapia codes I have concerns about without actually removing them? Sfan00 IMG (talk) 19:22, 12 July 2012 (UTC)

Hmm, are there any template writers here? I might have a compromise position... Sfan00 IMG (talk) 19:30, 12 July 2012 (UTC)

How long will banners like this persist in the articles to which they are being added? This one looks intended to be a permanent fixture. --Redrose64 (talk) 21:04, 12 July 2012 (UTC)

That particular banner is intended to be a 'fixture'. Sfan00 IMG (talk) 21:14, 12 July 2012 (UTC)

If you think it's better as a side-box or something, please say. Sfan00 IMG (talk) 21:16, 12 July 2012 (UTC)

For what other kinds of information in articles do we include a honking big notice saying that the information is "considered appropriate" by some individual editor? If I were you, I'd just drop this crusade to challenge geographic coordinates, Sfan. Deor (talk) 21:25, 12 July 2012 (UTC)

FFS. Worst. Banner. Ever. Really: have you taken leave of your senses? This has to stop right now. On what planet is it acceptable to plaster tens of articles with a banner asking for the geocoords to be reviewed? Exactly where is there any consensus for so doing? --Tagishsimon (talk) 22:06, 12 July 2012 (UTC)

I'm sorry , I'm not on a crusade. Sfan00 IMG (talk) 22:10, 12 July 2012 (UTC)

If it's really that important to you, create a list of articles with wikimapia sourced coords. Link it to the todo list, above, as coordinates needing to be checked. Stop spamming articles. Stop, especially, with Coord Reviewed. The most important thing about any article is not that Sfan00 IMG has reviewed and sanctified its coord. That sort of crowing banner has no place on wikipedia. --Tagishsimon (talk) 22:15, 12 July 2012 (UTC)

{{Coord review}} should link to maintenance categories :) Sfan00 IMG (talk) 22:20, 12 July 2012 (UTC)

{{Coord reviewed}}} removed from the 3 uses it had, I can't seem to make you happy.

You don't like outright removals. You don't seem to like flagging stuff for review by someone else.

I note you have listed a solution above. That 'list' is what {{coord review}} does. Sfan00 IMG (talk) 22:23, 12 July 2012 (UTC)

If you're going to indulge in ultra pointy behaviour such as adding templates to images I uploaded more than eight years ago [6] [7] please at least have the good grace not to mangle the job such that the template now proclaims that there's no author information.

You must be getting the impression that neither of your templates is welcome, and by your repeatedly flippant answers, you seem to show contempt for discussion. Exactly where is the consensus for decorating articles with this useless tag? --Tagishsimon (talk) 22:27, 12 July 2012 (UTC)

I'm following this discussion, and I'm not getting the impression that the template is unwanted. I am however getting an impression that there is viewpoint that doesn't want to source geo-codes , so that they can be checked against 'specific'sources. Sfan00 IMG (talk) 22:33, 12 July 2012 (UTC)

Flippancy by way of complete and utter disregard for all voices in this discussion but yours? Breathtaking.

As to the second point, to the extent discussed two of us have pointed out that the majority of coords are self-verifying by clicking through to maps. There's no objection to sourcing. There is an objection to your removal of coordinates.

As to the first. No one has expressed any enthusiasm whatsoever for your two banners. Altairisfar raised concerns about your actions. Deor echoed them. Stepheng3 was okay with the use with discretion of an existing template. Deor and I deplored your templates. No voices in support. --Tagishsimon (talk) 22:42, 12 July 2012 (UTC)

Well as I can't seem to convince you otherwise, I'll go revert my edits, something I didn't really want to do. Sfan00 IMG (talk) 22:51, 12 July 2012 (UTC)

Thank you. If you want to redo what you've not in a non-annoying way, follow the lead of {{coord missing}} which bungs articles into a hidden category, through which we can work. It'll achieve the same end without the tears. --Tagishsimon (talk) 22:57, 12 July 2012 (UTC)

Is there a way to add 'date' categories to {{Coord_missing}} ? Currently for some reason a bot groups the {{coord unsourced}} tags into date categories. I'd like this to continue Sfan00 IMG (talk) 23:27, 12 July 2012 (UTC)

{{Coord_missing}} takes up to two areas (countries, setttlements, etc) as parameters. {{coord unsourced}} takes a date parameter, as do most maintenance tags that render as banners. The geographic categorisation of {{Coord_missing}} seems to be immediately useful. Date could be added as a parameter, but I question its utility. It might be interesting to know for how long a template such as {{coord unsourced}} has been waving its banner at the top of an article. But we know for sure exactly how long an article has been without its coordinate: that would be today minus article_creation_date. Why would we want to know when {{Coord_missing}} was added, which would be the effect of dating the template? --Tagishsimon (talk) 23:42, 12 July 2012 (UTC)

I'm not going to delete {{coord review}} because I still think it has a use.. Perhaps it can be reworked into something less confrontational? Same with {{coord unsourced}}. Sfan00 IMG (talk) 23:07, 12 July 2012 (UTC)

The distinction is between templates that hijack the article to pronounce their importance to a mostly indifferent readership which only wants to read the article, versus templates that add hidden categories that are attacked by coord wonks. You really need consensus for the first, much more so than for the second. It would be ideal if there were a standard for coords on articles, such that the concept of a "review" was meaningful and not nebulous, as it is in the (look no links to what I mean by "review") {{coord review}}. {{coord unsourced}} is used sparingly, on less than 500 articles. --Tagishsimon (talk) 23:42, 12 July 2012 (UTC)

{{coord review}} is now T3 - I can't see it having a useful role.

{{coord unsourced}} is only on 500 articles, because I was tagging manually, and hadn't really got started, but your point is STILL valid.. Sfan00 IMG (talk) 00:28, 13 July 2012 (UTC)

Where would be the best place to open a disscussion about which sources are 'authratative' for geocodes? Sfan00 IMG (talk) 00:28, 13 July 2012 (UTC)

Here, maybe, though it tends to be a bit moribund.

WP:RS

would say that as they're self-evidently uncontroversial, they don't need a citation to an RS. Finally - and I must break this to you - there are thousands of coords which were arrived at by more or less painstaking OR, triangulating from any number of odd sources through one or more maps to the discovery of a coordinate: for the truth is, for very many geo-locatable objects, there is no RS for the location specified as a coordinate.

And set against all of that is the understanding that our time might be better spend adding coordinates than arranging the angels on the head of our pin argument about what constitutes an RS for a coord. I've checked through ten or so of the wikimapia coords, and I'm not very alarmed by what I've found; I've seen the same level of imprecision in data shipped in from uber-RS sources such as USGS. --Tagishsimon (talk) 00:47, 13 July 2012 (UTC)

OK, I still hold that gecodes probably should be sourced, but that's a personal opinion Sfan00 IMG (talk) 01:16, 13 July 2012 (UTC)

Yes, Sfan. Ideally all our information (not just geocodes) would be easily verified from reliable sources. However, pushing people around doesn't work well here. A good response might be to lead by example, pitch in and source geocodes reliably when you can. If you wish to encourage others to do so through gentle persuasion, that'd be fine. Unfortunately, your recent actions seem neither gentle nor persuasive.

Let's not make the ideal into the enemy of the good. We still have many, many articles that need coordinates. Like you, the people adding coordinates are volunteers, and most of them do a good job. Please don't come down on them if they happen to be lazy about documenting their sources. —Stepheng3 (talk) 05:47, 13 July 2012 (UTC)

I have been spending some time looking at the quality of geocodes in my part of the world (Suffolk, UK) and have found that geocodes for villages can easily be up to 10km off; another common error is where features in the West Midlands in the UK end in the sea off the Suffolk coast due to various (+/-) errors for longitude, such as describing a place as being -1.2 degrees west (which puts it back east). As such there is clearly a job to be done to improve accuracy of coordinates and to correct errors. That being said having something that is nearly right is much better than nothing so I would add my voice to the calls to not remove geocodes at this point for lack of a hig-quality source. PeterEastern (talk) 07:21, 13 July 2012 (UTC)

Hi folks, I'm seeing "Expression error: Unrecognised punctuation character" in the infobox for Wilmington, Delaware and Dover, Delaware (placing the locator dot on the state map). Is this a good place to report this, and if so, anyone here have the template fu to fix the problem? -- RobLa (talk) 16:34, 22 July 2012 (UTC)

This edit should sort it. --Redrose64 (talk) 18:05, 22 July 2012 (UTC)

I'm currently working on a massive expansion of the zoom in WikiMiniAtlas through client-side tile rendering. Check out the demo video. There are still a few minor glitches to work out, but in principle it works. At high zoomlevels the tiles are not pre-rendered images but raw OSM data is transmitted to the browser and rendered using canvas elements. This allows for reusing data while zooming in, making zooming in very responsive, have progressive data loading (the video shows building outlines being loaded incrementally). There is a ton of awesome things that could be built on this (I have all the meta-data, so I could make streets and building clickable, etc.). --Dschwen 05:33, 26 July 2012 (UTC)

Are we streaming the data from OSM itself? Secretlondon (talk) 14:17, 26 July 2012 (UTC)

I'm getting the data from an OSM mirror on the toolserver, which may be a few minutes behind. But more importantly I'm currently cacheing the database query results. The query per tile may take a few seconds and cacheing makes the map way more responsive in regions that have been visited already (plus I do not want to put too much strain on the DB server). However there is an action=purge option in my JSON tile extractor script. I'd have to add a GUI option in the WMA, then it would be possible to refresh my serverside cache and have absolutely up to date OSM data. --Dschwen 14:58, 26 July 2012 (UTC)

• With this revision, could you also adjust the aspect ratio so that non-equatorial areas are rendered with approximately proportional latitude and longitude distances? I believe that, at present, a
  plate carrée projection is used with a fixed ratio that significantly distorts mapping for northerly and southerly latitudes at sub-global zoom levels. — Richardguk (talk
  ) 15:03, 26 July 2012 (UTC)

  This revision does not directly allow me to do that. The issue is the back-end infrastructure that serves the clickable labels. It stores a set of labels per tile. And tile is defined in lat lon. I am slowly working toward making it projection independent (or at least adding mercator as an option). My not quite that serious reply to the latlon vs. mercator issue usually is: "At least lat lon only distorts in one direction, mercator distorts in two directions!" ;-) --Dschwen 16:17, 26 July 2012 (UTC)

  OK. I was hoping that it would be relatively simple to switch to an equirectangular projection, because browsers already support independent horizontal and vertical linear image scaling, so the existing PNGs could be displayed with width values scaled down by the secant of the median mapped latitude. — Richardguk (talk) 16:33, 26 July 2012 (UTC)

  Yeah, I was thinking about using css transforms, but it would change the thickness of lines depending on their orientation. Hmm, something to think about. --Dschwen 16:54, 26 July 2012 (UTC)

Testdrive it now

At http://toolserver.org/~dschwen/wma/index_dev.html you can testdrive the new zoomlevels. The demo starts at the last pre-rendered tile-layer, so zoom in once to get the client-side rendered tile, and then once more to see buildings pop up. I worked on the map styles a bit. You can see transparent rail lines which indicate subways. A few more buildings should be showing up as well. This will not work in old Internet Explorer browsers (the map just won't zoom in further), since IE up till IE8 did not support the canvas element! Let me know if you have any suggestions. --Dschwen 18:51, 26 July 2012 (UTC)

I clicked on a label and got an article - when I clicked to go back I ended up back in New York rather than where I started. What are the blue dots near Rome? Secretlondon (talk) 20:00, 26 July 2012 (UTC)

The blue dots are other coordinates on the page. You can click the dots and the page will scroll to where the coordinate appears in the text. Check it out on List of volcanoes in the United States. --Dschwen 21:15, 26 July 2012 (UTC)

Supporting the back button to restore the exact state of the WMA on a page when coming back is not trivial. I've been told recently that this might be a desirable feature though. I'll look into it. --Dschwen 21:18, 26 July 2012 (UTC)

I got the images by selecting from commons, rather than from English wikipedia. However it's mapped things that have camera locations in the EXIF which are not of things that should be geolocated. For example I took a picture of a modem and it's appeared on the map. This is probably a commons problem but it means that people could locate the flat I took the photo in - which is a privacy concern. Also no-one looking for a picture of that area would want a picture of a modem. I need to strip any geolocation stuff in the EXIF of anything I've uploaded to commons - I didn't pick up it was a problem until now :( Secretlondon (talk) 20:09, 26 July 2012 (UTC)

Well, yeah. If you make the data public it will be picked up by someone eventually. This is a commons problem, and actually the responsibility of the uploader. --Dschwen 21:17, 26 July 2012 (UTC)

Well I wasn't aware that my phone was doing that - and I'm pretty geeky. I'm sure your intention isn't to map contributors' houses anyway. Secretlondon (talk) 21:29, 26 July 2012 (UTC)

No, its not. But don't you put new uploads on your watchlist? There is a bot going around daily that extracts the GPS data from the image and put it onto the file page as a location template. A toolserver user called dispenser then extracts all coordinates and makes them available in a database. I fetch coordinates from that database. I have no way of knowing whether the geocoding was intentional or a mistake. --Dschwen 21:36, 26 July 2012 (UTC)

So if I remove the template from domestic photos the location info will go away? Secretlondon (talk) 22:14, 26 July 2012 (UTC)

Yeah, but keep in mind that the location data in the image file is still publicly accessible! --Dschwen 23:30, 26 July 2012 (UTC)

A lot has been going on in WikiMiniAtlas development recently. At Wikimania in DC I met Brian Jacobs, a user interface designer who made a ton of suggestion on how to improve the WMA user interface. The menu redesign is fully based on some of these suggestions. Also User:Dispenser has been enormously helpful with lots of suggestions and a rewrite of the backend database preprocessing (to make sure the data is even more up to date). When zooming in labels/thumbnails do not disappear but existing labels are displayed and more labels incrementally loaded. As a big improvement I have developed a client-side tile renderer, which increases the available zoomlevels substantailly (more than OpenStreetMap, GoogleMaps, or Bing Maps). Based on this infrasructure I was able to develop a 3D wireframe buildings display, which can currently be tested in the development version (see screenshots). --Dschwen 19:26, 31 July 2012 (UTC)

• 
  Downtown Chicago with 3D buildings
• 
  Petronas Towers (complex 3D building geometry)
• 
  Experimenting with the start_date tag to enable time dependent maps
• 
  Improved commons thumbnail mode
• 
  Deep Zoom (scalebar is 5m, still not the maximum zoom level)

Hello,

I'm not sure what I'm doing wrong, but I cannot get the 51.474621,-0.204259 coordinates to work for:

• {{Coord|51|47|46.21|N|0|20|42.59|W|display=title}} - when I click on the coordinate at the title and try and view a map it goes to another location in Essex with a different coordinate
• Figure out what map to use for London so it will show in the Infobox (right now I'm using England, which will be ok - but London would be nicer)

Would someone please help me?--CaroleHenson (talk) 17:41, 11 September 2012 (UTC)

Oops, now it goes to 51.796169,-0.345164 in Hertfordshire.--CaroleHenson (talk) 17:46, 11 September 2012 (UTC)

Do not just shoehorn decimal degrees into a degree/minute/second format, this will give you an unexpected result. Try

• {{Coord|51.474621|N|0.204259|W|display=title}}

--Dschwen 17:56, 11 September 2012 (UTC)

Oh, wonderful! I didn't know I could do it that way! Works like a charm!

Is there any way I could use another map in the Infobox other than England that would zoom in a bit more to the location? I've tried other maps, but I just get expression errors in the Infobox.--CaroleHenson (talk) 18:03, 11 September 2012 (UTC)

Never mind, I found the right list of maps. Yeah! The pushpin part isn't working now, but I've done the best I can. Thanks for the coord help!--CaroleHenson (talk) 18:50, 11 September 2012 (UTC)

The d/m/s coordinate system is base 60, not base 100: that is to say, one minute is one-sixtieth of a degree, and one second is one-sixtieth of a minute. Thus, a latitude of 51.4742 is not the same as 51°47'42", so you cannot simply split the coords into groups of two digits. Your attempt to use 51°47'42" was being interpreted as 51.795, which is above the upper limit for {{Location map Greater London}} which can only go as far north as 51.72. --Redrose64 (talk) 19:06, 11 September 2012 (UTC)

Ah! That helps a lot! And, while I was trying to word where on the map the pushpin should go (in the caption) I saw you fixed the way the coordinates are entered in the article so it works. I've been monkeying around with this for awhile and it's very much appreciated!--CaroleHenson (talk) 19:25, 11 September 2012 (UTC)

The Countryside Council for Wales makes available boundary files in mapinfo .TAB and ESRI .shp formats, for a range of entities such as SSSIs, AONBs, etc...should anyone fancy putting together {{Attached KML}} files for the many Welsh SSSI articles created by Dr. Blofeld. --Tagishsimon (talk) 23:31, 12 September 2012 (UTC)

How do I specify coordinates for a forest? In particular, Iwokrama Forest, which has in its text boundaries in terms of latitude and longitude, but probably fairly roughly. --DThomsen8 (talk) 01:40, 15 September 2012 (UTC)

Pick a spot somewhere near the middle of the forest,

don't be overprecise, and make sure that you have type:forest specified; preferably the appropriate ISO 3166-2 country or region code as well. For the particular case of Iwokrama Forest I would put {{coord|4.5|N|59.0|W|type:forest_region:GY|display=title}}; this will show 4°30′N 59°00′W / 4.5°N 59.0°W / 4.5; -59.0 at upper right. --Redrose64 (talk

) 15:18, 15 September 2012 (UTC)

When the minutes and seconds part of co-ordinates are less than 10, should we represent these with leading zeroes? For example: 21°0′32″S 6°18′5″E / 21.00889°S 6.30139°E / -21.00889; 6.30139 (without); and 21°00′32″S 6°18′05″E / 21.00889°S 6.30139°E / -21.00889; 6.30139 (with). And should we take this a step further and add leading zeroes to the degrees too? E.g. 21°00′32″S 06°18′05″E / 21.00889°S 6.30139°E / -21.00889; 6.30139 or even 21°00′32″S 006°18′05″E / 21.00889°S 6.30139°E / -21.00889; 6.30139. (021°00′32″S 006°18′05″E / 21.00889°S 6.30139°E / -21.00889; 6.30139 doesn't seem logical though.) Thanks, Bazonka (talk) 12:12, 4 October 2012 (UTC)

My vote: No. Doesn't do anything for me. --Tagishsimon (talk) 12:32, 4 October 2012 (UTC)

Personally, I don't think it matters much, and I certainly don't change the usage in an article unless I'm revising the coordinates for some other reason. I've noticed that the leading-zeroes-for-degrees style (e.g., 21°00′32″S 006°18′05″E / 21.00889°S 6.30139°E / -21.00889; 6.30139) is used mostly in airport articles; perhaps this reflects usage in the aviation community? Deor (talk) 14:17, 4 October 2012 (UTC)

Yes that's what I was thinking. As long as there's no inconsistency in an article, then it doesn't really matter. I only raised the matter here in response to this diff where User:98.67.96.230 said "Geographical coordinates in degrees & minutes are always given in four digits, even if they are something like 30 deg. 00 min. It has been this way for centuries." Bazonka (talk) 17:01, 4 October 2012 (UTC)

My personal style is to include them in minutes and seconds, but not degrees, because of dealing with non-delimited data where it was necessary to align the columns (e.g. 30201 for 3°2'1"). I'll note that, if you set your stylesheet to always render both DMS and decimal degrees, the one that was converted does not show leading zeros. I'll also note that there is at least one environment (maybe one of the UNIX utils like awk) that interprets numbers with a leading zero as octal (making 08 and 09 invalid numbers). However, I don't change existing values unless I'm editing for another reason, and don't think there should be a guideline that would suggest that people make these unnecessary (IMO) edits. —[AlanM1(talk)]— 17:09, 4 October 2012 (UTC)

I believe that the convention for including leading zeroes by the aviation community is to do with the problems associated with radio communication in poor reception conditions. If you always give the same number of digits regardless of your position, then the person who receives your call will be expecting that number of digits, and if they receive fewer, they know that one or more have been lost, and will request retransmission. --Redrose64 (talk) 20:04, 4 October 2012 (UTC)

I posted this in WP Maps and then realized this might be a better place for it: Today I find all the pushpin points placed on File:Uruguay location map.svg moved to the south. I checked with other location maps, like File:Greece location map.svg and I think I see in all of them a deviation of pushpins. Is this visible to all? Was there some change lately that could have this effect? One example as seen at the time I write this is that the coordinates of kilometre 0 of Montevideo Department dispay in the water, though when I placed them 3 days ago, the pushpin was exactly where it should be. Hoverfish Talk 12:27, 19 September 2012 (UTC)

I think that this is to do with the recent switch from XHTML 1.0 to HTML 5.0 - might be best to notify

WP:VPT

.

I copied the relevant code from the page source of Montevideo Department as served by MediaWiki - all the <div>...</div>, <a>...</a> and <img /> elements, plus some more - to a "blank" HTML doc and saved it - it displayed correctly. Then I added one line at the top, pinched from our latest served HTML - <!DOCTYPE html> - and upon saving and reloading, the dot shifted downwards by exactly the same distance as the error seen at Montevideo Department. --Redrose64 (talk) 20:01, 19 September 2012 (UTC)

I've posted this at Wikipedia:Village_pump (technical)#HTML 5 snafu - pushpin points moved south. --Tagishsimon (talk) 20:23, 19 September 2012 (UTC)

Also in National Constitution Center in Pennsylvania. Jim.henderson (talk) 20:26, 19 September 2012 (UTC)

And

170-176 John Street Building in New York City, again on the wrong side of a river. Jim.henderson (talk

) 20:38, 19 September 2012 (UTC)

Problem solved. See above mentioned VPT discussion. Hoverfish Talk 23:47, 19 September 2012 (UTC)

Not so fast. The problem has been solved in one instance of a map template. There is as I write, another template declared as having the problem, and there are possibly many other templates affected. Hoverfish is right that the general cause & solution has been identified. --23:53, 19 September 2012 (UTC)

Oops, I neglected this after the problem went away, which was about a day after these posts. No idea why the delay, but belated thanks to whoever repaired it. Jim.henderson (talk) 12:28, 6 October 2012 (UTC)

Resolved

I don't really know whether anyone is watching Template talk:Infobox Maldives, so I thought I'd see if any template-savvy editor here might address the problem I brought up there. Deor (talk) 13:42, 7 October 2012 (UTC)

I just wanted to drop a link to a logo proposal I contributed for the upcoming WikiVoyage thingie, and it's been suggested that it would fit better with an atlas of some sort, so I thought I would put it here and ask for thoughts. So: meta:Travel_Guide/Logo#Option_25; Thoughts?
--

20:45, 26 October 2012 (UTC)

Parade coordinates

Someone placed the coordinates missing template on a page for a parade. I'm curious of the purpose of coordinates in articles. This parade happened only periodically through the years, and followed different routes in downtown Milwaukee. But a couple of times was outside of Milwaukee. Would providing coordinates be helpful? What point should I use for these coords? Beginning or end? Most common throughout the years? What kind of precision do we require? Should I just pick a random spot in the downtown area? -Freekee (talk) 01:45, 2 November 2012 (UTC)

Geocode using {{Attached KML}} with a time-dependent KML file that can be animated in Google Earth ;-) (only half-kidding!) --Dschwen 03:29, 2 November 2012 (UTC)

More seriously, an article can (and often should) include more than one set of coordinates. My inclination would be to start with the staging area of the most recent parade, then work back through prior parades, then (if still motivated) add endpoints or reviewing stands. Note that the article was tagged by The Anomebot2, a "bot". Questions about the bot's behavior go to the bot's talkpage. —Stepheng3 (talk) 06:02, 2 November 2012 (UTC)

New WikiMiniAtlas feature

Click anywhere on the WikiMiniAtlas map to identify objects under your mouse pointer. This works with buildings, artwork, streets, parks, etc. The name of the object (or address of the building if no name is given) will show up at the top of the WMA window. For public artworks the name of the artist and the colloquial name of the piece will be given as well (if present in the OSM DB). --Dschwen 00:50, 7 November 2012 (UTC) P.S.: you need to be at a high zoomlevel for this to work (so no IE < 9 yet). --Dschwen 00:52, 7 November 2012 (UTC)

No coordinates needed template?

So as I've been culling out missing coordinates for various articles, I see the coordinates missing template in different articles which certainly do not need coordinates. Articles such as concepts or programs, etc., where no geographic location could ever be added. From my quick review, it looks like a bot has added the template. Well, is there a template we can add to stop the bot from adding such templates? If so, I ask that it be posted on the Project page. If not, I suggest that a knowledgeable editor provide one. Thanks.--S. Rich (talk) 03:58, 7 November 2012 (UTC)

The Anomebot2 is currently the only bot (that I know) that adds {{coord missing}}. It is coded such that it will not revert the removal of the template. Articles are erroneously tagged, for the most part, because they live in a category that looks as if it would contain geo-coordable articles. It follows that should a new bot attack this task, it would be likely to make much the same errors. On that precautionary basis you could try to build a case for such a tag. Equally the false positive rate is (consults elbow) pretty low - judged on a few years of watching this page. And I tend to doubt that many editors would pick up the habit of tagging false positives. So there are reasons against - the templates are cruft against a foreseeable but not likely in the near future development. --Tagishsimon (talk) 04:18, 7 November 2012 (UTC)

I've made a comment on Anomebot2's talk page. This is a technical area far beyond my keen. But if the bot does not repeat the "attack" on articles which get templates removed, that's fine. Perhaps a note on Anomebot's page, explaining this feature will be fine. Also, notes on the Project page giving such an explanation will be helpful. Thanks so very much!--S. Rich (talk) 05:34, 7 November 2012 (UTC)

Anomenbot2 has replied to my inquiry. Basically the bot remembers what pages it has "attacked", so manual removal of coordinates missing templates takes care of the problem. (There are exceptions, e.g., when an article is renamed.)--S. Rich (talk) 14:12, 7 November 2012 (UTC)

Radio Stations

I have a few questions relating to adding coordinates to articles about radio stations. Should they be added at all? How specific should they be? Should they point to the radio station headquarters, where it broadcasts from, or the general location where it is broadcast to? Anything else that I should know about adding coordinates to radio stations would be really helpful. Thanks. --qwekiop147 → talk 05:53, 10 November 2012 (UTC)

Well, here's a lead. The GNIS lists towers for radio and TV stations. For example, see U.S. Geological Survey Geographic Names Information System: KUNA-AM (Indio). (As internet (and Sirius/XM) radio becomes more and more available, these towers will become artifacts.)--S. Rich (talk) 06:38, 10 November 2012 (UTC)

IMO, for traditional AM (VLF) and FM (VHF) broadcast stations, the transmitter building, antenna, or center of or one element of an antenna array, are reasonable. AFAIK, GNIS is not updated well/often. For US stations, the FCC is a better source:

• AM stations
• FM Stations

Note that the queries return, first, the "station co-ordinates" which are in

datum for WP, it's worth checking them against satellite imagery to be sure – many licensees do not understand the difference and use whatever is convenient, which may often be a poorly-scaled value from an old topo map. Of course, you also need to be reasonably certain of the satellite imagery's accuracy, which should be decent in most of the continental US, but worth verifying elsewhere. —[AlanM1(talk

)]— 07:33, 10 November 2012 (UTC)

Also note that when you add coordinates to the "coordinates" field in {{Infobox radio station}}, the displayed infobox shows them as "Transmitter coordinates", so in those cases they definitely should be the coordinates of the transmitter/tower. Deor (talk) 09:03, 10 November 2012 (UTC)

Okay, thanks everyone! --qwekiop147 → talk 20:32, 10 November 2012 (UTC)

I have another question. Is there a similar site to the FCC one but for Canada? --qwekiop147 → talk 20:04, 11 November 2012 (UTC)

British Geological Survey link

Is it possible for the UK geohack list to include a link to the British Geological Survey, to give geological maps from the coord map links? BGS provides various publicly accessible ways into their data, which includes a simple URL version. For example central Sheffield will look like this http://www.bgs.ac.uk/data/services/mapCreator/WmsMap.html?mapCentreLat=53.383611&mapCentreLong=-1.466944&mapZoom=14&boxWidth=800&boxHeight=450&geologyType=bedrock50k&mapType=HYBRID, which I would guess could have the relevant variables slotted in to it. More details on usage and options are here. RobinLeicester (talk) 20:19, 23 November 2012 (UTC)

I'll do that, shortly. There's a lag, so it might not be live for a few hours. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:35, 23 November 2012 (UTC)

OK, that's done. For future reference, the template is {{GeoTemplate}} and you can leave requests on its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:47, 23 November 2012 (UTC)

Thanks - for response and template guidance. RobinLeicester (talk) 23:50, 23 November 2012 (UTC)

That's now live; please test it. I didn't pass a zoom parameter, because geology tends to be on a large scale. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 24 November 2012 (UTC)

Liason with Wikivoyage?

en.wikivoyage has the "Geo" template (and now also the "GeoData" template, which I've just ported from de.wikvoyage), which does a job very similar to that of {{coord}} here. Would anyone be interested in starting to populate wikivoyage with geodata taken from Wikipedia, to fill in its articles which are currently missing coordinates? -- The Anome (talk) 12:01, 25 November 2012 (UTC)

Yes, but perhaps that's a job for a bot? Does the "GeoData" template include a geo microformat? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:28, 25 November 2012 (UTC)

I don't know: but it could easily be updated to create one, if it doesn't already. -- The Anome (talk) 17:43, 25 November 2012 (UTC)

Update: I've now found the right place for this, here -- The Anome (talk) 21:57, 25 November 2012 (UTC)

I've now geocoded about 7000 Wikivoyage articles. I can do quite a lot of the others, too, but I have to modify my code a bit first to take into account the different structure (breadcrumbs, not categories) and much sparser article set. -- The Anome (talk) 00:13, 7 December 2012 (UTC)

Sorting of coord problem pages

Can someone use {{Namespace Greek}} in the coord template error categorisaion key to help sort the wheat form the chaff. Rich Farmbrough, 21:59, 16 December 2012 (UTC).

I rather think that's a bit late in the day; it would mean invalidating the cache for millions of articles - and the job queue is through the roof already. --Redrose64 (talk) 22:20, 16 December 2012 (UTC)

No the category is full of noise, indeed it is 90% noise now. The job queues can run up to "several million" entries without cause for concern, we are told, and each entry represents, I believe 500 pages. Therefore the impact should be minor - a million articles would be 2,000 entries compared with the recent peak of about 6 million, which are being processed at about 150k items per hour - essentially adding about 45 seconds to the current 24 hour backlog. Rich Farmbrough, 22:01, 18 December 2012 (UTC).

Please see also the comment I left at Template talk:Namespace Greek#Discrepancies. --Redrose64 (talk) 22:56, 18 December 2012 (UTC)

Why is coord broken?

Why is it that

{{coord|45.48|N|73.04|W|type:mountain_region:CA-QC|format=dms|display=inline}}

displays

45°29′N 73°02′W / 45.48°N 73.04°W / 45.48; -73.04

instead of

45°29′N 73°02′W / 45.483°N 73.033°W / 45.483; -73.033

like I expected? Is it a bug caused by a recent change to a subtemplate of {{coord}}?

This problem breaks pretty much all coordinates in {{

Infobox mountain range}}. I hope someone here knows how to debug it. Thanks! —hike395 (talk

) 03:09, 18 December 2012 (UTC)

Agreed. This is a high priority bug! I suspect that this edit needs to be reverted. —Stepheng3 (talk) 06:06, 18 December 2012 (UTC)

I think that the problematic test does not call {{coord/dec2dms/dms}}. That template is fine. Instead, it calls {{coord/dec2dms/dm}}, which has not been updated for whatever mysterious change there has been to the mod function:

<!--pre tags added post-TFD of the templates below; see TFD 16 May 2022-->
:::{{coord/dec2dms|45.48|N|S|dm}}
:::{{coord/dec2dms|-73.04|E|W|dm}}
:::{{coord/dec2dms|45.48|N|S|dms}}
:::{{coord/dec2dms|-73.04|E|W|dms}}

I will investigate further. —hike395 (talk) 06:37, 18 December 2012 (UTC)

Later: The problem was that {{coord/dec2dms/dm}} has not been fixed yet. The fix to {{coord/dec2dms/dms}} is just fine. I proposed a fix to {{coord/dec2dms/dm}} at Template talk:coord. Thanks for pointing me in the right direction. —hike395 (talk) 06:59, 18 December 2012 (UTC)

(e/c) Sorry, but I didn't have much time to explain my actions last night. The problem is caused by a change to the functionality of the mod function in the Mediawiki software. Previously it was non-standard, but has now been fixed. Unfortunately, this screws up anything that relied on it being non-standard - as the coord template seems to do. There is a simple way solution though: expressions including a mod b should be replaced with trunc(a) mod trunc(b) (or trunc(a) mod b if b is already an integer). This problem arose last week on with the

run!

07:01, 18 December 2012 (UTC

I looked at your fix, reverse-engineered it, and applied it to {{coord/dec2dms/dm}}. It's all good. It may be that all other subtemplates listed at {{coord/dec2dms/subdoc}} need the fix: I have not looked yet. —hike395 (talk) 07:05, 18 December 2012 (UTC)

Later: Indeed, {{coord/dec2dms/dm1}} and {{coord/dec2dms/dms1}} also need fixing —hike395 (talk) 07:08, 18 December 2012 (UTC)

I'm going off-line for a while, so flag up any changes with editrequest.  An

run!

07:12, 18 December 2012 (UTC)

I found that the dm rounding was broken (2'28" was being rounded to 3'), so I fixed both the rounding problem and the mod problem in one proposed edit. Interested editors are welcome to check my solution, as detailed at Template talk:Coord. —hike395 (talk) 09:22, 18 December 2012 (UTC)

GeoGroupTemplate debugging

Here is a page

GeoGroupTemplate

}} to produce the two useful maps. Perfick!

I am populating

GeoGroupTemplate

}} and I just get error messages about a corrupted data file. What is happening?

I have done a character by character comparison and fail to see a difference. The Coord links all work. I have tried inserting content from the Yorkshire page into the Stockport page and previewing and running {{

GeoGroupTemplate}}- it ignores the new content and drags back an image from a cache. Any ideas? Thought I would share this. --ClemRutter (talk

) 10:52, 18 December 2012 (UTC)

I suspect that the KML for each page is cached and that it is not being updated promptly, perhaps due to the unusually long Help:Job queue backlog. —Stepheng3 (talk) 17:49, 18 December 2012 (UTC)

Suspect it will catch up in the end. If I put usecache=0 instead of the usecache=1 at the end of the search string (before the blue magnifying glass button, then click the button) it then brings up a reasonable map and list. I often have to use this trick when changing page with coordinates for KML. Oosoom ^Talk 18:00, 18 December 2012 (UTC)

Home and dry. Just to make the technique clear for those of us with multiple blue magnifying glasses- On the template click on the Google map link. Up comes a map with error message- go to the browser searchurl line (top left) change the address to https://maps.google.com/maps?q=http://toolserver.org/~para/cgi-bin/kmlexport%3Farticle%3DList_of_cotton_mills_in_Yorkshire%26usecache%3D0 from ....re%26usecache%3D1 or if it is in plain text try putting usecache=0 instead of the usecache=1. That line needs to be prominent in the documentation-- so I have been bold rather than wait for Christmas. --ClemRutter (talk) 20:18, 18 December 2012 (UTC)

GeoData deployed

Hi, the GeoData extension announced here finally went live! So far it's mostly in data collection mode, the only enabled function is to retrieve page coordiantes (example). I've initiated data population with this edit, it should take job queue some time to process all the pages using this template. Pages with coordinate problems are tracked by Category:Pages with malformed coordinate tags, example fix. The next step would be to enable spatial searches (find pages around the given point) once we have the hardware for it. Max Semenik (talk) 07:50, 6 December 2012 (UTC)

Something I didn't see mentioned was the notion of precision. When specifying coords, I'm careful to use (per MOS) the correct precision for the size of the object, which is usually units of about 1/10th the smallest dimension. E.g. a city that is 20x20 km gets decimal coords with three decimal places (~1.1 km precision) or degrees and minutes (~1.8 km precision). It might be useful to store the precision used in the article, something like:

precision :=
  If (seconds)
   "S" + max(decimals in longitude secs, decimals in latitude secs)
  Else If (minutes)
   "M" + max(decimals in longitude mins, decimals in latitude mins)
  Else
   "D" + max(decimals in longitude degs, decimals in latitude degs)
  Endif

Alternatively, the actual precision (in meters) of the latitude and longitude could be calculated, which is obviously more computationally expensive, but could avoid consumers having to do the calculation. There is also the issue of how this relates or conflicts with the scale param. —[AlanM1(talk)]— 23:26, 6 December 2012 (UTC)

Since GeoData stores the information about coordinates and POI type in the same form as it's entered in articles, reusers will be able to decide themselves which accuracy to use. Max Semenik (talk) 09:31, 7 December 2012 (UTC)

What about throwing an error when the precision between latitude and longitude don't match? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:24, 7 December 2012 (UTC)

What if some article is located precisely at 12.34567° N 23.000000° E? Max Semenik (talk) 13:19, 7 December 2012 (UTC)

You specify appropriate number of decimal places per

I knew to be defined as exactly 2° W. If I had put |longitude=-2 that would have implied that the station lay at any point between 1.5° W and 2.5° W. --Redrose64 (talk

) 15:07, 7 December 2012 (UTC)

Anyone? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 24 December 2012 (UTC)

Devil's advocate: Is inconsistent lat/lon precision really a significant and identifiable problem? Wouldn't a tracking category be dominated by trivial cases where people had dropped significant trailing zeroes or where decimalised sexagesimal fractions lead to recurring decimals in one coordinate? — Richardguk (talk) 11:07, 24 December 2012 (UTC) (Also, at extreme latitudes, the relative significance of longitude properly differs; though that would not be relevant to the vast majority of inconsistently specified coordinates. — Richardguk (talk) 11:24, 24 December 2012 (UTC))

Excellent! Glad to see this rolled out. Will there also be dumps of the data? User:Dispenser currently makes some dumps by regex-scanning the externallinks table using ghel, but an export from GeoData would be a more direct route. --Delirium (talk) 00:04, 7 December 2012 (UTC)

Yes, we will add this to dumps when things stabilize. Max Semenik (talk) 09:31, 7 December 2012 (UTC)

Longitudes on astronomical objects

One of the conventions for expressing locations on astronomical objects is to use east longitudes up to 359°59'59" rather than the east-west system. Currently, such coordinates have been showing up with error messages, so I've been converting them to equivalent west longitudes; but is there some way of avoiding these error messages for non-Earth globes in the first place? Deor (talk) 15:10, 11 December 2012 (UTC)

Actually, the IAU longitude conventions vary from globe to globe. Based on a prior conversation with MaxSem I was expecting GeoData to respect those conventions. If it doesn't, then We Have Work To Do. —Stepheng3 (talk) 17:56, 11 December 2012 (UTC)

I don't know what the conventions for the moon are, but Rayleigh (lunar crater) and Ranger program are two examples where east longitudes >180° produced error messages. Deor (talk) 18:16, 11 December 2012 (UTC)

According to the USGS, lunar longitudes are conventionally measured eastward and cover the range from -180 to +180 degrees. So it seems reasonable to me that longitudes >180 should produce error messages in the context of globe:moon. —Stepheng3 (talk) 21:11, 11 December 2012 (UTC)

how suppress change's impact on displaying bad coords

Umm, the change to {{

List of Unitarian churches, where I have put in a bunch of templates with blank fields, i.e., like {{coord||||W||||N|name=}}, and where I and others are busy looking up and adding in real coordinates. Previously it just worked nicely, showing nothing, now it shows an angry/bad appearance. Is there some way I could turn off the red display on a given page, or change all these individually so they don't give that bad appearance? I hope you don't say remove the coord set up entirely and leave it to future editors to construct them anew, as it has worked much better to have them set up in advance. --doncram

01:17, 7 December 2012 (UTC)

You can temporarily "comment out" the blank coordinates: put <!-- and --> either side of the templates, and the parser will ignore them. — Richardguk (talk) 01:34, 7 December 2012 (UTC)

What about other articles that currently have blank coord params? Shouldn't the template either continue to render nothing, or a search for them be conducted and the results dealt with? —[AlanM1(talk)]— 11:15, 7 December 2012 (UTC)

This is what I have done to some of these lists. --Redrose64 (talk) 13:03, 7 December 2012 (UTC)

It would seem a lot better if the coord template and/or the GeoData whatever would be revised to again properly allow blank coordinates. It is good in many list-articles and elsewhere to set up blank coord templates. Yes, those can be commented out, and that takes edits, and then later when editors add coordinates, it will cause more edits to remove the commenting out. And confusion that editors don't see why the coords they added do not show, etc., etc. THIS IS A PROGRAMMING BUG, not a good Feature. --doncram 19:27, 7 December 2012 (UTC)

Templates are not designed to be used with no completed parameters. I see no need for the revision you request. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:22, 7 December 2012 (UTC)

You see no need? What about the need being what is happening in a bunch of list articles that have been using the blank coord templates, while they are works in progress, as a means of helping editors add coordinates?

Some templates are designed to be used that way. Why the hell not design them that way, if that serves editors' needs? In fact, the coord template was designed to be that way, at least up until 2 days ago. I am pretty sure that was deliberate, from past experience a few years ago when it did not function that way, and then observing it did function that way. I can't prove that, maybe it was just an accident that the coord template functioned helpfully that way for a couple years. So, anyhow, could someone please restore this useful functionality? I can't make you, Pigsonthewing, or anyone else do this. The programmers here do have the power to impose costs on other editors by taking away this functionality. I don't suppose I can really fight that successfully, if programmers don't care to support me and other editors on this. --doncram 04:24, 8 December 2012 (UTC)

You've already been given a fix for the use-case you describe. We don't need to modify a template because people are misusing it. I designed the template; I think I know better than you what my intentions were; but if you doubt me you can also refer to its documentation: note the absence of an example with no parameters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:41, 8 December 2012 (UTC)

While I sympathize with Andy that it is an improper usage, the fact is that there was a bug—if you will—which allowed the usage to exist. Since it went apparently undetected for a considerable length of time, I think there is now an obligation to help support demoting the usage without impacting casual readers of such pages. How about adding code to {{coord}} to detect the placeholding usage and if it is, don't call the parser function but do put the article in a maintenance category, perhaps for a bot to convert it to the commented-out form. —EncMstr (talk) 17:46, 8 December 2012 (UTC)

There are fewer than 260 pages in the category mentioned above; the vast majority of which are not caused by this lack of parameters, so let's not create a bunch of work - and permanent template bloat on well over 800,000 articles - to work around a small handful of malformed articles for which a simple and quick fix already exists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:50, 8 December 2012 (UTC)

Having seen several articles with duplicate primary coordinates that showed the new error message but were not listed under Category:Pages with malformed coordinate tags, I think that the category is grossly under-representing the number of affected pages. (This might be the cause and/or effect of the recent job queue backlog which has soared from under 10,000 to over 750,000 in the past 2 weeks and continues to rise rapidly. Pages will not be recategorised until they are edited or until the job queue catches up with them.) — Richardguk (talk) 23:27, 8 December 2012 (UTC)

Fixing the bad coordinates and title conflicts reminds me of playing Whac-A-Mole. But somehow we do seem to be keeping up. —Stepheng3 (talk) 21:46, 9 December 2012 (UTC)

Is there any way of telling how many moles remain unwhacked—i.e., how many articles bear error messages but haven't made it to the category yet? Deor (talk) 15:03, 11 December 2012 (UTC)

Unfortunately {{PAGESINCATEGORY:Pages with malformed coordinate tags}} just reports the same as the cat page, i.e. 39. The job queue (the jobs= figure here) is massive, so we could be looking at days or even weeks. What I've been doing is detecting trends - for example, when I noticed that three or four articles on German PoW camps were listed, I went directly to

CAT:COORD or not. --Redrose64 (talk

) 16:04, 11 December 2012 (UTC)

Don't forget that anons usually see cached versions of every page, so if a page hasn't been processed by job queue readers will likely not see the error messages. Max Semenik (talk) 21:37, 11 December 2012 (UTC)

Possible additional problem

Is it something to do with this that is causing a huge increase in the population of Category:ParserFunction errors, even though no error messages are displaying in the articles? Deor (talk) 01:40, 7 December 2012 (UTC)

Probably unrelated. For around an hour after midnight UTC, there was a problem with parser functions, when division by decimal numbers between 0 and 1 was incorrectly reporting "division by zero"; see Wikipedia:Village pump (technical)#Recent changes to MediaWiki. The pages might need purging or a null edit to re-render. — Richardguk (talk) 01:52, 7 December 2012 (UTC)

All the pages were null edited to fix this problem. The remaining ones probably actually have parserfunction errors. Legoktm (talk) 15:40, 7 December 2012 (UTC)

Add to to-do list?

Perhaps Category:Pages with malformed coordinate tags should be added to the "Fix" section of the to-do list at the top of this page? The new category appears to be catching many problems that the existing tools, such as the "Overlapping title coordinates" one, are not listing. Deor (talk) 10:19, 8 December 2012 (UTC)

Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:49, 8 December 2012 (UTC)

Done! —Stepheng3 (talk) 03:47, 9 December 2012 (UTC)

Tangentially, I've been seeing quite a few cases where the new category has been catching "negative east" coordinates being used in {{coord}} for west longitudes. Wasn't the existing Category:Coordinates templates needing maintenance or Category:Coord template needing repair (I don't recall which) supposed to be catching these? Has the new category made one or both of these categories redundant? Deor (talk) 16:47, 8 December 2012 (UTC)

Category:Coord template needing repair is still useful because it catches a number of dubious practices which Category:Pages with malformed coordinate tags misses. For instance, see the Template:Coord/testcases cases such as "dim= dec", "extra d", and case #1 under "Invalid formats". As for Category:Coordinates templates needing maintenance, it is populated solely by the seldom-used {{Repair coord}} template; if that template were deleted then the category could be deleted. —Stepheng3 (talk) 23:51, 10 December 2012 (UTC)

Bad infoboxes

We have a problem where an article has two infoboxes, and each is hard coded to put its coordinates (which may not be the same) in the title location. ( e.g this page). I'll notify the infobox project, as it's those template which will need modification. We must take care that any fix doesn't remove the title coordinates in existing, single-use cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:49, 8 December 2012 (UTC)

I've been running into some of these. When the infoboxes contain the same coordinates (as when a train station is on the

A4 Portway park and ride, I just removed the Station infobox entirely, since no station actually exists and, as near as I can tell, no specific site for a proposed future one has been determined. Whether what's essentially a parking lot is notable enough for an article is a whole different question.) Deor (talk

) 16:29, 8 December 2012 (UTC)

Deor makes good points. However, there are definitely some cases where an infobox needs modification. —Stepheng3 (talk) 18:13, 8 December 2012 (UTC)

{{Infobox NRHP}} may be nested inside most other infoboxes, by specifying |embed=yes as I did here. This avoids the visual jar that when one infobox ends, the next probably won't be exactly the same width; it also avoids a problem (with certain versions of Internet Explorer) where the lead section text can be pulled down to start adjacent to the second infobox. --Redrose64 (talk) 19:30, 8 December 2012 (UTC)

But if it's embedded in an infobox that also contains coordinates (with both sets having title display), something still needs to be done to resolve the conflict. Deor (talk) 21:36, 8 December 2012 (UTC)

Yes: I didn't suggest that both sets of coords should be retained. --Redrose64 (talk) 23:14, 8 December 2012 (UTC)

Yes, Stepheng3, every infobox that accepts coordinates in latitude and longitude fields rather than with a {{coord}} template really should have some sort of display field so that the title display can be "turned off" when necessary. Template:Infobox UK place is an example of one that doesn't, and Cranfield is an article that contains two of those infoboxes. There's really no easy way to fix the article (that I know of) other than to eliminate the second infobox and put the coordinates (and grid reference) inline in the text. I'm sure there's a number of other examples of such infoboxes. Deor (talk) 21:36, 8 December 2012 (UTC)

{{Infobox UK place}} now recognises |coordinates_display=inline, as here. --Redrose64 (talk) 23:21, 8 December 2012 (UTC)

Excellent! —Stepheng3 (talk) 23:27, 8 December 2012 (UTC)

Long lists

List of Sites of Community Importance in Spain hits the limit of 500 coordinates per page hard. What to do in this situation?

• The limit can be easily raised, however there has to be a sane limit.
• The list can be splitted too per-province lists, however individual monument entries don't contain province information. Max Semenik (talk) 01:57, 9 December 2012 (UTC)

The same issue affects Template:Coord/speedtest, though that's not so high a priority as the article.—Stepheng3 (talk) 03:34, 9 December 2012 (UTC)

Also List of glaciers in the Antarctic. --Redrose64 (talk) 14:08, 9 December 2012 (UTC)

Frankly, in a case like the glaciers list, where every entry is a blue link and the individual articles are presumably geotagged, I question the utility of including a column of coordinates at all. (The list article doesn't even have a {{GeoGroup}} tag, which could arguably add a bit of usefulness to the coordinates, even though I think it would be minimal.) In the Spanish one, there are many redlinked entries and there is a {{GeoGroup}} tag, but the list is so huge that that I can't see how viewing a display of all the coordinates on one map would be of any use at all. Breaking up the list into regional lists (in accordance with the classification at the top of the article) may be the only way to go if it's desired to retain the coordinates as a help to editors creating articles for the redinked places. Deor (talk) 14:37, 9 December 2012 (UTC)

Is the any reason not to up the limit to 1000 or 2000? —Stepheng3 (talk) 21:22, 9 December 2012 (UTC)

I've raised it to 2000 for now, however I don't see much sense in it anyway, so will probably tweak it to follow the limit quietly, without displaying those scary error messages. GeoData isn't that page's worst problem anyway:

NewPP limit report
Preprocessor visited node count: 281137/1000000
Preprocessor generated node count: 106112/1500000
Post-expand include size: 2048000/2048000 bytes
Template argument size: 825395/2048000 bytes
Highest expansion depth: 17/40
Expensive parser function count: 0/500

Templates at the bottom of the page aren't rendered and when I attempted to null edit that page after changing the configuration to make the error go away, it simply timed out. Seriously, if MediaWiki allows you to have such huge pages it doesn't mean that you should:) Max Semenik (talk) 12:36, 10 December 2012 (UTC)

List of cities, towns and villages in Groningen holed out at 500 but a null edit has fixed it. --Redrose64 (talk) 16:42, 10 December 2012 (UTC)

Exposing of unrelated coordinate problems

I realize that at the moment eveyone is mainly focused on getting rid of the red error messages as quickly as possible, but there's an opportunity here, if we want to take it, to correct other coordinate problems in articles. Just one example: Back in 2010, an editor named Shmilyshy (talk · contribs) geotagged a bunch of articles. Since he was in the habit of using a "negative north" format for south latitudes and "negative east" for west latitudes, a bunch of these are showing up in the maintenance category now; but the hidden problem is that many of his coordinates are simply incorrect. He seems to have operated on the assumption that "in the general neighborhood" is good enough; so for A'ufaga he gave (overprecise) coordinates for the middle of the island of Upolu rather than trying to locate the village more specifically, and for radio stations like ALL FM and 4ZA he added (overprecise) coordinates for the general area of coverage rather than trying to pin down the location of either the station offices or the transmitter. I don't have the stomach right now to go through all of his geotagging to root out the other errors, but it may be worth doing at some point.

This is not, by any means, the only such problem I've noted in the past couple of days. In general, it may be worthwhile to take a moment, as we're dealing with the error messages, to check that the coordinates in articles actually make sense. Deor (talk) 00:57, 10 December 2012 (UTC)

Undetected issues

See here. This has two sets of title coordinates, but is not throwing {{#coordinates:}}: cannot have more than one primary tag per page. I've determined that this is because one set of coordinates is using |display=it which is only partially recognised as a synonym for |display=inline,title . This is because Template:Coord/display/it is a redirect to {{Coord/display/inline,title}} but the code in {{coord}} only tests for four specific values: inline,title inline, title title,inline title . It should test for all of these redirects and also this one. --Redrose64 (talk) 17:33, 20 December 2012 (UTC)

I've coded a fix at Template:Coord/sandbox. Would someone please review it? —Stepheng3 (talk) 00:31, 24 December 2012 (UTC)

Yes, the two sets of aliases (one for inline,title the other for title) are now tested consistently. --Redrose64 (talk) 11:19, 24 December 2012 (UTC)

Coordinates for soap operas

The

Albert Square has co-ordinates at Elstree Studios where EastEnders is filmed, but which is nowhere near where Albert Square would actually be, if it really existed. Ramsay Street is another example, and I'm sure there are plenty more. Are these acceptable, or should they be removed? Bazonka (talk

) 22:04, 6 January 2013 (UTC)

My opinion isn't strong, but I'd lean towards that being a bit too indirect to warrant coordinates. It feels sort of like tagging a record album with the location of the studio where it was recorded, or a novel with the house in which it was written. That feels like it starts to lose usefulness, vs. just mentioning the filming/recording/writing location in the article/infobox, and reserving the coordinates for the article on the actual location. --Delirium (talk) 02:19, 8 January 2013 (UTC)

Yes, and it also has an element of blurring reality with fiction, because the only reason that I can think of why such articles have been given coordinates, is because the fiction in question is about a place. PaleCloudedWhite (talk) 02:36, 8 January 2013 (UTC)

Strongly oppose removal: The filming location for Ramsay Street is a real publicly-accessible cul-de-sac and tourist attraction. The Coronation Street exterior set was part of a public tourist attraction in the 1990s. Also, the exteriors for all three soap operas are permanent structures visible on satellite maps, so their locations are real in a tangible sense (in contrast with interior sets which could be relocated easily and are not publicly visible). In addition, the productions are all highly notable as popular long-running soap operas, and the exterior sets are prominently featured and their layouts interrelate with the activities of the fictional characters. (Even if a long-running drama used only interior sets, there would still be a good case for recording its location if it were well-known, just as one would label the location of any major business activity.) So I would support retaining the coordinates. — Richardguk (talk) 04:10, 8 January 2013 (UTC)

But they are misleading. Fictional Albert Square is in fictional Walford, and it is not correct to indicate that it is in real Elstree. These articles are ostensibly about fictional places, which do not have real-world locations. However, studios and film sets do have real-world locations, and hence meaningful coordinates. But rather than removing the coordinates completely, it might be better to only display them as inline coords when the studio or film set is mentioned. Bazonka (talk) 18:32, 8 January 2013 (UTC)

Bazonka's suggestion is eminently sensible. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:04, 8 January 2013 (UTC)

Or perhaps preferably, if there are separate articles about the sets, then just keep them there e.g. Coronation Street sets (which by a strange quirk, has ever so slightly different coordinates to the main article...). PaleCloudedWhite (talk) 23:23, 8 January 2013 (UTC)

That makes sense to me, and matches what the current guidelines say for sports teams: sports teams shouldn't be tagged with the coordinates of their stadia, but rather, the stadium should have a separate article and the coordinates should go there. --Delirium (talk) 20:13, 9 January 2013 (UTC)

FYI: Geotagging on WikiVoyage

I just wanted to let the people of this project know that similar activity is getting under way as part of the new Wikivoyage site. I thought that the goings on there could greatly benefit from your input, especially at this early stage. All the world's a Wikiproject.
--

WikiWar

14:34, 16 January 2013 (UTC)

Mount Ararat

The place of "Agri dag" (or Mount Ararat) is not correct on the map in that article. It is situated in Turkey, while map shows it is in Armenia. We need to ensure the following points:

a) whether borders of Turkey are correct in that map;

b) whether coordinates of "Agri dag" (Armenians call it "Mount Ararat") are correct.

At least one of these is not correct, if both were correct, then this peak has to be within territories of Turkey. Best, Konullu (talk) 19:46, 27 January 2013 (UTC)

Per Google Maps, the coordinates (39°42.113′N 44°17.899′E) are accurate, and they are well inside Turkey. I don't understand the operation of location maps well enough to say exactly where the error is, but it's not in the coordinates themselves. —Stepheng3 (talk) 19:57, 27 January 2013 (UTC)

(edit conflict) Although the best place to address this would be Talk:Mount Ararat, I don't think it's correct to assert that the map shows the mountain in Armenia. If you click on the coordinates icon at the top of the page and zoom in, you see that the mountain is pretty close to the border, so with the larger scale of the map in the article, the icon may look as though it's in Armenia even though it's in the correct location. According to Google maps, the coordinates are correct, and they are also sourced as well. Spencer^T♦C 20:00, 27 January 2013 (UTC)

There's an eastward protrusion of Turkey at that point (cf. the location map in Iğdır), but the big triangular location symbol used by {{Infobox mountain}}—along with the "t" in the "Mount Ararat" label—obscures it, so that it just looks as though it's sitting to the east of the Turkish border. Deor (talk) 20:49, 27 January 2013 (UTC)

WikiMiniAtlas - new 3D building models

Friday afternoon/evening. Worst timing for an announcement, but here it is:

I added new WebGL based hardware accelerated 3d buildings to the WikiMiniAtlas. This feature requires WebGL support by the browser (all modern browsers except IE). For modern IE the old wireframe mode acts as a fallback. For browsers that do not support the canvas element (older IE <=8 and obsolete browsers) nothing is shown (it should degrade gracefully). --Dschwen 22:52, 8 February 2013 (UTC)

Squashed a few bugs that led to wrong illumination of some buildings, flickering (z-fighting), and missing building parts. Manhattan has some gorgeous 3D buildings to look at now. --Dschwen 18:34, 12 February 2013 (UTC)

Multiple coordinates per page?

Hi,

How d you add multiple coordinates per page? — Preceding unsigned comment added by 86.136.17.96 (talk) 19:10, 14 February 2013 (UTC)

Just add them with display=inline rather than display=title. --Dschwen 19:18, 14 February 2013 (UTC)

If there are loads of them, then the {{

kml}} template can be useful to help them all be displayed on a map at once. Bazonka (talk

) 20:08, 14 February 2013 (UTC)

Coordinates from template will also be displayed on the map all at once. I would strongly advise against using KML to insert point coordinate clouds. They will be invisible to coordinate extraction projects and they will lack the semantic contect that the templates in teh wikitext provide. For line and area like objects, however, {{Attached KML}} is a great choice (see Mojave Desert for an example), unless the objects are already linked through OpenStreetMap (like Argentina for example). --Dschwen 21:34, 14 February 2013 (UTC)

{{

kml}} is a template; Bazonka wasn't suggesting the use of an actual KML file. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

21:52, 14 February 2013 (UTC)

Oh... right. :-) I totally missed that. --Dschwen 23:56, 14 February 2013 (UTC)

We could give you a more helpful answer, with examples, if you tell us which article you're looking at. Meanwhile see

Elan Valley aqueduct. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

21:52, 14 February 2013 (UTC)

I was thinking about Great Central Railway (heritage railway) (and similar), which has 4 stations as entry points. So that when you click on the link it opens all of them in one go. — Preceding unsigned comment added by 86.136.17.96 (talk) 22:08, 14 February 2013 (UTC)

If you add the coordinates of each station in the "Stations of the heritage GCR" section and insert the {{GeoGroup}} template in the article, that template will link to Google and Bing maps showing all four locations at once. Use "display=inline|name=name of station" in each {{coord}} template. Deor (talk) 22:20, 14 February 2013 (UTC)

Also |type:railwaystation_region:GB --Redrose64 (talk) 22:33, 14 February 2013 (UTC)

Then {{

Crossings of the River Severn. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

22:31, 14 February 2013 (UTC)

OK so I did it at Great Central Railway (heritage railway), but when you open it it calls them #1, #2, #3, #4, how can you make them labelled properly? — Preceding unsigned comment added by 86.136.17.96 (talk) 20:10, 15 February 2013 (UTC)

To get appropriate labels, use the name= parameter on each {{Coord}} template. —Stepheng3 (talk) 07:34, 16 February 2013 (UTC)

That's exactly what had already been done; and I too see merely "#1" through "#4" in both Google Maps and Bing. --Redrose64 (talk) 11:16, 16 February 2013 (UTC)

That's what happens when you add the names after the fact rather than before adding the {{GeoGroup}} template. Change the "D1" at the very end of the URL to "D0", and you will see the labels. The map displays usually catch themselves up after a day or two. Deor (talk) 11:28, 16 February 2013 (UTC)

There's a hell of a delay before the edits run through all the caches and finally appear. When updating 12 of my pages- I think it was about 4 days before they started to appear. Patience! --ClemRutter (talk) 11:33, 16 February 2013 (UTC)

List of cathedrals in the United States

template limit and the last few templates on the page don't display. In fact, the coordinates for the cathedrals in the last nine states alphabetically have not even been added to the page yet, so eventually the {{coord}} template is likely to be called on even more often. There are at least two solutions to this I can think of: (1) split the page up into separate pages, or (2) remove some of the uses of the {{coord}} template. Does anyone have any other ideas? --Metropolitan90 (talk)

18:47, 23 February 2013 (UTC)

Didn't we discuss such matters above? --Redrose64 (talk) 21:07, 23 February 2013 (UTC)

Lua (see above) may fix this, or you could divide the page into two or more sub-pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 27 February 2013 (UTC)

Individual Engagement Grant Notification, reposted from WikiProject Maps talk page

I'm reposting this from Wikipedia talk:WikiProject Maps in case it's of interest to anyone here:

“

Hello! I have posted a draft of an Individual Engagement Grant titled GIS and Cartography in Wikimedia. The grant calls for increased contributions of map content to Wikimedia projects through outreach to GIS and cartography communities that are currently not exposed to the idea and practice of contributing content to Wikimedia. This will be led by Darin Jensen, the Department Cartographer and a Continuing Lecturer in UC Berkeley’s geography department and Evelyn Hammid (myself), a UC Berkeley geography student and Wikipedia editor. We will recruit GIS and cartography courses in colleges, universities and possibly high schools into the US Education Program and assist these classes in contributing their projects to Wikimedia. We will also conduct outreach to GIS and cartography communities outside of schools to encourage freely licensed map contributions. If you are interested in this project or have any questions or concerns, please take a look at the draft and comment on the discussion page. Thank you and I look forward to hearing from you. EHammid

”

-- The Anome (talk) 10:24, 27 February 2013 (UTC)

Lua scripting for {{coord}} and other similar templates?

I believe Lua scripting support may now be, or very soon should be, enabled on en: Wikipedia. This might be an opportunity to rework complex templates like {{coord}}, to make them more maintanable and faster, and at the same time to lay the foundations for making them more flexible and versatile in the longer run. Seee http://www.mediawiki.org/wiki/Lua_scripting/Tutorial for more details... -- The Anome (talk) 19:42, 18 February 2013 (UTC)

I read in The Signpost that Lua is enabled on enwiki. Yes, I think {{Coord}} and its subtemplates should be rewritten using Lua, if only to see whether we can make them more efficient. Whoever tackles this project should gain experience by first rewriting some simpler templates. —Stepheng3 (talk) 07:39, 21 February 2013 (UTC)

I have not checked for almost five years, but the limit (imposed by WikiMedia software transclusion limitations) for the number of uses of {{coord}} on a single page has been raised from 689 to 1333,^[1] probably by the transition to a Lua implementation.

This is a nice step forward—but what is limiting it? Previous discussion about the advantages of the different coordinate templates indicated that the old {{coor d/dm/dms}} could have 3880 instances per page (which was data I deduced around that time). What is limiting the number of transclusions now? Especially since {{coord}} no longer appears to use subtemplates, though I am confused by what it does:

 {{#invoke:Coordinates|coord}}
 {{#coordinates: (with all the parameters passed to it) ... }}

What is the difference between #invoke:Coordinates and #coordinates?

1. ^ see User:EncMstr/List of Oregon GNIS features for a demonstration

—EncMstr (talk) 20:22, 15 March 2013 (UTC)

{{#invoke:}} is a

parser function which brings in a module, and is part of the recently-introduced WP:Lua feature. The first parameter is the module name; so {{#invoke:Coordinates|coord}} uses the code inside Module:Coordinates. The second parameter is the name of the function which is to be called; it must be defined within that module. The coord function within Module:Coordinates does the "traditional" work of {{coord}} by creating and formatting a link to mapping services via Template:GeoTemplate

.

{{#coordinates}} is another parser function which has been available for some months now. It doesn't display any coordinates, but carries out some error-checking including a test to ensure that you don't get two sets of coordinates at upper right. More at mw:Extension:GeoData. --Redrose64 (talk) 20:56, 15 March 2013 (UTC)

Wikidata

I notice in the current issue of the Signpost that Wikidata plans "to 'flesh out' the phase 2 implementation to support other data types, most notably co-ordinates". Does anyone know anything about this? Where are these coordinates to come from? There's currently a good deal of inconsistency across the various Wikipedias in this respect (some coords currently in en.wp may be more accurate than those in other versions, some may be less accurate, there may be a number of sets of coords given for a particular place in the various versions, coordinates in external databases vary considerably in their accuracy, and so forth). The "consensus" to employ the Wikidata database for interwiki links on en.wp was reached in a fairly obscure (at least to me) manner; will we grunts have any say in this proposed use of Wikidata for coordinates? Deor (talk) 17:18, 28 February 2013 (UTC)

As long as I get the ability to edit Wikidata, I probably won't gripe. —Stepheng3 (talk) 18:26, 28 February 2013 (UTC)

It seems non-controversial that data common across projects should reside in one place only, and perhaps that is why the Signpost would mention that coordinates should be migrated to Wikidata. Unlike a set of interwiki links—which should be identical in each project—coordinates have been handled in a more ad hoc manner to date, and that is the major cause for any disagreements. They should be the same. Obviously there should be some way to resolve disagreements, but I suspect a slight majority (51%?) exactly match across projects. That is the low hanging fruit.

I (now) propose for Wikidata to capture all the variations for each landmark; if they differ by more than a few hundred meters (or more than 50% of the dim parameter), then the newly revised {{coord}} flags for human review. Reviewers could then check the coordinate cloud on a map or satellite view and choose one (or maybe select a new coordinate). —EncMstr (talk) 19:05, 28 February 2013 (UTC)

When coordinates match exactly across projects, it's usually because they've been blindly copied by bots. If there's a majority rule, then much of the effort put into improving coordinates by hand will be destroyed: in particular, the effort to combat

WP:OPCOORD. —Stepheng3 (talk

) 19:15, 28 February 2013 (UTC)

What about infoboxes that don't make direct use of {{coord}}? Will they all need to be rewritten to handle the Wikidata coordinates? Who will do so? If all coordinates are stripped out of en.wp, as is now happening with interwiki links, how will problems be identified when the tools linked at #Fix no longer flag them? I'm not a Luddite, especially since I don't really understand how all this technological stuff works, and I see the value of a centralized repository of (verified) coordinates; but I'd like to see some evidence that the potential for major disruption is being considered and dealt with in this matter. Any necessary cleanup seems likely to become the responsibility of regular schlubs rather than the techowizards. Deor (talk) 19:56, 28 February 2013 (UTC)

What infobox does not use {{coord}}? As far as I know, they all do. If some are not, they should be upgraded. —EncMstr (talk) 20:09, 28 February 2013 (UTC)

Plenty don't. Anything where coords are inappropriate, like {{infobox person}} {{infobox book}} {{infobox album}} or {{infobox locomotive}}. Need any more examples? --Redrose64 (talk) 20:59, 28 February 2013 (UTC)

I meant What infoboxes handle coordinates without using {{coord}}? —EncMstr (talk) 21:09, 28 February 2013 (UTC)

I sincerely hope that number is zero. --Dschwen 21:35, 28 February 2013 (UTC)

I suspect the question refers to the fact that some infoboxes have {{Coord}} hard-coded, while others take it as a parameter value, and some have both options. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:12, 28 February 2013 (UTC)

As with all data on Wikidata, it'll either a) be added by hand, or b) be copied from one or more Wikipedias. The decision on the actual method of copying hasn't been made yet, and probably won't be until the system is actually able to support coordinates (right now, it isn't). You're right that this is one where we're going to have a lot of slight variation between projects, even if they all have approximately the same value.

It might be that there is some easy way to flag "better" coordinates when comparing between wikis - appropriate accuracy seems a good one. wd:Wikidata talk:Infoboxes task force/places will probably be the appropriate place to figure out how to handle the import. Andrew Gray (talk) 19:34, 28 February 2013 (UTC)

I've seen plenty of very accurately expressed coordinates (>6 decimal places or fractions of a second) that were nonetheless dead wrong for various reasons. Frequently, places have the coordinates of other places with the same names attached to them. Migrating coordinates to Wikidata seems likely to multiply rather than reduce such errors. Clearly, I don't much like the idea of having the many coordinates I've corrected by hand suddenly be replaced, with no way to tell that it's been done, by incorrect coordinates obtained from who knows where. Deor (talk) 19:56, 28 February 2013 (UTC)

As paradoxical as it seems, merging coordinate pairs for the same location will reduce errors. Right now, we simply are not aware of discrepancies across projects. Once they are combined, the errors will be obvious. However, I expect the majority will simply match "close enough" so that one can be chosen as the one "true" coordinate and the complexity instantly melts away. For pathological coordinates, they need to be identified and fixed. For coordinate repairs I have done, 99% of them are simple and obvious to fix. The others sometimes require a few minutes to find the actual place and geocode or transcode them. —EncMstr (talk) 20:15, 28 February 2013 (UTC)

Appropriate != most precise ;-). I certainly don't think taking the one with the most significant figures is always likely to be best; looking for the expected number of significant figures given the scale of the feature in question might be a good way to find the "human-curated" results rather than the ones pulled off an automatic database. Or we could (thinking wildly here) have the import bot look for the most recently edited by a reliable user, or

I suspect that what will happen is that any page with complete agreement across all wikis will be imported; any with major outlying discrepancies will be flagged for human review; and it's the middling group, where they disagree on the last couple of significant figures, that are going to be a headache.

One other thing to quickly bring up - the way Wikidata works for interwikis isn't quite the way it's going to work for any other data elements. These won't be automatically added on to an existing article; rather, they'll be invoked from Wikidata using something like a template function; see meta:Wikidata/Notes/Inclusion syntax for some approximate ideas of how it's going to work. At the moment, WD will only be gathering interwikis; actually switching the ones used here for the WD versions is going to be an opt-in process. Andrew Gray (talk) 20:36, 28 February 2013 (UTC)

Rather than a language-wide opt in, it almost certainly should be article-by-article. Perhaps by replacing harvested {{

wikidata coord

}} or something similar.

It would have to be done on a per-article (or per-template) basis anyway; there's no easy way to flick a switch for the project and have all the WD elements appear. Including data elements from Wikidata is like transcluding templates - to generate the WD value for something, you'd use the code {{#property:population}}. So what you'd probably have would be a coord template that called |coordinates={{#property:coordinates}} or something similar; it might be that this is set up to only display the WD coordinates if there's no local value set, though. The mechanism is a bit speculative, but hopefully the principle is clear - we get to decide this for ourselves :-). Andrew Gray (talk) 21:38, 28 February 2013 (UTC)

GNIS – is it a reliable source?

GNIS is a piece of crap, and should not be touted as reliable. Pick ten locations at random, and you will find GNIS does not point to them. Typically it rounds to a (not the) minute of arc. Abductive (reasoning) 13:18, 20 March 2013 (UTC)

Even if GNIS is inaccurate, it is not proper for us to post our personal opinion on the project page. In this regard,

WP:RSN is a better place to discuss. – S. Rich (talk

) 13:31, 20 March 2013 (UTC)

No, that is not true. This is a Wikiproject page, not an article, so the users here decide what the page should say. Do you deny that GNIS is error-prone? Abductive (reasoning) 20:38, 20 March 2013 (UTC)

I'm surprised by Abductive's claim. GNIS is not perfect, but it's reliable enough to be used as a source when nothing better is readily available. I picked ten arbitrary IDs between 1 and 999,999:

1. U.S. Geological Survey Geographic Names Information System: Fitzgerald Cemetery - verified using ACME Mapper (topo view)
2. U.S. Geological Survey Geographic Names Information System: Reed Creek - verified using ACME Mapper (topo view)
3. U.S. Geological Survey Geographic Names Information System: Town of Ossining - verified using ACME Mapper and Google Maps
4. U.S. Geological Survey Geographic Names Information System: Toombs (historical) - not verified but seems plausible
5. U.S. Geological Survey Geographic Names Information System: Dailey Dam - points to Dailey Lake, within 800 ft of the dam
6. U.S. Geological Survey Geographic Names Information System: Flint Hollow - verified using ACME Mapper (topo view)
7. U.S. Geological Survey Geographic Names Information System: Tillman Cemetery - verified using ACME Mapper (topo view)
8. U.S. Geological Survey Geographic Names Information System: Montezuma District Mine - not verified
9. U.S. Geological Survey Geographic Names Information System: Betty Branch - verified using ACME Mapper (topo view)
10. U.S. Geological Survey Geographic Names Information System: School Number 10 (historical) - verified using ACME Mapper (topo view)

I'm not seeing a problem here.—Stepheng3 (talk) 21:26, 20 March 2013 (UTC)

GNIS has ±2,000,000 entries. A

sample size of 10 entries does not seem to be a valid statistical test. (Moreover, 500 meters east of Montezuma District Mine is a berm across the wash. Built from mine tailings?) – S. Rich (talk

) 01:43, 22 March 2013 (UTC) PS: With regard to what goes on the project page, this talk page is certainly a place to discuss in order to reach consensus.01:47, 22 March 2013 (UTC)

I think that Stepheng's reply was intended to put the literal terms of your claim to the test.

The U.S. government provided GNIS (U.S.) and GNS (non-U.S.) databases aren't perfect, and their resolution is limited to minutes of arc, but they aren't bad. They are also license-free, and curated by a large organization that takes some care in doing so, and definitely meets the

WP:RS

criteria. They are sometimes wrong, and often not as precise as could be wished, but overall, It's a reasonable starting point for bootstrapping a free coordinate database, providing you don't take it as gospel.

OpenStreetMap has higher standards regarding both precision and attribution, but currently has much sparser coverage of many parts of the world. Over time, I expect us to move toward using their data as a reference instead of relying on GNIS/GNS. Making that transition wholesale is an interesting challenge, and one I look forward to participating in. In the meantime, there's nothing to stop us from finding and fixing errors in GNIS/GNS data as we come across them. -- The Anome (talk) 11:34, 25 March 2013 (UTC)

Stepheng did well by putting the challenge to the test, and GNIS came out well too. My point about test validity simply pointed out that 10 data samples was not very useful. Still, I will attest that I've sent 2 corrections to GNIS about misplacements and miscategorizations. They responded immediately. As for http://www.openstreetmap.org/, we can't use it, directly, as a source because it is a wiki. In looking at 20 GeoNames hits that came up on Openstreetmap for "Palm Springs, California", 3 of the 20 were inaccurate. Of the 2 "Nominatim" results for Palm Springs, one was spot on, the other was in the city limits, but way off to one side of the city in an unpopulated area. In any event, GeoNames itself uses GNIS as one of its sources. All of this comes down to editing judgment and common sense. We find a location with Google Maps, GNIS, OpenStreetMap, etc., look at it on the screen, and make decisions about what we find in each edit. If something is really wrong, we can notify GNIS, Google Maps, or whoever, and ask them to make corrections. – S. Rich (talk) 21:12, 25 March 2013 (UTC)

Toolserver broken?

It seems for a couple hours now Toolserver has been down. Wikipedia:Village_pump_(technical)#Is_toolserver_broken? Apparently this shuts down our coord templates until it's fixed. Jim.henderson (talk) 13:38, 7 April 2013 (UTC)

It's been on and off since I woke up this morning, about five hours ago. Coordinate links are working for me at this particular moment. As I remarked at the Help Desk yesterday, during another outage, Toolserver has been acting particularly squirrelly for the past month or so. Deor (talk) 14:17, 7 April 2013 (UTC)

Seems to be completely broken for most of today, returning a 404: The requested URL /~geohack/geohack.php was not found on this server. WikiMiniAtlas is also returning 404s. --Delirium (talk) 09:30, 13 April 2013 (UTC)

It works if you access geohack over HTTPS, at least for me right now. HTTP is dead though, so we should probably change the link as a temporary fix. Bjelleklang - talk 07:36, 16 April 2013 (UTC)

WP Geographical Coordinates in the Signpost

The WikiProject Report would like to focus on WikiProject Geographical Coordinates for a Signpost article. This is an excellent opportunity to draw attention to your efforts and attract new members to the project. Would you be willing to participate in an interview? If so, here are the questions for the interview. Just add your response below each question and feel free to skip any questions that you don't feel comfortable answering. Multiple editors will have an opportunity to respond to the interview questions, so be sure to sign your answers. If you know anyone else who would like to participate in the interview, please share this with them. Have a great day. –Mabeenot (talk) 02:04, 15 April 2013 (UTC)

Well, folks, since it was I (not officially a member) who recommended this project as a candidate for a Signpost feature, I'm beginning to feel like a fool. Is no one other than Jim.henderson willing to respond to the interview questions—in particular, no one who can address the more technical aspects of geotagging? I thought that it might be useful to draw the attention of the general WP editorship to the work that the project's members do, but perhaps nobody's really interested. Deor (talk) 19:09, 23 April 2013 (UTC)

Ah! I've see I've just invited you to the interview! I've also responded, and I've just paged Andy Mabbett as well via his talk page: he may well have something interesting to say... -- The Anome (talk) 10:40, 24 April 2013 (UTC)

Splendid to see it grow beyond what an ignorant enthusiast like me can supply. But y'know, the parts about better attracting readers made me think. Maybe the main click target should be not the line of numbers but the locator map. Much bigger. Of course we can't put words like "click here for real map" in the article header, but maybe near the red dot inside the little outline map in the infobox. Jim.henderson (talk) 18:44, 25 April 2013 (UTC)

Systematic review of NRHP tags?

A number of our articles about U.S. National Register of Historic Places entries have coordinates imported from the NRHP listing without validation. Unfortunately, I've found that a large portion of these coordinates are imprecise. A common case is that the coordinates are just the city center of the nearest city, rather than the actual location of the structure. For example, until I corrected it, US 281 Bridge at the Brazos River was tagged with the coordinates of the city center of Mineral Wells, Texas, which is 12 miles away from the bridge. As another example, Roy A. and Gladys Westbrook House was tagged with the coordinates of downtown Ft. Worth, but the house is about 3 miles away from downtown. I've been fixing these on and off by spot-checking, but would be a good idea to do a more organized review? That way we could avoid either duplicating effort or failing to check some cases. --Delirium (talk) 21:38, 25 April 2013 (UTC)

Over-precise coordinates – things of the past?

A pair of coordinates I recently added has been truncated (from six decimal places of degrees to four), with reference to

WP:OPCOORD

, due to the fact that they referred to a 40-mile-long railway – I'd intentionally placed the point on top of the track. As someone who mainly creates and thinks of coordinates as placemarks in Google Earth, I find this perplexing.

Virtual globes now mostly visualise terrain to a resolution of one metre or better using satellite imagery, and so it has become reasonable to expect a coordinate to point to the correct visible feature on the metre scale. Arguably, all coordinates on the internet now have one-metre resolution, whether they warrant it or not. As such, allowing a coordinate to land on a private dwelling, the wrong side of a border, a nearby but unrelated railway, or far away from the subject (as with long, narrow and curved structures), when we have the power to arrange otherwise, may have contentious results. In the case of Google Earth, a precise coordinate allows the point to be attached to an existing cluster.

As for the solitary claim against precise coordinates, that they mislead over the size of the feature: presentation issues are really a matter for the {{Coord}} template – but again, when taking input on the size of the subject, consider that it may be big and yet easy to miss (narrow).

Is it still appropriate to advise editors to limit the precision of coordinates submitted to Wikipedia?

Edit: Precise coordinates for large subjects are also legitimate when pointing to small objects (railway tracks, monuments) that stand for the subject as a whole. re/greg/ex;{mbox|history} 19:31, 5 March 2013 (UTC)

Of course it is appropriate, but perhaps not in the case of a railway track. These may be big due to their length, but still require precision due to their width. A city, on the other hand, certainly doesn't need a 6 decimal place coordinate. Bazonka (talk) 20:14, 5 March 2013 (UTC)

(edit conflict) This is the edit in question. That particular railway line begins at Swanley Junction (17 miles 50 chains from Victoria) and ends at Ashford "B" Junction (58 miles 61 chains). It is thus 41 miles 11 chains long, and with two tracks will not be much more than 20 feet wide (stations excepted). A precision of six places of decimals implies a measuring accuracy of four inches (10 cm), that is to say one-sixtieth of the width of the line, or 1/650000 of the length of the line. By contrast, the parameters fed to {{coord}} specify scale:500000 - that's two millimetres to one kilometre, so 10 cm on the ground comes out at 200 nanometres on the paper - comparable to the wavelength of ultraviolet light. I fail to see why it is necessary to have a measurement precision that is so much at odds with the scale of the map. --Redrose64 (talk) 20:19, 5 March 2013 (UTC)

Because it's not just about maps any more. If you forget about

Charles I statue in the centre of London, from which distances to London are measured. re/greg/ex;{mbox|history

} 21:09, 5 March 2013 (UTC)

If it's not just about maps, why bother setting a scale? If I want to find London on a map, I want to see symbols representing the agglomeration of buildings, not a specific statue (and other distance markers do exist, such as

rail chairs. Things should be kept in proportion. If a feature is large enough to need a small scale, it should use a correspondingly low precision. If it's small enough to need a high precision, it should use a suitably large scale. --Redrose64 (talk

) 21:47, 5 March 2013 (UTC)

I only add a scale for the benefit of the pop-up atlas so that it defaults to showing the whole subject and its context (whereas dim does not allow for context). re/greg/ex;{mbox|history} 18:37, 7 March 2013 (UTC)

I'll offer a contrary view, one that I could more easily do in the context of insurance data, but the terms won't mean much so I'll see if I can do it in terms of map coordinates.

In short, addition precision serves as a proxy for an audit function.

Making up a situation, suppose there are several sources for some coordinate and the sources report as follows:

• Source 1 277804|0.522821
• Source 2 277804|0.522816
• Source 3 277804|0.522823

All of these, truncated to 4 decimal places, produce the same answer. But the six decimal point answer, also helps identify the source.

Obviously, in a perfect world, people who add coords add solid sources, but it isn't a perfect world, and seeing overly precise coords carries a benefit,t hat it might help identify or refute a possible source as the real source.--SPhilbrick(Talk) 20:42, 5 March 2013 (UTC)

The source is the least of our worries. Readers will want the co-ordinates to be accurate and appropriate. If they take you to the right place on a map when you click on them, then that's enough proof that they're correct. Geographic co-ords don't really need to be sourced in the same way that most other information in Wikipedia. (Obviously this is more difficult with small features that aren't on the maps, but then you should use a normal ref.) I think unreferenced co-ordinates are generally worse than very over-precise co-ordinates. Bazonka (talk) 20:35, 6 March 2013 (UTC)

You could upload a KML file and use {{Attached KML}}. --Bamyers99 (talk) 20:47, 5 March 2013 (UTC)

Is excess precision a thing of the past? No, as long as we have coordinates specifying 10 decimal places of precision (0.01 mm precision) —- and we do —- WP:OPCOORD remains a concern.

Is there any justification for using 6 decimal places of precision? Maybe. If we had sources accurate to 0.000001 degrees (10 cm), I'd support the use of such precision for locating railroad tracks, small statues and the like. However, I don't believe Google Maps is quite that accurate.

As for identifying sources, overprecise coordinates would be an obscure and unreliable substitute for an explicit citation. —Stepheng3 (talk) 04:34, 7 March 2013 (UTC)

Please see Wikipedia:Bot requests/Archive 54#Over-precise coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:50, 15 March 2013 (UTC)

WP:BOTREQ. I'll need a little time but I'd appreciate knowing for sure if this Wikiproject has decided on this. Thanks! --ikseevon^(T)(E)

05:30, 28 March 2013 (UTC)

It looks like AlanBOT is on the job. —Stepheng3 (talk) 00:41, 12 April 2013 (UTC)

But AlanBot is truncating instead of rounding up or down as appropriate. (It is impeding continental drift as a result.) I've left a message with the bot-master. – S. Rich (talk) 00:44, 12 April 2013 (UTC)

True, but lots of human editors have been doing the same thing for years without any complaints. At 6 decimal places, the maximum effect is a 16-centimetre (6.3 in) change in place of a 8-centimetre (3.1 in) one. —Stepheng3 (talk) 00:52, 12 April 2013 (UTC)

Indeed, and they have been wrong for years. The AlanBot-master is stopping for now, will fix (this quite minor issue), and restart. All will be well with the world soon. – S. Rich (talk) 01:01, 12 April 2013 (UTC)

The bot appears to be rounding now instead of truncating. —Stepheng3 (talk) 03:32, 12 April 2013 (UTC)

The bot will, however, apparently round to 60 seconds of a degree, which is not good. If the bot can't bump x minutes 59.9 seconds up to (x + 1) minutes 0 seconds or x degrees 59.9 minutes up to (x + 1) degrees 0 minutes, it may be more trouble than it's worth. Deor (talk) 08:02, 12 April 2013 (UTC)

That's a bug. —Stepheng3 (talk) 21:29, 12 April 2013 (UTC)

Would someone with admin privs please stop the bot? —Stepheng3 (talk) 21:31, 12 April 2013 (UTC)

Never mind. I'm told it's taken care of. —Stepheng3 (talk) 22:10, 12 April 2013 (UTC)

Indeed. Somebody pointed out a coordinate that the bot missed, which was an easy fix, so I killed the bot until I can do it. This was even before Deor's comment. Let me look at both things after this weekend and we should be golden. Also, I have a list of the edits the bot made, so I can easily go through it on my own and undo any edits that bumped the seconds to 60, which is the extreme minority of the changes. --Alan^(T)(E) 22:21, 12 April 2013 (UTC)

 Good to go. --Alan^(T)(E) 04:04, 29 April 2013 (UTC)

A user has raised a concern related to this conversation, so I directed him over to here to centralize the discussion. --Alan^(T)(E) 22:32, 12 April 2013 (UTC)

USCG light list coordinates

Locations for US lighthouses and other ATONs are given in the official light lists (e.g. 2013 Vol II) to three places of accuracy in seconds. Others have questioned the need to round this off. Mangoe (talk) 16:14, 29 April 2013 (UTC)

Three d.p. in seconds is 30 millimetres (1.2 in), near enough; I've never measured a lighthouse, but I think they're usually more than 3 metres (9 ft 10 in) in diameter - so per

WP:OPCOORD, two d.p., which is an accuracy of 300 millimetres (11.8 in), should be sufficient. --Redrose64 (talk

) 16:50, 29 April 2013 (UTC)

The issue is more or less moot for me, because I always convert these coordinates to decimal degrees, which external authorities seem to think that four places is the right level of precision. I only ask because other people (including myself in the past) simply copy the values out of the light list without changing them. Mangoe (talk) 18:25, 29 April 2013 (UTC)

The filament of the light (most, but not all lighthouses have incandescent lamps) is vertical and only a few millimeters in diameter, not 3 metres (9.8 ft). Even the new VLB-92 LED beacon from Vega is only 460mm in diameter. The Coast Guard gives us an official measurement to the third d.p., presumably because that they think that it is appropriate to do so. Is it really our job to second guess a well known and respected source?

As for Mangoe's conversion to decimal degrees, I wish he wouldn't. Aside from the possibility of error in conversion, it means that when you edit a lighthouse article, you have to do the math in order to check that the location is correct. Why not just leave it DMS so that it can be instantly checked from the light list? I recognize that DMS is more or less obsolete, but most mariners use degrees and decimal minutes (because a minute of latitude is a mile for us, within 1% or so), so decimal degrees isn't any closer to actual practice. . . Jim - Jameslwoodward (talk to me • contribs) 18:54, 29 April 2013 (UTC)

I was under the impression that we give coordinates of the structure, not of specific equipment installed in that structure. --Redrose64 (talk) 19:00, 29 April 2013 (UTC)

My recollection of why I was doing it was that there was some operation (I forget which, but off the top of my head I believe it was the "show all in a map" tool) that didn't work properly with DMS. Also, for extant but inactive lights the best source for location uses decimal degrees. I've always used the FCC page for conversions so there shouldn't be a problem with the arithmetic. If we would like to pick one way or the other it needs to be kept in mind that on the state list page there will always be some conversion involved, in one direction or the other. Mangoe (talk) 19:22, 29 April 2013 (UTC)

It's also possible that I only used decimal degrees for active lights in the state list articles. Mangoe (talk) 19:24, 29 April 2013 (UTC)

I agree that it's a mess and a fine point, but, as I said, using the same units as in the source (Light List or otherwise) makes it easier for subsequent editors to check that the figure is correct. I have found that they are often wrong, usually because the NRHP uses the 1927 NAD and is often out by several hundred feet, but also because other sources are also often wrong or not copied correctly. I trust me and thee and a few other editors to get them right, but not most others. . . Jim - Jameslwoodward (talk to me • contribs) 13:13, 30 April 2013 (UTC)

@Redrose - The light is usually (but not always) at the center of the structure, so the point is mostly moot. However, the official name (and correct article title) is almost always "XYZ Light", not "XYZ Lighthouse", so if you want to split hairs, we are writing about and locating the light, not the structure. That's appropriate because, after all, the reason they were built is to show the light.. . Jim - Jameslwoodward (talk to me • contribs) 13:13, 30 April 2013 (UTC)

Precision problem

Resolved

Hi, I have encountered a problem that I can't figure out how to solve, and would greatly appreciate any help. I hope I'm addressing the right forum. I'm trying to add infoboxes for some articles about castles in Estonia - the one I try to fix is Purtse Castle. The infobox I'd like to add is Template:Infobox military installation.

When I try to add coordinates under |latitude = |longitude = I can't get them precise enough. It seems to be (although I'm not sure where the fault is) that somehow only the four first digits (i.e., in this case, 59.25 for lat and 27.0 for long) is being read. This places the marker on the map (both the location map and e.g. Google Earth) quite far away from the castle. I'd like to get the whole set of coordinates in, and still keep the location map, but right now I'm not sure what to do - nothing seems to make the map react... ;)

Yakikaki (talk) 16:34, 29 April 2013 (UTC)

The "latitude" and "longitude" fields take decimal coordinates, and it seems you were trying to add coordinates in degrees and minutes to them (that is, whereas the latitude is, roughly, 59°25', you entered that as 59.25 instead of, roughly, 59.417). Minutes are sixtieths of degrees, not hundredths of degrees, so degrees & minutes & seconds are not numerically equivalent to degrees & decimal fractions. I've readded the infobox to Purtse Castle, giving the coordinates in decimal form; is it better now? Deor (talk) 17:37, 29 April 2013 (UTC)

Aha! Thanks a million times, that explains a lot :) Now it looks the way it should! Yakikaki (talk) 17:42, 29 April 2013 (UTC)

Wikimapia behavior

Lately (for at least the past couple of weeks), when I access Wikimapia through GeoHack by clicking on the coordinates in an article, I get, not a satellite view of the location indicated by the coordinates, but a satellite view of my own location. This happens with different computers in different cities, so it's not just my computer. Any idea what's behind this? Deor (talk) 14:36, 19 March 2013 (UTC)

It seems to work okay for me. What do you see when you select Wikimapia | Map from this?

I still see a satellite view of my own location. For what it's worth, the only browser I've used (the only one available to me just now) is IE. Deor (talk) 18:43, 19 March 2013 (UTC)

If it is a mobile device set to share its location with apps, maybe try disabling location sharing. Also, perhaps there is a Wikimapia setting to overlook the device's location, though it is hard to see how that would override given a specific location. Maybe give more details about your setup? —EncMstr (talk) 20:34, 19 March 2013 (UTC)

Seems like an issue at wikimapia. The url we use is www.wikimapia.org. This now gets redirected to wikimapia.org and that causes the location information to get lost apparently. —TheDJ (talk • contribs) 20:54, 19 March 2013 (UTC)

Hmm ... well, last night while I was sleeping, my old IE8 was updated to IE10 and the problem went away. But it was there when I was using my parents' IE10 last week. So I'll just put this one down, as I do so often, to the magical behavior of computers. Deor (talk) 16:25, 22 March 2013 (UTC)

Geohack on mobile

I don't know whether this is the right department but speaking of mobile and Geohack, isn't that an awfully busy page to see on a small screen? The difficulty is mild on my 10 inch Android Galaxy Tab but severe on my 4 inch phone. Better to offer 4, 6, 8 or other small number of choices, and "more" for users who want one of the less popular tools. And, for user devices having internal mapping facility such as internal Google Maps, make that the most prominent. Jim.henderson (talk) 00:04, 6 May 2013 (UTC)

VisualEditor is coming

The WP:VisualEditor is designed to let people edit without needing to learn wikitext syntax. The articles will look (nearly) the same in the new edit "window" as when you read them (aka WYSIWYG), and changes will show up as you type them, very much like writing a document in a modern word processor. The devs currently expect to deploy the VisualEditor as the new site-wide default editing system in early July 2013.

About 2,000 editors have tried out this early test version so far, and feedback overall has been positive. Right now, the VisualEditor is available only to registered users who opt-in, and it's a bit slow and limited in features. You can do all the basic things like writing or changing sentences, creating or changing section headings, and editing simple bulleted lists. It currently can't either add or remove templates (like fact tags), ref tags, images, categories, or tables (and it will not be turned on for new users until common reference styles and citation templates are supported). These more complex features are being worked on, and the code will be updated as things are worked out. Also, right now you can only use it for articles and user pages. When it's deployed in July, the old editor will still be available and, in fact, the old edit window will be the only option for talk pages (I believe that

WP:Notifications

(aka Echo) is ultimately supposed to deal with talk pages).

The developers are asking editors like you to join the alpha testing for the VisualEditor. Please go to Special:Preferences#mw-prefsection-editing and tick the box at the end of the page, where it says "Enable VisualEditor (only in the main namespace and the User namespace)". Save the preferences, and then try fixing a few typos or copyediting a few articles by using the new "Edit" tab instead of the section [Edit] buttons or the old editing window (which will still be present and still work for you, but which will be renamed "Edit source"). Fix a typo or make some changes, and then click the 'save and review' button (at the top of the page). See what works and what doesn't. We really need people who will try this out on 10 or 15 pages and then leave a note Wikipedia:VisualEditor/Feedback about their experiences, especially if something mission-critical isn't working and doesn't seem to be on anyone's radar.

Also, if any of you are involved in template maintenance or documentation about how to edit pages, the VisualEditor will require some extra attention. The devs want to incorporate things like citation templates directly into the editor, which means that they need to know what information goes in which fields. Obviously, the screenshots and instructions for basic editing will need to be completely updated. The old edit window is not going away, so help pages will likely need to cover both the old and the new.

If you have questions and can't find a better place to ask them, then please feel free to leave a message on my user talk page, and perhaps together we'll be able to figure it out. WhatamIdoing (talk) 01:03, 7 May 2013 (UTC)

Correction: Talk pages are being replaced by mw:Flow, not by Notifications/Echo. This may happen even sooner than the VisualEditor. WhatamIdoing (talk) 14:27, 7 May 2013 (UTC)

Wikidata, {{coord}}, and OpenStreetMap relations

Now Wikidata Phase II has arrived, we're beginning to reach a turning point in Wikipedia's integration with other geodata sources. In particular, we should think about how article coordinates, particularly the display=title coordinates, should be transcluded to/from Wikidata.

In the very short term, we've now got a really interesting opportunity to add something beyond just a point to our geodata functionality. If you look at the London article, you can see that its Wikidata node is Q84, and that that has a property P402, with the name "OpenStreetMap Relation ID", with a value of 65606, which can be used to generate the link http://www.openstreetmap.org/?relation=65606 , which leads us to a map of London that shows the administrative boundary defined by that OSM relation. As you can see here, hundreds of articles now have this parameter available. This goes way beyond anything we've been able to do before: it shows not only the location, but also the shape and size of London. This is massive progress, and, excitingly we could use this for many other features, with very little work, by doing just the following:

• Firstly, generating an extra parameter for the geohack URL, with the OpenStreetMap relation in it. For example, instead of

  http://toolserver.org/~geohack/geohack.php?pagename=London&params=51_30_26_N_0_7_39_W_type:city%288173194%29_region:GB

  as the link at the head of the London article, we could generate this:

  http://toolserver.org/~geohack/geohack.php?pagename=London&params=51_30_26_N_0_7_39_W_type:city%288173194%29_region:GB&OSMrelID=65606

  Because the proposed OSMrelID parameter would just be a new HTTP GET parameter, the current geohack software just ignores it, and no damage is done.
• Secondly, augmenting the Geohack page's code to interpret the OSMrelID field, so that we can provide a map of London's geographical boundary in the OpenStreetMap link from that page.

Now, I believe it may be possible to do the first entirely within the {{coord}} template, using the built-in resources of Wikiadata Phase II and the Lua code that defines the template. If so, we could do this for every article with a coord template in one go, generating the OSMrelID parameter if the article's Wikidata node has one, and doing nothing if it does not. If I'm right, no further human intervention or bot work should be needed to make this work for every article with this relation defined, it should "just work". Once that's in place, modifying the geohack page should be trivial.

Doing all of the above now generates a virtuous circle. By providing an immediate visible benefit for this data, it will encourage third parties to add relation data to OpenStreetMap, that can then be harvested and added to Wikidata, that will then appear in Wikipedia's geohack pages, without any need for further intervention here.

Since as far as I can see this appears to have nothing but upside, and no drawbacks other than the need for some careful coding and testing before we go live with this on a template used in around a million articles, I can't see any reason not to do this, unless others here have other opinions. I'd be interested in hearing from others on this. -- The Anome (talk) 21:34, 26 April 2013 (UTC)

The first is definitely practical - assuming the ongoing RFC closes in favour of Wikidata within templates - and I think you're right that it could well be a virtuous cycle. It'd be a good first test before doing anything very ambitious with the coordinate data itself, once that's ready :-) Andrew Gray (talk) 22:04, 26 April 2013 (UTC)

Given the apparent consensus that appears to have evolved at the RFC, it looks very likely that it is going to be closed in favor of option 4 for templates, which would allow this. -- The Anome (talk) 07:33, 28 April 2013 (UTC)

Agree on the trend, I just didn't want to sound overconfident :-) Andrew Gray (talk) 07:37, 29 April 2013 (UTC)

The Toolserver tool coord-enwiki.log is currently showing "OSMrelID=65606" as a "bad parameter" in the London article. Presumably the tool will need to be altered or something before whatever change The Anome is talking about (which passes my understanding) is rolled out big-time, or the tool will become useless for identifying actual {{coord}} problems. Deor (talk) 12:04, 27 April 2013 (UTC)

A good point. That's a third thing that will need fixing. (As a stop-gap solution, I've just nokwiki'd the URL links above to take it out of the error log when the next analysis pass is run.) But I don't see this as insuperable: these are all very small changes, and if we have a consensus that this interface change to the URL parameters would be a good idea, implementing all three should not be a problem. -- The Anome (talk) 07:30, 28 April 2013 (UTC)

IIRC from my involvement in OSM, OSM ids are relatively volatile compared with those in other databases (like WP). While relations are probably the most stable of them, things like ways and nodes routinely change ids when they are split, combined, etc., which happens for many more reasons in OSM than one would initially think (e.g. changes in speed limits, lanes, and many other properties of ways, etc.) By definition, there is no significant attempt made to retain ids. For that reason, we generally thought that OSM should host IDs relating out to other databases, not the other way around. —[AlanM1(talk)]— 17:03, 30 April 2013 (UTC)

This is a terrible idea! Please inform yourself about the existing efforts for connecting OSM and Wikipedia data. We have the wikipedia key in OSM, and the WIWOSM project that connects the data. This avoids the OSMID craziness and is much more flexible. It is simply frustrating that this secondary method was proposed without doing any research. Now the ball is rolling and there is most likely no way to stop this idiocy. :-( --Dschwen 16:14, 1 May 2013 (UTC)

No ball is rolling. yet: the whole idea of posting this here was to elicit comments before doing anything on a larger scale. This is the research. If you can suggest a better venue to raise this, please let me know.

Fundamentally, I'm interested in functionality, and any particular implementation is only a means to an end. The need here is for a way to provide backreferences from Wikipedia to OSM, by somehow keeping an inverse mapping from Wikipedia/Wikidata entities to OSM features, so that maps such as the map accessible from d:London can be displayed easily and consistently. After reading your concerns about this, I can see that your objections to this particular way of doing things are entirely reasonable, and I agree that storing OSMIDs in Wikidata isn't the right way to do it.

However, if storing the reverse mapping data in Wikidata won't do the job, then we should find another way to do this, Perhaps the way to do this is to (1) just store in Wikidata the fact than an OSM -> Wikipedia mapping exists (which is only a hint, and in any case very likely to remain stable), and then (2) for OSM themselves to run the service that performs the reverse mapping, by implementing a URL such as, say, http://www.openstreetmap.org/?mapping=wikipedia:London to display the relevant features that are tagged for the London article? Since OSM themselves hold the master database, it would be a simple matter for them to maintain an inverted index, and expose this through their UI. Perhaps they have done so already -- but if so, I haven't been able to find it.)

For example, perhaps we could define a property in OSM_mapping_exists in Wikidata, and set it to "true" whenever such a mapping exists in OSM's database. Once this is done, the {{coord}} template could just pass in an extra HTTP parameter to the geohack URL that says "OSMfeature=yes", and geohack could then add an extra link to the OSM row in the table that requested display of the features tagged to that article, by tag, not by OSMID. (Alternatively, we could just make geohack Wikidata-aware, and get it to query that flag directly.

By the way, regarding Wikidata property P402: you might want to take this up with the people at Wikidata who created it, and are adding these data points, and find out how far they've got. If this is a thing that needs to stop, and be replaced by something better, we should enlist their help to do so. I've made a comment at http://www.wikidata.org/wiki/Wikidata:Project_chat#Property_P402_and_OpenStreetMap to get the conversation started there. -- The Anome (talk) 10:29, 3 May 2013 (UTC)

We could explain the issue to our friends at OSM, and see whether they can come up with a solution for providing more permanent UIDs for objects they map. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:18, 3 May 2013 (UTC)

On review, https://wiki.openstreetmap.org/wiki/WIWOSM -- written by our old friend kolossus -- seems to be the way to go here. Adding an annotation into Wikidata that a particular item has a WIWOSM tag should thus be enough to get what we need. -- The Anome (talk) 14:11, 3 May 2013 (UTC)

That's a neat tool, but I don't see how it obviates the need to record UIDs in Wikipedia, so that they are available in database dumps, as linked data, and to API users. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:54, 3 May 2013 (UTC)

Yes, it is. The key thing here is that property P402 abuses OSM's data model by relying on something which is not guaranteed to be stable. The fact that they have been more-or-less stable, historically, is no guarantee that they either will or should stay stable. In programming terms, it's like using an undocumented API, or, worse, holding a pointer into someone else's address space, and expecting them to keep the data you found at that location not only stable, but also in the form you wanted it. If we use this, this way, we are either building up a reservoir of potentially bad data, or effectively holding another free knowledge community to ransom by forcing them to use OSMIDs in a way that they were never meant to be used. -- The Anome (talk) 10:05, 4 May 2013 (UTC)

It looks like Wikidata held a deletion discussion for P402, and closed it two days ago, while we were still discussing this here. I've asked for it to be re-opened there, so we can get some more views on this. I can't stress too much that I'm not trying to stop this linkage of Wikidata and OSM -- as you can see above, I'm really enthusiastic about it -- I'm trying to do it right, and, as I've now discovered, P402 is, alas, part of the problem, not part of the solution. In the meantime, I'll do some more research, and see if there are any ideas already floating around for how to do this with a proper linked data solution, beyond just using WIWOSM as a run-time hook. -- The Anome (talk) 10:05, 4 May 2013 (UTC)

I'm also a little bit frustrate how it could come to P402. I would wait with the next deletion request until we have coordinates support inside WikiDATA, which should come soon. I think behind the coordinates we will have services like Geohack and a map. The map will support WIWOSM and so P402 will be obsolete. --Kolossos (talk) 13:08, 1 June 2013 (UTC)

In the discussion comes the question if there an API exist, for the way we go with WIWOSM and I want answer this question:

As API everone can use http://toolserver.org/~master/osmjson/getGeoJSON.php?lang=LANG&article=ARTICLE to get a geojson file. Everyone with Toolserver-Account has database access, everyone can use OSM planetfiles. OpenStreetMap provide with the overpass-API an easy to access the information. So I see no reason to store this information inside Wikidata. With WIWOSM it's for us also easy to integrate later Wikidata-Tags for objects without an Wikipedia article. --Kolossos (talk) 13:08, 1 June 2013 (UTC)

Discussion on OSM mailing list

There is also a discussion of this topic on the OSM mailing list: see here. In particular, see which is talking about exactly what I described above.

Quoted from this this email:

"I am less concerned about the Wikidata side - if they make a bad judgement then it is their mess to clean up. I am however concerned that if more people simply assume that the status quo is there to stay ("IDs are stable enough"), this will put pressure on *us* and limit our flexibility in the future.

I fear that some day soon we'll have a good idea about re-organising our admin bounds that involves large-scale changes, and then people come to us and say "ah, that's unfortunate because we at [insert some other project or product or company] had assumed that relation IDs are relatively stable...".

And from this:

"A physical object will not always correspond to the same OSM ID. It is this last property that matters for external links. As an example, a particular Lowe's home improvement store near me used to be OSM node 1498097430 and now is OSM way 136961700. When I get new imagery for the area and re-trace the building depending on what is easiest I may end up creating a new way.

Relying on the OSM representation of some real-world object to maintain the same ID is wrong. There is no property of OSM IDs that allows you to say that Joe's coffee shop will continue to be node 123."

These are from active participants in the OSM project, who I would hope would be in a better position to understand OSM's workings than others. People have also been proposing alternative implementations for linking OSM to Wikipedia/Wikidata: see [8], and [9]. -- The Anome (talk) 10:57, 6 May 2013 (UTC)

Edit request on {{Decdeg}}

There's an edit request here requesting to replace this rather complex template with a new Lua one. I'm happy to put it through, but there's been no discussion, and I don't really understand it well enough to be confident switching it in a template used 13000+ times. Could someone take a quick look and confirm all is well? Andrew Gray (talk) 22:49, 29 April 2013 (UTC)

More eyes would be welcome. The Lua code Andrew refers to is the dms2dec function at Module:Coordinates. See also: Template:Decdeg/testcases. —hike395 (talk) 01:33, 30 April 2013 (UTC)

Given the lack of response from Lua experts, it might be worth mentioning your request at

WP:VPT. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

10:40, 6 May 2013 (UTC)

I left my review over at the template talk. — Bility (talk) 19:31, 8 May 2013 (UTC)

Help needed

Recent changes to {{Infobox Australian place}} have caused many articles containing the template to display overlapping title coordinates, so that the population of Category:Pages with malformed coordinate tags is now well over 1,000. Help with cleaning this up would be appreciated. Could a bot perhaps be used to strip the redundant {{coord}} templates from the articles in question? Deor (talk) 13:59, 16 May 2013 (UTC)

Anybody? It seems that this would be an easy task to automate: Search articles containing {{Infobox Australian place}}; if the "latd" and "longd" infobox fields contain numerals and there is a {{coord}} template in the article, delete the {{coord}} template. (Won't get all of them, since a few contain {{Mapit-AUS-suburbscale}} rather than {{coord}}; but would reduce the backlog to practically nil.) Deor (talk) 14:07, 17 May 2013 (UTC)

All  Done mostly by self and

talk · contribs) - there may have been others. I don't think I've made 1000 edits in 24 hours 2 minutes before. And all without AWB too. --Redrose64 (talk

) 16:02, 18 May 2013 (UTC)

Thanks. One thing I noticed is that, although it may not be intended to be so used, the infobox is being used in some cases for islands, topographic features, and the like. For that reason, it probably needs a "coordinates_type" or similar field that can be used to override the "city" type that it currently applies to everything. Deor (talk) 20:12, 18 May 2013 (UTC)

Such instances should be replaced in articles by {{

Infobox island}} or another subject-specific infobox (which should first be modified if and as required). Remaining instances should then be replaced with {{Infobox settlement}} and finally the location-specific template should be deleted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

20:18, 22 May 2013 (UTC)

These Australian-specific templates are quite problematic - there's no reason why there needs to be a separate template for Australian places. --Rschen7754 07:35, 9 June 2013 (UTC)

Wikidata geocoordinate datatype is live

That is a game changer, and everything remains to be done. A first thread has been created d:Wikidata:Project chat#When should we use point coordinates ?. We need more people to contribute their thoughts and skills there ! --Superzoulou (talk) 08:38, 13 June 2013 (UTC)

Bot run to remove extra {{coord missing}} tags

Maybe it's just recently, but I've come across quite a few articles with the {{coord missing}} tag that already have coordinates in the article (someone added them but did not remove the tag). I don't know who to ask, but can we have a bot go through and remove the unneeded tags in articles already with {{coord}} in them? Spencer^T♦C 16:16, 20 June 2013 (UTC)

That sounds like a task for

talk · contribs) --Redrose64 (talk

) 17:15, 20 June 2013 (UTC)

Dispatch article

Coordinates in infoboxes are discussed, very negatively, at Wikipedia:Wikipedia Signpost/2013-07-10/Dispatch. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:58, 12 July 2013 (UTC)

Infobox dam

Could someone who understands template coding take a look at the edit made today to {{Infobox dam}}? The template's documentation advises users to fill in the "coordinates_type" field with "type:landmark", but the articles in which that occurs are now thowing up an error as passing a double "type:type:" to the coordinates template. (Click on the coordinates in either sample infobox at Template:Infobox dam/testcases to see the problem.) It's a minor problem, I guess, but since I don't understand the reason for the edit to the template in the first place, I thought I'd better ask rather than just revert the edit. Deor (talk) 10:54, 20 July 2013 (UTC)

(Taps microphone.) Anyone? I hesitate to mess with the infoboxes that are producing error messages lest someone revert the template code, so that my changes will result in new errors. Deor (talk) 12:44, 21 July 2013 (UTC)

I left a note on the talk page of the editor who made the change. Zero^talk 12:54, 21 July 2013 (UTC)

Thanks. I guess I should have done that myself, though the editor hasn't edited here since the edit in question, and his user page says that he's mainly active on jp.wp. Deor (talk) 13:57, 21 July 2013 (UTC)

Old geohack links

The support for geotemplate pages has recently moved to the tools.wmflabs.org server. As of 19 August, there are still quite a lot of pages that appear to contain hard-coded geohack URLs pointing to the old toolserver.org server: see this external link search for a list. These should be fixed, as I believe the old toolserver is not going to be guaranteed to be supported for much longer, and hardcoding URLs like this is in any case inelegant and not particularly metadata-friendly. Only the article space pages really need fixing: at a guess, there seem to be a couple of hundred or so of these.

Does anyone know if the {{coord}} template, or some variant thereof, can be persuaded to give the effect desired in these articles? If not, what, short of the easy short-term solution of just search-and-replacing the old URL path with the new, would other editors recommend be done with these links?

Once we have a consensus on this, I will, of course, be happy to make the necessary bulk editing changes with the Anomebot. -- The Anome (talk) 18:44, 19 August 2013 (UTC)

A large number are for football clubs, and {{Coord}} can be used. For example, this change will work, when this edit request is actioned. I've also manually replaced a couple of one-off examples with {{Coord}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:45, 19 August 2013 (UTC)

It looks like we've got rid of all that aren't either a football club or on a talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:00, 19 August 2013 (UTC)

Alas, your change to Bardon Hill F.C. doesn't work as I think you intended: the template does not have a "coordinates" parameter, and so the coordinates are thus simply ignored, and displayed nowhere, neither inline nor as a title. -- The Anome (talk) 21:25, 19 August 2013 (UTC)

Try reading that again (hint: especially the "when this edit request is actioned" bit) ;=) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:45, 19 August 2013 (UTC)

I missed that link: you're quite right. I stand corrected. -- The Anome (talk) 10:33, 20 August 2013 (UTC)

No worries. Looks like there'll be a delay while we wait to see if anyone objects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 22 August 2013 (UTC)

@The Anome: Now done; see Bardon Hill F.C.. Go get em! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:18, 22 August 2013 (UTC)

Like this? --Redrose64 (talk) 18:53, 22 August 2013 (UTC)

Spot on. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:00, 22 August 2013 (UTC)

I think we should use only inline display (example) on these rather than "inline,title", as the coordinates are for the ground the club plays home games on rather than for the club itself (whatever coordinates for a club might mean). I seem to recall seeing a discussion about this somewhere; I'm unable to locate it at the moment, but I assume it's the reason why the GeoHack links were used in the first place rather than the {{coord}} template. I'll look around some more to see if I can locate the discussion. Deor (talk) 19:51, 22 August 2013 (UTC)

Mobile: 'Title' coordinates not showing

There's an issue with coordinates not showing in mobile; please see

WP:VPT#Mobile: 'Title' coordinates not showing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

12:51, 26 August 2013 (UTC)

Links to Google Maps

In a similar vein to the above, we have a lot of links to maps.google.com pages; I've recently removed many that were hard-coded, with variables for coordinates, from templates (replacing them with {{Coord}} of they didn't already have one). Is it possible to configure that search for article space only?

A whole series on Japanese mountains, for instance Mount Shunbetsu, and another on US roads, e.g. Utah State Route 210, and other, individual articles, even use the Google Maps home page as a reference; a bot could usefully remove these (perhaps excluding any page with "map" or "google" in its name).

Some articles, e.g. Prince Edward Islands, cite a specific Google Maps URL/ point. Others, like Whitecliffs Branch, use them as external links.

In other cases (and perhaps for some references), it may be more appropriate to replace the link with a {{Coord}} template. Does anyone with the necessary scripting skills want to work on this? (I'll link to this discussion from some related project pages) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 25 August 2013 (UTC)

My immediate comment is linking to simply maps.google.com isn't helpful, but Google Maps can serve a role as a reference if used properly (for example, FA U.S. Route 41 in Michigan). Chris857 (talk) 17:08, 25 August 2013 (UTC)

That's a useful example, thank you. In what way could it be detrimental to replace that citation with an instance of {{Coord}}, using the same coordinates, and marked up as a reference? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:16, 25 August 2013 (UTC)

I don't have any examples immediately on hand, but I seem to recall a few articles that use a Google-derived distance measurement aka linking to a series of points, instead of a single point like coord is suited for. Maybe @

WP:USRD. Chris857 (talk

) 17:25, 25 August 2013 (UTC)

The various highway articles would have verification issues if the citations were altered. There are 17 FAs and over 180 GAs for the state of Michigan that use Google Maps citations that can't be converted over to coord for two reasons. The first is that we're using their aerial imagery to include additional detail about the environment surrounding the road, details that can't be sourced directly to the paper maps alone. Secondly, we're using their driving directions to plot/match the route of the highway on the map, something that {{

Bing maps}} for the same function. Imzadi 1979 →

17:35, 25 August 2013 (UTC)

Thank you, that makes sense. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 25 August 2013 (UTC)

I would have to agree, why is this change desired? --Rschen7754 17:38, 25 August 2013 (UTC)

The first reply that springs to mind is that google maps is so notoriously unreliable - witness, to take one single example, the very poor overlay of the geographic map on the satellite images (which is correct?); second, that it contains user-contributed content; and third, that any satellite imagery is a primary source, and any description based on it is

WP:OR unless published in an independent reliable source - in which case, that source and not the satellite image should be cited here. Justlettersandnumbers (talk

) 11:44, 27 August 2013 (UTC)

Non-specific links

What about the references that cite the Google Maps home page? What about the inclusion in external links sections? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 27 August 2013 (UTC)

Well, I don't actually know what you mean by "Google Maps home page". As far as I know it doesn't have one, but instead allows each user to configure her or his own. If I follow the "Google Maps" link in Mount Shunbetsu, I am taken, just as I would expect to be, to a detailed map of the location that I have defined as my home, which as it happens isn't anywhere near Mount Shunbetsu, or even in Japan. I suggest that any such links should be removed, whether they are refs or EL. The question of whether Gmaps should be allowed as an external link in general is one I'm going to leave to wiser heads than mine.

I see another problem, though. I don't know about others, but if I need to find the coords of a landmark I don't go and look it up in a reliable source. I go on Gmaps, do "What's here", round off some insignificant figures, and paste the result into a {{coord}} template or whatever. At that point I might just well cite the webpage, I think? Justlettersandnumbers (talk) 22:08, 27 August 2013 (UTC)

I mean that the URL is given as http://maps.google.com, with no parameters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:54, 30 August 2013 (UTC)

Yes, that's what I thought you meant. It's beyond me to understand how that link could be expected to convey any useful information since Google tailors content for it based on the user's preferences (and probably on her brand of toothpaste too). It appears completely useless and potentially misleading. It should go. Justlettersandnumbers (talk) 22:12, 30 August 2013 (UTC)

For the set of articles about Japanese articles, here's a sample removal. A job for a bot, or someone with AWB, perhaps? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:34, 31 August 2013 (UTC)

Alerts

cardinal points seem confused. In ictu oculi (talk

) 05:08, 8 September 2013 (UTC)

GeoGroup Template URL encoding errors

There are URL encoding problems in the GeoGroup Template: can anybody have a look? Thanks, Pietro (talk) 22:30, 9 September 2013 (UTC)

Looking at that page, I think this has been fixed. -- The Anome (talk) 14:16, 17 September 2013 (UTC)

Articles missing coordinates by view popularity

This: http://wikistics.falsikon.de/latest/wikipedia/en/topics/Coord_missing.htm looks like a nice resource for finding popular pages which are missing coordinates. Alas, its data is very outdated, dating back to 2009, so it's not currently of any use.

Given that up-to-date data appears to be publicly available from the WMF here, it would be interesting to see if this approach might be used in a more up-to-date way for prioritizing pending tasks for this and other topics. -- The Anome (talk) 14:06, 17 September 2013 (UTC)

I'll have to be done on our own dime. Minimum Storage: (4 bytes–daily count + 4 bytes–page id + 2 byte-date offset) × 356 days/year × 4.3 million articles = 16 GB/year. This doesn't include database overhead (multiply by 3) and indexing (multiply by 4). Plus we'd like more than 1 year and not just enwiki. If the Toolserver had the space I would've done it. Not even WMF's bastard project Labs can offered me 1 TB of non-backed-up storage. — Dispenser 04:58, 6 October 2013 (UTC)

More regarding my ignorance of templates

Template:Infobox Province of China (PRC) is a wrapper for Template:Infobox settlement; however, it automatically passes the type "city" for the coordinates and won't accept any other type or other coordinate parameters. Could someone fix the template code so that it will accept the settlement infobox's "coordinates_type" field with "adm1st" as the default type, since it applies to all Chinese provinces, and to allow a scale or dim parameter to be used? Deor (talk) 10:54, 20 October 2013 (UTC)

 Done I added three more parameters: {{{coordinates_type}}}, defaults to adm1st, {{{dim}}}, and {{{scale}}}. As an added bonus, the template automatically computes {{{dim}}} from {{{Area_km2}}}, so you probably won't need to override it. —hike395 (talk) 15:55, 20 October 2013 (UTC)

Many thanks. That automatic calculation of "dim" seems to work well. Deor (talk) 17:41, 20 October 2013 (UTC)

Google Maps removed Wikipedia Layer

In August 2013, Google Maps removed the Wikipedia Layer. Google Maps Drops Wikipedia Layer.

Search Engine Roundtable. (September 10, 2013). -- Jreferee (talk

) 13:55, 5 October 2013 (UTC)

Yep. That's pretty annoying. There are numerous forums which people are quite critical of Google for the way they handled it.

Google Earth still has a Wikipedia layer though. It's under "More" between "Traffic" and "DigitalGlobe Coverage". —EncMstr (talk) 00:13, 6 October 2013 (UTC)

See also: Wikipedia_talk:Wikipedia_Signpost/2013-09-11/In the media#Google Maps drops Wikipedia. --Atlasowa (talk) 09:25, 6 October 2013 (UTC)

Alas, in places like Lower Manhattan where articles with coords are rife, GE only shows me some ten or fifteen percent of them. Even zoomed in on an area around Wall Street that must have more than thirty tagged articles, Earth shows half a dozen. My hopes, slim as they are, are on OSM or some similarly Wiki-related mapper. Jim.henderson (talk) 20:01, 6 October 2013 (UTC)

WikiMapia. However, it looks like Google itself added Wikipedia to its maps in April 2008.[11] Per Wikipedia:Wikipedia Signpost/2012-04-09/Technology report, Wikipedia replaced Google Maps with OpenStreetMap as the base map provider for an official Wikipedia app in 2012. Does anyone know if Google Maps removed the Wikipedia Layer due to something within Wikipedia? Do we have any contacts at Google Maps to find out what happened and see if there is something we can do on our side to help get the Wikipedia Layer back on Google maps? -- Jreferee (talk

) 10:07, 7 October 2013 (UTC)

I just found Category:Wikipedians who contribute to Google Map Maker. I'll ping them in hopes they can answer why Google Maps removed the Wikipedia Layer and if there is something Wikipedia can do on our side to help restore the Wikipedia Layer to Google Maps: User:AlanM1, User:Captain Assassin!, User:Kittsville, User:Macedonicus, User:Nickvet419, User:Rahman.safwan. -- Jreferee (talk) 03:18, 22 October 2013 (UTC)

I don't know what happened but I can ask the Google Team for more information. I will copy their response here, but it might take a few weeks since they don't reply very frequently. Macedonicus (talk) 13:11, 22 October 2013 (UTC)

Google Maps contributing Wikipedians have no special place/authority in Google beyond regular people, we're just an intelligence swarm that contributes to the accuracy of Google Maps data. However, over on the Map Maker Product Forums someone asked this very question and while there was no proper answer from Google there are a few useful links in between the avalanche of complaints.Kittsville (talk) 22:25, 27 October 2013 (UTC)

Can't be sure without their response but I think it has to do with their new map look and bringing back google map icons. Many features that were once part of the maps are no longer a part of the new maps. The wikipedia links are still available in the google earth program and licked to search info boxes. --Nickvet419 (talk) 03:51, 6 November 2013 (UTC)

Coordinate-checking tools

The tools coord-enwiki.log and glupt.log, linked above in the "Fix" section under "To do", seem to have stopped working properly. They appear to be running on their once-a-day schedule; but coordinate problems that I fixed days ago are being relisted every day, and I can't tell whether they're actually picking up any new problems. Anyone have any ideas why this may be so? Deor (talk) 11:37, 10 November 2013 (UTC)

Yes: they run on Toolserver, which has been dying a slow death for well over a year. There has been plenty related to this at

WP:VPT. --Redrose64 (talk

) 23:04, 10 November 2013 (UTC)

Well that's not good; those tools catch a number of types of {{coord}} syntax errors that will otherwise go unflagged. Do you know whether there are any plans to migrate them to Wikimedia Labs or whatever the new tool system is called? Deor (talk) 00:08, 11 November 2013 (UTC)

Personally, no: afaik it's up to each individual tool owner to migrate their tools. There may be something in the VPT archives; or you could contact the tools' owner, Dispenser (talk · contribs). --Redrose64 (talk) 00:20, 11 November 2013 (UTC)

Coordinates in redirects

There are hundreds or thousands of articles on what the U.S. GNIS terms "populated places" that consist of nothing much more than "Populated Place X is an unincorporated location in County Y, State Z." Ninety-nine percent of these articles will never be expanded beyond stubs. It would be nice to be able to combine the content of these articles into a list in the superior political area article. In most cases, this will be the county article, but for some places it will be a township article or some other type of municipality. Is there a way to program coordinates for a location whose article title redirects to another article? The goal is to keep the coordinate functionality so an icon will appear in whichever mapping programs show Wikipedia icons, but eliminate the thousands of stubs that will never be expanded.  VC  21:41, 16 November 2013 (UTC)

Have a look at

Disused railway stations (Bristol to Exeter Line). Each station has a redirect pointing to that list article, and each has coordinates in the article itself. --Redrose64 (talk

) 23:03, 16 November 2013 (UTC)

That is a good example of what I am going for on the Wikipedia end. However, it does not fully answer my question. Do Wikipedia icons for the redirected items show up in mapping programs that have a Wikipedia layer? I cannot currently check myself due to computer issues, so it would be great if someone else could check in one or more of the relevant mapping programs. Granted, I question how useful that capability is since the one most people probably used, Google Maps, discontinued their Wikipedia layer a few months ago.  VC  04:47, 17 November 2013 (UTC)

Toolbox method for newbies

In discussing Wikipedia:Village pump (technical)/Archive 120#Can someone extract GPS coordinates from an article I started thinking, the methods that work for me are far too complex for people who haven't studied. There ought to be a Toolbox item, "Location" or some such name, leading to a world map. Zoom and scroll so the crosshairs hit the spot, and click the "Here" button. If the article already has an infobox calling for coords, it's filled in. If not, a Coord template goes at the bottom with the "Title" parameter. If the article already has coords, the map starts there and acts as a correction machine. Naturally some cases will be complex and call for the same old complex, manual methods, but most are simple. Jim.henderson (talk) 14:21, 25 November 2013 (UTC)