Wikipedia talk:WikiProject Geographical coordinates/Archive 26

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Returning to dispenser's daily error report after a short vacation, I find that it has lost much of its usefulness due to noise. The major noise sources are:

  1. Dutch villages using {{Infobox settlement}} with incorrectly-translated parameter names: Rich Farmbrough has kindly offered fix these.
  2. Warnings for combining dim: and scale: parameters: I don't think these are real problems. If they are, we should note this issue in the template documentation.
  3. Lost ships (so far only those whose names begin with "A") whose positions are being coded with {{coord|Unknown|S|Unknown|E|...}}.

The last of these points to a need for a way to code articles when the subject's location is unknown (and not easily found). I already discovered this need during my work on Category:California articles missing geocoordinate data where I ran into articles such as Astakiwi, California which state the the subject's precise location is unknown.

Applying {{coord missing}} to these would create problems because Category:Articles needing coordinates is a work queue that could become clogged up with articles of this sort. We already distinguish Category:Year of death missing from Category:Year of death unknown for much the same reason.

I think there ought to be a template to handle this situation. Does such a thing exist? If not, would anyone object to me creating one? --Stepheng3 (talk) 20:24, 12 October 2009 (UTC)

No objections, sounds like a plan. Should it be a template or merely a category? Hitherto, I've simply removed {{Coord missing}}, on the basis that The Anome's bot will not add it again. But I guess history will not entirely thank me for that approach. --Tagishsimon (talk) 21:26, 12 October 2009 (UTC)
I am definitely in favour of a template, that can be pasted over {{coord missing}} but a few thoughts. There is a difference between {{coord of things unknown}} and {{coord of things unknowable}}! There is a worry that articles could be wrongly tagged as unknowable that are later known. Also, what does unknown mean- unknown to me or to whom- do we have a UK copyright like situation, where one has to distinguish between photographs by a potentially known photographer and proveable unknown photographer.... But apart from that- good idea. --ClemRutter (talk) 23:11, 12 October 2009 (UTC)
Simon, I think a template would provide the most flexibility.
Clem, I'm thinking that {{coord unknown}} would mean we have a reliable source to indicate that the location of the subject is unknown (and no reliable sources giving a location). If the location later becomes known (i.e. a shipwreck or lost village located by archeologists) then we would just replace it with {{coord}}.
I'm not sure what you mean by things unknown and things unknowable. Would you be so kind as to provide examples of each so we can decide if such a distinction would be useful? --Stepheng3 (talk) 23:55, 12 October 2009 (UTC)
(EC)I think for our practical purposes, we might label articles as unknown, if the evidence of the article is that there is no consensus on location; or else we are certain that to all intent & purpose there is no current knowledge of the location. I think we have to rely on posterity to correct those things we've coorded as unknown when, for instance, the sites of the Massacre of the Ninth Legion, the Battle of Assandun or the Battle of Watling Street are discovered. Are there any unknowables out there? Sounds a category too far. Whatever, I think an unknown-at-this-point test needs to be established, or at least guidance given that difficult to coord is not the same as outright implausible. Meanwhile I'm good with a template; on reflection, it allows us to continue with subcategorisation by country, &c. --Tagishsimon (talk) 00:00, 13 October 2009 (UTC)
Fiddler's Green is fairly unknowable- then theres Camelot --ClemRutter (talk) 00:27, 13 October 2009 (UTC)
So's Valhalla and Heaven, but I don't think we'll be marking them with {{coord missing}}. Camelot may yet be discovered, not least when Arthur returns, ye of little faith. --Tagishsimon (talk) 01:34, 13 October 2009 (UTC)
{{coord missing}} quondam, {{coord}}que futurus. Deor (talk) 01:43, 13 October 2009 (UTC)
Clem: for cases like Camelot and Fiddler's Green where the mainstream view is that the locale is fictitious, I think we shouldn't supply a {{coord}} tag at all. If I saw {{coord missing}} on such an article, I would remove it.
Simon: I'd be okay applying {{coord unknown}} to Battle of Assandun because the location is disputed by mainstream sources, and to Battle of Watling Street because the location is only vaguely known (to a large multiple of the diameter). I'm fine with defining a county/region parameter as in {{coord missing}}, but I'm in no hurry to replicate the Category:Articles needing coordinates hierarchy. Let's wait until there are enough tagged articles to make such categorization worthwhile.
All: any other concerns I've missed? --Stepheng3 (talk) 04:13, 13 October 2009 (UTC)
No concerns: I mention such things now, so they can be used as what not to do examples in the template/documentation. --ClemRutter (talk) 08:41, 13 October 2009 (UTC)
I'm concerned that {{coord unknown}} isn't ready for me to apply to articles this morning; beyond that, I'm fine ;) --Tagishsimon (talk) 10:32, 13 October 2009 (UTC)

I've gone ahead and created the template and the category to go with it. I've documented the intended scope as carefully as possible, but I'm sure there'll be some controversial cases. --Stepheng3 (talk) 20:17, 13 October 2009 (UTC)

Thanks. I suggest per {{coord missing}} that {{coord unknown}} creates a hidden category. Thoughts? --Tagishsimon (talk) 22:38, 13 October 2009 (UTC)
I prefer having the category visible, but won't object if someone makes it hidden. --Stepheng3 (talk) 17:14, 14 October 2009 (UTC)
And running through my list of removed {{coord missing}}s, the following appear unsuitable for coords ... is there a case for {{coord unsuitable}} for entities which one might otherwise expect to have cooordinates? The following have all had {{coord missing}} removed; which category, if any, should each now be placed in - you can consider this a request for a second opinion on some of the removals?
Megatripolis, Clothes Show Live, The Harold Pinter Archive in the British Library, Cambridge Shakespeare Festival, Atlanta Fire Department, Revenue and Customs Prosecutions Office, International Futures Forum, UCLES, Northern Ireland Office, UKeU, Defence Research Establishments, Centre for Quantum Computation, Cathedral Close, Cambridge University Constabulary, Aeroplane and Armament Experimental Establishment]], Yeomanry Mounted Division, Upton Blues Festival, Oxford University Library Services, Oxford Libraries Information System, The Story Museum, Beargarden, Barnet and Chase Farm NHS Hospitals Trust (hospitals not the Trust need coords?), Anna Fiorentini Theatre and Film School (somewhat peripatetic), Wychert, McArthurGlen Group, Scotland's Malt Whisky Trail, Northern Ireland Parliament constituencies, Outer Pennine Ring, Queen's University of Belfast (Northern Ireland Parliament constituency) (not a physical entity), Science College, Schools of Ambition, Sailing barge Thalatta, Motorway service area, Hotel du Vin, Hogback (sculpture)

As we are in discussion mode- here are a few suggestion on whether and how

--ClemRutter (talk) 09:35, 14 October 2009 (UTC)

I generally agree with Clem's suggestions. We're not out to tag the entire wikiverse. If a subject is not suitable for coordinates (such as Motorway service area) then its article should not be tagged with {{coord}}, {{coord missing}} or {{coord unknown}}. --Stepheng3 (talk) 17:23, 14 October 2009 (UTC)
I've made some comments. I think that's it for me & geocoding. Bye. --Tagishsimon (talk) 09:25, 16 October 2009 (UTC)

dim: unit suffixes

Quite a few entries in Dispenser's list complain about dim having suffixes—which I thought were supported—the most common is km. I do remember having issues when adding cm, so I did leave it as dim:0.62cm in the end. But surely a km suffix should be completely understood and supported, right? —EncMstr (talk) 00:12, 13 October 2009 (UTC)

The only first & only discussion of Dim: I recall was at Wikipedia_talk:WikiProject_Geographical_coordinates/Archive_25#sk_geo_report where it talks about it being defined in metres, with the Mill Ends Park example of dim:0.61 (no suffix) being cited. It's not clear to me who implemented it in {{GeoTemplate}} --Tagishsimon (talk) 00:31, 13 October 2009 (UTC)
I think the km suffix on dim: was a good idea. It reduces the likelihood of data entry errors due to losing track of zeroes: for instance, typing dim:20000 when you meant to type dim:200000. Aside from documenting the feature, is any additional work needed to bring it up to snuff?
Meanwhile, let's hold off on adding other unit suffixes (such as cm) until a need is clearly demonstrated. --Stepheng3 (talk) 04:58, 13 October 2009 (UTC)
I implemented dim: into GeoHack just so we could start using it. I intend to eventually add support for units, km and m only. I would like to point out that there are tools aside from GeoHack which interpret the URL. The ghel parser (which produces those logs) is used to build a daily database. It divides the messages into two types "Error" (it doesn’t know what to do with it) and "Warning" (it understands it, but other programs might not be able to understand it). — Dispenser 05:07, 13 October 2009 (UTC)
I'd greatly appreciate it if you could implement the 'km' suffix, and also arrange to be able to tolerate an optional 'm' suffix: this would make dim: much more self-documenting: 'dim:100m' in the context of a large building, for example, is pretty much self-explanatory. I can't see any need for any other SI suffixes at the moment: as said above, 61cm is perfectly well codable as 0.61m, and things like 3000km are just fine for all earthly applications, in my opinion. -- The Anome (talk) 06:46, 13 October 2009 (UTC)

Loss of other information when moving coords to infobox

It's clearly not a good idea to have coordinates in an infobox and also in a coord template. But the coord template can also have other useful information like type, region and dim. Presumably the infobox could pass on this type of info to the embedded coord template but are the infobox templates actually set up to do so? If not, would each infobox template need to modified separately?--Cavrdg (talk) 15:45, 16 October 2009 (UTC)

Many infoboxes do accept the {{coord}} template whole (although, confusingly, some call the field "coordinates", some call it "coord", and at least one [Infobox University] calls it "coor"—I have to go to the template page every damn time to see what the correct field name is if an empty field isn't included in the article). Of the ones with "latitude" and "longitude" fields that pass the info to an embedded {{coord}}, some have additional fields for format, type, etc. (again, one has to go to the infobox's template page to check). Personally, if a particular infobox template doesn't accept the parameters I want to use, I just use a {{coord}} template outside the infobox. Deor (talk) 16:24, 16 October 2009 (UTC)
The better-quality infoboxes (such as {{Infobox settlement}}) already accept coordinates_type= which can be used to embed parameters such as type:, region:, and dim:. We should work to incorporate coordinates_type= into all infoboxes. (Though one might wish it had a more descriptive name.)--Stepheng3 (talk) 17:27, 16 October 2009 (UTC)

UK coord missing effort

In other news, and FYI, I put together a sortable table of progress on coords for the UK - Number of coord missing tags per UK category - which updates by use of PAGESINCAT. Some very good progress on some counties, such as Kent, Oxfordshire, Berkshire, Herefordshire. --Tagishsimon (talk) 01:28, 1 September 2009 (UTC)

This looks like a relaxing way of spending an evening. I think this would be easy to do if we had a Advice on how to geocode United Kingdom articles missing geocoordinate data as a brief glance shows that a large number of the missing tags are on the same type of article. It needs to say where to tag, and the precision to use. I have put together a draft- please add to it and quibble over the advice- when every one is happy, the page can be created.
Feature What to tag Degree of Precision Example
Parliamentary Constituencies Anywhere in the middle
Help: 2007 Constituency descriptions
Degs and mins only
-- deg(1 sig fig)
Chatham and Aylesford (UK Parliament constituency)
District Councils Anywhere in the middle maybe the council offices if known Degs and mins only
-- deg(1 sig fig)
Canals Anywhere significant in the middle Degs and mins sec
-- deg(4 sig fig)
Ashton Canal
Branch Canals A point near its mouth or a more significant point in the middle Degs and mins secs
-- deg(4 sig fig
Beat Bank Branch Canal
Libraries Reception on the largest site Degs and mins secs
-- deg(4 sig fig
Parks A significant point usually the big house Degs and mins secs
-- deg(2 sig fig
Lyme Park
Stations A significant point usually the booking hall Degs and mins secs
-- deg(4 sig fig
Chatham railway station
Schools Reception on the largest campus Degs and mins secs
-- deg(4 sig fig
St John Fisher RC Comprehensive School
--ClemRutter (talk) 12:59, 6 September 2009 (UTC)
--ClemRutter (talk) 15:23, 14 September 2009 (UTC)
Please see Wikipedia:WikiProject Geographical coordinates/Linear for linear features. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:29, 14 September 2009 (UTC)
Sure. I think everything here complies. That discussion seems to have gone quiet at the moment. In hitting Greater Manchester, most of the targets are schools, proposed railway stations, defunct councils with an occasional culverted river and unfinished branch canal. Do you disagree with any of the advice I have given above, if I have you endorsement I will write it up as a page. --ClemRutter (talk) 16:27, 14 September 2009 (UTC)
No disagreement: I was thinking that you might want to quote from, or refer to, it. You could also include rivers, which it has, but your table doesn't. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:15, 14 September 2009 (UTC)

Touch-to prevent archiving.--ClemRutter (talk) 08:25, 14 October 2009 (UTC) I have enough material hewre to put on a separate advice page. What should it my called- please give a suggestion. The best I have come up with is UK geo-coding: the missing manual but there must be a precedent- and then what namespace? If I can have a name I have the page ready in zero time. --ClemRutter (talk) 09:24, 22 October 2009 (UTC)

Out of this World

Just a heads-up: {{Coord}} is now emitted, with a "globe" parameter duly set, by {{Infobox crater data}}, {{Infobox Mars crater}}, {{Infobox feature on Venus}}, as well as many more artciles mentioning The Moon and our local planets. I'm also planning to add it to the Mars Geo family of templates. I've notified Google, so that they can be aware not to include them in Google Maps (and maybe do so in Google Maps Moon/ Mars instead).

Next, we need to suppress {{Coord}}'s microformat output for non-Earth bodies, or better yet, make it emit the draft non-Earth geo microformat instead. Anyone up for that? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:05, 22 September 2009 (UTC)

For what it is worth, Google's Wikipedia layer is not ignoring Mercury information, as of Oct. 22nd 2009; e.g., Arecibo Vallis is shown in Google Maps as being in the middle of Egypt. Andy, you might want to poke your contacts at Google again? LuisVilla (talk) 16:00, 22 October 2009 (UTC)

Subcategorization of Ireland coord missing articles by county

Category:Ireland articles missing geocoordinate data now has a set of per-county subcategories, which I hope will make geotagging these articles easier for editors with local knowledge.

Note that, as with other top-level country categories in this hierarchy, this is for the state of Ireland; for the counties of Northern Ireland see Category:Northern Ireland articles missing geocoordinate data.

I'm now beginning the process of re-filing some 1,400 articles currently in Category:Ireland articles missing geocoordinate data into their respective county subcategories. This will leave around 600 articles which will need to be sorted by hand into the county subcategories. -- The Anome (talk) 15:19, 21 October 2009 (UTC)

Update: It looks like a considerable number of the articles remaining in Category:Ireland articles missing geocoordinate data are actually in one of the six counties of Northern Ireland: I'll fix the recategorization code to detect these as well. -- The Anome (talk) 16:53, 21 October 2009 (UTC)
 Done. That now leaves around 360 articles in Category:Ireland articles missing geocoordinate data in need of county sorting and/or geocoding. -- The Anome (talk) 21:51, 21 October 2009 (UTC)

Australian electoral districts

It appears that there are authoritative sources for these areas, as least as of 2007, linked from http://www.aec.gov.au/electorates/electoral_dpm/index.htm and http://www.aec.gov.au/profiles/index.htm .

Although we can't use images of the maps themselves since they're copyrighted; and we can't use the GIS data either, since it is subject to a data licence, we should be able to use the maps as visual references for using our own judgment for locating the centres and approximate radii of these areas. -- The Anome (talk) 19:57, 10 September 2009 (UTC)

Well good luck with that. Sadly our antipodean friends seem to insist that their precious fscking electoral areas should not have geo-codes - [1]. Words fail me. If proponents of Geographical coordinates - readers of this page, for instance - do not enter into the discussion then the argument is lost. --Tagishsimon (talk) 00:47, 14 September 2009 (UTC)
I am inclined to geocode them, though the question isn't acute since readers can click on the listed included communities. Especially surprising to see opposers whose single member electoral constituencies have names, hence seldom wander far without changing their name. Contrast New York's 4th congressional district which no longer shares any ground or boundary with the constituency bearing the same number in the first half of the 20th century. Incidentally I would prefer that my home US State call this district "Hempstead" adopting Australia's system of named divisions, but of course that's a political question, not a Wikipedian one.Jim.henderson (talk) 02:55, 14 September 2009 (UTC)
We get similar coord-missing requests from Anoeebot on Category:Canadian electoral disricts and there are similar complications as those you describe re the 4th congressional district; a same-name riding's boundaries can change with each redistribution, ie. its centrepoint pretty much has to shift; determining it and citing that is hard to do; BCGINS and CGNDB (I think re CGNDB) reference Regional Districts of British Columbia|Regional Districts]] and I'd suppose Ontarian/Quebec/Maritimes counties. But they don't have electoral district coordinates becauase they constantly changed and aren't "gazetted". There will be legal descriptions, in any redistribution legislation/report, out there proscribing their boundaries, but that's a different thing. I'm not sure they're useful and certainly would take a lot of work (over time) to maintain and difficult to auto-update as seat distributions change. Averaging extreme-point coordinates won't work, ie.. to create a centre point, partly because of the irregular shape of most ridings. Sometimes they might coincide with a particular municipality (this is fairly rare though New Westminster (electoral district) comes to mind. One thing's for sure Yale (electoral district) in 1871 was a very different thing from what it was by the '30s; any coordinates provided would have to be put next to each election where the new boundaries of a redistribution came into effect, i.e. if the seat stayed the same. I think the best thing to do is to have Anomebot remove "coord-missing" from all electoral district articles, for all of the above reasons; taking it out is a nuisance since there's no citable source for the information it requests.Skookum1 (talk) 02:20, 29 October 2009 (UTC)

Datum

Is anywhere said that coordinates must be refered to a determinate datum (WGS84 datum, I think)? If not, it should be, to avoid bad geocoding. David Perez--80.24.28.31 (talk) 10:24, 24 October 2009 (UTC)

Yes; the {{coord how-to}} explicitly specifies the use of the WGS84 datum. -- The Anome (talk) 11:10, 24 October 2009 (UTC)

OK, thanks. David Perez--80.24.28.31 (talk) 19:01, 24 October 2009 (UTC)

Multiple Coordinates

With roads, rivers etc what coordinate is given: start, finish, middle? - can we give both in a header?
Can we give three? I'm thinking of the likes of the Fastnet race - can we give three in the header? ClemMcGann (talk) 02:03, 25 October 2009 (UTC)
Only one coordinate makes sense in a title. For roads, the current suggestion is to choose a point directly on the feature which is representative of the road, somewhere near its center, and not near any intersections which could make the point ambiguous. Other coordinates may appear in the article, but should not include a title coordinate (display=title or display=inline,title. Instead, use a named coordinate along with {{GeoGroupTemplate}}. Alas, I was not able to find an excellent example, but Vista Ridge Tunnels is close. —EncMstr (talk) 20:02, 25 October 2009 (UTC)
Thanks for the reply. With roads and rivers it makes sense. A reader can follow the coordinates through one of the mapping sites and see the feature on a map. However to return to my particular question, what would you recommend for the Fastnet race? It starts at Cowes 50°45′34″N 1°18′1″W / 50.75944°N 1.30028°W / 50.75944; -1.30028, rounds the Fastnet Rock 51°23′3″N 9°36′1″W / 51.38417°N 9.60028°W / 51.38417; -9.60028 and then finishes at Plymouth 50°22′17″N 4°8′33″W / 50.37139°N 4.14250°W / 50.37139; -4.14250.  ? ClemMcGann (talk) 22:12, 25 October 2009 (UTC)
On looking at your example Vista Ridge Tunnels - where are the instructions to get google&bing to display both points? ClemMcGann (talk) 22:15, 25 October 2009 (UTC)
It's the {{GeoGroupTemplate}} at the top of the wikitext. —EncMstr (talk) 16:33, 26 October 2009 (UTC)
Look at the section #UK coord missing effort above, where a lot of the work has been done- I am waiting for a suggestion for a page name, then I will put together further suggestions that can be discussed. --ClemRutter (talk) 09:11, 29 October 2009 (UTC)

Airports without coordinates

User:The Anome/Airports missing coordinates is a listing of over 700 airport-related articles which currently do not have geographic coordinates. It is based on old data, and can't be relied on to be either complete or completely accurate, but I hope it's useful. -- The Anome (talk) 00:53, 30 October 2009 (UTC)

call for discussion on extending {{Coord}}

I think {{Coord}} needs to provide a more flexible way of citing sources for coordinates. The current mechanisms either work only for inline coordinates, or else are awkward/limited in some regard. On the template talk page, I proposed adding add an optional "note=" template parameter, but so far there's been no response. While capable of coding and documenting the change, I'd feel excessively bold changing the syntax of a template that's transcluded 525,000 time without seeing some evidence support. I invite your input at Template talk:Coord under the heading "References for {{coord}}". --Stepheng3 (talk) 16:12, 21 October 2009 (UTC)

I feel an attack of boldness coming on. --Stepheng3 (talk) 17:25, 5 November 2009 (UTC)

Converting zoom: to scale:

I want to convert all the zoom: values imported by my bot from the nl: wikipedia into scale: values.

(possibly irrelevant GeoHack-related material snipped)

Thus suggesting something like this zoom: to scale: mapping:

1 10000000
2        ?
3  3000000
4  1000000
5   300000
6   100000
7    30000
8    10000

Does this seem reasonable? Does anyone have a suggestion as to what zoom:2 should correspond to? The geometric mean of 10 and 3 is 5.477, so perhaps a scale of 5000000:1 would be appropriate?

-- The Anome (talk) 03:03, 14 November 2009 (UTC)

I don't have much knowledge nlwiki, but I think you're on the right track. --Stepheng3 (talk) 04:15, 14 November 2009 (UTC)

OK: having explored a bit more, as far as I can see, the nl: GeoHack tool passes the "zoom" parameter directly into Google Maps URLs as the "z" parameter. So I'll examine that behavior instead. -- The Anome (talk) 14:01, 14 November 2009 (UTC)

Here are some of the links and articles in question:

Note that the en: GeoHack does not behave in the same way as the nl: GeoHack, so you will have to follow the interwiki link to the nl: article, and click the map link there to see how it does it. -- The Anome (talk) 17:50, 14 November 2009 (UTC)

More: a discussion on http://laudontech.com/GISBlog/?p=28 suggests that dim: might be more appropriate than scale: as a replacement for zoom:, and suggests some possible equivalences. Also, this: http://blogs.esri.com/Support/blogs/mappingcenter/archive/2009/03/19/How-can-you-tell-what-map-scales-are-shown-for-online-maps_3F00_.aspx -- The Anome (talk) 18:31, 14 November 2009 (UTC)

Scroll down to the scale section, it should be explained there. And while dim: is a better parameter for new data, it is not a suitable for conversion as there are large gaps in zoom levels. Additionally, the zoom is usually chosen on what looks good rather than object diameter. You should either eliminate zoom: or best effort convert scale:. — Dispenser 23:21, 14 November 2009 (UTC)

Addis Ababa, Ethiopia

Ref.: 9°1′48″N 38°44′24″E / 9.03000°N 38.74000°E / 9.03000; 38.74000 and Talk:Addis Ababa#Coordinate error
On the popup map of Ethiopia, the capital city of Addis Ababa appears twice. The southernmost position is correct. How does one go about removing the incorrect position on this map?
 —  Paine's Climax  10:33, 31 October 2009 (UTC)

Can nobody fix this?  —  Paine's Climax  19:11, 16 November 2009 (UTC)
The coordinates in the current Addis Ababa article seem okay. I suspect the Atlas has old data or maybe data from another article. You might try reposting your question at meta:Talk:WikiMiniAtlas. --Stepheng3 (talk) 19:27, 16 November 2009 (UTC)

UK to free their geodata?

The Guardian has an interesting new story about the UK government actively considering freeing the Ordnance Survey's geodata. -- The Anome (talk) 10:24, 18 November 2009 (UTC)

Google wikipedia layer - negative longitude problem?

Is google, when drawing up its wikipedia layer, screwing up coords in which the longitude is entered as a negative number. Take Fawcett Street, Sunderland, which since the inception of the article has the following coord statement: {{coord|54.905564|N|-1.381464|E|display=title}} which resolves as {{#coordinates:}}: invalid longitude. But now check out google at 54°54′20″N 1°22′53″E / 54.905564°N 1.381464°E / 54.905564; 1.381464 and there you should find the wikipedia logo for the Fawcett Street article. (props to User:82.20.52.30 who pointed me down this general line of investigation. There really are a great number of articles bobbing around in the sea on google which ought to be on land. (and doubtless there are others, on land, equally mirrored in the meridian. --Tagishsimon (talk) 23:40, 31 August 2009 (UTC)

If you can furnish me with a couple of other examples, I'll pass them on to my contacts at Google Maps. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:22, 1 September 2009 (UTC)
Thanks Andy. I'll do some digging - maybe now, maybe in a day or two. Meanwhile there's more discussion of this general issue at User talk:The Anome#Mirrroring the meridian. --Tagishsimon (talk) 00:26, 1 September 2009 (UTC)
  • Problem with unknown origin
  • Negative Northing problem
    • Moedwil, specified as {{coord|-25|38|00|N|26|58|00|W}}, found on google at {{coord|25|38|00|N|26|58|00|W}}

So it's looking like they need to check their treatment of any lat or long held as a negative value - i.e. for any N, S, E, W value. --Tagishsimon (talk) 00:54, 1 September 2009 (UTC)

12.3916 is West - that's a data error. Again negative values and "N" should not be mixed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:04, 1 September 2009 (UTC)
Knocked out the FP. Trouble is, people are entering -xN just as they're entering -xE or -xW. --Tagishsimon (talk) 01:07, 1 September 2009 (UTC)
The Bern temple coordinates are in {{LDS Temple/Bern Switzerland Temple}}. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:11, 1 September 2009 (UTC)
The Leipzig Botanical Garden example has me baffled. I've restored it, above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:23, 1 September 2009 (UTC)
Thanks for the Bern tip. Seems to have been entered with an East value [2] and not thereafter changed, but is found in the west. As entered, if in a coord, it would be 47°0′7.891200″N 7°27′29.67839″E / 47.00219200000°N 7.4582439972°E / 47.00219200000; 7.4582439972 but seems to turn up on google at 47°0′7.891200″N 7°27′29.67839″W / 47.00219200000°N 7.4582439972°W / 47.00219200000; -7.4582439972. Still don't know why this one is found in the sea, though. --Tagishsimon (talk) 01:25, 1 September 2009 (UTC)

Google uses coordinates from many Wikipedia languages, and shows the marker at the same coordinates for all languages. In case of differences, the location is most likely chosen by the age ("trust") of the data. With these examples, at least the Bern and Leipzig articles are off in the Spanish Wikipedia. I think we need a tool that works similarly on interwikis, by listing articles where the difference between languages is greater than the dimension of the object. --Para (talk) 12:31, 1 September 2009 (UTC)

Additional Examples: La Salle University, Linden Assembly, Wilmington Assembly and Hudson River all appear on Google Maps near the western boarder of China. The first three have negative East longitude. Not sure why the Hudson River is there, I can't find a negative East in it's history.
Anyway, besides Google not parsing the sign if there's a letter direction, do we want to consider this a data error in wikipedia as well and clean it up. I don't mean to prefer sign over letter, but using both seems pretty confusing. --J Clear 01:02, 6 December 2009 (UTC)

subparameter on type:country and type:mountain

I know about type:city taking a numeric subparameter for the population, as in type:city(12,345). For type:country and type:mountain there's no subparameter documented, but there are quite a few instances with subparameters in the wiki. For instance:

  • Peru coordinates have type:country(1,285,220)
  • Mount Fisht coordinates have type:mountain(2867)

As far as I can tell, GeoHack ignores these subparameters. Two questions:

  1. Is this an accepted practice, and if so, shouldn't it be documented in {{Coord/doc}}?
  2. What are the intended uses of the subparameters? What do they mean?

--Stepheng3 (talk) 07:26, 16 November 2009 (UTC)

I've never seen type:country(population) (which is what I assume the number is. Looking again at the documentation for this Template:Coord#type:T, type:mountain no longer says it accepts meters for the peak elevation, and type:city now says it ignore commas in the number, which represents the population. Anyone know why this has changed? If not, I'll fix the documentation in a day or two. —EncMstr (talk) 01:08, 17 November 2009 (UTC)
I don't think the documentation has changed in this regard. The oldest type: documentation I've found on enwiki was added in August 2008 by this edit. Note that the August 2008 documentation says commas are ignored in type:city(pop) and does not show subparameters for type:country or type:mountain. Nor have I found any evidence that these subparameters were ever documented for {{Coord}} on enwiki. If the subparameters don't actually do anything useful (such as affecting the map scale), then in the interest of simplicity I'd rather remove them than document them. {{Infobox mountain}} seems like a much better place to code summit elevations, and {{Infobox Country}} seems like a better place to code national populations. --Stepheng3 (talk) 05:34, 17 November 2009 (UTC)
Currently there are only about 60 type:mountain coordinates with the subparameter. I'm going to start removing the subparameters by hand. --Stepheng3 (talk) 05:15, 24 November 2009 (UTC)
It's unclear what harm there would be leaving type:mountain(elevation). However, if you must remove it, maybe consider migrating it to an elevation:height parameter? —EncMstr (talk) 06:04, 24 November 2009 (UTC)
There's no huge problem here, just a bunch of minor or potential ones. Like the elevation: and alt: parameters, the subparameter is not documented for use with {{Coord}} in this wikipedia. Thanks to Murphy's Law, different users will assume/use different units -- some assuming feet and others assuming meters. Also, it the subparamater might confuse or complicate automated tools that attempt to parse {{coord}} data. And finally, it's redundant (copied) information that increases maintenance and can result in contradictions. To understand this last, suppose someone corrects the height in the Infobox; they're unlikely to notice that the information was duplicated in the {{Coord}} template. So far, it looks like more than half of the mountain: subparameters were copied from dewiki, probably by bots. --Stepheng3 (talk) 06:17, 24 November 2009 (UTC)

It looks like most of the type:country(N) instances are generated by {{Infobox country}}. I've proposed changing {{Infobox country}} to remove the subparameter. If there are reasons to retain the subparameter, please comment at Template talk:Infobox Country. --Stepheng3 (talk) 17:02, 25 November 2009 (UTC)

the only reason are evaluations on external urls by API Visi-on (talk) 00:07, 26 November 2009 (UTC)
I don't understand. What API and what is it evaluating? --Stepheng3 (talk) 04:53, 26 November 2009 (UTC)

The original documentation (gis) only includes the type-size for adm1st, adm2nd, and city. It was meant to select a suitable scaling size when showing a map, but remains unimplemented in GeoHack. I do believe a few other tools (WMA) are using this, to provide relevancy on a map. However, such secondary uses are better served by computing the backlink count of the page. — Dispenser 06:21, 26 November 2009 (UTC)

Airports

User:Canglesea has been slowly geocoding their way through this list of the remaining airport articles without coordinates. Would anyone be interested in helping them? -- The Anome (talk) 15:02, 13 December 2009 (UTC)

Multimap -> Bing :(

As far as I can see, as of minutes ago, multimap is redirecting to Bing. Bing does not seem to provide coordinates for selected locations. Much lamentation; that's my geocoding technique buggered. Is there any way to get Bing to cough up coordinates? --Tagishsimon (talk) 02:34, 16 December 2009 (UTC)

Ah. Apparently I've been "selected to trial new Bing maps." Lucky me. Fortunately "At any time you can go back to Multimap". As you were, though the question still stands. --Tagishsimon (talk) 02:35, 16 December 2009 (UTC)

Not getting captured by Google

I've been trying for a while to get Google Maps/Earth to pick up the coordinates for Mont Clare, Pennsylvania. I've tried a few things without success (although if the slightly different coords in sv:Mont Clare, Pennsylvania were impacting, I just fixed those). Anyone have any suggestions? Thanks. --J Clear 00:19, 6 December 2009 (UTC)

It is a feature that Google has an idea where it is located.[3] The difference from the article's location is about 2,000 feet (610 m). The coord in the article is fine as far as I know, and I would expect a W icon to show up for the city in a few months. Google says it updates every one to three months, but my observation is that it is often quite a bit longer. —EncMstr (talk) 01:14, 6 December 2009 (UTC)
I set the article coords at the oldest part of town, near the former post office, where the population is denser, rather than the GNIS coords (what Google appears to be using) which are more in the area center, or perhaps just at a more major intersection. Maybe I'm "fighting city hall". Should be interesting to add secondary coordinates in the article and see what shows up. --J Clear (talk) 01:44, 3 January 2010 (UTC)

Geocodes of items in articles

Is there a way to put geocodes on specific landmarks mentioned in articles rather than the whole article? E.g. I think geocodes on the various Spite houses would be useful. --Dwchin (talk) 06:39, 19 December 2009 (UTC)

Yes, of course. Use the name= parameter with an inline {{Coord}}. For instance: {{Coord|40|46|36|N|73|57|26|W|region:US-NY_type:landmark|name=Richardson Spite House}} gives 40°46′36″N 73°57′26″W / 40.77667°N 73.95722°W / 40.77667; -73.95722 (Richardson Spite House). --Stepheng3 (talk) 06:45, 19 December 2009 (UTC)

Asymmetry

After reading the discussion of dim vs. scale I was off measuring my village to change its {{coord}} when I noticed a potential issue. How should asymmetric objects be handled? For example, New York City. Clearly lower Manhattan is the place to leave the coordinate, but most of the city is to the North and East of that. I'd think that using dim exclusively would tend to show too much of New Jersey and miss parts of NYC entirely. While scale could be adjusted to show the whole city, but still include too much New Jersey (I'm sure there's joke opportunity here...). And I think many populated places along a body of water would naturally have this problem (e.g Philadelphia, San Francisco), but not all (e.g. London). What's really missing here is that we'd like to center the displayed map somewhere other than the cultural center listed as the primary coordinates. OK, what's really missing is bounding box polygons, but perhaps a secondary coordinate would be much simpler for the interim.

Upon further reflection if the various mapping sites don't support the concept, then it's probably moot to add a second coordinate. However it might be useful to allow both scale and dim to be set, with dim recording the actual dimension and pass scale to the mapping service to get the whole asymmetric object on screen.

Another example are concave objects, such as the canal park along a big river bend that wraps around half my village. The "center" there isn't even in the object. (Always amusing when the GPS plotter puts the "City Park" tag near my condo a km away.)

Guess I'll leave the village dim-less for now. --J Clear (talk) 15:15, 4 January 2010 (UTC)

Taking a tape-measure to your village is probably overkill.
I believe that the sole purpose of dim: is to set the viewport (i.e. scale) for maps of the geocoded object or region. As such, it needn't be precise. I doesn't even need to indicate the actual size of the subject.
While in many cases dim: approximates the largest diameter, in others it is much larger. For instance, if the coded latitude/longitude is not centrally located (i.e. the mouth of a river, the capital of a nation, etc.) then the dim: ought to be about twice the distance to the furthest point. And if the subject is small (i.e., a building) or isolated, then the viewport should include nearby features to provide context. --Stepheng3 (talk) 17:37, 4 January 2010 (UTC)
I used a km long virtual tape measure. However I was less concerned about the dimension than what, if anything, can be done for asymmetric regions. --J Clear (talk) 03:06, 7 January 2010 (UTC)
My tape measure comment was tongue-in-cheek. In all seriousness, the coordinate specified needn't be the center. And if you set the dim large enough to encompass the entire region (when the viewport is centered on the coordinate) you've probably done right by the end-user. I think it's probably better to show too a bit too much than to cut off part of the region. --Stepheng3 (talk) 04:55, 7 January 2010 (UTC)

More region code analysis

I've now built my own regioncheck-like tool, using binned versions of the GNS and GNIS datasets as a reference for country coverage. Here are some stats, based on the most recent (and already well out of date) dump:

There are 868536 geolinks in the en: Wikipedia, of which there are:
  • ~283732 geolinks without any region: field, and
  • ~584810 with a parseable region: field, (these two don't quite add to the total above because of edge cases in parsing) of which there are:
  • 1110 with a region: tag, but no region coded
  • 2360 with uppercase region codes that are in ISO 3166, but look suspicious
  • 527 with uppercase region: codes that are not currently part of ISO 3166 (some of which I've broken down by code -- many of these are simple systematic errors)
  • 261 with lowercase region: codes that look accurate
  • 3 with lowercase regions codes that don't (all already fixed)
and all the others are most probably right, suggesting a lowerbound on the error rate for the region: tags that existed as of the time of the dump of around 0.7% -- and perhaps 50% of these remaining errors look as if they may be capable of being resolved automatically.

You can see some reports generated from this data on these pages.

I see that (mostly) User:Stepheng3 and (also) a number of other editors have fixed a lot of these already! I've just begun to realize just how valuable this work is in terms of generating information about political geography. -- The Anome (talk) 03:37, 6 January 2010 (UTC)

Geotags with uppercase region parameter, region=others seems to find problems with valid ISO 3166-1 alpha-2 codes, such as Guam - GU and the Northern Mariana Islands - MP. What's with that? --Tagishsimon (talk) 23:32, 6 January 2010 (UTC)
I'm planning to re-code these as US-GU, and US-MP respectively: I'm currently working on adding these and the other US-xx sub-codes to the analyzer. -- The Anome (talk) 15:20, 7 January 2010 (UTC)

Region code for Kosovo?

Since Kosovo does not have an ISO 3166 code at the moment, what region: code should we use for places in Kosovo? See User:The Anome/Geotags with uppercase region parameter, region=CS for a breakdown of some of the cases in question. -- The Anome (talk) 14:21, 6 January 2010 (UTC)

It's POV to suggest that Kosovo is not part of Serbia ... but on the other hand it's also POV to suggest that it is part of Serbia. So you've unearthed a thorny issue. I honestly don't know what's best, but as the United Nations (and presumably ISO) still consider Kosovo to be Serbian, then I would suggest using the code for Serbia. This will not please everyone of course. Bazonka (talk) 19:34, 6 January 2010 (UTC)
When a new country is attempting to form, I try to err on the conservative side -- i.e. which country the territory belonged to a couple years ago, since it's likely that other mapping services are (at least) that far out of date. The functionality provided by the region code is minimal; if you're seriously worried about NPOV, you can safely omit (or delete) the region code. --Stepheng3 (talk) 23:06, 6 January 2010 (UTC)
I'm going to go with code RS-KM, which is the valid ISO 3166 subregional code for RS that exactly matches the claimed territory, and will make it easy to re-code if/when Kosovo gets its own code. -- The Anome (talk) 15:14, 7 January 2010 (UTC)

Discussion at Template:Coord

I have started a discussion at Template_talk:Coord#WikiMiniAtlas_override.3F that may be of interest to this project. Shereth 16:32, 29 December 2009 (UTC)

Yes, this problem is very important at at Wikipedia_talk:WikiProject_National_Register_of_Historic_Places, see Wikipedia_talk:WikiProject_National_Register_of_Historic_Places/Archive_34#Loading_speed_of_our_longer_lists. The problem is with lists of 200-300 places, which take 15-20 seconds to load and can be nearly impossible to edit. Any help would be greatly appreciated. Smallbones (talk) 15:30, 18 January 2010 (UTC)
Yes, We could define an id alla disable-wma, that WMA will getElementId and when present not run WMA on those pages. It could be added with a {{disable wma}} or something. And then additionally add a 10second execution timeout in the script. I'll look at making such suggestions later today. That might be a solution for the NRHP issues. —TheDJ (talkcontribs) 21:57, 18 January 2010 (UTC)
'impossible' to edit effect, is mostly caused by an edit requiring the page to be parsed again. Some of those pages take well over 30 seconds to parse with the complexity of the coord template. That is separate from the javascript parsing delay. —TheDJ (talkcontribs) 21:59, 18 January 2010 (UTC)

Need help/advise...

The article Bethsaida has a link to et-Tell. The problem is that from the descriptions of the two sites they are two widely different locations, and this seems to be born out by the geo-coordinates given. I would edit-out the link myself except I'd like my conclusions double checked by experts (well... more expert than myself, anyway). Thank you, Shir-El too 09:24, 15 January 2010 (UTC) P.S. See comments on the discussion page too. Cheers!

I've weighed in at Talk:Bethsaida. There's a lot more wrong in the article than merely the link; I suggest a solution (probably involving a rewrite) is called for. The link is the least of the problems. --Tagishsimon (talk) 03:17, 26 January 2010 (UTC)

What am I missing?

I've been doing a few corrections from Category:Talk_pages_requiring_geodata_verification and I keep running into talk pages where someone has gone to the trouble to note the error and put the correct coords on the talk page, but hasn't gone on to correct the article page and remove the {{geodata-check}} template. I'm not objecting, just confused and wondering if there's something that I don't know about or don't understand. I'm consequently concerned that I'm somehow goofing up by making the corrections I'm making. Could someone provide enlightenment? Best regards, TRANSPORTERMAN (TALK) 16:32, 2 February 2010 (UTC)

A lot of users don't know how {{coord}} works and how to change the geographical coordinates of an article, so they make the request or respond to another user's request. I don't see anything wrong with taking their coordinates and using them in the article if you think they're correct. --Mysdaao talk 18:36, 2 February 2010 (UTC)
That's right, there are people who are worried that they might do something wrong (mutters stuff about computers on TV). This gives them a way of still contributing. Although, I'd check to make sure the coordinates weren't overly precise and they usually pull them from Google Maps which is known to sometimes have some errors in its imagery. Also, on inspection of Template:Geodata-check/report editintro, I fixed the v-d-e that overlaid the [show] link making it impossible to click to read the rest of the instructions. — Dispenser 03:13, 4 February 2010 (UTC)
Thanks, I was just afraid I was sticking my nose into something I didn't entirely understand. Now if I can just remember to insert edit summaries... Regards, TRANSPORTERMAN (TALK) 03:27, 4 February 2010 (UTC)

{{coord missing}} now accepts Indian state names as arguments

Support for Indian states has now been added to the {{coord missing}} system.

You can now use either "India" or the name of an Indian state as a parameter for the {{coord missing}} tag. This will automatically add it to one of the sub-categories of Category:India articles missing geocoordinate data, and will also work seamlessly with all the other geolocation management tools. For example, to add an article to Category:Delhi articles missing geocoordinate data, just put {{coord missing|Delhi}} at the end of the article.

As part of this process, the existing, but incompatible, Category:Indian location articles needing coordinates tree has been emptied of articles by converting all of them to use the new tag support, and should now be considered deprecated in favor of the new use of state names as parameters to {{coord missing}}.

A bot is currently working on automatically recategorizing around 12,000 articles currently tagged as {{coord missing|India}} into their respective Indian state subcategories.

Note that these new categories are hidden categories. To view hidden categories, one needs to activate them in Special:Preferences. Under "Misc", there is "Show hidden categories". -- The Anome (talk) 15:12, 7 February 2010 (UTC)

Shorter GeoHack URLs

GeoHack URLs are rather long. So I propose the following shortening scheme: drop pagename= as it can be gotten from the referer, make the language= and params= part of the request path using a rewrite rule. The effect is illustrated below:

http://toolserver.org/~geohack/geohack.php?language=en&pagename=PAGENAMEE&params=45_N_123_W_&title=NAME
http://toolserver.org/~geohack/en/45_N_123_W_?title=NAME

This is part of GeoHack's move off the stable server, no changes are mandatory when this happens. Other schemes under consideration are /~geohack/en/PAGENAMEE?params= and /~geohack/wikipedia/en/PARAMS. I am interested in hearing the thoughts from Toolserver users and others who parse the external links table. I will post the rewrite regular expression if we have finalized a scheme. — Dispenser 23:24, 2 January 2010 (UTC)

With this proposed change, what would happen to the region:, type:, scale: and zoom: fields? -- The Anome (talk) 13:24, 3 January 2010 (UTC)
They would continue to be used along the coordinate, so it would look like /~geohack/en/45_N_123_W_type:city_region:US?title=NAME. — Dispenser 14:26, 4 January 2010 (UTC)
OK, I can handle that. -- The Anome (talk) 13:53, 5 January 2010 (UTC)
first, i can handle it to. But why a second parameter for title?/~geohack/en/45_N_123_W_type:city_region:US_title=NAME. Visi-on (talk) 21:57, 11 January 2010 (UTC)
organize the attributes of coordinates. A coordinate describe
  1. a place with
    1. an elevation
    2. a population
    3. a name / title
    4. a type (landmark, city ... )
    5. a region (up to 4 ISO-Codes → Four Corners)
    6. a dimension
  2. the center of an area with
    1. an elevation (avg, max and min)
    2. an area
    3. a population
    4. a name / title
    5. a type (landscape, state, country, adm1st, adm2nd, adm3rd ...)
    6. a region (up to 4 ISO-Codes)
    7. a dimension
example: Berlin: /~geohack/de/52.5N_13.35W_area:891.82_pop:3431700_ele:45_maxele:115_minele:34_region=DE-BE_type=city/adm1st_name:Berlin
Visi-on (talk) 12:08, 12 January 2010 (UTC)
dimension added Visi-on (talk) 11:22, 15 January 2010 (UTC)
The biggest problem with the proposal is if we did name/title that way it would be limited to one word as the underscore/space would indicate a new param. This field also has the same title restrictions as in MediaWiki, in fact doing what I purpose requires some trickery in the regex with regards to question mark character. Also, usage of = (Equal sign) since this character cannot be easily typed into enwiki's templates.
oh this is true ...
  • but: /~geohack/de/52.5N_13.35W&a=891.82&p=3431700&e=45_34_115&r=DE-BE&t=city/adm1st&id=Berlin&d=20000 will work well and
  • with signed decimals: /~geohack/de/52.5_13.35&a=891.82&p=3431700&e=45_34_115&r=DE-BE&t=city/adm1st&id=Berlin&d=20000 even better
and you can left the old interface as is for compatibility reasons. Visi-on (talk) 14:27, 16 February 2010 (UTC)
Your welcomed to come up with whatever scheme for additional information you'd like to include in the URL. On region I know that there's at least one instance on the dewiki where 10+ were being used (broken my db) and it also the sort of stuff that should be sorted out by a computer. — Dispenser 06:39, 24 January 2010 (UTC)
The idea in the dewiki is that the first four region-iso codes must be interpeted because of the existence of places like Four Corner. The problem of rivers (lakes) touching a lot of regions is known. Visi-on (talk) 14:27, 16 February 2010 (UTC)

Google

Is anyone in touch with Google (or any of the other search engines) about this, just in case they are parsing these URLs for this information? -- The Anome (talk) 14:41, 6 January 2010 (UTC)

I can drop Google a line if you let me have more detail; better still, put some documentation on a page which I can point them to. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:22, 28 February 2010 (UTC)

Para's tool and geocoding progress

First, I'd like to say thanks to Para for all their help on geocoding, and make it clear that the following is not intended as a criticism of either them or their excellent work.

Unfortunately, the coord missing tool is now way out of sync with the current state of missing coordinates. Currently, it reports 182,737 articles with {{coord missing}}, whereas the category itself reports only 172,416 articles in Category:All articles needing coordinates. Most articles where coord missing has been removed after geocoordinates have been provided are being missed by the tool; for example, I've recently geocoded over 800 Japanese railway stations, none of which seem to have shown up on the tool's lists, and I'm sure the same is true of many of other people's edits.

This gives a discouraging impression that geocoding activities have slowed down significantly. In my bot runs, I see quite the reverse -- more than half of all geocodable articles are already geocoded before my bot can get to them, which is a huge improvement on how things were even a year ago.

At the same time, we are nearing saturation on the tagging of geographical articles without coordinates (except for a few feature types I have deliberately held back on), so I believe that the backlog indicated by the category count is pretty close to the true state of affairs.

I've dropped a note on Para's talk page asking for assistance. -- The Anome (talk) 16:22, 24 February 2010 (UTC)

Something seems to have happened on 2009-12-04, as the db has 172642 removals marked for that date, yet the viewer doesn't show the date at all. The query that feeds the database doesn't handle more than one addition and one removal of the template in any single article, so something like this would probably break the counts from there on. There can be some slow drift as well; I'm not sure if page moves or deletions are handled properly. Upside is that I've still got the hourly query results of all coordmissing pageids since the tool was created, so if anyone wants to make a multi-maintainer tool out of this, or to recreate the db and viewer, it shouldn't be too difficult. I'll try to have a closer look at some point as well, or maybe just reimport everything. --Para (talk) 23:21, 24 February 2010 (UTC)

Kenilworth railway station

Wonder if someone can take a look at Kenilworth railway station article, an IP has identified a problem with the label displayed on Google maps. The coordinates on the article appear to be correct showing a location in Warwickshire yet when looking directly at Google maps the station is shown as being in Suffolk, at 52°20′31″N 1°34′20″E / 52.34191°N 1.572232°E / 52.34191; 1.572232. Has anyone any idea what is going on here? Keith D (talk) 22:56, 7 March 2010 (UTC)

Many of the labels on Google maps are misplaced or otherwise inaccurate. It's Google's problem, not ours. In this case, they seem to have put the label at an east longitude when it should be at the corresponding west longitude. Deor (talk) 23:16, 7 March 2010 (UTC)
(edit conflict) Ah, you're referring to the link from Google Maps rather than the link to Google Maps.
The article was corrected when the missing minus sign was added to the longitude parameter on 17 January 2010 and the GeoHack links all seem fine now, but it looks like Google hasn't updated its cache. Maybe they don't check for changes of sign alone, or maybe they are just slow to update.
I've updated the coords to move them slightly closer to what seems to be the former (and proposed) site of the station, and rounded to 4 decimal degrees so as not to be overly precise. Not sure whether this will help Google Maps to notice that their link needs updating, but it can do no harm!
Richardguk (talk) 23:51, 7 March 2010 (UTC)
As Deor noted, google have an east-west transposition problem with some of our coords. It's their problem, and leaves very many UK locations sitting in the North Sea. There's further discussion here. It's been broken for quite a long time and shows no sign of being fixed. It is a problem of google's making, and we have no apparent means of fixing it. And, really, it's a bit crap. --Tagishsimon (talk) 00:29, 8 March 2010 (UTC)
Thanks for the pointers to what the problem is. Keith D (talk) 01:55, 8 March 2010 (UTC)
Can't see any examples of Google getting it wrong except where a Wikipedia article itself has (within the past few months) either also been wrong (minus sign incorrect) or has unconventially used negative degrees east (when the template should be called either with signed global degrees: -180 to 180, or with non-negative degrees east or west: 0 to 180 E/W). — Richardguk (talk) 02:59, 8 March 2010 (UTC)

Tz database - geolink the list of 400 lat-long pairs in ISO 6709 format

The tz database is the most common resource for information of time offset from UTC. It contains zone identifiers, ISO 3166-1 alpha-2 country codes and coordinates.

#...
# Latitude and longitude of the zone's principal location
#     in ISO 6709 sign-degrees-minutes-seconds format,
#     either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS

Data stored: Template:Time zone/coordinates

Is there a way to turn these coordinates into links to the geohack site?

Example of a page that might use such a link: Asia/Novokuznetsk. TimeCurrency (talk) 21:30, 10 March 2010 (UTC)

I can do this using my bot. I've downloaded the file (which is in the public domain). A quick sampling of articles at random from the list suggests that most of these already redirect to articles with geocodes, but it can't hurt to check that none have been missed out. I'll have a go at some point in the near future. -- The Anome (talk) 00:19, 11 March 2010 (UTC)
I wanted that templates can handle ISO 6709 "+-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS". The current redirects to existing articles do not help here. Maybe Template:Tz/latitude and Template:Tz/longitude in a format that geohack can handle need to be created. But this is duplicating the data in Template:Time zone/coordinates, which I better like to avoid for better maintenance. The tz data is updated quite often, so the process to do the update here should be very simple. TimeCurrency (talk) 01:26, 11 March 2010 (UTC)
See my comment below.--Stepheng3 (talk) 19:39, 11 March 2010 (UTC)

Germany railway stations without geocodes

I've now managed to get the number of German railway station articles without geocodes to below 50; see User:The Anome/German railway stations still missing coordinates for the list of those remaining. Would anyone be interested in helping to code some of the last few remaining stations? -- The Anome (talk) 00:40, 11 March 2010 (UTC)

Done. Fischbek station and München Hirschgarten station are too new to show up on the Google Maps satellite views; but Bing shows the former under construction, and the information in the article was sufficient to pinpoint the latter more or less exactly. Deor (talk) 15:01, 11 March 2010 (UTC)

Add full ISO 6709 support to Template:Coord

Template:coord should have full ISO 6709 support.

Currently accepted per project page are

D|MM|SS.S|NS|D|MM|SS.S|EW   {{coord|57|18|22.5|N|4|27|32.7|W|display=title}}
D.DDD|NS|D.DDD|EW           {{coord|44.112|N|87.913|W|display=title}}
-D.DDD|-D.DDD               {{coord|44.112|-87.913|display=title}}

where "-" means - has to be written, but + can be ommited
NS North/South, EW East/West

ISO 6709 defines

±DD.DDDD±DDD.DDDD
±DDMM.MMM±DDDMM.MMM
±DDMMSS.SS±DDDMMSS.SS

TimeCurrency (talk) 02:48, 11 March 2010 (UTC)

Also supported is:
D|MM.M|NS|D|MM.M|EW   {{coord|51|12.5|N|4|27.3|E|display=title}}
Have you thought about how to implement this? As far as I know, Wikimedia templates don't support parsing strings in this fashion, which is why {{Coord}} uses the stile ("|") to separate parameters. --Stepheng3 (talk) 19:36, 11 March 2010 (UTC)
I converted the data with some regex and zone/coord&action=historysubmit&diff=349274787&oldid=349250805 added it to the new template:Time zone/coord. The data is now stored close to the coord format, e.g. "05/19/N/004/02/W" But neither "|" nor {{!}} were accepted. It would be good if geohack could accept data as one string. -D.DDD|-D.DDD is two strings, but for DDMM only the selfmade pipe splitting is accepted. Standards are there to make life easier. If GeoHack would follow ISO 6709 editing would be much easier. I have no idea what technology is available in mediawiki to help. Is there any string splitter that at least could process strings similiar to "05/19/N/004/02/W"? TimeCurrency (talk) 01:49, 12 March 2010 (UTC)
GeoHack is independent of {{Coord}}, so you can generate GeoHack links without using {{Coord}}. GeoHack uses underscores ("_") between parameters. GeoHack is written in a real programming language, so it's capable of parsing strings.
I admit I don't understand what you're hoping to accomplish here. Perhaps what you want from {{Coord}} is a new output format (alternative to format=dms or dec) rather than a new input format?--Stepheng3 (talk) 17:50, 12 March 2010 (UTC)

Bottom link proposal for Template:Infobox mountains

It has been proposed by Stepheng3 that {{Infobox mountain}} use the {{coord}}'s {{{notes}}} parameter to display a link in the title line to a bottom note. See an example here. This discussion is at Template talk:Infobox mountain. It is proposed that this style be adopted by all templates which include coordinates. –droll [chat] 10:19, 17 March 2010 (UTC)

Usability of GeoTemplate

Comments on the usability of {{GeoTemplate}} (the page listing mapping services found by clicking on coordinates in articles) are invited, at Template talk:GeoTemplate#Usability redux. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:33, 17 March 2010 (UTC)

Precision and precedence

In this edit, I reduced the precision of coordinates for a 13Km-diameter feature from 7 to 6 decimal places (on reflection, I realise that I could have reduced further). I was reverted, and it has since been claimed that, since the 7-dp coordinates are from a cited source, that has precedence over the Wikipedia guidelines on coordinates precision, which require rounding to fewer decimal places. What do others think? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:59, 17 March 2010 (UTC)

As a matter of principle, I would hope that our guidelines take precedence. However, this particular example does not seem like a high priority for the WikiProject, given that we have plenty of coordinates with 16 dp precision to work on. --Stepheng3 (talk) 17:12, 17 March 2010 (UTC)
The change was reverted due to WP:V. Policy takes priority over any guidelines. The number was changed from one directly supported by a reference to one which was not. In a comment Mr Mabbett left on my talk page, he says he doesn't like USGS numbers because of their level of precision. But that is not a Wikipedia editor's decision to make. The coordinate precision recommendations apply to making one's own coordinates from a map or GPS. If the number is supported by a source, especially a widely accepted one like USGS GNIS as it was in this case, using the source's numbers will keep it verifiable for other editors. If the numbers don't match, you'll waste people's time going forward as they check whether the change was vandalism or good faith. Ikluft (talk) 17:23, 17 March 2010 (UTC)
Rounded coordinates can still be verified from the original source via a routine calculation.
In the case of GNIS coordinates, there's also a partial workaround because everywhere GNIS gives decimal-degree coordinates (to about 1 cm precision), it also provides them in dms format, rounded to something like 30 metres precision. We can choose the more appropriate precision without resorting even to routine calculations. --Stepheng3 (talk) 17:42, 17 March 2010 (UTC)
Please don't misquote me; I said no such thing. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:05, 17 March 2010 (UTC)
OK, fair enough. No misrepresentation was intended. But the quote was "inanities of the GNIS" so displeasure with them was understood to be a factor. Ikluft (talk) 18:55, 17 March 2010 (UTC)
Yes; I thought the GNIS were being inane, because I believed your explanation (I paraphrase) that they were providing a single set of 7dp coordinates for a 13Km-diameter feature. But that's not the case, is it? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:50, 17 March 2010 (UTC)
Per Stepheng3, rounded coordinates can still be verified from the original source via a routine calculation. We do not want inappropriate 7dp coords, and policy should not be misused to force us to have them. Nor should we have to be dragged through a policy versus guideline hedge before being allowed to do the patently obviously right thing. --Tagishsimon (talk) 19:55, 17 March 2010 (UTC)
I have some vague ideas on this subject. It might be that, in the future, high precision becomes the expected norm. How those values are displayed is another question. Decimal degrees with nine decimal places should not be displayed, IMHO. I generally use DMS format it overcome this. There is, I think, a valid question about the coordinates of large areas. I suppose agencies like GNIS have some algorithm they use to centralize the coordinates. I don't know much about it. Defining the location of a city or state might not require high precision. I do think we have some duty to our sources. I know others disagree. If GNIS gives seven decimal places then I think there is no crime in reflecting that in stored data. How that data is formatted for display is, I think, the important issue. I would support a DM format option for decimal degree data. I also would like to see a format option for displaying DDMMSS.sss that rounded to seconds. The point is that information storage and display are not the same. This was alluded to in the discussion above. –droll [chat] 22:58, 17 March 2010 (UTC)
GNIS gives degrees, minutes and seconds. For most things, more than four decimal places is overkill. I've been planning for some time to do a bot run to reduce these kinds of excessively precise coordinates. I would suggest that five decimal places (of degrees) or one decimal place (of seconds of arc) is the absolute maximum we should expect to support for any article. Now we have an up-to-date dump, I'm willing to do a bot run to round off these figures, if desired. -- The Anome (talk) 23:16, 17 March 2010 (UTC)
Did you read my comment above? Also Geohack converts all input to six decimal places. What is your rational for only four place precision. On what kind of articles are you proposing to revise or is the revision to be indiscriminate? –droll [chat] 23:52, 17 March 2010 (UTC)
Doesn't appropriate precision depend on the object? I usually round off the POV of an urban photo (in Commons) to thousandths of a minute. Another decimal or even two more would be appropriate for a life-sized statue, if available, while even unsubdivided degrees are arguably overkill for a continent or especially an ocean. Jim.henderson (talk) 00:52, 18 March 2010 (UTC)
Appropriate precision does depend on the subject. The guideline that kicked off this discussion (Wikipedia:WikiProject_Geographical_coordinates#Precision) suggests "one tenth the size of the object, unless there is a clear reason for additional precision". The question under discussion is what to do when a source provides (what we consider to be) excessive precision. --01:24, 18 March 2010 (UTC)
Oops! Yes, I should read the links, not just the text here. On the question at hand, about faithfulness to source or to Wikiprinciple of precision, I offer no advice. Jim.henderson (talk) 04:41, 20 March 2010 (UTC)

So: would someone like to fix the coordinates on Victoria Island structure (lest I be accused of edit-warring); noting the additional discussion on its talk page, about the fact that the cited source doesn't support the coordinates as used? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:33, 19 March 2010 (UTC)

Use by iPhone apps

Our geotagging is being used to find "nearby" articles, by several iPhone apps, according to the Signpost article "New commercial Wikipedia iPhone app reviewed". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:16, 24 March 2010 (UTC)

Almost all of these services use http://geonames.net btw. —TheDJ (talkcontribs) 23:37, 24 March 2010 (UTC)
And how do they get from there to Wikipedia articles? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:55, 24 March 2010 (UTC)
Geonames' explanationEncMstr (talk) 06:35, 25 March 2010 (UTC)

GeoGroupTemplate problem?

{{GeoGroupTemplate}} has stopped working for me (by which I mean that I get the error message "File not found at http://toolserver.org/~para...." when I try to access a multiple-location Google map, and the error message "This content is not available. It may have been deleted by the author" when I try it with Bing). The problem seems to have started sometime between 18:15 and 23:30 UTC yesterday, 23 March, as it was working for me at the former time. Is this a problem with my computer or a failure of some sort on the toolserver end? Deor (talk) 13:23, 24 March 2010 (UTC)

Never mind; it's working again. Must have been a transient glitch. Deor (talk) 16:10, 24 March 2010 (UTC)
The links fail quite often, in fact. I'd been assuming that the failures were due to load or lag on the toolserver in question, but I have no proof. --Stepheng3 (talk) 17:25, 24 March 2010 (UTC)
Google is impatient with requests that take the tool longer to process. When Google gives up waiting, they cache the result of that request as failed. If the user is impatient as well and keeps on refreshing the failed page, Google seems to cache it even more persistently. A watched kettle etc... Bing behaves similarly with quick timeouts, though I haven't noticed this caching problem with them. This was briefly mentioned at Template talk:GeoGroupTemplate#Long-list-warning option needed too. So I have now changed the template so that it will first have the content parsed, and then ask Google just to fetch it. That option of the tool hasn't seen much use[4], so there will probably be bugs with some obscure option used on some page. --Para (talk) 20:24, 24 March 2010 (UTC)
When it wasn't working for me, I tried using it from a variety of articles, some containing only two or three geocoded locations. That's why I was concerned (along with the fact that similar glitches in the past turned out to be a sign that my computer was infected with a virus). Deor (talk) 13:58, 26 March 2010 (UTC)
According to toolserver logs, the tool was giving back errors between 20:31 23 Mar 2010 and 13:51 24 Mar 2010. The timeframe coincides with software upgrades the toolserver admins were doing at the time. So Deor's issue was fixed by the ts admins, while my edit to the template fixed Stepheng3's issue above. If the tool is unreliable in the future, plesae report it to me, or in case of more toolserver software upgrades, to #wikimedia-toolserver. --Para (talk) 12:32, 28 March 2010 (UTC)
Actually, my timeout issues were not all related to the toolserver upgrade. I know this because I've been encountering the issue for many months. --Stepheng3 (talk) 00:33, 29 March 2010 (UTC)

Viewing diameter support in GeoLocator tool

I've added a viewing diameter (dim:D) in/edit/out support in latest release (changelog). Examples: Slovakia, Bratislava, Bratislava Castle. There is also elevation reverse geocoding available using Aster Global Digital Elevation Model (samples ~ 30x30 m between 83°N..65°S) via geonames.org. I'd appreciate any feedback here. Regards, --Teslaton (talk) 22:52, 29 March 2010 (UTC)

This ought to be accessible via GeoHack. If you agree, make your request at Template talk:GeoTemplate. --Stepheng3 (talk) 23:16, 29 March 2010 (UTC)
It already was there (sometimes back in 2008) as an "Edit this location using GeoLocator tool" link or such, but got lost during some GeoTemplate cleanup. I'll add it back into Export auxiliary globe, or eventually discuss an adition somewhere onto main GeoTemplate page. --Teslaton (talk) 23:28, 29 March 2010 (UTC)

Google Street View links

I have two questions: are links to Google Street View locations appropriate external links to Wikipedia articles? (examples: [5], [6]) And if they are, should we expect the links to become outdated? I don't know if GSV links can be construed as a search result, as GSV is a subset of Google Maps/Google Earth. But there is a user who has a goal of including these links to articles about New York City Subway stations. Tinlinkin (talk) 01:39, 26 March 2010 (UTC)

As I mentioned in the linked Project talk page, I think yes they count as EL, and yes they are good links. However, after a bit more thought, it seems to me a template such as Template:Gsvlink is the better way to implement these ELs. If the Google interface changes, this will allow a central way of handling the change rather than scurry around to find and kill or repair a multitude of broken links. If other map sites such as Bing Maps develop similar views, a template may allow a quick way to take advantage. —Preceding unsigned comment added by Jim.henderson (talkcontribs) 17:10, 27 March 2010
They are still just links, and when the linkage changes, all the articles need to be edited. If you search for GSV links from before 2008 for example, none of them seem to work. It would be better to have a template that takes the values of the url parameters and then constructs a link from those, so that any changes at the service's end would be easy to fix with a single template edit. --Para (talk) 21:54, 27 March 2010 (UTC)
I don't think they're appropriate, when we're not linking to other services that provide geotagged images, and when Google Street View coverage is too big and complex to mirror in our articles of landmarks. Or is it? Could there be a project for adding some tags to articles if their object is visible on GSV, and similarly for all the other street view services?
Seeing as people are adding them anyway, I think we should reformat them and make the added information as reusable as possible. The links, even with the Gsvlink template, are currently just raw links and the information can't be used with anything else but Google Street View. As they however are parametric, we could instead have editors provide a camera location and direction, as sort of a "best viewed from" location (most likely converted from a link given by GSV). The French Wikipedia has fr:Template:Google Street View that constructs links from that information. This way we could have a template or a GeoHack-like more complex application link to GSV and possibly other services, as mentioned at Wikipedia:WikiProject Council/Proposals/Street View#There can be more than one.
Alternatively, editors could just provide the coordinates of the object, if it's not already in the article. Google and probably others can then show images of that location, like at Wikipedia talk:WikiProject Geographical coordinates/Archive 25#Linking to panoramic views (or [7] with the first example here). --Para (talk) 21:54, 27 March 2010 (UTC)

An object location only provides the location of the object, whence the reader can see the world from the object's POV. The pleasant thing about a GSV link is that it provides by automation a good place to stand, and direction to turn, to see the object. This pleasant and informative view is what, in my (this time metaphorical) view, should be regularized with use of the template, or rather of a more general template if someone smarter than me can make one. Jim.henderson (talk) 02:10, 6 April 2010 (UTC)

Ordnance Survey "free" data

According to this BBC report, the Ordnance Survey has "launched a new service offering free and unrestricted access to most of its map data."

Unfortunately, it seems that it's only free-as-in-beer, and not free-as-in-freedom; the licensing conditions seem to be very restrictive. See http://openspace.ordnancesurvey.co.uk/openspace/faq.html -- The Anome (talk) 08:48, 1 April 2010 (UTC)

I think you're looking at old licence terms there, the new service is called OpenData, and replaces OpenSpace (though it looks like the OS website is currently overwhelmed). This should be the new licence http://www.ordnancesurvey.co.uk/opendata/licence but for some reason it's asking for username and password currently. The available datasets can be seen at http://data.gov.uk/data/publicbody/Ordnance%2520Survey David Underdown (talk) 10:40, 1 April 2010 (UTC)
You're quite right. The new stuff looks like it might be an improvement over the old: the new license is described as "UK Crown Copyright with data.gov.uk rights" -- The Anome (talk) 10:50, 1 April 2010 (UTC)
This looks promising: http://data.gov.uk/terms-conditions/ , particularly the words "These terms have been aligned to be interoperable with any Creative Commons Attribution 3.0 Licence. This means that you may mix the information with Creative Commons licensed content to create a derivative work that can be distributed under any Creative Commons Attribution 3.0 Licence." This strongly suggests that it may be Wikipedia-compatible, since Wikipedia is currently licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License -- The Anome (talk) 11:07, 1 April 2010 (UTC)
The OS site is suffering under thw weight of traffic. Meanwhile, here's a reliable cache of the newly released data; and an OS blog post featuring a video with TBL. Beomora (talk) 12:42, 1 April 2010 (UTC)

NAD83 on GNIS website

I've been adding coordinates from the GNIS website to Wikipedia articles, however, I noticed that the GNIS website says its coordinates are in NAD83 while the coord template says the coordinates should be in WGS84. Am I doing something wrong, and what do those abbreviations mean anyway?

For the definitions, see North American Datum and World Geodetic System. There's a difference, but I'm not sure how large it is in practice. --Stepheng3 (talk) 04:55, 9 April 2010 (UTC)
Use Google Maps. Top Right Click on red New button. In MapLabs enable LatLng Marker. OK. Choose a known point in your NAD83 data. Navigate the spot on the ground on Google- right click and you will see the WGS84 coord. You can now calculate the difference. Rule of thumb: in London the 5dp represents about 70cm. Hope that helps. --ClemRutter (talk) 08:33, 9 April 2010 (UTC)
So would I be better off just using Google Maps to look up coordinates? --TorriTorri(Talk to me!) 20:08, 15 April 2010 (UTC)

Question about no-longer-existing things

Should articles about things that no longer exist be tagged with {{coord}} for their former location? There are two types I've come across:

  1. Historic structures of which no trace remains, but the location is known.
  2. Organisations which no longer exist, where the building housing them is now used for some other purpose (e.g. a defunct art gallery whose building is now a shop).

Should these be tagged just like still-existing things? - htonl (talk) 23:39, 13 April 2010 (UTC)

For example, Fort Brooklyn hasn't existed for nearly two centuries; the site is now residential. Jim.henderson (talk) 18:05, 15 April 2010 (UTC)
Thanks for the answers. I'd kind of guessed that was the case, but I wanted to make sure. (By coincidence, my point 1 above was inspired by a fort: Redout Duijnhoop.) - htonl (talk) 19:59, 15 April 2010 (UTC)

Parameter name standardisation

Apparently, some templates use |coordinates_type= for type and region, while others, such as {{Infobox building}}, use |iso_region=. Standardisation would be a good idea, at least for new additions. The latter (with a separate coordinate type parameter) is more understandably named, more granular and more suitable for reuse. I do know know which is more wisely used. If we have standard parameter names, then conversions will be easier; there's less for editors to remember; and we could offer a library of reusable code snippets. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:27, 17 April 2010 (UTC)

Yes. What do you suggest as standardized names? -- The Anome (talk) 13:49, 19 April 2010 (UTC)
Generally, the most widely used, with exceptions where other names are clearer, or more granular, such as in the ISO example, above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:07, 19 April 2010 (UTC)

Interesting news story

From TechCrunch, this editorial article: "It’s Time For An Open Database Of Places" -- The Anome (talk) 13:48, 19 April 2010 (UTC)

User:Beeb144 was adding generic country-center coordinates to a large number of road articles. I think this is a misguided but well-intended effort, rather than vandalism, so I've left them a note on their talk page about this. I'd like to think they can be persuaded to stay and join in, rather than being put off from further participation. -- The Anome (talk) 06:23, 24 April 2010 (UTC)

52nd Street Penn Station in West Philadelphia

Iaddressed this on the WikiProject Trains talk page but I've been having nothing but trouble adding the coordinates for 52nd Street (Pennsylvania Railroad station), because GoogleMaps won't let me focus the specific coordinates on it, and stupid WikiMapia won't let me make an outline of where it used to be. ----DanTD (talk) 04:52, 30 April 2010 (UTC)

Have I tagged it correctly? Deor (talk) 05:18, 30 April 2010 (UTC)

504165 transclusions

The template transclusion counter found 504165 transclusions of {{Coord}} just now! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:47, 8 September 2009 (UTC)

Very good. Basis for a signpost story, I think. --Tagishsimon (talk) 00:18, 9 September 2009 (UTC)
Indeed. Good call. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:20, 9 September 2009 (UTC)

←And just now, 14 days later, 511927 transclusions - that's ~500 added each day! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:57, 22 September 2009 (UTC)

Now 534456, an increase of 22529 in just over a month since 22 September. -- The Anome (talk) 14:46, 26 November 2009 (UTC)
That would be a two month period thus 11k per month, non? Today we are at 541697, which is another 7k from 26t Nov. --Tagishsimon (talk) 01:56, 21 December 2009 (UTC)
558347, just now; an additional 16650. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:29, 28 February 2010 (UTC)
Please note that more transclusions is not necessarily better. Many articles geocode the same location three or more or more times, creating a maintenance headache. To reduce the number of {{Coord}} transclusions, I merge templates using the display=inline,title option whenever I see the opportunity. --Stepheng3 (talk) 03:09, 27 March 2010 (UTC)
I doubt that more than an insignificantly small percentage of those are duplicates. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:31, 18 May 2010 (UTC)
FWIW, it seems to count multiple transclusions on a single page as one. –xenotalk 16:34, 18 May 2010 (UTC)
In that case, the number is under-reporting, since many pages have more than one instance; and some pages many instances; each with a different value. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:46, 18 May 2010 (UTC)
If that is your definite of underreporting, it's definitely underreporting. See transclusion counter for "{{text}}" [8]. Note that the result "5" matches [9]. However note that it is used about 7 times alone in [10]. –xenotalk 16:49, 18 May 2010 (UTC)
578543, just now. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:31, 18 May 2010 (UTC)

what region to use for kosovo?

Hi there, what region can we use for Kosovo? I dont want to mark it as region:RS because it is disputed, better to be able to find all the items of interest in the region of kosovo. Suggestion: Region:Kosovo? mike James Michael DuPont 19:51, 16 May 2010 (UTC)

See previous discussion at Wikipedia talk:WikiProject Geographical coordinates/Archive 26#Region code for Kosovo.3F. --Stepheng3 (talk) 20:11, 16 May 2010 (UTC)

Announcement: Project Wikipedia-World moved to PostGIS-DB

Hello, I moved with my Wikipedia coordinate extraction project Wikipedia-World:
de:Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World/en
from Mysql to PostGIS on ptolemy.

The most advantage is that it is much faster and really support all 273 languages. I have 3 tables for different zoomlevels and use a geometry index (gist). I use coordinates-database from dispenser and merge the entries with the interwikilinks to one table.

I support the parameter "title" and can so extract more than one coordinate per article. Everybody on toolserver ptolemy should have access to the database u_kolossos.

I would be happy if somebody else make a announcement to the other wikipedia communities. --Kolossos (talk) 18:05, 20 May 2010 (UTC)

System?

There are multiple systems for measuring latitude and longitude, such as WGS-84, NAD27, etc. I see no statement in any of the coordinate related templates or style manual section about which one should be used. Jc3s5h (talk) 18:52, 25 May 2010 (UTC)

In {{coord}}, for instance, the documentation says "Map datum should be WGS84." (fourth box in the Quick how to box}. In the Purpose section, it says "It is primarily for specifying the WGS84 geographic coordinates of locations on Earth." I can't speak for the other templates. --Tagishsimon (talk) 19:02, 25 May 2010 (UTC)
Thanks. Considering that the map datum is given on every single USGS quadrangle in a reasonably consistent location, in a block with similar information, I think this information should be a bit more prominent, and should appear in the table of contents so it can be found by those who don't want to read through a ton of stuff they already know. Jc3s5h (talk) 19:10, 25 May 2010 (UTC)
Well, that's why we're an anyone-can-make-that-change- sort of a place. On you go. I'm content that it is mentioned in the quick guide and the second sentence of the first substantive section of the documentation. Hardly a ton of stuff to wade through before you see it. If you want to promote it, fine. But do bear in mind that {{coord}} can also be used for off-world locations, which are presumably not based on WGS-84. --Tagishsimon (talk) 18:44, 3 June 2010 (UTC)

Geocoding ring-roads

The A4540 road in Birmingham, England, needs geocoding. It's a ring road. So. Put the coord in the centre point - [11] or on the road - [12]? The first looks preferable, but the second does at least allow you to drill down to a point on the road. Thoughts? --Tagishsimon (talk) 17:27, 3 June 2010 (UTC)

That's an interesting one! Each solution has advantages and disadvantages. I'd say use the centrepoint (with a suitable radius value) and add a list of significant PoIs, in a table (reformatting the existing route list; with coordinates of each arterial crossing), to the article. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:20, 3 June 2010 (UTC)
We have a similar issue with atolls, most of which are ring-shaped. Examples like these point to a larger issue: sometimes this WikiProject seems to be of two minds about what geocodes are for. While the center is the most useful point for many purposes (such as generating a map of an extensive feature/region), the center is not necessarily representative of (or even part of) the subject. On the other hand, we have a tradition of trying to pin coordinates to a significant feature that can be precisely located: the capital of a country, the mouth of a river, the reception desk of a building, or the front gate of a military facility. --Stepheng3 (talk) 19:27, 3 June 2010 (UTC)
I see you (Tagishsimon) have just tagged some ring roads - which type of coordinates did you use? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:26, 7 June 2010 (UTC)
Your Plam A for the Brum outer ring road. But just a point on the two inner ring roads, from memory, one since it is small enough and the other because it was not obvious to me what the path of the road was. And for Coventry,again, a point on the road since it is small enough to be obvious in a map. Coming away from it, I'm still not comfortable using a centre point since it'll show up in Google, &c, away from the road it purports to represent. The ringroads are - should anyone want to fiddle with them - A4400 road, A4053 road, A4540 road, A4040 road. --Tagishsimon (talk) 11:10, 7 June 2010 (UTC)
Thanks, I've added {{kml}} to the articles with more than one point listed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:45, 7 June 2010 (UTC)

Observatories cleaned up a bit

I added coords to approx. 20 observatories on Category:Wikipedia infobox observatory articles without coordinates ... there are still a few I'm stuck on but I think I made a dent. This is fun!-- φ OnePt618Talk φ 07:15, 6 June 2010 (UTC)

Thanks. We only have another 189,000 to do ;) But every contribution helps. I've just finished all the UK coords I can do - 39 left. Over to someone with a different sort of geocording fu. --Tagishsimon (talk) 16:58, 7 June 2010 (UTC)

Geo URI - RFC 5870

FYI, RFC 5870 - A Uniform Resource Identifier for Geographic Locations ('geo' URI) has just been published. At my suggestion, it has a Coordinate Reference System property, allowing for lunar, Martian etc. coordinates (as well as non-WGS84 terrestrial coordinates). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:03, 8 June 2010 (UTC)

We might keep an eye on this and work out when to add geo-URIs to geohack. I don't think they're quite ready to replace geohack ;) --Tagishsimon (talk) 22:34, 8 June 2010 (UTC)
Indeed not. Baby steps! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:07, 9 June 2010 (UTC)
Update: I've created Geo URI and added 'geo' URI output to {{GeoTemplate/export}} - though it doesn't seem possible to make the instance on the latter clickable, yet. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:21, 9 June 2010 (UTC)

Via Wikipedia-World: The link structure of Wikipedia's collection of geolocated articles has been demonstrated to be consistent with Tobler's first law of geography.

Source: Hecht, B., Moxley, E.: Terabytes of Tobler: Evaluating the first law in a massive, domain-neutral representation of world knowledge. In Hornsby, K.S., Claramunt, C., Denis, M., Ligozat, G., eds.: Spatial Information Theory, 9th International Con- ference, COSIT 2009, Aber Wrac'h, France, September 21-25, 2009, Proceedings. Volume 5756 of Lecture Notes in Computer Science., Springer (2009) 88-105

-- The Anome (talk) 18:25, 10 June 2010 (UTC)

Something broken in Template:Infobox City Japan?

The Shijōnawate article contains a {{coord}} template, but does not emit the coordinate data. Is something broken in Template:Infobox City Japan? -- The Anome (talk) 05:21, 29 June 2010 (UTC)

The template documentation lists a Coords= parameter, but the parameter was disabled by this edit back in November. I've updated the docs and fixed the article. --Stepheng3 (talk) 05:37, 29 June 2010 (UTC)

A bug somewhere

So this started with a discussion on Justin.Johnsen's talk page. I don't understand everything he is talking about. Briefly, the GeoHack URL is malformed. Note that:

{{coord
| 37.2971555
| -118.6587268
| format = dec
| display = inline
}}

produces: 37°17′50″N 118°39′31″W / 37.2971555°N 118.6587268°W / 37.2971555; -118.6587268. Which produces a URL containing -118.6587268_E which is a double negative of sorts. According to Justin this is a problem for Google earth(?).  –droll [chat] 20:54, 15 July 2010 (UTC)

I propose modifying {{coord}} to add articles tagged with it to a new category, Category:All articles with coordinates, in the same way that {{coord missing}} currently adds articles tagged with it to Category:All articles needing coordinates. Does anyone have any objections to this? -- The Anome (talk) 10:41, 13 July 2010 (UTC)

That's something that would make sense. Would it be hidden? SpencerT♦C 00:49, 14 July 2010 (UTC)
It doesn't make sense to me. The latter is understandable as a tracking category, but what benefit does this have over simply using WhatLinksHere? Should we create Category:All articles with infoboxes while we're at it? — Dispenser 01:05, 14 July 2010 (UTC)
After some more thought, I can see your point. I'll look at other ways of achieving the same end, such as category traversal by bot. -- The Anome (talk) 19:35, 22 July 2010 (UTC)

Wonky link on GeoHack page

In investigating a {{geodata-check}} message on Talk:HMS Kandahar (F28), I've found that the "View this location in Google Maps" link at the top of a GeoHack page does not produce the desired result when an article's title ends with a parenthetical disambiguating expression (though the links to Google Maps in the "Global services" list work fine). Presumably this has something to do with the fact that—for reasons not clear to me—the link at "View this location in Google Maps" passes to Google Maps the article title, in parentheses, as part of the search string and Google Maps is "confused" by the multiple parentheses in the string. Is there any reason why that link should be set up differently from the links in the "Global services" list? If so, can the code be revised to eliminate the problem encountered by the user? Deor (talk) 14:38, 19 July 2010 (UTC)

Geocoding roads

For anyone interested, I've raised the issue of geocoding roads at Wikipedia talk:WikiProject Highways. You can find the start of the discussion at User_talk:The_Anome#Bot_adding_coord_missing_templates_to_road_articles. I'd very much like to achieve a resolution here that satisfies both projects, and I think there's a real chance of doing this if we all cooperate. -- The Anome (talk) 19:34, 22 July 2010 (UTC)

Mapping WikiProject pages by coords?

Hello, I have a question. It occurred to me that it would be very useful for WikiProjects such as Wikipedia:WikiProject Rivers to be able to automatically map articles (those with coordinates anyway) by various things like assessment class, "importance", and other parameters. The {{River}} template, for example, can contain things like mapneeded=yes, needs-infobox=no, etc. Is possible to make maps showing pages by parameter/WikiProject like this? Are there existing tools and/or bots that could be used, or modified to do this kind of thing? It would be a useful tool for other projects too--article assessment summaries are only so helpful, mapping them could reveal which regions are more in need of attention. And I can't see how to even generate summary statistics for project specific parameters, like "mapneeded=yes". I've noticed regional differences in the quality of river articles (eg, very good in Oregon, not so good in Texas, terrible in Mexico), but have no automated way to get a better sense of this. If nothing else generating maps of these things would be interesting from a purely "infographic" perspective.

I'm not familiar enough with Wikipedia tools, templates, bots, etc, to know whether this is reasonably simple or not. It seems like it would involve two main steps: somehow creating a list of articles with coordinates based on parameters like those described above, then using that list to generate a map. It wouldn't matter (to me) whether the end result mapping was something within Wikipedia like {{Location map+}} or something like Google Maps, Google Earth, ACME Mapper, etc. Whatever is easiest. I can imagine a tool that outputs KML/KMZ data for Google Earth. In that case it would be especially nice/useful if the placemarks in Google Maps/Earth were labeled by article name and provided a link to the actual Wikipedia page. But this is just something I'm imagining at this point.

I've searched around a bit for bots that might help. User:The Anomebot2 seems to do a lot with coordinates, but apparently focuses more on article with missing coordinates. Looking for tools turned up some leads. I found this tool that can make maps of articles with coordinates, but apparently not by WikiProject and project parameters like "mapneeded=yes" (and also seems to make "infographic" maps that give a general, not article specific picture). I also found the CatScan tool, http://toolserver.org/~daniel/WikiSense/CatScan.php --which can be used to generate lists of articles within a category (Rivers of Oregon, for example) that have a certain template (like "coord_missing"). This is pretty cool and useful, but not quite what I was looking for. The WikiProject parameters like "mapneeded=yes" are in templates on the talk pages of articles, and this tool doesn't seem to be able to work at that level. Also, the tool is based on categories while I am more interested in WikiProjects. Plus, I'm not sure how one would get from a list of articles like those made by CatScan to a map.

Anyway, does anyone know of other tools that might do the kind of thing I'm looking for? Or if not, whether they would be relatively easy to make? Thanks! Pfly (talk) 18:01, 7 August 2010 (UTC)

There are a few databases on the Toolserver; most do not have a convenient way of accessing the data. I could wipe something up for you, but it would take time as I'll have not learn the necessary libraries. — Dispenser 18:19, 7 August 2010 (UTC)
If you organize the project's articles (or article talk pages) into a flat category (such as Category:B-Class River articles, you can use {{GeoGroupTemplate}} to see the coordinates on a map. --Stepheng3 (talk) 04:58, 8 August 2010 (UTC)
Oh, I didn't realize those categories existed. That should work pretty well, thanks. One more question? Is it possible to make and automatically populate a category with, for example, river articles with "mapneeded=yes" in their project templates? There's Category:Wikipedia infobox lake articles without image and a couple other lake-related categories like that, so it seems possible. Or would one have to populated them by hand? Thanks very much. Pfly (talk) 15:33, 8 August 2010 (UTC)
Yes, it's possible. It would involve an edit to the protected template {{WikiProject Rivers}}. --Stepheng3 (talk) 18:47, 8 August 2010 (UTC)
Oops, I'm sorry, it turns out Category:River articles needing maps and related categories already exist. This will all be very useful, thanks for the help! Pfly (talk) 19:00, 8 August 2010 (UTC)

Oh, I guess I do have another question, now that I'm looking at some of the mapped results. It appears that if a page is, say high importance, and has multiple coord templates on it, all those coords get mapped when the GeoGroupTemplate is used on the high importance river category. For example, the Mackenzie River is ranked high importance. But its page has a list of 30 or 40 tributaries, all with coord templates. So all of these rivers become mapped "high importance" even though they are not (most have no pages at all). I'm guessing there may be no easy way around this, but perhaps there is something one can set in the coord template that would prevent GeoGroupTemplate from mapping it? Thanks again. Pfly (talk) 19:10, 8 August 2010 (UTC)

I don't see any easy way around it -- sorry! Try thinking of it as a feature, not a bug ... --Stepheng3 (talk) 19:44, 8 August 2010 (UTC)

Locations of concentration camps

User:The Anome/Concentration camps needing coordinates contains a list of articles about concentration camps that need to have geographic coordinates added. I'd greatly appreciate any help anyone particpating here can give on this. -- The Anome (talk) 07:32, 14 August 2010 (UTC)

More completism: Polish counties

I've posted a message on Wikipedia talk:WikiProject Poland‎ about the last 24 Polish county articles that need coordinates (out of a total of 379 counties). Would anyone here be interested in helping with this? -- The Anome (talk) 09:40, 15 August 2010 (UTC)

Ships

What is the policy for putting Geographical coordinates on ships? [13] - ClemMcGann (talk) 09:45, 22 August 2010 (UTC)

There is no formal policy; but best practice is to use them for wrecks, and permanently (or indefinitely) moored ships such as museum exhibits, training vessels and floating restaurants. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:25, 22 August 2010 (UTC)

Where is latitude and longitude on a college campus?

Using tools I was told about here, I tried to find a college's coordinates but the physical address gave me a location several miles away. I found a way to get the map but don't know where to put the marker.Vchimpanzee · talk · contributions · 20:56, 27 August 2010 (UTC)

I've added coordinates to the article. If you know where a place is located, either this site or this one allows you to zero in on the location (by repeatedly double-clicking on the map) and then simply read off the coordinates. (The latter one will even give you completed {{coord}} templates that you can copy and paste in articles.) In the case of Horry-Georgetown Technical College, there's both a West Highway 501 and an East Highway 501 in Conway, and I think that Google Maps was sending you to the wrong one. Deor (talk) 23:18, 27 August 2010 (UTC)
That's what I believe too. They should probably be told. Thanks for your help.Vchimpanzee · talk · contributions · 17:15, 28 August 2010 (UTC)

Coordinates for large geological features

An article I created, Hellenic arc has recently had a coord missing tag added by The Anomebot2. This feature is over 700 km long and over 300 km wide, and I am unconvinced that having a single set of coordinates will be of any use to anybody - the article has a map clearly showing its location already. I do think that adding coordinates is useful in many cases, I've just finished adding them to 24 earthquake articles, but for some articles a good location map is more important. Mikenorton (talk) 21:55, 27 August 2010 (UTC)

A coordinate will make the article appear in additional distillations of Wikipedia information, including Google Maps. It may be hard to decide on a single point, but there is almost always some place which makes sense. In this case, it looks like somewhere in the middle makes the most sense—maybe near the upward bump in the yellow line—. A dimension parameter providing the longest dimension would be especially apropos for this feature. —EncMstr (talk) 22:25, 27 August 2010 (UTC)
I've gone ahead and added coordinates to the article, centering on a point north of Crete, between the "volcanic arc" and the "non-volcanic arc", with a suitable "dim" parameter. If anyone thinks them incorrect or unadvisable, he or she is welcome to change or remove them. Deor (talk) 21:03, 28 August 2010 (UTC)
OK given the purpose of adding coordinates to an article like this, I've made them less precise - I think that the nearest half degree is more than adequate for a feature of this size (as used in the France article for example) - it should also help to make it clear that this location is to some extent arbitrary. Mikenorton (talk) 23:08, 28 August 2010 (UTC)

Webtool to make things easier

Hey guys. With the huge mountain of work that is needed to be done (Something like 185K needing {{coords}}) I figured making the process easier would make clearing the backlog quicker. I wrote a simple webtool to help y'all find coordinates for articles. The tool (coordhelper) is designed to take the monotonous work out of finding coordinates. Its brand new, so all feedback is welcome. Play around with it for a bit. If you think there is a way to make it easier, I'd be more than happy to incorporate your ideas. Thanks, Tim1357 talk 01:45, 29 August 2010 (UTC)

Comments: I had time to do one search, and just had a design comment. Is it possible to get DMS coordinates, instead of just decimal ones? In addition, would it be possible for the tool to generate a prefilled {{coord}} template with the new coordinates? SpencerT♦C 03:03, 29 August 2010 (UTC)

Should hiking trails have long table of coordinates?

Fellow editors: I'd like to get your opinion about Sierra High Route. That article has a very short amount of prose, and then a very long table of coordinates (in an odd format). I'm thinking that the table is an an excessive listing of statistics and should be removed, but I know members of this wikiproject value coordinate lists. What do you think?

(I worry a little about setting a precedent: imagine someone doing something similar for the Pacific Crest Trail, it would be enormous and have low utility. Also, it looks like the same editor has done a similar table for Sierra Crest: do we want to encourage long lists of coordinates for linear geographical features?)

Thanks! —hike395 (talk) 16:28, 4 September 2010 (UTC)

Coordinates are not statistics. The table in question seems short compared to the exit list in U.S. Route 101 in California. I see no reason to discourage the practice.--Stepheng3 (talk) 22:33, 4 September 2010 (UTC)
Per Stepheng3, I think the fault is that the article is short, not that the table is long. The table is poorly formatted, is not primarily a list of coords, and IMO should stay and be prettified somewhat. In general, linear features should ideally have a table of waymarks with coordinates; but few have. --Tagishsimon (talk) 18:21, 5 September 2010 (UTC)
OK, I see the point. Help in prettifying and formatting the table is welcome! —hike395 (talk) 00:04, 6 September 2010 (UTC)

EarthTools & malware

For the past few weeks, going to the EarthTools site, which is one of the sites listed at Wikipedia:Obtaining geographic coordinates (and which has previously been my go-to site for finding coordinates), has triggered my antivirus program to block attempts to download trojans to my computer. It seems worthwhile to mention that here, lest others be infected. Has anyone else noticed the problem? Deor (talk) 22:58, 8 September 2010 (UTC)

Leading zeroes

I'm wondering if there's ever been a consensus as to whether dms coordinates should include leading zeros. In other words, is there a preferences for 01°02′03″N 004°05′06″W / 1.03417°N 4.08500°W / 1.03417; -4.08500 over 1°2′3″N 4°5′6″W / 1.03417°N 4.08500°W / 1.03417; -4.08500 or vice versa? --Stepheng3 (talk) 18:18, 23 August 2010 (UTC)

Interesting question! Rehman(+) 13:09, 11 September 2010 (UTC)
What would be the point of leading zeros? IMO it just makes the coordinates look cluttered. I'd avoid them. If there shold arise a need for them the can be added in the template. --Dschwen 14:27, 11 September 2010 (UTC)

Geohack - remove Multimap option

It appears that Microsoft have turned Multimap off, and now redirect to Bing. I guess this means that the Multimap link in Geohack should be removed. Thanks for the dumbing down, MS. Bing does not accept UK OS grid refs as input, and does not (except tortuously) give out latitude & longitude useful for {{coord}}. /rant. --Tagishsimon (talk) 23:26, 28 September 2010 (UTC)

There may still be some slight differences between the two services, but not enough to justify a second link. I support removing the Multimap link. PS: ACME mapper is a decent tool for filling in Coord templates. --Stepheng3 (talk) 02:32, 29 September 2010 (UTC)
I'm confused by your "there may still be some slight differences between the two services" insofar as for me, multimap no longer exists and merely redirects to Bing = only one service. If, for instance, multimap is still available in some regions, then we should keep the link. Question: can anyone see multimap.co.uk or multimap.com, or do you merely get redirected to www.bing.com/maps/?mm_src=home&FORM=MMREDIR? --Tagishsimon (talk) 17:50, 29 September 2010 (UTC)
When I go through GeoHack, I get different map scales from the Bing and Multimap links. --Stepheng3 (talk) 18:18, 29 September 2010 (UTC)
Ah, I see that now. Thanks for ACME; was unknown to me and looks very good - will be my first choice from now, I think. But what I miss most is good support for querying by OS grid ref, and provision of OS maps, both of which MM offered. OS is invaluable for coording many UK places. I guess I live in hope that the release of OS maps will lead to a better service than the dire Get-a-map. It would be ideal if ACME provided them through its interface... --Tagishsimon (talk) 18:23, 29 September 2010 (UTC)
Sorry, I don't know a good tool for querying by OS grid reference. --Stepheng3 (talk) 18:46, 29 September 2010 (UTC)

Geohack type hack for Template:Mmukpc

We have a template, {{Mmukpc}} which provides a link to multimap using a UK postcode as an argument. It's used extensively on UK railway stations – A to Z I've not found a template which will take a UK postcode and provide a geohack style list of maps that can be visited. And I'm wondering if anyone fancies putting such a thing together, so that we can stop favouring Multimap and start to favour the users. thanks --Tagishsimon (talk) 17:38, 15 September 2010 (UTC)

In general, the coordinates given in the corresponding Wikipedia articles seem to be more accurate than the locations given using this template, which are often up to a mile from the real location of the station. We should remove them, and replace them with the coordinates in the articles. -- The Anome (talk) 21:21, 29 September 2010 (UTC)
That's a good idea. I'm aware there's a certain lack of standardisation across the first two or three pages of the UK railway stations – A to Z. Would you fancy doing the work to pull the coords across? --Tagishsimon (talk) 21:25, 29 September 2010 (UTC)
I've noted this as a proposal on Talk:UK railway stations – A --Tagishsimon (talk) 21:34, 29 September 2010 (UTC)
I've already got a list of 1360 UK railway stations, with their coordinates. I'll drag in the appropriate pages, and see if I can reconcile the two. Any that are missing, probably because the station is newer than the compilation of my list, can probably be copied from their Wikipedia articles. -- The Anome (talk) 21:46, 29 September 2010 (UTC)
You're a star. --Tagishsimon (talk) 21:58, 29 September 2010 (UTC)
OK, I've already got a draft list, here: User:The Anome/Railway station coordinates. I have the station codes for these, too, somewhere: I'll dig out the relevant code perhaps tomorrow evening. If you can let me know what format you want the table in, I can probably autogenerate 95% of the needed text, and mark the remiaing discrepancies for human review. -- The Anome (talk) 22:10, 29 September 2010 (UTC)
If I understand your question, the format I'd favour would be four columns 1) station name 2) link to live departures 3) link to station facilities 4) coord; pretty much as per UK railway stations – A but with slight re-ordering. We also have in the lists some heritage railway stations and others that don't have National Rail station codes, so we'd need to continue to be able to provide row listings for these ... I'd be happy to go through by hand after you've done your bit and reinstate all that get dropped as a result of your process (if there are any). I'm not sure what your thoughts on templates within the pages are. The history of the A page is instructive. It started at about 30k in length, got chopped by half when a first set of templates were added, and then in half again when a leaner set of templates were implemented. At a quick look, there are two approaches to templates in the A-Z pages, exemplified by A and C. --Tagishsimon (talk) 22:26, 29 September 2010 (UTC)
It's on my to-do list. -- The Anome (talk) 11:16, 10 October 2010 (UTC)

Another idea

The main tool for adding categories to an image appears to be hotcat.js. The philosophy there is do one job well. If only this could be extended so when the input field contained {{location.../{{coord... that whole tag was identified as a geotag and dropped intact on to the image page, I could cat and geotag images at the same time with the same simple tool. I suspect the problem is not coding but the negotiations between the two interest groups. --ClemRutter (talk) 18:07, 10 October 2010 (UTC)

Meanwhile is there a method for mapping the articles that already have both coords and a particular geographic category such as Category:Upper West Side which would help find mismatched cats and coordinate tags?
There's catscan, though I kinda think you might be wanting something that checks that the coords do not exist outside the reasonable bounds of the territory indicated by the article title. I've seen one (or maybe two) wikipedians put together tools to do this, though I cannot locate any now (bar The Anome's User:The Anome/Possible manually-generated geodata errors).

A new idea: a bot to notify users who edit articles needing coordinates

Here's an idea: this related changes search shows that other users are constantly making useful, constructive edits to articles that need coordinates, but that many of them are not currently adding coordinates as they do it. How about having a bot which monitors that list, identifies logged-in non-bot users that have constructively manually edited one of these articles without adding coordinates, and politely invites them via their talk page to consider adding coordinates to the article they just edited, with pointers to instructions about how to do it?

The ideal result of this would be to progressively get more and more users into the geocoding habit. All of this would be subject to sensible restrictions: an overall edit rate throttle, no more than one invitation per user per six months, a way to permanently stop the bot from notifying a user again, etc.

It might also be worth considering doing the same for editors who have created an article that is subsequently auto-tagged with {{coord missing}}. -- The Anome (talk) 11:42, 10 October 2010 (UTC)

I assume such an editor already has the article watchlisted, hence will see the "wanted" template being inserted, so a talk page notice will be seen as superfluous or even a minor nuisance. Jim.henderson (talk) 12:28, 12 October 2010 (UTC)

1 million milestone

I just noticed according to the glupt report we've hit 1,000,091 coordinates across all articles this morning. It somewhat inflated as many U.S. city articles (rambot/smackbot generated) have redundancy and coordinates are shared between articles and lists. — Dispenser 21:45, 27 October 2010 (UTC)

...in 628004 articles, according to Jarry1250's template transclusion counter (the milestone of 500,000 articles was reached in in September 2009, see Wikipedia:Wikipedia_Signpost/2009-09-14/News_and_notes#Milestones).
Regards, HaeB (talk) 00:40, 28 October 2010 (UTC)
Category:All articles needing coordinates currently contains 180,212 articles, so, if we assume that that figure is exhaustive, roughly 628004 / (628004 + 180212) = 78% of potentially geocodable articles now have coordinates. We are making real progress. -- The Anome (talk) 11:44, 28 October 2010 (UTC)
Incidentally, Para's coord missing tool is now becoming increasingly inaccurate: I have geocoded several thousand articles with my bot in recent weeks, and almost none of them have been registered by the coord missing tool. If the tool is missing thousands of edits from my bot, it may also very likely be missing a great many manual edits and underestimating the contributions of human editors. It would be interesting to see what the real figures are. -- The Anome (talk) 11:50, 28 October 2010 (UTC)
The numbers given by the template transclusion counter are across all namespaces. I have added article namespace statistics to the ghel reports (coord-*). — Dispenser 21:11, 2 November 2010 (UTC)

Google data re: broken geo-coordinates

Hi everyone. I work for Google, and we've got some folks here in our Search team who tell me that they have a bunch of data about Wikipedia articles that they think have broken geo-coordinates. That is, they've algorithmically determined that they're probably wrong somehow, based on other data that they have.

We'd like to feed this information back to Wikipedia and help out in any way we can to fix this information. What's the best way for us to approach this? For example, we could give you a dump of our analysis and you could do what you like with it, or we could potentially throw some people at it to just do the edits and get stuff fixed. But we don't want to do that without talking to you first, and making sure we're doing it the right way and won't step on anyone's toes.

What do you think? --Skud (talk) 22:39, 4 November 2010 (UTC)

In order; dump of analysis good. Throwing your people at it, better. Probability of toes being stepped on - I think, slight, especially in the area of fixing existing but broken article coordinates. It would be interesting to know more exactly what your people have; we've run some algorithms against our own data looking for, for instance, coordinates that assert they're connected to country A when the coordinate values fall outside the apparent bounds of country A ... recognising they may be broken is one thing; fixing them another entirely, since the algorithm doesn't tend to give you the correct data, but merely says the existing data is likely incorrect. So I guess, the way to proceed would be a) telling us more about the nature of your findings b) sharing the findings - e.g. the dump c) once we know what we're dealing with, we can talk about the remedies and d) if you're willing and able, we'd welcome an input of resource from you - either in fixing those you've found, or in working with us to assure the quality of what we have, going forwards. To answer your last question: I think it's excellent that you've brought this to us; thanks. We're all about making sure everything that can be geocoded is, and that the codes are accurate as can be. --Tagishsimon (talk) 23:02, 4 November 2010 (UTC)
If you throw people at it, please have them create accounts at Wikipedia and log into those accounts. That way if there are problems, other editors have an easy way to contact the people making the changes. --Stepheng3 (talk) 00:22, 5 November 2010 (UTC)
Yup, I would definitely do that, if we go that way. That would make it easier for us to track their contributions too, so it's a win all round. Not sure we'll head that way yet, though... lemme see if I can get this data for you first! (Another option which occurs to me is a bot, but I am well aware of what a big pile of drama that could be. That said, if someone who is already experienced with wikipedia bots wanted to do something botlike with this Google data, that'd be fab.) --Skud (talk) 00:46, 5 November 2010 (UTC)
In my experience, much (most? almost all?) of the incorrect geocoding in WP is due to east-west or north-south mistakes (i.e., failure to include or mistaken inclusion of a minus sign; I've done it myself). Still, I don't see any way of correcting such mistakes without human intervention to confirm that such an error is indeed what has produced the incorrect coordinates. Deor (talk) 00:57, 5 November 2010 (UTC)
Agreed. I've seen quite a lot of this. Another sort of thing I've seen, especially in areas that are not so well covered on English Wikipedia (eg. Africa), is geo-coordinates that are in roughly the right area -- like, for instance, it might point to the nearest city, rather than the exact location in question. But as for how updates could be made without (or with less) human involvement -- I'm just spitballing here, but assuming that Google have some other signal for where they think things are (eg. picked up from their index of the web, or from google maps, or something), they could take a random subset of those and get human review. If human review of the subset showed high accuracy, then you could decide that the overall data set was pretty solid, and let bots do the rest. This is what we do with Freebase, aiming for 99% accuracy. --Skud (talk) 01:18, 5 November 2010 (UTC)
Skud, any idea how many articles are affected? —EncMstr (talk) 00:50, 5 November 2010 (UTC)
I've asked the engineers in question exactly that question (also, whether it only affects English wikipedia or is international), and hopefully will be able to get back to you on that tomorrow. --Skud (talk) 01:18, 5 November 2010 (UTC)
Yes please! As an active geodata maintaner and bot operator here, I would very much like to be able to use this data so I can cross-check it and make corrections if necessary. -- The Anome (talk) 12:10, 9 November 2010 (UTC)
Followup... the engineer who needs to generate the data is busy at the moment and hasn't been able to get to it yet. But when he does, I will let you know! --Skud (talk) 00:04, 16 November 2010 (UTC)

Shy bairns get nothing

It occurs to me to list a few changes we'd love you to consider at your end; perhaps others will add:

  • Add a UK Ordnance Survey layer, as Bing has. AFAIK the data is free to use: OSOpenData, Licence
  • Accept OS grid references as valid search parameters
  • Display the coordinates of the centre of the map, so that we can more easily lift coordinate data from Google Maps into our coord templates. --Tagishsimon (talk) 23:18, 4 November 2010 (UTC)
All good suggestions, but unfortunately I'm not in the Maps group. (I'm in Search, specifically I work on Freebase (database) which Google recently acquired; we're working with other parts of the Search team to share how we ingest and work with Wikipedia data.) I can maybe see if I can talk to someone in maps, though. --Skud (talk) 23:25, 4 November 2010 (UTC)
You're certainly one step closer than me ;) thanks. --Tagishsimon (talk) 23:29, 4 November 2010 (UTC)
For the last one, right-click and select "What's Here?". The OSM folks don't like us using getting coordinates that way since it constituents as a derivative work. Other requests:
Dispenser 05:57, 5 November 2010 (UTC)
Regarding OS grid references, we have some [apparently] public domain code for OS grid to WGS84 coordinate transformation. It's a hacked-together cross-language port of some very old code which itself appears to have been ported from other, older, code, and it's slow becuase it uses successive approximation to invert functions, but it seems to work. For Google's own work, which will need to run fast, I'd suggest developing either high-order local polynomial approximations of the real transformations, or simply precalculate the data over high-resolution grids and use bilinear interpolation. A similar job can then be done on the inverse transformation. I'm happy to help, if you need it. -- The Anome (talk) 12:26, 9 November 2010 (UTC)
Can you let us have a reference for it, I'd like a look or you could stick it in my dropbox, clemruttter_wcs3-at-sendtodropbox.com. I have done the job once in writing ostowiki.html adapting other folks code so I may be able to help with a clean version. --ClemRutter (talk) 23:03, 9 November 2010 (UTC)
And isn't the expression : Shy bairns get nought. --ClemRutter (talk) 23:03, 9 November 2010 (UTC)

User reports

While we're on errors, I use the following query on the Toolserver to review how well we respond to user generated error (i.e. those in Category:Talk pages requiring geodata verification):

-- ;sql enwiki_p
SELECT DATE_FORMAT(rc_timestamp, "%H:%i %b %d") AS "Time  Day", rc_user_text, rc_title, rc_comment
FROM recentchanges
WHERE rc_comment LIKE "/* Coordinate error */%"
ORDER BY rc_id DESC
LIMIT 30;

So far we've been doing pretty good, although users are still a little perplexed how to fill it in. --— Dispenser 16:12, 12 November 2010 (UTC)

To Do by State?

I worked on this project a bunch back in 2008 and would like to get back in the saddle. Back then there was a to do list by US state. I can't find this anymore. Does this still exist? I'd like to continue in my home state and expand out from there. --Kojones

Welcome back!
Things are more automated now, and make more extensive use of Wikipedia's facilities. Near the top of this page are links to categories of all articles missing coordinates, articles by country, and by subject. For example, from Category:Articles missing geocoordinate data by country you can navigate to a category for your state of interest. For the countries with many subentries, use the A-Z navigator at the page top instead of slogging through the next page. Thanks! —EncMstr (talk) 21:21, 5 November 2010 (UTC)
Thanks! I went to that link and couldn't find the US. D'oh.. it was on the second page! Looks like my Colorado list has expanded a lot since I left! --Kojones —Preceding undated comment added 21:59, 5 November 2010 (UTC).

Question and ask for help.

I wonder if anyone here could advice on how to get the geographic template in the List of public art in Indianapolis to work such that it displayed the name of the artwork in the Google map instead of just a number? I can't seem to figure it out. Many thanks, --RichardMcCoy (talk) 22:15, 19 November 2010 (UTC)

At the end of the stuff within each {{coord}} template in the article, add the parameter |name=name of artwork (replacing "name of artwork" with the actual name of the relevant artwork, of course) and Bob's your uncle. Deor (talk) 22:36, 19 November 2010 (UTC)
Thanks for the reply! Sorry to be dense, but I'm not sure I get it. Will you edit as an example in the List of public art in Indianapolis? --RichardMcCoy (talk) 02:47, 20 November 2010 (UTC)
Responded to your parallel message on my talk page. Deor (talk) 03:09, 20 November 2010 (UTC)

UK national address location database

This news article about the proposed forthcoming official GeoPlace UK address database might be of interest to UK particpants here. -- The Anome (talk) 12:48, 3 December 2010 (UTC)

We might start with an article on it; I'll not hold my breath for it being available on any terms that will make it accessible to us :( --Tagishsimon (talk) 12:57, 3 December 2010 (UTC)

The creator/defender of this article submitted an AfD after I objected to its existence, long before I got around to an Afd msyelf. A recent Afd on Quadripoint failed, and that article has since spiralled out of control with conflation and undue weight and original research, and its evil twin is Tripoint and there's also quasi-geometric topics like List_of_sets_of_four_countries_that_border_one_another. Geo-junk, backed up by tons of coordinate cites but no actual cites establishing these as valid topics. This isn't directly part of this WikiProject, but all such articles are masses of coordinates, and largely built out of them - as geo-fabrications by people totting up similar numbers or situations and trying to pretend that they're a topic. Wikipedia is supposed to be an encyclopedia, not a compilation of trivia and abstractions built on trivia.Skookum1 (talk) 21:51, 5 December 2010 (UTC)

Please add "Busstop" as permitted type

Railwaystation is allowed as type. I suggest busstop as well. The bus stop is typically the central point of residential areas in most parts of the world, and you can easily find its coordinates from geolocator. Mange01 (talk) 17:14, 15 December 2010 (UTC)

Just a couple of issues: which bus stop? Residential areas in my understanding tend to have multiple stops. Second, and more seriously, type is used to set the scale of the map, and whereas a bus stop tends to be a relatively small location calling for a more detailed scale (we set 1:10000(, a residential area tends to be very much larger calling for a different scale (1:20000 or more). So what scale do we fit type=busstop to? Its use to denote bus stops (e.g. a bus station, of which we have many on wikipedia) or its use to denote a residential area? Type should relate to the thing we are marking with a coordinate (a residential area), not the anchor for the coordinate (the bus stop).
In other news, I do agree that the list of types is somewhat parsimonious and on the one hand I favour many more types; on the other I think we should get rid of types altogether since their only use AFAIK is as a proxy for scale. Given the paucity of types and the existence of categories, it is unlikely that we'll ever make use of type for any reason other than scale, and so I lean to getting rid of it. Oops. We use it to to select a marker icon in the WikiMiniAtlas. So maybe we should do some work on expanding the number of types. --Tagishsimon (talk) 17:56, 15 December 2010 (UTC)

How to correct misinformation picked up from WP

When we put co-ordinates in an article, other sites like Geonames pick them up; this is a problem when the article turns out to be a hoax and is deleted here but not there. For instance, Geonames still lists Monvilla, a non-existent Shropshire village which we deleted as a hoax over two years ago, and it also has Bunaka, an equally non-existent Indonesian island which we have just deleted. These entries credit Wikipedia, and quote part of the article text, but do not provide any direct link to click to get the actual article - which would enable an enquirer to check whether it had been deleted.

Do we have any contact at Geonames to tell about these? I don't see any particular contact point on their website, except this list of names. Are there any other sites using our data that we should warn? Regards, JohnCD (talk) 19:11, 27 December 2010 (UTC)

What articles should have coordinates?

Hello. A discussion on a user talk page was started regarding whether articles about such things as telephone area codes or congressional districts should receive geocoordinate tagging. Bringing here for wider discussion.--—Elipongo (Talk contribs) 04:22, 7 January 2011 (UTC)

Yes. Telephone area codes and congressional districts should have {{Coord}} tags so that they can easily be displayed in GIS tools such as Google Maps. Because these regions are large, the coordinates need not be very precise, but they should be tagged all the same. --Stepheng3 (talk) 05:58, 7 January 2011 (UTC)
I think the general principle for display=title coordinates is whether an article describes something with an associated geographic focus or centroid, whether it's 20 meters across, or 500 km across. Using this principle, I agree that area codes, top-level postal code areas, and congressional districts, apart from At-Large districts, should be geocoded. Transitory events like hurricanes and other storms should in general not be geocoded, unless it's the inline coordinates of a specific site in the article that is notable for its involvement in that event. Eatrhquakes, on the other hand, definitely should be geocoded, using their epicenter.
On the same principle, companies that have their business associated with a particular location should be geocoded -- for example, breweries, single restaurants, theaters -- but others, which have national or multinational scope -- for example, restaurant chains, and most large companies -- should not, because what matters is their activities, which are diffuse, not the location of their headquarters. An article about the headquarters itself, on the other hand, should, and, although I would not add them myself, I see no problem with an inline mention of coordinates for the location of the headquarters in the article about the main entity. Thus, no coordinates for U.S. Army, but coordinates for The Pentagon. Similarly, small radio and TV stations can be geocoded at the site of their studio or transmitter, but national TV stations or satellite channels should not, unless, for example, like Comedy Central, their business is notable for being carried on at a particular location.
Ships, aircraft, and other mobile objects are an interesting special case, and I think the same reasoning can be applied. In general, the only ships which should be geocoded are ones which are now in a permanent location -- having been sunk in a battle, or laid up at a permanent mooring. The same principle applies to aircraft. I believe that types of things are never geocodable, only specific instances: for example, the Spitfire article should not have a display=title coordinate, but individual Spitfires with specific long-term locations can have their coordinates added inline within the article, or of course added as display=title if they have their own article. -- The Anome (talk) 13:09, 7 January 2011 (UTC)

Makes good sense to me, Steamship gets no tag, but RMS Titanic does. Aircraft carrier doesn't but USS Intrepid does. ESPN doesn't, but one could geotag inline for the location of its headquarters in Bristol, Connecticut. I do differ in that I think that "at-large" congressional districts can be tagged too, they still represent a defined geographical area, i.e. the entire state! Therefore I would use the same coordinates for the at-large district as for the state itself.--—Elipongo (Talk contribs) 17:56, 7 January 2011 (UTC)

At-large congressional districts, perhaps. But all the numbered districts don't need coordinates because they're irregular and not shown on mapping services. I wouldn't have a bot tag congressional districts; there are few enough to do manually and avoid false positives from the bot. Pi.1415926535 (talk) 18:12, 7 January 2011 (UTC)

Irregular? By that logic West Virginia wouldn't be geotagged. Not shown on mapping services? Should we then remove the geotags from all the NRHP listings? --—Elipongo (Talk contribs) 18:47, 7 January 2011 (UTC)

West Virginia is clearly shown with borders on mapping services; area codes and congressional districts are not. The vast majority of NRHP listings are buildings which can clearly been seen in satellite images; historic districts tend to be small (< 1 km) and deliniated by streets or geographic features so that coordinates are valuable, while congressional districts are almost by definition large and gerrymandered such that they don't have a shape visible on mapping services and a central coordinate doesn't make it possible to see where the whole district is. Coordinates should only be used where they show a single distinct feature (like a building or shipwreck) or a larger area that is shown on mapping services (state or body of water). If there's a way to create multiple coordinates that automatically show an area, then those would perhaps be appropriate for congressional districts, but I don't know of any way to do them through geohack. Pi.1415926535 (talk) 18:58, 7 January 2011 (UTC)

It's beside the point, but it bears pointing out that Google Earth has always had layers depicting congressional districts, zip codes, area codes, etc. ad nauseam. In fact it depicts those things BETTER than it does many town borders (I always had to turn on the zip code layer to see the outlines of Connecticut's towns and cities). The fact is that most external mapping products will NOT show you where the town borders of, for example, Ellington, Connecticut are - that is why there is an illustration in the article itself depicting the shape, extent, and location of the town within the state. Why then have the geocoordinates on the article at all, we already have a map/illustration - we don't need an external link to another product to illustrate the subject, do we? No, but we do provide the link so that users can find out what else is nearby and use other resources provided by the map site. It is most definitely not for illustrative puposes as you seem to think - we can do that perfectly well already without resorting to external links. --—Elipongo (Talk contribs) 20:59, 7 January 2011 (UTC)

I have to agree with friend Eli (Sorry I won't be seeing him at Wikipedia:Meetup/NYC/Wikipedia Day). Yes, Maryland is split by a wide bay and France has bits overseas and Malaysia is largely but not entirely archipelagic, but these are individual, not general difficulties. Most postal and telephone code areas are far more compact than many municipalities or political subdivisions (See the long flagpole annexations of Los Angeles and Chicago. By coincidence I just spent several minutes finding the right location for a church on the edge of Bensonhurst where not everyone agrees where the neighborhood boundary is.
Indeed gerrymandered constituencies can be difficult, with the additional complication that many (not in Japan) are regerrymandered every few years. So, when it's difficult, better not to do it than get it wrong, but again it's a case by case question. Jim.henderson (talk) 21:52, 7 January 2011 (UTC)
Fair enough, especially now that I know that you can autoset the coordinates to scale. I would prefer that geobots like Anomebot2 not index pages that have to be decided case-by-case, though, unless there's some way - a template or whatnot - to tell the bot not to index a page. Otherwise, you just get a cycle of delete template / bot replaces. Pi.1415926535 (talk) 01:00, 8 January 2011 (UTC)
If the same bot is adding a category more than once, that sounds like a bug in the bot. Can you point to an example of this happening? --Stepheng3 (talk) 07:21, 8 January 2011 (UTC)
Not specifically a bug; it just has a tendency to retag pages which havve had the tag removed but no coordinates added. For example: Area codes 860 and 959 Pi.1415926535 (talk) 05:45, 9 January 2011 (UTC)
Sorry about that. I've gone through my logs on this. The bot keeps a record of the tagging state of each article by name, and won't (unless I force it manually) re-tag the same state to the same article name twice. I've just checked this article and the problem was that the article was renamed from Area code 860 to Area codes 860 and 959: since the bot keeps records by article name, not page ID, it saw the renamed article as a new article, and tagged it accordingly. -- The Anome (talk) 10:22, 10 January 2011 (UTC)
Aha. That makes sense. Those incidents seem to be rare enough that they can be dealt with manuallly.Pi.1415926535 (talk) 13:05, 10 January 2011 (UTC)

Google Earth goes astray

Has anyone else seen our Geohack leading Google Earth to display the wrong location? For me, the tag atop Fulton Ferry, Brooklyn leads to an inland location, 5 km to the northeast in Greenpoint though Google Maps goes to the correct riverbank location. Jim.henderson (talk) 16:12, 12 January 2011 (UTC)

I just had the same experience with Out Stack, clicking on the 'Open' option for Google Earth gives me a location over 9 km to the south-southeast, but if I click on 'w/ meta data' instead it goes to the correct location. Mikenorton (talk) 18:25, 12 January 2011 (UTC)

Today my Brooklyn article goes to the correct location in GE. Coordinates in the article were adjusted two days before my first notice here, by a margin much smaller than the error I observed, but not since then. So, either the system was repaired elsewhere, or the problem is intermittent. Jim.henderson (talk) 21:44, 18 January 2011 (UTC)

But for me the problem with Out Stack is unchanged. Mikenorton (talk) 22:59, 18 January 2011 (UTC)
See Template talk:GeoTemplate/FAQDispenser 05:38, 19 January 2011 (UTC)
Drat. This presumably means we cannot point Google Earth at a newly described location, thus severely diminishing the usefulness of GE, at least for me and any others who may have been using it for precisely the purpose of checking recently Wikigeotagged locations. To help others who would try to use it similarly, the Geohack page that our Template:Coord brings up should have a warning. I haven't noticed this problem with Template:Location. It this my own mental numbness, or does GE treat camera locations differently in this regard? Jim.henderson (talk) 23:35, 20 January 2011 (UTC)

 Done EncMstr (talk) 01:04, 25 January 2011 (UTC)

this university is in the news. the coordinates look messy. can someone take a look? there are two one is labeled old and the other new. thanks. -Shootbamboo (talk) 00:45, 25 January 2011 (UTC)

I fixed the coordinate problem, but there are several important issues to address in other aspects. —EncMstr (talk) 01:04, 25 January 2011 (UTC)

International Court of Justice found in Oregon forest

I don't see the cause of this one. See this Google Map with the Wikipedia layer enabled. In the middle is an icon for the International Court of Justice. That coordinate, 45°N 122°W / 45°N 122°W / 45; -122, appears as a wikicomment in the article. As far as I can tell, it was never naked. The article's actual coordinates were first added with this edit on 2008-12-03. WikiBlame doesn't show it being changed (except for several vandalism/revert cycles) since then. Surely Google didn't extract the commented-out coordinate?! —EncMstr (talk) 03:11, 26 January 2011 (UTC)

I've moved the {{coord}} from the bottom into the infobox, and removed the comment, so hopefully the next Google Maps update will fix it. As to why it happens, I think we have to assume that the code that Google uses doesn't ignore HTML comments. - htonl (talk) 10:31, 26 January 2011 (UTC)
Improbably, it is no longer there. Could it be that posting the problem here cleared it up? Or was it that deleting the commented out coordinate fixed it? It'd be nice if there was a feedback loop in the dialog with Google.... —EncMstr (talk) 17:30, 27 January 2011 (UTC)
Never mind it being gone. It was a matter of proper zooming to see it. —EncMstr (talk) 17:31, 27 January 2011 (UTC)

Google Maps and coords

I noticed recently there is a checkbox on google maps to display wikipedia entries, I was wondering how long after we tag an article with coords, it will take to show up. Any ideas? TiMike (talk) 21:06, 26 January 2011 (UTC)

Google says an update is made every one to three months. By my observation, it is not quite that frequent. —EncMstr (talk) 17:20, 27 January 2011 (UTC)
Thanks EncMstr. TiMike (talk) 03:46, 5 February 2011 (UTC)

Wikipedia:Bot requests

There are two pending Wikipedia:Bot requests for Geo coordinatges.[14][15] Please contribute your thoughts there. -- Uzma Gamal (talk) 14:46, 4 February 2011 (UTC)

Source question

Hate to say it, but isn't adding coordinates to an article an addition of an unsourced statement of location?

We're having a specific question which led me to think about this. At the SS Edmund Fitzgerald article, (whihch we are getting ready for FA review) the only coordinates from an RS that we have so far been able to find has a least significant digit (which sort of equates to claimed accuracy) of 1/10th of a minute (roughly +/- 1/2 mile) There is a question of how close to the US border the wreckage field is, and whether or not it is fully in Canada. An RS covers a claim that a part is in the US. The coordinates in the usual place on the article has more significant digits, i.e. more information and a claim of greater accuracy than we have found in extensive review of RS's. And the co=ordinates indirectly say that it's all in Canada. So the question is, what is the source of that coordinate information? If it's solid, that would be great info. If it's unknown, it is putting unsourced info into the article in a very significant area. Sincerely, North8000 (talk) 02:48, 28 January 2011 (UTC)

There are several ways to cite the source of the location. The {{coord|lat|long|source:source-description}} coordinate attribute, a standard <ref> {{cite something ...}} </ref> , and some infobox templates provide a way to cite a coordinate. One could even add a general citation in the References section. Any of those would be better than not providing a source.
However, it seems the problem you face is different—and much more difficult: how to choose a suitable reliable source for a location, and how that location has size and shape which affects which border it is behind. Some folks here might chime in.
Adding a coordinate to an article has, in some cases, been considered a type of sourcing in itself. For common types of landmarks, like cities, roads, etc., clicking on the coordinate should show an object on the map corresponding to the article. The source is then the mapping service, such as Google Maps. For unmapped objects, of course, this doesn't work. —EncMstr (talk) 03:11, 28 January 2011 (UTC)

Thanks. Sorry for any confusion. I wasn't referring on how to format a citation, what I really meant is "where exactly did those Edmund Fitzgerald wreck co-ordinates come from?" Thanks to anyone who can answer. Sincerely, North8000 (talk) 20:29, 28 January 2011 (UTC)

Unsourced coordinates are rather common, it seems. I don't know about the Edmund Fitzgerald page, but since the formatting topic came up I thought I'd mention one I didn't know about for a long time—you can footnote "title" coordinates by putting the ref tag in the coord's "notes" field, like this: {{coord|35|43|0|S|57|20|50|W|display=title|notes=<ref>cite info here</ref>}} I tried it a little but decided I didn't really like how it looks. Still, it's an option use title coords. Perhaps there are other cases where it would be useful. Example page: Samborombón River. Pfly (talk) 01:40, 29 January 2011 (UTC)
Thanks. I think that since most coordinates are for visible objects/places, they fall under "Paris is the Capital of France" regarding sourcing. In this case, for multiple reasons, I'd really like to know where those coordinates came from. North8000 (talk) 11:15, 29 January 2011 (UTC)
The coordinates came from an IP who has no talk page.[16] I added a request at Geo coordinates for SS Edmund Fitzgerald wreckage for you. -- Uzma Gamal (talk) 12:07, 5 February 2011 (UTC)
I found the addition of the coordinates with the edit addition of facts from coast guard report by Ydorb at 2004-08-30T20:06:42 UTC, approximately the 25th edit since the article was created on 2003-04-28T22:10:31 UTC. Among many other changes, it adds the phrase She sank in 530 feet of water at a position 46 degrees 59.9' N, 85 degrees 06.6' W, which is about 17 miles from the entrance to Whitefish Bay.EncMstr (talk) 01:52, 6 February 2011 (UTC)
Thanks. Per the thread at the artcile's peer review page, I found a source in the NTSB report. I was unable to add a cite to the normal coordinate listing, so I added it in the info box and put the citation there.North8000 (talk) 21:17, 6 February 2011 (UTC)

Defunct townships, boroughs, etc

Hi, I have been doing a lot of work on the New_Jersey_articles_missing_geocoordinate_data category. I am getting to the "bottom of the barrel" and am noticing a lot of former or defunct places.

They either have been dissolved or merged into another administrative area at some point prior to 1900. In some cases I know about where the location is, but SHOULD I use that location. Is there any precedent?

Thanks, TiMike (talk) 21:00, 6 February 2011 (UTC)

I think even an approximate location is better than none. Just don't be excessively precise. In other words, if you only know the location to within 8 miles, round the coordinates to 10 minutes of arc or 0.1 degree. Consider also mentioning "approx" in the parameters, the article body, and the edit summary. —Stepheng3 (talk) 21:59, 6 February 2011 (UTC)
Thanks Stepheng3. Will do. TiMike (talk) 20:13, 7 February 2011 (UTC)

NJ is complete

Just a heads up... Over the past few weeks, I have been banging away at the list of missing coordinate data for New Jersey articles. Started at over ~700. There are only 2 left, and they have been tagged as PROD, so essentially NJ is done!

TiMike (talk) 00:39, 13 February 2011 (UTC)
Our thanks to you and everyone else involved in clearing out this backlog. Keep up the good work. —Stepheng3 (talk) 20:05, 13 February 2011 (UTC)
That's fantastic. If we could have more editors like you, we'd have no backlog at all! -- The Anome (talk) 12:20, 15 February 2011 (UTC)
Yeah right. We cleared out the UK some time ago, but some Anome chappie merely came along and filled it back up again. But congrats to TiMike anyway, sterling effort, much appreciated. --Tagishsimon (talk) 12:28, 15 February 2011 (UTC)
Thanks guys, I am continuing on doing the United States articles missing geocoordinate data. When this is done, I will start on some more individual states. TiMike (talk) 20:14, 15 February 2011 (UTC)

Help me add coordinates to settlement template.

Hi could someone please help me add these coordinates 59°24′04″N 17°56′38″E / 59.401°N 17.944°E / 59.401; 17.944 to the settlement infobox for Rinkeby-Kista. Thanks. P. S. Burton (talk) 20:05, 26 February 2011 (UTC)

 Done: you can't put fractional decimal degrees in the "latm" and "longm" fields, but you can simply put the whole thing into the "latd" and "longd" fields. There were also duplicate "coordinates_display" fields which were preventing the coordinates from appearing in the title. - htonl (talk) 20:51, 26 February 2011 (UTC)
Thank you. P. S. Burton (talk) 12:06, 27 February 2011 (UTC)

Dead People?

Hi, I came across this article: Valentine Mason Johnson with a coord missing|United States tag. Do we tag dead people? I can see some saying no and some saying yes, if the burial plot is known... Any thoughts? TiMike (talk) 20:10, 15 February 2011 (UTC)

Hmmm. It was added by a bot. That usually suggests that the bot was working through a category. However, I don't see why either Category:Florida State University or Category:History of United States colleges and universities might require all their members to have coords though. --Redrose64 (talk) 20:20, 15 February 2011 (UTC)
We geo-tag some dead people, where their resting place (usually a grave) is known - see documentation for {{Infobox person}}. Note though, that such coordinates should be precise, and not simply the generic location of, say, a cemetery or graveyard. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:55, 20 March 2011 (UTC)

Template:Coord unknown has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Bazonka (talk) 21:53, 23 March 2011 (UTC)

Galilee (ship)

The Galilee (ship) article has had a coords missing tag added. The remains of the ship are however in three different places, part of the prow at Fort Mason, the stern at Benicia and the remains of the rest at Sausalito, so where to put the coordinates? Mikenorton (talk) 13:44, 25 March 2011 (UTC)

If there is a best known, significantly more accessible or well visited portion, make that the title coordinate. Add the other parts in the text or a table of locations, using name=description of part. Also, add {{GeoGroupTemplate}} to the article. If there is no clear "primary" piece, perhaps make the coordinate a general area (by using a low-precision coordinate and a large dim:<widest dimension in meters>) and then specify precise coordinates for all the parts with none of them having a title attribute. If that isn't clear, see Vista Ridge Tunnels for an example of the first technique. —EncMstr (talk) 15:31, 25 March 2011 (UTC)
Thanks, I followed your advice but decided just to include the bow and stern pieces, I don't think that there's anything left to see at Sausalito. Mikenorton (talk) 23:09, 25 March 2011 (UTC)

A history of the world in 100 seconds & allegedly broken coords

I found this - A history of the world in 100 seconds based on articles with coordinates and historic dates. Make of it what you will. The post also pointed to a table of 5k or more "invalid coordinates", though my casual wander through these suggests that many are fine and it's merely a broken parser error. --Tagishsimon (talk) 10:38, 28 March 2011 (UTC)

Help needed: OS grid reference

Earlier today, I was adding coordinates to the Dinedor Hill article and happened to notice that the Ordnance Survey grid reference in the infobox seems to be in error, indicating a spot a bit more than a kilometer to the west of the hilltop. I don't understand the OS grid system and therefore don't know how to fix this; could someone who does understand it take a look? Deor (talk) 21:15, 31 March 2011 (UTC)

Green tickY Done. --Tagishsimon (talk) 21:37, 31 March 2011 (UTC)

Thanks, Tagishsimon. Deor (talk) 21:46, 31 March 2011 (UTC)
For future reference, http://www.nearby.org.uk/ can do conversions in both directions. -- Dr Greg  talk  22:13, 31 March 2011 (UTC)
Also, if you click the lat/long to get to the GeoHack page, and from the row "Ordnance Survey Get-a-map", select the "OS maps" link, that will show a 2 km square centred on the lat/long in question: in the bottom margin of this square it shows "Grid reference at centre - SO 522 363 GB Grid". The "SO 522 363" part is the actual OS grid ref; it's to 6 figures, which is an accuracy of 100 metres. In the past you needed to take the spaces out of this to make "SO522363" before feeding it into certain Wikipedia templates, but this is no longer necessary in most, including {{infobox mountain}}. Further info on OS grid refs is at Ordnance Survey National Grid. --Redrose64 (talk) 08:30, 1 April 2011 (UTC)

What articles should be tagged with geographical coordinates?

Please see Wikipedia talk:Manual of Style (dates and numbers)#What articles should be tagged with geographical coordinates.3F. Please leave comments at that page, not here. Thanks! Kaldari (talk) 20:54, 6 April 2011 (UTC)

Announcement: "Add-tags" a tool to connect OpenStreetMap & Wikipedia

Hello, there is a new tool to bring more Wikipedia-Tags inside OSM-database and connect so both projects more and more. It can be found here:
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl/Add-tags

It's the idea to use this connections later to highlight the matching OSM objects in the OSM-map in Wikipedia. So it's a new kind of geocoding for Wikipedia.

It brings also the information that was collected collected in Wikipedia like Interwikilinks into OSM to render better multilingual-maps. --Kolossos (talk) 08:20, 16 April 2011 (UTC)

Osama's hideout

Given the recent death of Osama Bin Laden, I've had a go at locating his hideout on Google Maps, based on the graphic in this BBC News story. I get somewhere near 34°10′10″N 73°14′34″E / 34.169399°N 73.242677°E / 34.169399; 73.242677. However, the match-up isn't perfect, and this might well be old imagery; would anyone else like to have a go?

See http://www.polycapitalist.com/2011/05/google-map-of-bin-ladens-compound-in.html for discussion of various possible candidates for the compound's location. -- The Anome (talk) 20:09, 2 May 2011 (UTC)

Ah. A quick look at Death of Osama bin Laden shows others have already identified the same location before me. -- The Anome (talk) 20:18, 2 May 2011 (UTC)
Six decimal places is way too precise unless you're pinpointing the individual bullet holes. --Redrose64 (talk) 21:26, 3 May 2011 (UTC)

Style preference regarding positioning

Is there a style preference regarding in-line v. infobox v. title positioning? I went to the Manual of Style hoping to find this, but it was just a "how-to". Thanks, cmadler (talk) 13:04, 9 May 2011 (UTC)

My view is that if the co-ordinates relate to the subject matter of the whole article, then they should be positioned in the title or, if the article has one, the infobox. But if the co-ords relate to a feature only mentioned in the body of the article, then they should be positioned in-line, after the first mention of the feature. Bazonka (talk) 13:45, 9 May 2011 (UTC)
Not all infoboxes allow coordinates, and for those that do, there are various ways of doing it: some have a full set of D/M/S parameters for latitude and longitude; some have just one for each; some have none, but instead use a generic parameter like |coordinates= in which you need to add your own {{coord}} or equivalent. You need to check the documentation for the specific infobox.
For those infoboxes that have none of these, you would need to put a {{coord}} somewhere suitable: if specifying |display=title, put it in the last section (before the categories); but if using either |display=inline or |display=inline,title it needs to go within the text at the point where the coordinate link should appear, per Bazonka's post above.
Some infoboxes with lat/long parameters will display the coordinates both in the infobox and at upper right: {{Infobox UK disused station}} is one such - that template also allows |coord_display=inline to suppress the upper right display, for use in articles with two or more infoboxes (see Dudley Port railway station).
Some infoboxes use the lat/long to generate a pushpin map: {{Infobox UK place}} is one such - the same coords are also used to produce the coord link upper right, see for example Didcot. --Redrose64 (talk) 14:11, 9 May 2011 (UTC)
So, for coordinates relating to the entire article, would you say that listing it in the infobox is preferable to the upper right (title), and that it should not be in both? The article that made me wonder was Sherzer Observatory; I was glancing through several articles, and since all the others had the coordinates in the upper right, at first I thought this article was missing it. I then noticed it in the infobox, but I wondered if it would be better in the upper right instead of the infobox, or even in addition to the infobox. Since it just uses {{coord}} it would be a trivial matter of adding the parameter to add or move it to the upper right, if that were preferred. cmadler (talk) 16:22, 9 May 2011 (UTC)
Standard practice for such an article is to use {{coord|lat value|lon value|type information|display=inline,title}} to put the coordinates in both places. —EncMstr (talk) 17:14, 9 May 2011 (UTC)
Thanks, cmadler (talk) 17:55, 9 May 2011 (UTC)

QR codes

Is anybody interested in QR codes here? A QR code is really just a bigger version of a bar code, and people use them to link to websites (among other things). Derby Museum uses them to link to Wikipedia articles via smartphone, and the article that comes up is automatically in the preferred language of the phone. Something similar may be happening in Spain soon. QR codes can be used outdoors as well. Last weekend as an experiment I created a new article on an NRHP site and posted the QR code on a planter in front of the building. Worked marvelously linking me straight to the article (on a borrowed smart phone).

So why did I think that WP:COORDS might be the place where folks might have some ideas or guidelines on this? This project links Wikipedia to places in the outside world; QR codes can link places in the outside world to Wikipedia. In other words, the whole world can become part of your browser, linking you from a specific spot to Wikipedia's article about that spot. Well, if you have ideas on this, or what project might be the best place to take these ideas and question, please leave general interest notes here, or more specific topics on my talkpage. Any help appreciated. Smallbones (talk) 20:13, 25 May 2011 (UTC)

Coords for large areas

I just noticed that the Southeastern New England AVA, which spreads across three states, has a {{coords missing}} tag. Should this have coords? How do you pick them, closest degree that falls in the middle? Thanks.--SarekOfVulcan (talk) 15:28, 9 May 2011 (UTC)

Since the entity has a stable location, it should definitely have coordinates. AVAs are often irregularly shaped. If you can, choose a point near the weighted center, but definitely use a minimum of digits to help express the fact that it is a large area. So use latitude of, say 42.5 instead of 42.46473729489750392. Also, use the dim:n parameter where n is the greatest dimension, expressed in meters. For example, if SWNE AVA is 120 miles across, then something like {{coord|lat_value|lon_value|type:landmark_region:US_dim:195000|display=inline,title}} (for use in the infobox—see question above). —EncMstr (talk) 17:22, 9 May 2011 (UTC)
Thusly, per Geolocator? --SarekOfVulcan (talk) 18:09, 9 May 2011 (UTC)
That's very good. It would be even better to omit the seconds of latitude and longitude, thus: 41°30′N 71°30′W / 41.500°N 71.500°W / 41.500; -71.500 or use decimal degrees thus: 41°30′N 71°30′W / 41.5°N 71.5°W / 41.5; -71.5. The presence of seconds of arc suggests much greater precision than is warranted for a region of this size. Best regards, —Stepheng3 (talk) 18:30, 9 May 2011 (UTC)

As a follow-up to this: currently, Wikipedia:WikiProject Geographical coordinates#Which coordinates to use says "For administrative districts, use the head office." But it seems like in practice, for things like states, provinces and municipalities we follow the same approach described above, using approximately central coordinates of an appropriately low precision. Should we change that text to reflect this? - htonl (talk) 02:19, 15 May 2011 (UTC)

I would support an addition to allow the approximate center as an acceptable alternative, especially for regions that have no head office.—Stepheng3 (talk) 16:59, 1 June 2011 (UTC)

three instances of mass-identical-coordinates on other-lang wikis

I'm not sure if this is the right place for it, but I'm not sure where to go on the Italian, Spanish, or French wikis to discuss this, and since coordinates are being aggregated a lot between languages lately, it might be of interest here also. I ran a query for clusters of articles located in the exact same spot, and found three clusters, two that seems to be wrong, and one suboptimal but not wrong per se:

--Delirium (talk) 12:50, 10 May 2011 (UTC)

Ouch. That looks like another sanity check that needs to be added to the interwiki coordinate conversion code. -- The Anome (talk) 14:05, 2 June 2011 (UTC)
I've now fixed fr:Modèle:Infobox Ville de Bosnie-Herzégovine. -- The Anome (talk) 14:17, 2 June 2011 (UTC)

Businesses with multiple locations, or how to prevent re-tagging

The current guidelines says: "Do not add coordinates to the tops or infoboxes of the follow types of articles: [...] Businesses with multiple locations (although listing coords for individual locations in a table may be appropriate)"

I'm not quite sure what that really means. I started going through a category of articles missing geocoordinate data recently and have already come across several articles of which I'm just not sure really need coordinates. For example, Malmö University College has more than 7 locations for education, research and administration. Would I add coordinates to only the main office, to each location in a table, or would I simply remove the {{coord missing}} template? If I remove the template, how can I make sure bots won't re-tag it in the future? I've already tried to find the answer in a whole lot of articles but all I find is the guideline I started out with. -- Nillli (talk, contribs) 16:43, 1 June 2011 (UTC)

A properly-designed tagging bot will not tag the same article twice. For Malmö University College, I would code the main office as a first step; the rest could be added later if someone wishes to do so. I'd discourage you from removing the {{Coord missing}} without a good rationale for doing so. —Stepheng3 (talk) 17:04, 1 June 2011 (UTC)
Indeed, AnomeBot is a well-designed bot which won't retag the article. AFAIK, it is the only bot tagging for coordinates.
@Nillli: Several articles have lists of coordinates and different approaches for dealing with them. For a strict list, see List of Mount Hood glaciers; for more subtle incidental lists, see Vista Ridge Tunnels and Pacific DC Intertie. The entire list of articles with multiple coordinates are in Category:Geographic coordinate lists. —EncMstr (talk) 17:52, 1 June 2011 (UTC)
Thank you, both of you. I now have more articles to read about how to properly help out with this project, but once I'm done I'll consider rearranging (or simply adding) information on the project page to better describe what to do with multiple locations. I promise I won't cry if someone else does it first though ;)Nillli (talk, contribs) 13:50, 2 June 2011 (UTC)

Observatories without geographical coordinates

I've put together a list of articles about astronomical observatories which so far don't have geographical coordinates, at User:The Anome/Observatories without coordinates. Is anyone interested in geocoding these? -- The Anome (talk) 13:40, 8 June 2011 (UTC)

Concentration camp coordinates

There are still quite a number of concentration camp articles needing geocoding: see User:The Anome/Concentration camps needing coordinates for the list. Many of these are quite a challenge to track down, yet historically important. Does anyone want to have a go at this list? Thanks in advance, -- The Anome (talk) 21:06, 20 June 2011 (UTC)

multiple copies of coordinates on a page?

I have been having a small disagreement with MrBill47 over whether it is appropriate to add coordinates to an article that already has them. MrBill47 has been adding an extra set of {{coord}} templates to articles, usually in the "Geography" section, e.g. [17].

MrBill47's point is that it is convenient to have the coordinates listed in a decimal format for people who need to enter them into software that only accepts them in that format. I think this unwise and is likely to lead to confusion, if one set of coordinates in the article disagrees from the other, and that there are software tools available to convert coordinates from one format to another if that's an issue.

Does this WikiProject have any guidance on this issue one way or the other? My reading of WP:COORD is that coordinates should be added to an article only once, but it is not really explicit about recommending that. Feedback is welcome. Thanks. —Tim Pierce (talk) 17:45, 8 June 2011 (UTC)

Wikipedia:USCITY#Geography says "In the past, standard practice was to include several coordinate instances: one in the infobox, one in Geography (often repeated in several notations), and once in the external links section using a Geolink or Mapit template. Such replication is confusing, uselessly redundant, and creates maintenance complexity." and "If a coordinate (latitude and longitude) is included in the infobox, remove any existing article coordinate from this section." —Stepheng3 (talk) 18:04, 8 June 2011 (UTC)
If an article has displayed coordinates (whether upper right, in an infobox or inline), try dragging a mouse over them to highlight followed by "copying" and "pasting" to somewhere else. This shows that the coordinates are in both decimal and DMS format - it's simply that in the displayed page one is hidden by means of a CSS class. The relevant classes are given by <span class="geo-dms">...</span> and <span class="geo-dec">...</span>. --Redrose64 (talk) 18:50, 8 June 2011 (UTC)
Click on any coordinates link (not the globe icon—that makes a map appear—but on the actual bluelinked numbers): the top of the resulting GeoHack page displays the coordinates in multiple formats, decimal, DMS, and UTM. Therefore, there is no excuse for formatting multiple ways within an article. —EncMstr (talk) 19:01, 8 June 2011 (UTC)
I'd like to point out the format parameter of {{coord}} and the coordinates_format parameter of {{infobox settlement}}. If MrBill47 thinks that the article needs decimal coordinates, then he can change it in the infobox and use coordinates_format=dms to leave the displayed text unchanged. Having multiple coordinates per page is quite poor practice, I think. Also: do be careful to not use excess precision in the decimal coordinates. —hike395 (talk) 03:21, 9 June 2011 (UTC)
The "quite poor practice" described by Hike395 is used throughout Wikipedia. The majority of city entries already have the coordinates listed in the Geography section. I am simply trying to conform to that practice and provide useful information for users of genealogy software. I understand the precision issue, but those same entries I mentioned above have the coordinates calculated to 6 decimal places. MrBill47 (talk) 14:16, 9 June 2011 (UTC)
Bill, I think this is a case of WP:OTHERSTUFFEXISTS -- the fact that other articles follow the practice you describe doesn't actually mean it's the preferred behavior. It just means we have a lot more cleanup to do. :-) —Tim Pierce (talk) 15:01, 9 June 2011 (UTC)
And it is not used "throughout wikipedia" It is used on something less than about 37,000 US articles that were created in circa 2003/2004 by a bot called Rambot, which culled information from somewhere or other. A very poor decision was taken at the time to include multiple coords in each of the articles. The settled standard for coords in articles is to have them in the infobox, if such exists, and at the top right of the page. --Tagishsimon (talk) 16:33, 9 June 2011 (UTC)
I've used the method suggested by EncMstr and that has the information I need. Thanks EncMstr!! MrBill47 (talk) 14:38, 9 June 2011 (UTC)

I'm convinced now. Thanks —Tim Pierce and others for enlightening me. I'm new here, so I am still learning. What I'm doing now is removing the redundant information when I encounter it. Entry by entry, it will be cleaned up. — Preceding unsigned comment added by MrBill47 (talkcontribs) 14:01, 10 June 2011 (UTC)

Your cooperation is appreciated, MrBill47! —Stepheng3 (talk) 16:33, 10 June 2011 (UTC)
I have been having a conversation with MrBill47 SEE HERE starting June 28 regarding removal of redundant coordinates. I am here to ask those editors with more knowledge of this subject their opinion/policy on this matter. I had been removing the redundancy with this style for several months. BASIC EDIT I feel the decimal coordinates are important information for a cities article, even if the custom in Wikipedia is to show the coordinates in the degree/minute/second form only in the title and infobox. The <br> was to keep the minus sign with the longitude number. It was the only solution I found after trying various code formats (help me if there is a better way). I would leave out the break (<br>) if the Geography section was lower on the page where this was not a problem.
I recently changed the way I was addressing this redundancy with an IMPROVED EDIT. However yesterday I see that Stepheng3 (who has helped me in the past) did a EDIT CHANGE TO an IMPROVED EDIT. So am I doing it correctly? In regards to Stepheng3's edit I thought the use of the {{Infobox settlement}} parameter |coordinates_format= dms produced the desired effect of showing the coordinates in degree/minute/second form in the title and infobox while actually using the decimal format not needing the N/S or E/W parameters (I had nothing to do with the duplicate display=). Am I mistaken about having an advantage of using the decimal form for outside programs? In an ideal Wikipedia article how should articles that have the {{Infobox settlement}} coordinates be formated? Should I keep the decimal coordinate information (not the template) in the Geography section.
Thanks, I will watch here for answers —RifeIdeas Talk 18:39, 1 July 2011 (UTC)
The short answer is that {{Infobox settlement}} supports entering geocoordinates in decimal format, and you are still welcome to enter them in that format. My edit to Cedar Falls, Iowa corrected a problem introduced by this edit, namely a minus sign in the longd= parameter of the infobox. {{Infobox settlement}} passes this parameter to the {{Coord}} template, which does not handle minus signs (−) for latitude and longitude very well because it expects a hyphen (-) instead. (Since most computer keyboards have a key for hyphens but lack one for minus signs, this is rarely a problem.) The resulting coordinates displayed fine in the article, but they broke GeoHack and likely other geocoordinate tools as well. I apologize if my workaround misled you in any way. —Stepheng3 (talk) 17:34, 5 July 2011 (UTC)
No need for an apology as your explanation made perfect sense. I went back and checked and found I had made 8 of what I called the IMPROVED EDIT s. Cedar Falls , Iowa was the only one where the minus sign instead of the hyphen was used. In my defense I was just employing copy and paste for the decimal information from the Geography section and not paying attention to the differences. With your explanation I will be more vigilante in the future and make sure it is a hyphen. Or do you think I should employ your work around and keep the parameters |latNS = N and |longEW= W ? Also is changing the infobox coordinates to decimal form helpful to outside programs or am I just making work for myself?
On to the question of what is the consensus or guideline about retaining the decimal coordinate information but not the redundant template in the Geography section? My reason is that the practice that I have seen in Wikipedia articles (at least in the USA) is to display the title and infobox coordinates in the d/m/s form. The Geography section is the place to retain this decimal information for those readers who need it and are unaware of the click on the coordinate feature to show the GeoHack information.
--RifeIdeas Talk 01:08, 6 July 2011 (UTC)
See my post of 18:50, 8 June 2011 - it doesn't matter whether the coordinates in the Wikicode are in decimal or DMS, because both are present in the final page - it's just that one is invisible to the eye, but is certainly present in machine-readable form. Manually changing coordinates from one form to the other is undesirable because of the possibility of introducing error. Removing a |long_EW=W and replacing it with a minus sign can actually break the formatting of certain maps which span longitude 180°. The golden rule is: don't edit just for the sake of it; and if you are unsure about anything, don't do it. --Redrose64 (talk) 13:05, 6 July 2011 (UTC)

UK National Grid conversion still wrong

I can't believe that after over three years since I raised this bug [18] (and even found some drop-in PHP code that could be used to fix it), the conversion from Latitude/Longitude to UK Ordnance Survey National Grid co-ordinates has still not been corrected.

To see this in action, go to eg Royal Observatory, Greenwich and click through to GeoHack. If you choose Bing Maps UK (data passed as lat/long), click map, and zoom out one notch you get an arrow bang in the middle of the old Observatory building. But if you choose Streetmap UK (data passed as OS National Grid) you get an arrow out in the middle of the park.

What is going wrong here is very simple. The UK National Grid is based on the old OSGB36 datum. So what we should be doing is:

Start with WGS84 lat/long ---> convert to OSGB36 lat/long ---> calculate Ordnance Survey co-ordinates from lat/long.

Instead, we're missing out the first conversion step. We're just doing

Start with WGS84 lat/long ---> calculate Ordnance Survey co-ordinates from lat/long.

and as a result those co-ordinates that we are calculating are not correct.

Can somebody who can edit the toolserver code please fix this? At the moment every grid reference we're giving out, and every map people pull up from Streetmap, for every location in the UK... is wrong. Jheald (talk) 16:01, 21 June 2011 (UTC)

Coordinates for people or things associated with an event

The article Blair Peach contains coordinates tagged with type:event. These coordinates identify the place of the event which makes Peach notable (his death), but of course there was more to him than this - during his life he was a movable, and not specifically locatable, entity. If the article had been entitled Death of Blair Peach, then I would not quibble with the inclusion of coordinates, but its title isn't specific to this event, even though the bulk of its content relates to it. I'm sure there are other similar examples.
Should articles about people or things which are chiefly related to an event, but which are not specifically about that event, have coordinates? Bazonka (talk) 21:14, 4 July 2011 (UTC)

Not in my opinion. -- The Anome (talk) 00:54, 5 July 2011 (UTC)
Yeah, that sounds like a confusing use of coordinates to me. I would remove it. Kaldari (talk) 01:30, 5 July 2011 (UTC)
I agree with The Anome and Kaldari. When I see title coordinates in a biographical article, I expect them to indicate the person's burial place, not the place where (s)he died. If we wish to include place-of-death coordinates in the article, they should appear in the body of the article, as inline coordinates. —Stepheng3 (talk) 17:41, 5 July 2011 (UTC)
Okay, I'll 'fess up to putting that coord in the title. I've now moved it inline. --Tagishsimon (talk) 12:45, 15 July 2011 (UTC)
I'm confident that when you put the coordinates in the title, you were acting in good faith. Thank you for relocating them. Cheers, —Stepheng3 (talk) 15:55, 15 July 2011 (UTC)

Duplicate Coords in City Articles

ok, so who is going to sit down and remove the duplicate coords in 20,0000 city articles on Wikipedia? If you have a rule to remove them, then you better have a way to do it, otherwise you should dump the rule. Having people cherry picking the deletion of this information from just their favorities cities is not a good thing. • SbmeirowTalk • 05:30, 12 July 2011 (UTC)

I've done it for about 400 cities near me. Why don't you do the 50 cities closest to you? That way, only a few hundred more editors are needed to complete the task. —EncMstr (talk) 07:45, 12 July 2011 (UTC)
I expect to continue working on this (among other things) for the foreseeable future. —Stepheng3 (talk) 00:52, 15 July 2011 (UTC)
There is a report Wikipedia:Database reports/Articles containing overlapping coordinates updated weekly which lists those pages which, in essence, contain two or more {{coord}} specifying |display=title or |display=inline,title. In many cases there will only be one actual {{coord}} visible in the wikicode - the other is disguised as |lat=|long= (or similar) parameters within an infobox. Unfortunately the report ignores any coordinates specifying |display=inline. --Redrose64 (talk) 11:51, 15 July 2011 (UTC)

Obsolete categories nominated for deletion

I've nominated Category:Indian location articles needing coordinates and its subcategories for deletion, as they are unused and obsolete: see Wikipedia:Categories for discussion/Log/2011 August 3. -- The Anome (talk) 14:02, 3 August 2011 (UTC)

Discussion: Manual of Style (road junction lists)

Discussion: Should Manual of Style (road junction lists) advise people to use {{Coord}}, if they are adding coordinates to articles about roads? Please discuss at Sub-section on coordinate templates. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 17:10, 7 August 2011 (UTC)

Wikipedia articles in Google maps not refreshing?

Hi, I just wanted to ask why the set of geotagged articles shown in google maps doesn't seem to include ones which have been tagged (not so) recently. Is this just a matter of long interval refreshing or is the selection completely stagnent? --U5K0'sTalkMake WikiLove not WikiWar 02:14, 2 August 2011 (UTC)

I guess long interval refreshing, tending towards infinity. Sadly, it is for Google or Bing or whoever else abstracts coordinates to decide for themselves the appropriate refresh rate. There is a table, somewhere, but I cannot find it right now, which lists services which take WP geo-data, and which specifies what we know about their refresh intervals. --Tagishsimon (talk) 23:35, 10 August 2011 (UTC)
Thaks. I've been obsessing about this for months now. In case you get any new info on this I'd apreciate it if you could post it on my talk page. Again, Thanks. U5K0'sTalkMake WikiLove not WikiWar 19:03, 14 August 2011 (UTC)
Your think of Template:GeoTemplate#Wikipedia articles. I'm currently the most up to date (daily, 5 hour ETLs, 70 wikis), but also the least user friendly. — Dispenser 20:03, 14 August 2011 (UTC)

Proposed deletion of template:Shc

A coordinate template, {{Shc}} has been nominated for deletion. Your input would be welcome. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 17:45, 10 August 2011 (UTC)

"Missing" coordinates for roads and railways?

Hi, there is the following issue that IMO should be discussed here rather than in the The Anomebot2 talk page: [19] and [20]. Should coordinated be required for all roads and railways? If so, how should the coords be determined? My feeling is there should be some special template or way of presenting such coordinates and not only one set of coords for one point. I am not sure if this is of any use in searching and locating. I followed the link in Bundesautobahn 2 via GoogleMaps and here is what I found: one lands on a spot of the Route (which should be precise enough to avoid looking aroud for the line) then I zoom out to get the whole picture, but at a certain scale the Route disappears so I don't really end up with any useful view of the whole road. Any ideas? Hoverfish Talk 20:17, 24 July 2011 (UTC)

This was also discussed at Wikipedia talk:WikiProject UK Railways/Archive 20#Railway line coordinates. --Redrose64 (talk) 20:48, 24 July 2011 (UTC)
Thanks for the link, Redrose64. Here is a very interesting page I discovered that should be more easy to find: Wikipedia:WikiProject Geographical coordinates/Linear. For long roads, I like a "Coordinates list" solution of M6 motorway#Junctions: No title coordinates but a list of inline important points. Hoverfish Talk 20:58, 24 July 2011 (UTC)
This ground has been covered many times. A table of coordinates is great if anyone is prepared to put one together. A title coord is useful, in combination with the Dim: parameter, in showing the extent of the road within a map window. The best should not be used to drive out the good. --Tagishsimon (talk) 09:16, 26 July 2011 (UTC)

At this point in time, there is no consensus for adding geographical coordinates to articles. Interstate 5 in California is one example of why. --Rschen7754 23:15, 10 August 2011 (UTC)

With more than 704,000 uses of {{coord}} [21], I think we can cheerfully say there is de facto acceptance of the practice of adding geographical coordinates to articles. And because wikipedia is a very broad church, there will always be those who oppose such coords enabling nay-sayers to assert that there is no consensus. Bluntly, if we have to wait until everyone is on-side before we do something, we will find ourselves unable to do anything. I don't find the Interstate 5 in California article an exemplar of either school of thought. I do find it annoying that I cannot easily locate that road on a map for lack of any clickable geo-coordinates. Why is it a good thing that I cannot click through to see the road on a map? --Tagishsimon (talk) 23:30, 10 August 2011 (UTC)
That "Interstate 5 in California is one example of why" is an assertion; please substantiate it. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:47, 11 August 2011 (UTC)
There is more than one possible place to tag I-5. Consensus has been to not tag road articles at all, since there is no specific place to tag. Some want all junctions of a highway to be tagged. I don't think that's a good idea. --Rschen7754 23:44, 11 August 2011 (UTC)
"Consensus has been to not tag road articles at all" That simply isn't true.
You have yet to substantiate your assertion that "Interstate 5 in California is one example of why". Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 18:13, 19 August 2011 (UTC)
Look at the article. What do you notice about it? --Rschen7754 20:50, 19 August 2011 (UTC)
Well, it has a table of intersections etc that is simply crying out for coordinates. Is that it? --Tagishsimon (talk) 20:53, 19 August 2011 (UTC)
Are you volunteering to tag every single exit on that road? --Rschen7754 20:57, 19 August 2011 (UTC)
You're really clutching at straws, aren't you? Your argument moves from "you can't" to "there isn't the space" to "who'll do the work". It's really pitiful. Wikipedians have added better than 700,000 coords. I don't think a poxy couple of hundred more is much of a challenge. And if it is not worth showing readers where the feature is, what is the point of putting the feature in the table in the first place. Other than IDONTLIKEIT, your argument makes no logical sense whatsoever. And now I refer you to Andy's post, below: we deserve your answer. --Tagishsimon (talk) 22:15, 19 August 2011 (UTC)
No you don't. As the roads projects have made very clear, you will get nowhere by insisting that we add 100,000 more coords to the roads articles. We're willing to work with you to get a solution, but if you're going to insist on having it all your way and tagging every junction, we are out, and we can revert and will revert every single coordinate tagging of a road article that you do. --Rschen7754 22:24, 19 August 2011 (UTC)
That's just another variant of IDONTLIKEIT, in the form of MEANDMYARMYDONTLIKEIT. Can we get beyond the yah boo sucks stage of the argument, and onto, for instance, why it is logical to list geographic features but deny readers the opportunity to visit them on a map. Or, indeed, onto substantiating your assertion, as Andy has repeatedly requested. --Tagishsimon (talk) 22:29, 19 August 2011 (UTC)
Please don't make stupid threats. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 22:52, 19 August 2011 (UTC)
I don't notice you substantiating your assertion. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 22:04, 19 August 2011 (UTC)
Pretty much every UK road on wikipedia has a {{coord}}; most often at a rough midpoint and using the Dim: parameter such that the entire length of the road is displayed when viewed on a map. I think your "consensus" is either limited in scope or a figment of your imagination. And I do not see why your antipathy to coordinates blinds you to the view taken by others that they do wish to associate wikipedia articles on geographical features with maps which show those features. It seems an obvi ous and obviously useful thing to do. --Tagishsimon (talk) 23:52, 11 August 2011 (UTC)
If you look, less than 1% of all road articles outside of the UK are tagged. --Rschen7754 23:57, 11 August 2011 (UTC)
Even supposing that is true, it is not a thing to be proud of. Explain, please, why you think it is a good idea not to provide an easy means by which users can view a geographical object on a map. --Tagishsimon (talk) 00:00, 12 August 2011 (UTC)
Because tagging "the midpoint and the two endpoints" as suggested below is quite useless for a linear feature such as a road. --Rschen7754 00:33, 12 August 2011 (UTC)
Right. Because the idea that you could use the midpoint and Dim: to enable a wikipedia user to see the whole route at a glance on a map would be anathema to an encyclopedia that's trying to provide useful information to users. To be honest, I'm with you on this one, and would go further and delete the whole article lest we pass any useful information to readers. --Tagishsimon (talk) 21:01, 19 August 2011 (UTC)

I don't see how it is beneficial to include coordinates for major intersections along a road. A road is a linear object and therefore too hard to place exact coordinates on. It is also cherry-picking to select only a few places along a road to have coordinates for. Dough4872 00:47, 12 August 2011 (UTC)

I think what the coordinate group fails to recognize is the huge different between a straight line and a linear feature. The geographical middle is rarely the physical centre. Rivers should also be brought in to this discussion, as the problem is also prominent there. The fact that bots have massively applied coordinates to every single article in no way implies that you are free to impose them on every article, nor that any consensus has been attained. After all, WP:SILENCE puts it out there plainly that silence is the weakest form of consensus. Roads are among these articles. Just because they haven't been removed from a small minority of articles does not mean that there is now magically a standard to apply them. Back to what I was going at: Linear features are not always straight. They often curve about, zig zag, u-turn, or even loop around. So tell me, what is the midpoint of one of the ring roads around Moscow? What is the start or end terminus? Clearly the only way of fairly representing these features is to be able to map out a path, rather than a coordinate. Arbitrarily assigning longitudes and latitudes does not fairly or accurately represent linear features. Not only that, but it is subjective and therefore original research. - ʄɭoʏɗiaɲ τ ¢ 00:53, 12 August 2011 (UTC)

I see no Wikipedia guideline that mandates the use of coordinates. --Rschen7754 01:11, 12 August 2011 (UTC)

There is the essence of Wikipedia which breaks down as some incidental policies like WP:RS, WP:V, and WP:NOR. WP:V says The threshold for inclusion in Wikipedia is verifiability, not truth—whether readers can check that material in Wikipedia has already been published by a reliable source, not whether editors think it is true. It doesn't give any weight to whether it "clutters" an article. —EncMstr (talk) 01:58, 12 August 2011 (UTC)
But the argument that you make seems to go against our notability guideline on Wikipedia. --Rschen7754 02:02, 12 August 2011 (UTC)
@EncMstr, simply because some datum can be verified does not mean it therefore must be included in an article. Verifiability is the minimum threshhold for inclusion -- other policies and guidelines as well as editorial discretion all play a part in determining what is or is not appropriate for inclusion in any particular article (or set of articles). olderwiser 02:12, 12 August 2011 (UTC)
Obviously there is a lot more than a threshold for inclusion to writing a useful article. Naturally, data should relate to the article and should lend itself to helping understand the topic. The lead of every road article is morally, if not literally, obligated to include a geographic description of where the road is or, more usefully, what it connects. Whether such places are described by "four houses south of John's Bar and Grill" or a link to a map is more a matter of style. Oh, except that most people won't know where John's place is, so the map has much greater usefulness and utility. —EncMstr (talk) 03:13, 12 August 2011 (UTC)
The ability to open up a map service to see the object is what is important, as then you can zoom in and out and see where it is. The latitude and longitude of these points is clutter. - ʄɭoʏɗiaɲ τ ¢ 10:54, 12 August 2011 (UTC)
For point locations (or places such as cities where a single point can approximate the central position), then sure coordinates may be helpful -- though as Floydian suggests, for most users, the actual coordinate values are less meaningful than access to a map. For more complex geographical features, displaying an large array of coordinate values might be clutter. It might be more useful to learn or recruit editors with map-making skills to produce free maps representing such geographical features. olderwiser 16:51, 12 August 2011 (UTC)

My personal opinion

There is a utility to intelligently adding coordinates data to articles. A road's junction list is the best place to store said data because it has already boiled a linear feature down to a series of points. The problem is that the table already has enough information being physically displayed in legible form. The actual coordinates themselves (the raw numbers) are not the useful data; the link to display that point is the useful data. The fact remains that the numbers themselves have very little meaning to the majority of the readership and create another blue link in the text or table. Any attempts to modify {{coord}} to suppress the display of the numbers yet still link to a map were rebuffed, so {{shc}} was created. Should that template be merged into {{coord}}, then this discussion is no longer one of display but of frequency in the table. (Every junction in a table is overkill on longer highways, and frankly unnecessary work.)

If the template's streamlined display functionality is not retained in some fashion, we'll need a plan B. I have a concept at User:Imzadi1979/Coords. Yes, it would create a {{coordRJL}} that would act as a wrapper for {{coord}}. The new template would pass the coordinate data to coord, and wrap it in a standardized footnote coding and specify the default viewing parameters for coord. Then the templates ({{jctbtm}} and {{legendRJL}}) would be modified to display the coordinates list along with {{GeoGroupTemplate}} in a collapsed row of the already-required footer of the table. The end result is that the table still gets tagged, but the table isn't cluttered with additional blue links, unless the reader expands the list at the bottom.

As to the frequency, tagging every junction on many highways would be overkill, especially longer freeways that already list every interchange (grade-separated junction). For the US, I'd recommend that the 5–10 most major intersections, plus termini, already listed in the infobox for a highway are the ones that get geotagged. For highways that are longer, at least one per county or so. For highways under a mile (or 1.6–2 km), then a single coordinate value for the midpoint of the roadway using {{coord}} displayed in the title position. Outside of the US, I'd have the other highway projects (WP:CRWP, WP:UKRD) or the regional task forces of WP:HWY develop frequency recommendations, but I'd encourage them to avoid overkill. Imzadi 1979  22:56, 19 August 2011 (UTC)

BTW, current consensus on some of the various roads projects has been to remove coordinate data when encountered to minimize the visual clutter. Until that clutter issue is resolved, I don't see people's opinions changing and coordinates being left alone or added. Imzadi 1979  22:59, 19 August 2011 (UTC)
The thing is, you have to buy into the visual clutter argument to accept any of this. I don't buy it, not least for the (by number of columns) puny table in Interstate 5 in California - currently 6 columns. A small'd {{coord}} takes up the same space as 18 regular characters. This is not bank breaking. I really don't know where this idea comes from that adding one more column to a six column table suddenly takes us into future shock territory. Clearly you're entitled to your view, but let us at least look at a couple of gash mock-ups [see #Tagishsimon's Examples] (and apologies, I don't know how to rowspan, offhand). Bottom line - you're trying to solve a problem which does not exist. (I'll pass on discussions of which features should be listed and how many rows are desirable ... I'm concerned solely with the logic that if a place is worth mentioning, it is worth providing a maplink; and that the current {{coord}} implementation is not a destroyer of tables. (Finally, check out West_Virginia_Public_Broadcasting#Stations which has a ten column table. Amazingly, for me, again, coords add no visual clutter.) --Tagishsimon (talk) 00:14, 20 August 2011 (UTC)

Tagishsimon's Examples

Without coords

County Location Postmile Exit Destination Notes
San Diego San Diego R0.31 1A Camino de la Plaza No northbound exit; last USA exit southbound
San Diego San Diego R0.88 1A I-805 north (Jacob Dekema Freeway) Northbound exit and southbound entrance
San Diego San Diego R1.20 1B Via de San Ysidro No southbound entrance
San Diego San Diego 2.31 2 Dairy Mart Road


As Decimal

County Location Postmile Exit Destination Notes Coordinates
San Diego San Diego R0.31 1A Camino de la Plaza No northbound exit; last USA exit southbound 39°51′29″N 78°50′31″W / 39.858°N 78.842°W / 39.858; -78.842 (W07DN-D)
San Diego San Diego R0.88 1A I-805 north (Jacob Dekema Freeway) Northbound exit and southbound entrance 39°57′50″N 78°44′31″W / 39.964°N 78.742°W / 39.964; -78.742 (W08EE-D)
San Diego San Diego R1.20 1B Via de San Ysidro No southbound entrance 38°59′13″N 78°45′50″W / 38.987°N 78.764°W / 38.987; -78.764 (W09CT-D)
San Diego San Diego 2.31 2 Dairy Mart Road 39°07′23″N 78°45′54″W / 39.123°N 78.765°W / 39.123; -78.765 (W23DR-D)


As DMS

County Location Postmile Exit Destination Notes Coordinates
San Diego San Diego R0.31 1A Camino de la Plaza No northbound exit; last USA exit southbound 39°8′38″N 78°26′9″W / 39.14389°N 78.43583°W / 39.14389; -78.43583 (W07DN-D)
San Diego San Diego R0.88 1A I-805 north (Jacob Dekema Freeway) Northbound exit and southbound entrance 39°27′36″N 78°3′45″W / 39.46000°N 78.06250°W / 39.46000; -78.06250 (W08EE-D)
San Diego San Diego R1.20 1B Via de San Ysidro No southbound entrance 38°49′15″N 78°53′56″W / 38.82083°N 78.89889°W / 38.82083; -78.89889 (W09CT-D)
San Diego San Diego 2.31 2 Dairy Mart Road 39°18′34.5″N 78°43′1″W / 39.309583°N 78.71694°W / 39.309583; -78.71694 (W23DR-D)

Discussion

Nice try, but wrapping things in <small></small> without saying so skews the validly of the sample. Imzadi 1979  00:25, 20 August 2011 (UTC)
That's cobblers. Sheer, utter, unadulterated cobblers. Nonsense on fscking stilts. Exactly what is the problem with smalling coords? Do you think it is somehow cheating to propose minimal solutions like this. And, btw, did you read the bit where I said "A small'd {{coord}} takes up the same space as 18 regular characters." --Tagishsimon (talk) 00:28, 20 August 2011 (UTC)
And if you want to screw with the tables to make them bigger to prove that big tables are a problem, make your own tables. Don't mess with my examples. That's just plain dishonest. I mean, really, what are you trying to prove? That if you bugger up a reasonable table implementation, you end up with buggered up tables? Great work, Imzadi. --Tagishsimon (talk) 00:33, 20 August 2011 (UTC)
Here's how the tables would actually look [see #Imzadi1979's Examples]. Imzadi 1979  00:49, 20 August 2011 (UTC)
This is nonsense. The tables will only look like this if you choose to make them look like this. There's no god-given writ that says coords cannot be small. And whilst I still cannot see the visual clutter, if the only way you can win the argument is to choose to make the ugliest table possible, forsaking all other options, then we might as well end the discussion here. It's just not rational. --Tagishsimon (talk) 00:52, 20 August 2011 (UTC)

Imzadi1979's Examples

Without coords

Note: Except where prefixed with a letter, postmiles were measured on the road as it was in 1964, and do not necessarily reflect current mileage. The numbers reset at county lines; the start and end postmiles in each county are given in the county column.

County Location Postmile
[1][2][3]
Exit[4] Destination Notes
San Diego San Diego R0.31 1A Camino de la Plaza No northbound exit; last USA exit southbound
R0.88 1A
I-805 north (Jacob Dekema Freeway)
Northbound exit and southbound entrance
R1.20 1B Via de San Ysidro No southbound entrance
2.31 2 Dairy Mart Road
As Decimal

Note: Except where prefixed with a letter, postmiles were measured on the road as it was in 1964, and do not necessarily reflect current mileage. The numbers reset at county lines; the start and end postmiles in each county are given in the county column.

County Location Postmile
[1][2][5]
Exit[6] Destination Notes Coordinates
San Diego San Diego R0.31 1A Camino de la Plaza No northbound exit; last USA exit southbound 39°51′29″N 78°50′31″W / 39.858°N 78.842°W / 39.858; -78.842
R0.88 1A
I-805 north (Jacob Dekema Freeway)
Northbound exit and southbound entrance 39°57′50″N 78°44′31″W / 39.964°N 78.742°W / 39.964; -78.742
R1.20 1B Via de San Ysidro No southbound entrance 38°59′13″N 78°45′50″W / 38.987°N 78.764°W / 38.987; -78.764
2.31 2 Dairy Mart Road 39°07′23″N 78°45′54″W / 39.123°N 78.765°W / 39.123; -78.765


As DMS

Note: Except where prefixed with a letter, postmiles were measured on the road as it was in 1964, and do not necessarily reflect current mileage. The numbers reset at county lines; the start and end postmiles in each county are given in the county column.

County Location Postmile
[1][2][7]
Exit[8] Destination Notes Coordinates
San Diego San Diego R0.31 1A Camino de la Plaza No northbound exit; last USA exit southbound 39°8′38″N 78°26′9″W / 39.14389°N 78.43583°W / 39.14389; -78.43583
R0.88 1A
I-805 north (Jacob Dekema Freeway)
Northbound exit and southbound entrance 39°27′36″N 78°3′45″W / 39.46000°N 78.06250°W / 39.46000; -78.06250
R1.20 1B Via de San Ysidro No southbound entrance 38°49′15″N 78°53′56″W / 38.82083°N 78.89889°W / 38.82083; -78.89889
2.31 2 Dairy Mart Road 39°18′34.5″N 78°43′1.3″W / 39.309583°N 78.717028°W / 39.309583; -78.717028
Now, a few points. The samples here use the standard "wikitable" class used by most tables around this website. Tagishsimon left out some details. Of course, I don't know what resolution or size his browser window is, but mine approximates the display width of a standard sheet of paper, not the full width my display could show. We have to design tables that look good on a variety of display sizes and resolutions, and switching to a CSS class that makes everything smaller isn't the answer. Imzadi 1979  00:59, 20 August 2011 (UTC)
So, let's sum up. "wikitable" class is not mandated in Wikipedia:Manual of Style/Tables. Prohibition of small coords is not mandated anywhere. You have elected to design suboptimal tables, and despite this, your tables do not suffer from the alleged "visual clutter". Where do we go from here? --Tagishsimon (talk) 02:23, 20 August 2011 (UTC)
MOS:RJL, which is a part of the Manual of Style and governs their formatting, uses that class. They have not been determined to be "suboptimal" for all of the highway articles that comply with MOS:RJL that have been reviewed at FAC and other forums. No where is there even a requirement to tag the articles, or if tagged, for the coordinates to be displayed. {{Shc}} below, or some functional equivalent display, would tag the junctions, it wouldn't clutter the article with the numbers (remember that the actual numbers aren't the useful component, but rather the access to the map), and both sides would be happy. Imzadi 1979  02:35, 20 August 2011 (UTC)
My true preference

Note: Except where prefixed with a letter, postmiles were measured on the road as it was in 1964, and do not necessarily reflect current mileage. The numbers reset at county lines; the start and end postmiles in each county are given in the county column.

County Location Postmile
[1][2][9]
Exit[10] Destination Notes
San Diego San Diego R0.31 1A Camino de la Plaza No northbound exit; last USA exit southbound
R0.88 1A
I-805 north (Jacob Dekema Freeway)
Northbound exit and southbound entrance
R1.20 1B Via de San Ysidro No southbound entrance
2.31 2 Dairy Mart Road

Further discussion

So I'll take that as your agreement that the MoS does not mandate "wikitable" class, not mandate against small coords. Thanks. --Tagishsimon (talk) 02:46, 20 August 2011 (UTC)

I didn't say that, so don't put words into my mouth. MOS:RJL is the applicable section of the MOS for these types of tables, and all of the examples therein use that class. Imzadi 1979  02:49, 20 August 2011 (UTC)
Can you or can you not point me to a mandate for either of the issues? Not an en passant example. A mandate. --Tagishsimon (talk) 02:54, 20 August 2011 (UTC)
Yes. The example uses it, so we should use it everywhere. This is an implicit mandate. Sorry, but we couldn't foresee every single time some outsider is going to find some loophole where something isn't explicitly spelled out in the guideline when we wrote the guideline. But if you want an explicit mandate, I'm sure we could get consensus and modify the guideline to have that in there. --Rschen7754 03:50, 20 August 2011 (UTC)
Please explain in what way Tagishsimon is an "outsider". Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 12:15, 20 August 2011 (UTC)
Doesn't have to be an "outsider" per se; could be anyone, really. --Rschen7754 03:04, 21 August 2011 (UTC)
So it was really just a careless ad hominem attack. Very classy. --Tagishsimon (talk) 03:06, 21 August 2011 (UTC)
No explanation, then? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 22:27, 22 August 2011 (UTC)
MOS:RJL has examples of the use of coordinates; thank you for confirming that's a mandate to include coordinates in road articles. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:46, 20 August 2011 (UTC)

All the visible coordinates look fine to me; discussion over minor formatting is bikeshedding and should be resolved once the in-principle matter has been decided. The table with hidden coordinates is less useful, less obvious to novice readers, and has accessibility issues. Where else do we use the same icon to link to multiple targets with no disambiguating text? Note also that coordinate dsplay is a user-configurable option, including the option to hide them completely. Those arguing WP:DONTLIKEIT should adjust their settings accordingly, rather then trying to impose their merely aesthetic preferences on others.. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:44, 20 August 2011 (UTC)

But you're imposing your aesthetic preferences on us by doing so. --Rschen7754 03:09, 21 August 2011 (UTC)
No; I'm not. I'm advocating that we publish data, not pushing an aesthetic presentational PoV. I note that you ignore my point about user settings. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 09:19, 21 August 2011 (UTC)
The "data" is visible on the next screen, so that point is moot; you are arguing your aesthetic preference. If someone can't make that extra click, they probably can't enter DMS coordinates into a GPS (since that is how people find their way around, right?). Trying to game the system isn't going to help here, road editors do not support the tagging of road articles with a single point in the title and do not support the inclusion of the cluttering latitude and longitude on exit tables. If no workaround is found, than modifying WP:RJL to add coordinate support is fruitless and will inevitably be overturned. - ʄɭoʏɗiaɲ τ ¢ 16:35, 22 August 2011 (UTC)
The data (no need for scare quotes) is not visible on the page, so the point is not moot. I repeat, I am concerned with the visibility of data, not aesthetics. If you wish to insinuate that I am attempting to "game the system", please do so on ANI, with evidence. When were you appointed to speak for all "road editors", and how are they identified? WP:RJL, as you've already had pointed out to you recently, already allows for the use of coordinates on articles about roads. I note that you, too, ignore my point about user settings. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 22:27, 22 August 2011 (UTC)