Wikipedia talk:WikiProject Geographical coordinates/Archive 12

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

A quick survey of tagging progress

I just did a very quick survey, by clicking on "random page" a few times -- of the 86 pages I looked at, before getting down to the bottom of the page in my notebook:

  • 71 were not candidates for geolocation
  • 7 were candidates for geolocation, properly categorized, but not geotagged
  • 8 were both categorized and correctly tagged with their geolocation

Applying the ratios above to the roughly 1.7m article pages gives an estimate of about 150,000 for the number of tagged pages, which is reasonably close to the figures in the last Kolossus dump, and also suggests (on a rather small sample, with wide error bars) that roughly half of the articles needing tagging so far have been tagged. -- The Anome 23:50, 4 April 2007 (UTC)

Duplication of title coordinates

It looks as though articles that use {{Geolinks-US-cityscale}} and {{coor title dms}} now produce incompatible overlapping of the title coordinates. I'm not sure how long this has been happening, as I rarely even notice the title coordinates. But I did notice when someone started removing the geolinks templates from articles because of the incompatible duplication. For example, see Port Austin, Michigan. Seems that the geolinks uses decimal coordinates while coor title dms does not. I seem to recall that the geolinks templates did not previously add the coordinates into the title--though I could be mistaken--like I say, I rarely even notice the title coordinates. Personally, while I have no objection to the title coordinates, I find the geolinks presentation much more user-friendly. olderwiser 12:28, 7 April 2007 (UTC)

Please see {{coord}}, which is intended to replace all of the coor template-family. geolinks templates should incorporate coord and this has been raised with the editor who is, I believe, responsible for geolinks. Andy Mabbett 16:17, 7 April 2007 (UTC)

Care should be take to avoid adding {{Geolinks-US-cityscale}} and {{coor title dms}} on the same page. As they are two separate templates, it should be fairly easy to spot collisions. -- User:Docu

Problems with Coord template

The Coord template doesn't appear to work on Great Barr, despite Great Barr being the sample article on Geo (microformat). Does it matter or will the Coord be discontinued? Seems a bit odd that people go around announcing that all articles should be like that. -- User:Docu

What do you mean "doesn't appear to work" ? It's working as expected, from here. No, {{coord}} will not be "discontinued". You appear to have something against it - perhaps you can reassure us that that's not the case? Andy Mabbett 16:22, 9 April 2007 (UTC)
Just wondering, where are the coordinates on Great Barr supposed to be displayed? -- User:Docu
Exactly where they are displayed; coord is being used, there, with the default, in-line setting. But if you don't know that - which is clearly explained in the template's documentation - how were you in a position to criticise? Now that's cleated up, perhaps you'll kindly reverse your recent reversion of the note about it, on the main coordinates meta-template? Andy Mabbett 16:49, 9 April 2007 (UTC)
Hm, not sure if there is much support for your idea.
Once the solution is working, maybe we want to discuss it. In the meantime, please stop changing articles from working templates to this type of mess. -- User:Docu
There is, apart form your bizarre, unsubstantiated and unfounded claims - nothing but support for the idea. It is already working. There is no "mess". I note that you have ignored the points in my previous post, and haven't been able to give the assurance I requested. I repeat: kindly reverse your recent reversion of the note about it, on the main coordinates meta-template. All you are succeeding in doing is stopping interested parties from finding out what's being planned.Andy Mabbett 19:07, 9 April 2007 (UTC)
Two comments: 1) This is a new template and works somewhat differently than other templates, so comments that amount to RTFM are not helpful (nor especially persuasive for engendering support for using the template). 2) The "problem" with Great Barr as it is now, is that the coordinates are in a decidedly unusually location. If that is suppose to be an exemplar of the new template's use, then I quite agree that it is a very poor example. The coordinates are simply hanging at the bottom of the page -- is this recommended by any style guide at present? If you want to use it in-line, the put it into a sentence or a bullet point, not dangling at the end of article. Otherwise, the standard placement for bare coordinates is in the title area. olderwiser 17:13, 9 April 2007 (UTC)
I think it is entirely reasonable to expect someone to "RTFM", as you put it, before they announce that something isn't working; especially when it is. The coordinates in Great Barr are exactly where they were put. If you want to see other examples (of which there are already thousands in Wikipedia), then I you do indeed (to again use your own phrase need to "RTFM", since they're right there in the template's documentation. Andy Mabbett 19:07, 9 April 2007 (UTC)
Gee, thanks for more of your counterproductive rhetoric. While it may be completely unfair to the template (and anyone else who participated in developing it), your responses leave me inclined to ignore the template entirely and continue to use all the old familiar templates. olderwiser 19:46, 9 April 2007 (UTC)
I'm glad at least Paradisal read the manual and fixed Pigsonthewig's change on Great Barr. Compared to the initial version by the Anomebot, the number of templates called by the coordinates appears to have increased from 3 to 9:
  1. Template:Coord (protected)
  2. Template:Coord/input/d
  3. Template:Coor/prec dec
  4. Template:Coor dec2dms1
  5. Template:Coor dms2dec
  6. Template:Precision1
  7. Template:Coor link
  8. Template:Coor URL (protected)
  9. Template:Coord/display/title
Are they a problem? -- User:Docu
Sometimes people seem to choose to write long comments of a problem they could fix themselves in less than a minute, so someone had to go around and fix the conversion in that article. I can't comment on the server load of the template, but still don't really agree on introducing an incomplete template or doing the job only partially when converting other templates to it. The disappearance of the parameter variable mentioned above (halfway down) for example doesn't seem to have been fixed yet, and with the Great Barr article Pigsonthewig "fixed" the problem by simply removing the grid information that was in the parameters. When rtfming it myself, I was of two minds whether to revert the conversion altogether or allow it being done partially. --Para 22:44, 10 April 2007 (UTC)

{outdent}

Firstly it would seem far more sensible for any concerns you may still have to be raised on the template's talk page, where the author of the template is more likely to see them. If you look there, you'll also see that the parameter issue is resolved (or, if you think not, you'll need to be more specific about what you think is still missing). The change I made to Great Barr was done deliberately, as I needed an article using that configuration for testing, so chose a relatively low-key page.Andy Mabbett 07:55, 11 April 2007 (UTC)

I expected to see the followup here since the issue was raised here. But I have to admit that I didn't look past the first examples for info on parameters being supported or not, so I now added one there too. I advise you not to use live articles, even if low key, as a testbed for new templates, but instead have a sandbox of your own for that. --Para 22:06, 11 April 2007 (UTC)

Standardisation of co-ordinates in infoboxes

Has anyone seen/done any work on this? Are there any guidelines regarding the preferred formats for coordinates within infobox data entry? I have seen a number of different formats in use:

The latter is picked up by Google Earth, but it seems the former 2 are not. Both transclude the {{coor}} template, which Google doesn't see.

Anyone any ideas? Ta Frelke 20:45, 9 April 2007 (UTC)

A quick look at the source shows that {{Infobox UK place}} uses {{coor title d}}
Please be aware that the coor family are soon to be replaced by {{coord}}, which has all of their combined functionality, and adds user choice of display an the Geo microformat. Andy Mabbett 21:59, 9 April 2007 (UTC)


Initially it wasn't possible to use {{coor at dm}} as an argument for coordinates in the article, e.g. on Venice, Italy one couldn't use coordinates = {{coor dm|45|26|N|12|19|E}} for {{Infobox CityIT}}.
Back then, the way coordinates are displayed had to be defined in the infobox template. Thus the template was called with several variables, e.g. on Omagh there are: north coord = 54.36 | west coord = 7.19 for {{Infobox Place Ireland}}.
IMHO, in general, it's generally preferable to use to {{coor at dm}} in the article, rather than the infobox template.
However, there is one case where you want to use the variables of the coordinates to display a dot on a locator map in the infobox, in addition to the coordinates themselves: e.g. as Template:Infobox German Location does with "lat_deg = 49 |lat_min = 18 |lon_deg = 10 |lon_min = 35" on Ansbach. This avoids adding the same coordinates several times to the article.
Ideally, if a template needs variables such as lat_deg, lat_min, lon_deg, lon_min, they are always named the same. BTW in the sample, they are always "N"/"E".
The use or non-use of {{coord}} doesn't really change anything to this. -- User:Docu

::When you say that "it's generally preferable to ..." are you discussing your own preferences, or a MOS-issue, or some geo-guideline that I am unaware of? This is something that needs to be written down somewhere. It shouldn't be based on an individual's opinion. Frelke 06:56, 10 April 2007 (UTC)

Standardisation of co-ordinates in infoboxes (2)

Has anyone seen/done any work on this? Are there any guidelines regarding the preferred formats for coordinates within infobox data entry? I have seen a number of different formats in use:

  • {{Infobox UK place}} uses plain Latitude and Longitude parameters
  • {{Infobox Place Ireland}} uses north coord and west coord
  • {{Infobox CityIT}} uses a {{coor}} simple template

The latter is picked up by Google Earth, but it seems the former 2 are not. Both transclude the {{coor}} template, which Google doesn't see.

Please can we keep this discussion relevant to the point in question and not include comments about the use of the brand spanking new {{coord}} template Frelke 08:21, 10 April 2007 (UTC)

A quick look at the source shows that {{Infobox UK place}} uses {{coor title d}}
Please be aware that the coor family are soon to be replaced by {{coord}}, which has all of their combined functionality, and adds user choice of display an the Geo microformat. Andy Mabbett 08:32, 10 April 2007 (UTC)
Due to continued trolling I am discontinuing involvement on this page. Frelke 08:53, 10 April 2007 (UTC)

Globe parameter

does the parameter globe work? I try:

{{Coor d|57.3|S|175.2S|E|globe:Moon}}

{{Coor d|57.3|S|175.2S|E|globe:Moon}} but it's still on earth. --WISo 09:04, 14 April 2007 (UTC)

Tinsley Viaduct

I recently added some coordinates to Tinsley Viaduct. My work was reverted and there's been some, er, interesting discussion which folks here might want to read. Andy Mabbett 13:03, 15 April 2007 (UTC)

Bit more heat than light in that discussion, I think, not to mention violations of WP:KETTLE. I called (above) for a project consensus on which articles needed coordinates and which didn't. Clearly there's a related question of whether articles need more than one set, and if so, how many, and a perhaps more fundamental question of how coordinates are to be presented. I really, really, do not think I should be the one who suggests what the consensus should be - that should done by someone committed to the project, and I'd prefer to stay outside the project making constructive criticism. FWIW, I'm sure there are articles that unquestionably need to have more than one set, and some already do (e.g. Channel Tunnel). But care should be taken to keep the article space taken up by the coordinates in proportion to their importance. A list of coordinates the full width of the page is likely to be overkill in most cases. Just asking, but in the case where more than one set are needed, could they be presented by, say, mouse rollover tooltips on a map rather than bald textual statements in the main body? Philip Trueman 13:59, 15 April 2007 (UTC)
"where more than one set are needed, could they be presented by, say, mouse rollover tooltips on a map" - that fails to meet basic accessibility criteria. How does a mouse rollover work for someone using a keyboard, or a touch-screen PDA? Andy Mabbett 14:26, 15 April 2007 (UTC)

A poll is now being conducted. Andy Mabbett 20:44, 15 April 2007 (UTC)

Coordinates for linear structures

Further to the above, I'd suggest that, for any linear structure (viaduct, canal, river, railway, wall (e.g. Hadrain's), motorway, etc.) then there are several significant coordinates - each end, the mid-point (for shorter structures, to give a location for the article as a whole: good for Tinsley Viaduct, not good for the M1), and any notable features, crossings or junctions. What constitutes "notable" will depend on the scale. Andy Mabbett 14:51, 15 April 2007 (UTC)

On a motorway, you'd do it in the list of junctions. --NE2 15:22, 15 April 2007 (UTC)
Yes, I've been looking at the tables on a few motorway pages, recently, to see if I could find a way to integrate coordinates without spoiling the presentation. I'd like to include the hCard microformat at the same time (see Crossings of the River Severn for examples). Any ideas? Andy Mabbett 15:28, 15 April 2007 (UTC)
I'd strongly support any way of getting linear coordinate info into articles. For the purpose of creating a layer on a map this information would be invaluable. A mere list of junctions (in the M1 example) on the other hand would merely clutter the map. --Dschwen 17:05, 15 April 2007 (UTC)
I'm not sure I follow you - why would it "clutter up the map"? Andy Mabbett 17:30, 15 April 2007 (UTC)
A slew of map markers of junctions would not be a ideal way of showing the Motorway on a map. They wouldn't standout from other markers and they would all point to the same article. It would be like having a connect the dots. With linear coordinate data I could draw a line on the map much more adequately visualizing the Motorway. --Dschwen 17:56, 15 April 2007 (UTC)
If you're concerned about having multiple markers for one article, than you should only include those {{coord}} with the attribute "display=title" (which may also be "display=inline,title" or "display=title,inline") which implies that the coordinates relate to the whole article, not merely one of may points referred to in it. Andy Mabbett 18:05, 15 April 2007 (UTC)
Sigh. Sure, but that still wouldn't give me polygon data to plot on the map. --Dschwen 18:24, 15 April 2007 (UTC)
I sympathise, but I can't see that we'll ever get to the point where WP has GIS data for roads and the like. Perhaps Wikimapia has something you could use? Andy Mabbett 18:33, 15 April 2007 (UTC)
Wikimapia is not what I'm aiming for. Wikimapia is not looking for encyclopedic relevance. And GoogleMaps is fine as a contemporary background, but I could also imagine generating historic map layers to illustrate wikipedia articles. It just seems as a logigal next step to me to insert not only point but polygon geodata into articles where it is appropriate.--Dschwen 18:53, 15 April 2007 (UTC)
Oh, and one tiny detail. Wikimapia only has lots of rectangular boxes. No linear structures no other polygons at all. --Dschwen 09:26, 24 April 2007 (UTC)

Churches

A potentially useful resource for articles on churches without coordinates isDove's Guide for Church Bell Ringers This contains information including (OS) grid reference or other coordinates for all churches with 3 or more bells hung for change ringing. The majority of these are in England, but it also includes some churches in the rest of British Isles, Australia, New Zealand, Canada, USA, South Africa, Zimbabwe, Kenya, India, Pakistan, St Vincent, Grenada and Spain! David Underdown 14:39, 20 April 2007 (UTC)

Coordinate template for non-terrestrial bodies

I've hacked up a coordinate template for non-terrestrial bodies which uses the USGS astrogeology mapbook and planetocentric latitude with east longitude (which, I believe, is the convention). It's currently parked at User:MER-C/Coord. MER-C 12:33, 22 April 2007 (UTC)

Good work. I think you need to include a property to indicate the schema in use (UK coordinates assume WGS84 - we'll have fun when that eventually changes!). See the discussion of non-Earth Geo on the microformats wiki (and linked pages), which is pertinent. Instead of coor mars I would use coor|mars, allowing for other bodies to be named as an attribute, say coor|venus or coor|moon. Note also that the name {{coord}} is already in use; and that that template has display options (title, inline or both) which you may wish to adopt. Perhaps coorp, with "p" for "planet" would be OK? You could then have, say, {{coorp|mars|IAU2000:49900|-2.1|354.5|Meridiani Planum}}. I hope that the output would be Meridiani Planum (-2.1,354.5), or suchlike, and that the coordinates would not be hidden. Would you be kind enough to use the HTML class names in the "Straw Man" at the aforesaid page, as a test case? Please see also WikiProject Microformats Andy Mabbett 13:00, 22 April 2007 (UTC)
I'd strongly discourage introducing a new template for this purpose.
Either add a parameter to {{coord}} or, even better use an already existing convention: the globe attribute! i.e type:landmark_scale:1000_globe:moon --Dschwen 13:48, 22 April 2007 (UTC)
{{coord}} may not be suitable, because of the different method of giving Westings. globe does not allow for a schema, as discussed above - though if these issues can be resolved, using coord may make sense. Andy Mabbett 14:23, 22 April 2007 (UTC)
I don't quite se/understand the problem, please could you elaborate? --Dschwen 16:16, 22 April 2007 (UTC)
Terrestrial coordinates range from 0 to 180 (Eastings) and 0 to -180 (Westings). AIUI, other bodies use 0 to 360. In each case, respectively. 10 west of the meridian would be -10 and 350 (all figures in degrees). A schema needs to be stated, because there is more than one way of measuring coordinates on the Moon, and on Mars. Again, see the linked discussion for more. Andy Mabbett 18:30, 22 April 2007 (UTC)
Isn't this a complete non-issue?! There is no ambiguity between the two schemes. Just use a modulo and both schemes are the same. --Dschwen 20:03, 22 April 2007 (UTC)
The Mars ones aren't quite the same. See, for example, [1]. Notice the difference in latitude between the coordinate systems. MER-C 10:41, 23 April 2007 (UTC)
Yeah, the difference between Planetocentric and -graphic (explained here). But why is that an issue? We have to decide upone one system to use and the ensuing coordinate transformations to adapt to the various(?) map sources can be performed server-side. There are different coordinate systems on eath as well, still we are currently establishing a single template and have long decided to go with WGS84 as the coordinate system. --Dschwen 11:47, 23 April 2007 (UTC)

Also, {{coord}} links to http://tools.wikimedia.de/~magnus/geo/geohack.php?params= , which is very useless for stuff outside of Earth. And the naming was something I haven't decided - it was originally designed only for Mars but due to the inability of the USGS mapbook to produce meaningful output for a given location I changed the implementation. The new implementation has the additional bonus of working on every planet. MER-C 05:55, 23 April 2007 (UTC)

That can be changed easily. I'd volunteer to adapt the maphack. The code to adapt the westings could be included sever-side. --Dschwen 08:33, 23 April 2007 (UTC)

Nice job MER-C. I agree that the Eastings/Westings issue looks like a difference in signedness that's easily resolved by use of modulo. Integrating it in the same php script and templates would keep syntax and presentation uniform (though I can see arguments against it as well). Quarl (talk) 2007-04-23 10:20Z

Title coordinates gone wrong?

Has something gone wrong with the template for title coordinates? For example, Shoreham-by-Sea's cooordinates at the top right are touching the line below the article title. (I'm using Internet Explorer 6, if that helps.) --A bit iffy 08:33, 26 April 2007 (UTC)

I'd also previously noted this problem, which seems to happen with certain infoboxes that set a smaller font size. I had suggested that the low-level template be modified to use a constant font size in the title area rather than inheriting it from the infobox. It could probably also be fixed in the infobox template but that would just fix that particular infobox. --GregU 13:50, 26 April 2007 (UTC)
Thanks Greg. I'll leave another request at Template talk:Coor at d.--A bit iffy 09:29, 29 April 2007 (UTC)
You should be able to fix the problem on Shoreham-by-Sea by placing Template:Coor title d on Template:Infobox UK place before <table class="infobox geography vcard" style="width: 23em;">. It works on Template:Infobox Swiss town. -- User:Docu
Please don't issue such advice without considering the ramifications - in this case, removing the coordinates from the hCard microformat. Andy Mabbett 21:52, 29 April 2007 (UTC)
Pigonthewing, what's your suggestion to fix your contribution? -- User:Docu
As already explained you you elsewhere, the bug is not in "my contribution". Andy Mabbett 10:21, 30 April 2007 (UTC)
Pigsonthewing, please check the additions on http://en.wikipedia.org/w/index.php?title=Template:Infobox_UK_place&action=history -- User:Docu
My name is Andy Mabbett. If you think there's a problem, please identify it more specifically. Andy Mabbett 10:56, 30 April 2007 (UTC)
Pigsonthewing, GregU explained it above, do you understand it? -- User:Docu

Changed location of Barents Sea from (71°55′49″N, 41°20′49″E) to (71°56′N, 41°21′E)

The logic is that: ±½' of latitude (±½ Nautical Miles exactly) is approx ±1013 yards (exactly ±926m ≈ ±1km)

Traditionally Ship/Aircraft navigators used their divider's distance between the latitude lines as their unit of measure, i.e. 1 Nautical Mile.

Given the size of Barents Sea, ±1km seems reasonable. :-)

Could we also have a note somewhere extolling the virtues of using the Degree/Minute format (d°m′N d°m′W) for anything bigger then a ship? (This - as a consequence - becomes a great aid in mentally estimating distances between two objects.)

Is there a best (unintrusive) location for such a guideline?

(OT: another useful conversion is: 2 knots ≈ 1.03m/s, esp for estimating wind speed)

NevilleDNZ 06:08, 29 April 2007 (UTC)

Are you looking for WikiProject Geographical coordinates#Precision ? -- User:Docu
Even minutes were overkill for something this big. I changed them to simply (75°N, 40°E), which is better centered anyway. --GregU 06:36, 1 May 2007 (UTC)
Excellent, Greg. It may seem only a small thing, but any reduction in unnecessary detail is to be welcomed.--A bit iffy 07:31, 1 May 2007 (UTC)


Coord region parameter question

What is the region:GB part of region:GB_type:city giving us in the coord template? I've read the advice at Wikipedia:WikiProject_Geographical_coordinates#region:R but I'm just not getting it. I've experimented with & without the parameter & have not spotted a difference. --Tagishsimon (talk)

Try Meta:Gis_geo_tag#region:R. -- User:Docu
Thanks. That sheds some more light, but I come to the conclusion that the parameter is for a feature (the delivery of a set of maps located in the namespace Wikipedia:Map sources/RR where RR is the ISO code for the region) which has not been implemented. --Tagishsimon (talk)
...yet ;-) Andy Mabbett 10:17, 18 May 2007 (UTC)
It was implemented on egil's server that run the gis extension (later replaced by the current "geohack")
and is used on kolossos (see de:Wikipedia:WikiProjekt_Georeferenzierung/Wikipedia-World/en#Expert_mode). -- User:Docu


Decimal-to-DMS conversion template

I have created a template {{Coords dec to dms}} that will convert coordinates in decimal format to DMS format. I am not quite sure where this template can be used, but at least the functionality is available. ●DanMSTalk 23:55, 28 May 2007 (UTC)

Thank you, but this functionality - and much more - is already provided by {{coord}}. Andy Mabbett 12:15, 29 May 2007 (UTC)

Map?

Is there any way to link coordinates with physic / political maps?. --Mac 16:14, 3 June 2007 (UTC)

Doubled-up coordinates

Hi there. This is probably a very stupid question, but I can't find the answer on the article or talk page. I've just created an article on the Bermuda Atlantic Time-series Study, an oceanographic study site. Anyway, I've included coordinates for it, but for completeness added the coordinates for a neighbouring study site. Unfortunately, both sets of coordinates now appear overlaid at the top of the article. I'm sure there's a simple way to stop this from happening, but am too incompetent to find it. Any help would be very gratefully received. Cheers, --Plumbago 09:53, 8 June 2007 (UTC)

I've fixed that by upgrading to {{coord}}, which allows you to specify inline, title, or both displays. Andy Mabbett 10:32, 8 June 2007 (UTC)
Brilliant! Thanks very much. --Plumbago 10:57, 8 June 2007 (UTC)


Migration to the coord template

Seeing a push in the near future for conversion of all geographical coordinates in Wikipedia to the new {{coord}} template, it would be good to do some preparation. Coordinate numbers are better read by machines than people, so machine readability is an important issue. Following previous concerns on machine readability, perhaps we could improve on many areas and standardise our geocoding when starting the search & replace spree:

Wikipedia:WikiProject Geographical coordinates#Templates currently lists 5 main sets of coordinate markup templates, plus some miscellaneous ones. These should be reduced to one: coord.

  1. Inline coordinates: {{coor d}}, {{coor dm}}, and {{coor dms}}{{coord|display=inline}}
  2. Title coordinates: {{coor title d}}, {{coor title dm}}, and {{coor title dms}}{{coord|display=title}}
  3. Both inline and title: {{coor at d}}, {{coor at dm}}, and {{coor at dms}}{{coord|display=inline,title}}
  4. Templates with default parameters: {{Geolinks-*}}
    The choice of geographical information service should be left to the reader. These can all be converted to {{coord}}, but they need to be discussed separately in case GeoHack is not up to date. The type, scale and region parameters the templates have default values for are likely to never change in most cases. The main question is if it's worth it to have the infobox template choose the additional parameters, or could the coord uses be complete and have static parameters?
  5. Infoboxes that use coordinates
    To maintain machine readability and easy reuse of data, infoboxes should take the {{coord}} template as a coordinates parameter, instead of building it from separate variables. That is, like {{Infobox CityIT}}, not like {{Infobox Swiss town}} for example. Again the only downside would be the loss of default parameters. Is it really a downside at all?

Could someone count the occurrences? Special:Whatlinkshere will be incorrect, as it counts the end result only, multiplying the number if the geocoding template is used through an intermediary template such as an infobox.

And finally, who can volunteer to do the bot work? --Para 06:53, 8 June 2007 (UTC)

6. There are a number (possible a lot) of articles which have coordinates in the infobox and a coordinate template elsewhere in the article. When the infoboxes are updated to take a single coordinate field these coordinate templates should be moved into the infoboxes. -- Patleahy 07:36, 8 June 2007 (UTC)
I agree with most of what you both say; but note that {{coord}} is already available for use. {{Infobox Swiss town}} is the subject of a disputed revert (see its talk page), which has removed microformat markup from it (the documentation refers to the version with microformats). Some articles have separate latitude and longitude fields, and sue these to put a marker on a map. It's pointless to then require coordinates to be entered again in {[tl|coord}}, when the template can generate a {{coord}} from the existing data. There are some notes on migration issues, and usage counts, on the {{coord}} talk page. Template talk:Coord/conversion - I suggest we conduct further discussion there, rather than swamping this page (and move the above discussion there, if you're agreeable). Andy Mabbett 08:41, 8 June 2007 (UTC)
People responsible for all those infoboxes and templates will of course have to be invited to the discussion and see if we can reach any consensus with them, but first I'd like to see some more opinions here. We'll probably need a subpage for this conversion project then. I wasn't aware of locator maps being generated with CSS like that, but also I don't see it as a problem to duplicate the static coordinate information for that purpose, while having all location related articles use the same coordinate template. Perhaps others will. --Para 10:39, 8 June 2007 (UTC)
If we put invites on 100s of template/ infobox talk pages, we'll be accused of spamming (though there has been a notce on {{Main coordinates templates}}, which is on all the coor * documentation) for some time). Besides, many have been using coord for weeks, with no issues. There's no point in asking editors to enter the same data twice; and to do so risks mis-matches, not least by any errors being corrected in one set and not the other. I've set up a sub-page at Template talk:Coord/conversion, with the pre-existing material. Please feel free to move my comments if you move yours there. Andy Mabbett 11:05, 8 June 2007 (UTC)
I'd prefer seeing the discussion here for now, as it concerns more than just the new template. We can put the results of the discussion on the conversion page.
Requesting opinions, positive or negative, from people responsible for or interested of the templates we would like to see changed doesn't match the criteria of Wikipedia:Spam or Wikipedia:Canvassing. We're not some voice of god and can't just apply a big change on the whole site without discussing it first with everyone involved. But before any of that, we need to establish what exactly needs to be changed and to what extent. I'll put together a quick list for preparation.
Please don't be too bold in this project, the template has enough bad reputation as it is. --Para 12:19, 8 June 2007 (UTC)
I dispute that this template has a "bad reputation", but if its reputation is not what it should be, then the sort of disnformation you're posting will have played a major part in that. Andy Mabbett 14:20, 8 June 2007 (UTC)
It's just that you never quite got to work the prototype article you had chosen .. -- User:Docu
That doesn't appear to be a meaningful sentence. Andy Mabbett 16:02, 8 June 2007 (UTC)
It's the saga about the Great Barr article above, where you tried to add Template:Coord, but finally removed it. -- User:Docu
I successfully added {{coord}} to that article; I have never removed it. Andy Mabbett 18:38, 8 June 2007 (UTC)
Note also Category:Geobox. Andy Mabbett 10:33, 8 June 2007 (UTC)

Coordinates parameter in infoboxes

Why should infoboxes take coord as a parameter? Can infobox templates which accept geocoord parameters themselves invoke {{coord}}? This would require no changes in article, only a change to each template. (SEWilco 12:54, 8 June 2007 (UTC))

Coordinate information is best handled in groups, items located in the same area for example. This is impossible if there is no access to the whole of the data. The goal of standardising is to have all the coordinate information entered using the same format: it is not enough that it looks the same when the HTML is rendered, the wikitext should be in the same format in all articles. It is unreasonable to expect us or anyone else to maintain database parsers for all the various parameters currently used in infoboxes when it's possible to use just one. --Para 13:03, 8 June 2007 (UTC)
There are advantages to both methods. Using {{coord}} as the parameter gives the editor control over the display, zoom, etc., and allows entry in decimal or DMS values. Having latitude and longitude parameters in the infobox, which then invokes coord is more straightforward, but is less flexible. We serve our readers first, then our editors, and only then external parsers. Andy Mabbett 14:08, 8 June 2007 (UTC)

A possible alternative may be to define default names for variables of coordinates (latd=, longd= etc.). -- User:Docu

The default names for latitude, longitude and coordinates are, er, latitude, longitude and coordinates. Andy Mabbett 16:01, 8 June 2007 (UTC)
Do you have samples for those? -- User:Docu
They're in every good English dictionary. Andy Mabbett 18:38, 8 June 2007 (UTC)
I think you are missing my point, I was refering to templates. -- User:Docu
As am I. Andy Mabbett 20:50, 8 June 2007 (UTC)
That's still too complicated to parse, as the keywords could be anywhere in the article, with a random number of braces between them and the infobox text and opening braces. To parse that you would need to run MediaWiki for all articles really. This leads into silly things like people on Google Earth not seeing the Wikipedia placemark on a city, but only on small locations there, etc. I don't know if people count users of external services that use Wikipedia data and link here, as Wikipedia readers, but in my opinion it's an excellent opportunity to attract more people here, and we shouldn't let it go. --Para 17:51, 8 June 2007 (UTC)
It appears that, e.g. google, recognize some infoboxes better than others. I was told that Template:Infobox Afghan City works. Not quite sure why.
To avoid duplicating coordinates, we could try consolidate location maps into the/a coordinate template (e.g. {{coor title map dms|50|43|25|N|3|31|39|W|type:_region:|map=UK}}). Possibly this would lead to location maps being transcluded into articles with the template, e.g. all UK location maps are already transcluded by Template:Infobox UK place at http://en.wikipedia.org/w/index.php?title=Exeter&action=edit . -- User:Docu
We're in the middle on consolidating a number of coordinates templates into one, and you want to start creating new ones? Andy Mabbett 18:38, 8 June 2007 (UTC)
It's mainly that you will need to add coordinates twice to some infoboxes, e.g. Template:Infobox UK place. Just wondering why Afghan City might work .. -- User:Docu
I looked at the first few Infobox Afghan City article coordinates on Google Earth and none of the articles were there. Kabul for example is not, though it'd probably be the most important. Then I came upon Kandahar, which actually turned out to be visible. The coordinates in the article were in coor title dms format for half a year in 2006, before it was split to composite parameters. It seems that Google keeps coordinate information from us even when it's removed from our articles or converted to an unknown format. That's good, any single editor can't do much damage then. --Para 19:01, 8 June 2007 (UTC)
Ok then we need to split them out. Do you think it's preferable to have the coordinates for the locator map separated or not? -- User:Docu
I don't see any problem splitting the coordinates in two sets: keeping locator map coordinates however they are now, and use coordinates={{coord}} parameter like with any other article, preferably still in the infobox. Locations of cities are not very likely to change, so the data won't start developing in different directions like some other data might when forked like that. --Para 19:17, 8 June 2007 (UTC)
"It seems that Google keeps coordinate information from us even when it's removed from our articles" - that's very bad; it means that they will perpetuate errors we have corrected. Andy Mabbett 20:50, 8 June 2007 (UTC)
"you will need to add coordinates twice to some infoboxes" - On the contrary, you will find that I have just said that we should only ask editors to enter data once. Andy Mabbett 20:50, 8 June 2007 (UTC)
How would you generate the locator map? -- User:Docu
From the coordinates. How else? Andy Mabbett 08:22, 9 June 2007 (UTC)
Can you provide a working sample of what you are trying to describe? -- User:Docu
I don´t know a working example, but I wish that the keywords for all infoboxes the same! At the moment we have too many keywords for the same thing. Sometime lat, Lathitude, degree, latminute, ...! If we change the infoboxes to a special set of keywords, it is not so difficult to parse the information from the infobox. -- sk 12:04, 11 June 2007 (UTC)
Can you suggest a preferred format? I'd agree to update Template:Infobox Swiss town. Currently, it uses nd=,ns=,ed=,es= which dates from when templates couldn't transclude other templates. If you'd parse the once that would be nice anyways. -- User:Docu
The preferred format should be (at least on the English-language Wikipedia) "latitude" and "longitude", or "coordinates". Andy Mabbett 20:47, 11 June 2007 (UTC)

HTML

Which is what it would be far more sensible to parse the microformats in the published HTML. And before you tell me again that it's "crazy" to suggest that Google download our HTML output, how on Earth do you think they index the rest of the site? Andy Mabbett 18:38, 8 June 2007 (UTC)
Search engine spider traffic is a necessary evil, but suggesting that the traffic should be doubled is outrageous. It probably takes Google longer than the time between our database dumps to download the HTML of all our 60,749,091 pages, so the updates through the dumps are quicker than if they implemented the parser to use the spidered pages. And it's not just Google Earth we're interested in, but everyone should be able to use our data. To get an idea of the amount of data, all the articles compressed in the xml dump are only about 2.5 GB, while the static HTML uncompressed, as it's sent live, is about 700 GB. --Para 19:01, 8 June 2007 (UTC)
"Suggesting that the traffic should be doubled is outrageous". Who suggests that? And why don't we parse our data, and publish a list (XML, maybe, or RSS) of URLs and matching coordinates? Andy Mabbett 20:47, 8 June 2007 (UTC)
We don't need to parse the dumps. The Germans are already doing it. And they publish the urls and co-ordinates in Google Earth. Thats what they are already doing. Now if you would like to do a similar task and publish it in a different format, then by all means feel free to do so. Frelke 23:17, 8 June 2007 (UTC)
Whoooshhhh! Andy Mabbett 23:39, 8 June 2007 (UTC)
The smart way for this case obviously would be to use the pages they already have in their index - no extra downloading. But I guess dumpparsing retains more information, or is the type ( city(pop), mountain(height), landmark, etc. ) parameter in the microformat? --Dschwen 06:43, 9 June 2007 (UTC) P.S.: and Google will sooner or later have to start parsing microformats anyways. --Dschwen 07:37, 9 June 2007 (UTC)

Increasing Coordinates templates from 300,000 to 1,500,000

An element to consider if templates should be converted: the number of templates called for the coordinates of a single location may easily increase by a factor of five:

If there are 150,000 coordinates, we could end up with 1.5 mio template calls. -- User:Docu

Formats

I think we should convert all template to one favourite template format. For human it is easier to understand this template and for computers it is easier to parse this template. My favourite format is {{Coord|43|29|4.5|N|79|23|0.5|W|type:landmark_region:US-TX_dim:3000}} We have many interesting discussion at the german wikipeda about one favorit format. At the moment we have only 3 formats (inline, inline and title, title) at de. For inline we have also at the end "|name=Theater of Trier}". So we can name many list of coordinates with metadata. If the english Wikipedia find a favourite template format then many other languages will also use this. -- sk 12:14, 11 June 2007 (UTC)

As sk does most of the post-processing, his preferred format shall be mine. -- User:Docu
That is against one of the explicit purposes of {{coord}}, which is to give editors the choice of input format and specificity, and readers the choice of format they view, regardless of what the editor used; and to do so in one template, replacing 9+ other templates. Andy Mabbett 20:38, 11 June 2007 (UTC)
We had in the german Wikipedia the same discussion. The best way is to replace the format when the user input the coordinate. In the german wikipedia the user from Switzerland would use the coordinate system from Switzerland (for example: 47° 12' 17.97" N, 8° 45' 28" E is x=699942 y=229067) in de:Freienbach). The user can use the template de:Template:CH-Koordinate. There he can insert the swiss coordinates or geographic coordinates. When he save the article the template will replace the swiss coordinates in geographic coordinates in a standard format. So everybody can input his favourite format, but we have only one format inside the article source code. When we display the article we can say: this is a infobox from a city in Switzerland than display also the special coordinates from Switzerland. I think this will be the best way for the English Wikipedia. Everyone can use every format to write the coordinates but inside the article we only save one standard format. (Ask user de:User:Visi-on for more information. He produce this special template.) -- sk 11:41, 12 June 2007 (UTC)
That's an interesting idea, but would mean that anyone subsequently editing the article would only see the new format. I can't see that being accepted. Andy Mabbett 12:03, 12 June 2007 (UTC)
I think after the first confusion they will accept the new format. -- sk 12:42, 12 June 2007 (UTC)
To make sure I understood correctly: the German Wikipedia has article groups where the coordinates in articles are written in a format accepted by that article group only. Editors can insert coordinates in any format, but a bot will soon come to convert them to the group's local format and remove the original contribution. From there on only the converted format is accepted in that article. There can be many different formats throughout the German Wikipedia, and someone somehow manages to parse all these. Is that correct?
The English Wikipedia does the opposite in a sense: coordinates can be entered in any format, but a bot will later convert them all to the format commonly accepted on the whole English Wikipedia. It will however leave the original template intact, provided that it's in an entirely different format and not just a template markup difference. For example, many people in the Great Britain are used to the British national grid reference system, and their OSGB coordinates live happily together with WGS84 ones in articles. Are we getting ourselves in trouble here then? People probably aren't familiar with both the local and the Wikipedia-wide format, and prefer to edit one or the other but not both. There was discussion above about locator maps and duplicating coordinate markup for two purposes as the location in those maps isn't expected to change, but in all the other articles the likelihood is much higher. --Para 14:25, 12 June 2007 (UTC)

@Para:Sorry for my bad english. There is no bot. It is inside the template. If you write in the german de:Wikipedia:Spielwiese (Wikipedia:Sandbox) the following code:

{{CH-Koordinate
|Text   =X 
|Artikel=X 
|LAT    = 45.6
|LONG   ={{subst:CH1903-WGS84|600|200||koor=L|subst=subst:}}
|TYPE   =
|VALUE  =
|REGION =
|DIM    =
|ONLY   =
}}

then you get after the save-button (german:"Seite speichern") in the article

{{CH-Koordinate
|Text   =X 
|Artikel=X 
|LAT    = 45.6
|LONG   =7.438637<!--{{subst:CH1903-WGS84|600|200||koor=L|subst=subst:}}-->
|TYPE   =
|VALUE  =
|REGION =
|DIM    =
|ONLY   =
}}

So the man and woman from Switzerland can everytime change it and inside the article is only geographical coordinates. -- sk 19:39, 12 June 2007 (UTC)

Interesting feature. However, my question above for Template:Infobox Swiss town is somewhat different: Each of the 2600 articles using the infobox have coordinates added to them. The question is just in which way to format them to make it easy for you to parse them. The infobox uses the coordinates both for displaying a locator map and for displaying the coordinates themselves. -- User:Docu
The best are standard keywords (LATITUDE,LONGITUDE,INHABITANTS and ISO-CODE-REGION =CH-BE ) and the degree value as "-45.2394". So you can produce map and coordinate and I can easy parse all different templates. But please discuss the keywords. If all different templates use the same keywords it is the best. -- sk 19:53, 15 June 2007 (UTC)
Boggle For weeks, Docu has been persistently removing {{coord}} from {{Infobox Swiss town}}, despite having originally requested its addition, and despite the fact that Stefan - and Google Earth and GeoNames - have already said that they will parse it. {{Infobox Swiss town}} is the only one of very many infoboxes using coord from which it has been removed. Andy Mabbett 20:35, 15 June 2007 (UTC)
@Andy: It is possible to make a locator map inside the template when the template use "coord"? I don't know? If this possible then you should use the template:Coord inside the template:Infobox. I mean the best is only one template for all coordinates inside article text and inside infoboxes. But if one function (locator map) is not possible then we need a second standard (keywords). (Sorry for my English!)-- sk 22:32, 15 June 2007 (UTC)
If latitude and longitude are entered, as decimal values, into a template, then it's possible for that template to generate both a locator map and a coord template. I'm not sure how one could generate a locator map if the coordinates are entered by typing using cord template as the value, because I don't know enough about parsing within templates. That doesn't seem to be relevant to Docu's constant reverting, though, as he's switching from outputting coord, to outputting coor dm and coor title dm, which is no different, in regard to map generation. Please don't apologise for your English! Andy Mabbett 09:31, 16 June 2007 (UTC)
@sk: Template:Geobox_Settlement uses lat_d, lat_m, lat_s, lat_NS, long_d, long_m, long_s, long_WE, population as names for the variables. In Template:Geobox_River, these are used as suffixes. For ISO-CODE-REGION there doesn't seem to be an equivalent. What do you think of the geobox names? -- User:Docu
Why are a single set of coordinates being used for linear features like rivers? Andy Mabbett 11:02, 16 June 2007 (UTC)
@Pigsonthewing, try Template talk:Geobox River. -- User:Docu
@Docu: For me it is important, that this keyword is only use for georaphic coordinates. Sometime I found coorx =12 and coory=52 with coordinates for the locator map in pixel. This is not good. So please use only one set of keywords in all templates. This will be the best. "lat_d" and Co is ok but I think the long form "latitude_degree" is better to understand. -- sk 08:57, 19 June 2007 (UTC)
In my view the splitting of the parameter in degrees, minutes and seconds is very bad practice. I think the best format will be decimal degrees. All other formats (inclusive swiss coordinates) are best supported by transformational templates. This favorite format is also usable for locator maps. Visi-off 12:24, 26 June 2007 (UTC) visi-on in german wikipedia
@sk: if decimal coordinates are given, there would just be two variables of the length of "latitude_degree", but if six are used (lat_d, lat_m, lat_s, lat_NS, long_d, long_m, long_s, long_WE) seem shorter.
@Visi-off: One of the disadvantages of decimal degrees is that we would need to convert existing coordinates and there seems to be some preference in using dms for display (which means that they would need to be converted back). -- User:Docu
(The preceding comment by {user|Docu}}) As I though you were already aware, {{coord}} handles that conversion, in either direction, automatically, and allows the user a choice of display preference. Andy Mabbett 08:51, 28 June 2007 (UTC)

De-migration

At the same time as we are thinking of reducing coordinate templates to one, others work on creating more of them, such as {{PoIgb}}. What should be done to discourage this? Summary restructuring and deletion? --Para 21:14, 16 June 2007 (UTC)

PoIgb is not a new coordinates template; it's a table template which calls {{coord}} in exactly the same way you've been suggesting elsewhere. More FUD. Andy Mabbett 21:51, 16 June 2007 (UTC)
The coordinates are given to PoIgb, and without running MediaWiki on their own a data reuser can't know that the numbers would later be given to coord. Additional data entry templates like that are exactly what we're trying to develop away from. Why can't coord be called directly in tables? --Para 21:57, 16 June 2007 (UTC)
Just as happens in about half of the geo-infoboxes. Since the coordinates in PoIgb don't generally, apply to the whole article, why should parsers need to see them? as to your last question, there are vocal opponents to such a move, for the same reasons you've opposed other templates, which do use coord as a value, in the last few days. {{PoIgb}} is the model you said you wanted, when opposing {{hcard-geo}}, which has coord as a value, the model you oppose. Please make up your mind what you want. Andy Mabbett 22:03, 16 June 2007 (UTC)
It shouldn't be up to the data providers to choose what the data reusers want to see, though inline data no doubt has lower priority. All coordinates should be entered using the same template. In this topic we have tried to find out whether it would be possible to really do that, or if infoboxes need to be exempt and have composite coordinates using some standard parameter set. The problem with hcard-geo isn't its different data entry, but the naming and syntax from another data representation layer, and the unnecessary wrapping of one template inside another, when only adding minor information that could as well be implemented in the inmost template. Table row templates seem to generally be accepted, though personally I'd prefer seeing the normal wikitable syntax, especially in this case where all the cells between rows are different and no information is repeated. The preferred data model with structured data in articles is to call the data by its name, be it a coordinate or a point of interest, but not by its possible eventual output format name. --Para 23:34, 16 June 2007 (UTC)
"All coordinates should be entered using the same template." If you wish to implement that as policy - it certainly isn't now, nor has it ever been, in the time I've been here - then feel free to raise it in the appropriate forums. In the meantime, it's just your opinion, and as such is without merit. Andy Mabbett 20:01, 17 June 2007 (UTC)
Geeez, what's the matter with you? Don't you realize how unproductive your rude manners are? We are all just trying to contribute to improve the geocoding on Wikipedia. You make it seem like it's you against all others... --Dschwen 08:47, 18 June 2007 (UTC)
I was perfectly polite. Please don't make false accusations. Andy Mabbett 09:37, 18 June 2007 (UTC)

I just noticed {{PoI}} too. Can we put an end to this and not create any more coordinate entry templates? Or should they just be converted to use named parameter as proposed below? --Para 11:05, 29 June 2007 (UTC)


Updating documentation

Unless anyone objects, I shall shortly update this project page, to say that people should use {{coord}} in preference to coor * templates. Andy Mabbett 16:45, 27 June 2007 (UTC)
Given http://earth.google.com/userguide/v4/geoweb_faq.html (mentioned by AM elsewhere) this seems reasonable to me. -- roundhouse0 20:02, 27 June 2007 (UTC) I await consensus elsewhere. -- roundhouse0 12:19, 28 June 2007 (UTC)

This is again being discussed at the talk page of the Manual of Style as well. --Para 23:48, 27 June 2007 (UTC)

Mapit/ Geolinks templates

The mapit and geolinks template families include many templates (e.g. {{Geolinks-buildingscale}}, {{Mapit-US-cityscale}}) which add map links to an article, duplicating those provided by http://tools.wikimedia.de/~magnus/geo/geohack.php (see Lassen Peak for an article on which the coordinates are entered using both coord (was coor at dm) and a Geolinks template). Any thoughts on removing/ deprecating them also? Andy Mabbett 13:25, 4 July 2007 (UTC)

Why? The Geolinks provide one-click access to relevant map sites, without having to scroll down the long list accessed by {{coord}}.
—wwoods 15:02, 4 July 2007 (UTC)
I tend to agree with Pigsonthewing. The geolink templates are somewhat redundant with the coordinates near the article title. -- User:Docu

Standardize names for coordinate variables in template namespace

Following the lengthy discussion and suggestion above at #Formats, I'd suggest to define the following names for coordinate variables in template namespace:

Templates other {{coor *}} or {{coord}} should use the following variables as for coordinates: lat_d, lat_m, lat_s, lat_NS, long_d, long_m, long_s, long_WE [Changed to:] long_EW.

This should be defined here and in a section of the Manual of Style. -- User:Docu

Minor nit... please make it long_EW rather than long_WE. More logical, matching lat_NS with the positive direction given first for both (and also alphabetical for both). And more commonly spoken this way I think. --GregU 06:35, 29 June 2007 (UTC)
And want to add, I support this abbreviated form. These would be ubiquitous so not a problem with understanding, and this allows 4 or even 8 to fit on a line easily. --GregU 07:07, 29 June 2007 (UTC)
Good point, I updated the proposal to read "long_EW". -- User:Docu
You don't say why you think coord should use those variable names; and it's certainly not worth applying them to coor *, when were discussing the process of deprecating them. Andy Mabbett 09:11, 29 June 2007 (UTC)
Indeed, I didn't, as the proposal is for templates other than {{coor *}} or {{coord}}. -- User:Docu
Support with long_EW. I don't think we have addressed the inline coordinates issue yet, where some editors prefer seeing coordinates inside infoboxes only and not in the title: if a page has coordinates using coord and none of them are specified to be in the title, which of the possibly many inline coordinates should be used to represent the whole article? So in addition to these variables, I suggest a coordinates= variable which takes the coord template. It's already done that way in many places with the old templates and noted by external services too, but not recently with the new template. --Para 11:00, 29 June 2007 (UTC)
"if a page has coordinates using coord and none of them are specified to be in the title, which of the possibly many inline coordinates should be used to represent the whole article" - if there's one set in an infobox, that one; otherwise, none. Andy Mabbett 11:51, 29 June 2007 (UTC)
So how can it be detected which of the possibly many coord are in an infobox? --Para 12:00, 29 June 2007 (UTC)
Support proposal. As for display, other editors (doubtless misguided) prefer coordinates not to appear in the infobox at all. I would like a line |display=inline/title in the infobox, to give all 3 options - if an infobox is modified leaving the appearance of the page unchanged, then much of the opposition is disarmed. (If the intention is to irritate as many editors as possible and argue the toss infobox by infobox and page by page, delaying the introduction of microformats and stimulating opposition to the whole idea, then the 'both only' option is optimal.) -- roundhouse0 13:51, 29 June 2007 (UTC)

Given the support, I updated Wikipedia:Manual_of_Style_(dates_and_numbers)#Geographical_coordinates by adding the above proposal. Thank you for your contributions and support. -- User:Docu

(previous comment by {user|Docu}}) That isn't manual of style issue; and the proposal above didn't suggest changing the MoS. Was this discussed on Project Infobox? Andy Mabbett 11:47, 5 July 2007 (UTC)
Do you disagree with the proposal or are you just on a reverse spree? -- User:Docu
Do you always answer questions with questions? Andy Mabbett 14:11, 5 July 2007 (UTC)

Inline coordinate display

A comments request a while ago invited people to participate in a discussion about inline coordinates displayed as icons instead of numbers. I think it would be better to have that discussion here. Inline coordinates are not too common now, but when we run out of articles to add title coordinates to, people will inevitably start locating smaller things mentioned within articles. In my opinion inline coordinates make article text harder to read, and the numbers don't tell me much; I need a visualisation to make sense of the location. See Ridge Route for example of an article with many inline coordinates. There are undoubtedly people who are fluent coordinate number readers, and prefer keeping the information visible, but I suspect they are in the minority. So how about just making them less visible? Would it be possible to have coordinates work much like references do, by having:

  1. Inline coordinates displayed not as such, but as a small superscript icon
  2. Inline coordinates create an anchor link to a table somewhere in the article (at the end, preferably, before references) using the icon as the link, possibly together with an index number
  3. A <coordinates/> tag at the end of the article expanding to anchors, perhaps a name given with coord (as proposed here), and the coordinates themselves.

This would still keep coordinates editable where they are first mentioned, so editors wouldn't have trouble finding them. It would follow the Wikipedia link style where linked words lead to other articles, and superscript notation right after a word lead elsewhere in the same article. The references-style table placement tag would likely need a modification for the references extension though to make it more general. Thoughts? --Para 13:01, 29 June 2007 (UTC)

The use of an icon to hide the coordinates would, like one of your other suggestions, involve hidden metadata; I refer you to our previous discussion on that subject; and to our discussion as to why your proposal to add a name value to {{coord}} is flawed. Andy Mabbett 16:50, 29 June 2007 (UTC)
Please read the proposal before commenting. I did not suggest hiding the coordinates, but placing them elsewhere in the article with a direct link between. --Para 17:02, 29 June 2007 (UTC)
Do you mean that your three numbered items are a not alternative choices? If so, then I think your proposal would work in some cases as I suggested at Talk:Ridge_Route#move_inline_coordinates_into_table, but the suggestion was not liked there. How many pages have coordinates inline in the manner and quantity of those at Ridge Route? Andy Mabbett 17:39, 29 June 2007 (UTC)
Obviously the items wouldn't all work on their own, but all together, in that order of reader perception. Inline coordinates are few now, but again, as I said, they are likely to become more common once title coordinates have been added to our articles. The discussion you cite has three contributors, two of which are us, so you can hardly give any weight to that. --Para 18:12, 29 June 2007 (UTC)
I like the idea of superscripts with a <coordinates/> tag, working not unlike the idea (which people are now accustomed to) ... very good. I think any long walk or route/road/canal might lend itself to this treatment. I think a table of co-ordinates is (or can be seen as) rather intrusive and also difficult to maintain, much as a table of refs would be. -- roundhouse0 18:34, 29 June 2007 (UTC)


Heights

While looking up heights of hills & mountains, I came across a site that gives coordinates (including height) of trig stations (probably Canberra specific). area around Red Hill, Australian Capital Territory. [How] should I include this in articles? --RobBrisbane 08:32, 1 July 2007 (UTC)

Changing {{Geolinks-start}}

{{Geolinks-start}}, which is called by {{Geolinks-US-buildingscale}}, still uses {{coor}}. Shouldn't we update it to use {{coord}}? I am an admin, so I can edit the template, but I don't want to break anything :-) --bdesham  18:08, 9 July 2007 (UTC)

There's talk above to get rid of all coordinate entry templates except {{coord}} and templates using the proposed standard keywords as parameters. That means that coord should be used directly and not through another template. The Geolinks templates only duplicate GeoHack, and if there's something wrong with GeoHack, we should work on improving it instead of building alternative systems on the side. The choice of geographical information service should be left to the reader in all cases. --Para 17:25, 12 July 2007 (UTC)
I've gone ahead and changed {{Geolinks-start}} to use {{coord}}. This fixes a lot of Geolinks templates; unfortunately, they're all really redundant and so I've had to change a couple of others (e.g. {{Geolinks-US-streetscale}}) manually. --bdesham  17:45, 12 July 2007 (UTC)
The change lead to the coordinates being bolded. I reverted the change as it didn't add much besides the bolding. Please use test before changing numerous pages. -- User:Docu
I removed the bolding on Geolinks-start -- dml 17:53, 13 July 2007 (UTC)
Please also restore the use of {{coord}}, as requested on its talk page. Thank you.. Andy Mabbett 19:17, 13 July 2007 (UTC)
I have restored the use of {{coord}} and removed the bolding. @Docu: as you can see from Template:Coord, that template is now preferred over the deprecated {{coor}}. By the way, it does "add much" vis-à-vis microformats. Cheers, bdesham  20:00, 13 July 2007 (UTC)
Apparently on {{coord}} it reads that everything else is depreciated.
The current solution is just, that there are several ways to add coordinates, where coord is a problematic way to do it, as it's not generally being parsed yet, e.g. by sk. BTW you may add the microformat directly to geolinks. -- User:Docu
User:Docu wrote: "coord is a problematic way to do it" - you keep making these unfounded and unsupported assertions. I note that you have raised no supposed bugs on Template talk:Coord. {{coord}} is being parsed by Google Earth. Adding the microformat mark-up directly to the Geolinks template would not give the other benefits of Coord, such as giving the user the choice of display type. If by "sk" you mean "Stefan Kühn" of Wikipedia-World, he stated in early June that he would start parsing it. If he has failed to do so, over a month later, why should that stop Wikipedia from progressing? Andy Mabbett 08:44, 14 July 2007
Pigsonthewing: oddly, you can't provide us with a proof for the ways you are asserting coord is being parsed. So why not stop doing that? -- User:Docu
Why is the bolding gone? Geolinks-start has been bold for years (since 2004: I went back and checked) --- why the sudden change? It looks wrong to me now. hike395 15:00, 18 July 2007 (UTC)
There was really no reason for the Geolinks header to be bold in the first place. External links aren't usually (ever?) bolded; in retrospect, I'm just surprised that no one has changed it before now. Probably because the template is protected? --bdesham  20:04, 18 July 2007 (UTC)
I think it was bold to show that it marked a subsection of the external links section, similar to triple equals. Now, the map external links are not well distinguished from the other links in the same section. hike395 01:29, 19 July 2007 (UTC)
I can see your point, but the other links in the "subsection" are indented, and IMO that makes them stand out enough. It would probably be best to change {{Geolinks-start}} to output a === heading ===, but that could lead to silly situations in which the external links section consists entirely of the one subsection. --bdesham  02:54, 19 July 2007 (UTC)

Location of tag

Just a minor formatting query: is there a generally accepted preference for where in the article the {{coord}} tag should be placed? --Muchness 21:20, 27 July 2007 (UTC)

Maybe at the end of the article, near the external links section? That's where categories, interlanguage links, and the like are already placed, so that makes the most sense to me. On the other hand, for most situations you're better off just adding an infobox—it will call {{coord}} automatically, and you can put a bunch of other information there too. If you must, there are also the Geolinks templates—see here—although those seem to be deprecated in favor of infoboxes these days. Cheers, bdesham  21:32, 27 July 2007 (UTC)
Thanks for the help, appreciated. --Muchness 21:48, 27 July 2007 (UTC)

Making geographical information services better available

There's discussion at Template talk:GeoTemplate#Redesign.3F and Template talk:GeoTemplate#GeoHack_improvements to improve the page that appears after clicking on coordinates in Wikipedia. Comments and suggestions would be welcome. If the proposed changes can be implemented, the page might finally be usable and useful enough to perhaps let the geolinks templates go. --Para 19:33, 30 July 2007 (UTC)

Export points of interest as KML; see them on Google Maps

Pages marked with {{coord}} can be exported as KML (for use in Google Earth, for example) via Brian Suda's site, in this format:

http://suda.co.uk/projects/microformats/geo/get-geo.php?type=kml&uri=http://en.wikipedia.org/wiki/List_of_volcanoes_in_the_United_States_of_America

The same URL can be pasted into Google Maps as a search, and will show the locations, as push-pins on a map

Andy Mabbett | Talk to Andy Mabbett 09:53, 2 August 2007 (UTC)
The template {{kml}} was created - and promptly nominated for deletion. --Para 13:39, 3 August 2007 (UTC)

Linear features

I propose that we add a section to this project's guidelines, to offer advice on recording coordinates for linear features such as roads, railways, rivers, canals and trails, We could look at current best (and bad!) practice, involve he relevant WikiProjects, and take into account emerging technologies such as {{coord}} and the services linked to form {{kml}}. We should also aim to ensure that any published examples meets current polices, (or see whether such polices are in need of revision). Andy Mabbett | Talk to Andy Mabbett 06:20, 5 August 2007 (UTC)

This is one of my pet peeves too. Geocoded linear features in articles would be very useful for generating complex locator maps. Please have a look at this discussion and commons:Template:GeoPolygon (and the example on the template talk page). --Dschwen 09:50, 5 August 2007 (UTC)
While Polygons and linear features are different, some of the same principles apply. I like your template (though it could be improved by also outputting Geo microformats; perhaps by usung multiple instances of {{coord}} as input values), and wonder why you favour that approach there, but oppose it in {{kml}}, and have voted for its deletion. (Other editors might like to see pages, about linear features, using the latter, such as Manchester Ship Canal and Netherton Tunnel Branch Canal). (Folks interested in polygons might also be interested in my proposal to extend the Geo microformat to cater for boundaries.) Andy Mabbett | Talk to Andy Mabbett 17:27, 5 August 2007 (UTC)
At the time I created it I didn't know about the GEO MFs, feel free to improve it though. The idea of my template was centered around creating a query string, containing all coordinate data, which could easily be passed to an external script. I'd think that multiple instances of coord (though a nice an powerful template) would be quite clumsy for larger line features (many points). In any case the template and script thingie was created for commons as a proof of concept, and I wouldn't want tons of coordinates to clutter the article. Another idea would be using subpages to store polygon data. I don't have a silver bullet solution and I fear that introducing line features or polygon data to wikipedia will neither be easy nor doable in a short timeframe. Good luck anyhow. --Dschwen 17:58, 5 August 2007 (UTC)
Line features have already been introduced on WP-EN; I'm seeking discussion of how best to implement them. Thank you, though for your good wishes. While we have a disagreements over an accessibility issue, I don't think were very far apart in wanting to improve Wikipeida's use of coordinates and maps. Andy Mabbett | Talk to Andy Mabbett 18:25, 5 August 2007 (UTC)
P.S. Because commons:Template:GeoPolygon has one field for all coordinates )"latitude, longitude, latitude, longitude, latitude, longitude, latitude, longitude, ad infinitum) it is hard to add microformat mark-up without using a template for each coordinates pair. Could commons:Template:GeoPolygon have a separate field for each pair, with some sort of delimiter after the last one? I have no idea whether that's possible or, if it is, how to make it so. Andy Mabbett | Talk to Andy Mabbett 18:31, 5 August 2007 (UTC)
A road is linear in character, but details are now visible with significant width. In Google Earth one can mn seconds make a translucent orange rectangle showing the location of the fallen I-35W bridge (or enclose the whole bridge in the orange indicator). Would such markers be useful in additions to coordinates? (SEWilco 21:33, 5 August 2007 (UTC))
Perhaps; but perhaps we also need to walk before we run? ;-) If I mark up the coordinates of a linear structure like a 300-mile motorway, I would include the major junctions, not each twist and turn, let alone its width. Andy Mabbett | Talk to Andy Mabbett 21:36, 5 August 2007 (UTC)
The best description of an object is dependent upon the characteristic being described. For a road being used for movement, the linearity is important because it is a line which connects points. When the road crosses the Golden Gate Bridge, that bridge itself has its own characteristics of interest which may require 2-D or 3-D descriptions. When the topic is toll roads, the pinpoint location of the toll booths along the road are of interest. For an event such as a disastrous landslide across a road or a collapsed bridge, the location(s) of the event are of greater interest than the road itself. The requested guideline will have to be somewhat general. (SEWilco 16:59, 6 August 2007 (UTC))
Using present Wikipedia technology, I suggest that the guideline recommend describing linear characteristics in the form of a table or list. So a description of the Grand Canyon might be a west-to-east description of highlights along with their coordinates. It would be legible to someone without special tools and each point can be described as needed. Such information can have various markup added, particularly as Wikipedia technology changes. (SEWilco 16:59, 6 August 2007 (UTC))
In the specific case of a wikitable which contains rows with coordinates, can microformat markers be added before and after a list of individual geotags which marks the list as being a linear object? So a wikitable of Grand Canyon features would look to a microformat browser as being a linear geo object, by adding an appropriate marker ahead of and after the table? (SEWilco 16:59, 6 August 2007 (UTC))
Not yet, but see geo-extension for waypoints for a proposal to enable that. Andy Mabbett | Talk to Andy Mabbett 13:55, 7 August 2007 (UTC)
Yes; see the Manchester/ Netherton examples, above, plus M62 motorway#Route and Walsall Canal (the latter uses {{PoIgb}}; see also {{PoI}}). See also List of United Kingdom locations: Bal, which is not a linear feature, but uses additional hCard properties, in a table. (I will document the various methods, when I have time, under WP:UF) Andy Mabbett | Talk to Andy Mabbett 18:48, 6 August 2007 (UTC)

New type value for small scale items

Wikipedians have started adding coordinates to articles of deceased people, see Template talk:Infobox_Person#Resting_place. We have already discussed a similar topic with other small scale objects at Wikipedia talk:WikiProject Geographical coordinates/archive011#Articles_that_do_not_need_coordinates. Usefulness, accuracy and reviewability aside, should we add another type to be used in these very small scale cases instead of landmark? It would make it easier to ignore the redundant information copied from the main article of the location, without relying on categorisation only. How about something like type:object with scale 1:500? --Para 21:35, 10 August 2007 (UTC)

An interesting idea. What is the standard for "type" classifications? And is there a distinction between a small scale resting place and Grant's Tomb, which probably is type:landmark? (SEWilco 15:17, 14 August 2007 (UTC))
Looks like User:Egil (who used to run GeoHack before Magnus) just made up the type parameter at the dawn of the GEO project for this exact purpose. The whole type classification system is sort of redundant as the category tree could be walked to find what type an article represents, but that's a bit too complicated for reuse, so people have manually tagged articles with a coordinate type. I would still use categories to help assign a type to an article; articles about a location should be tagged with type:landmark or bigger, and others such as deceased people, paintings and other items that are usually not associated with coordinates, with type:object. If there's an article of the resting place, be it small or big, that would make it a notable landmark, whereas a non-notable location of the resting place mentioned in the person's article would be just an object. Thoughts? --Para 19:26, 14 August 2007 (UTC)

Little boxes, little boxes

The following was copied from a subdiscussion about viewing all coordinates on a page such as List of impact craters in the United States and Central America. The template {{kml}} currently emits this text (with links)
# Export points of interest (as KML)
# View points of interest on Google Maps

and it is planned to add additional such services.


I was thinking of something more like the Commons box, but without the big logo, and brief text such as "A collection of coordinates is available.". At first I thought it should go by the coordinates. But a right-side box in External Links seems better, particularly as it can then be found when you're looking for it. I'm using an external link in the examples but should be a link to a coordinate collection selection page.


Here's one based on the box linking to the Labelled Image Editor (used for Labelled Maps):


A box stripped down from Commons box:


A box based on the Portal box:

A collection of coordinates is available.

(SEWilco 17:35, 11 August 2007 (UTC))

I think you should raise these issues - which have merit (but which require different wording) on the talk page for {{kml}} or WP:GEO. Andy Mabbett | Talk to Andy Mabbett 17:53, 11 August 2007 (UTC)
End of copied text from Template talk:Coord.
Perhaps better text in the box would be "This article contains a collection of coordinates." because that is a statement of fact about the article which would be more true in printed form than "is available" being on a piece of paper. (SEWilco 05:02, 13 August 2007 (UTC))
It may be better for the link text to convey an action "The coordinates on this page are available on maps, or for downloading", or some such); with the box styled to not be printed. Andy Mabbett | Talk to Andy Mabbett 11:03, 13 August 2007 (UTC)
That phrase is kind of long. It would be nice to have something likely to use less than half a line, so it can reside on the right side of the first few external links. (SEWilco 02:14, 15 August 2007 (UTC))
hence "or somesuch" ;-) The shortest I can come up with, referring to both uses, is "View/ download all waypoints". Andy Mabbett | Talk to Andy Mabbett 20:57, 15 August 2007 (UTC)

Second set

Here's the new phrasing. Which of the boxes seems best? (SEWilco 16:27, 16 August 2007 (UTC))


I'm currently ambivalent about which box is used. For the sake of three extra characters, I'd prefer "View or download..."'; and all the text should be in the link, so that it will "stand alone". Note also that "waypoints" is both shorter and more precise than "coordinates". Andy Mabbett | Talk to Andy Mabbett 16:33, 16 August 2007 (UTC)

Amended. Use of "/" isn't as clear as "or". And I left it as "coordinates" because that's what numerical definitions of locations generally are called in articles. (SEWilco 17:26, 16 August 2007 (UTC))
I also changed the HTML to be more consistent and to not appear on the printable version. (SEWilco 17:56, 16 August 2007 (UTC))
I think the second box is best. It's not very wide and there is no need for bold text. (SEWilco 17:58, 16 August 2007 (UTC))
Thank you for the amendments. On further reflection, the text should not be below 90% (preferably, not below 100%) for accessibility reasons. Likewise, if it is below 100%, it should be emboldened. Andy Mabbett | Talk to Andy Mabbett 18:40, 16 August 2007 (UTC)
Possible alternative, shorter wording: "Map or download..."; "Map or use..."; "Use..."; "See..."; or just "All coordinates"; or how about a small globe icon and "All coordinates"? Andy Mabbett | Talk to Andy Mabbett 18:46, 16 August 2007 (UTC)
Removed font size specification and altered to "Find maps of..." phrasing similar to the intro of GeoTemplate. I still prefer the 2nd box. (SEWilco 22:22, 16 August 2007 (UTC))
Thanks for fixing the fonts; I think the second box is OK, but would still like to add a globe icon (or maybe a push-pin). "Find maps of all coordinates" could be shortened to "Map all coordinates". but neither of those expresses the facility to download or extract the coordinates. Andy Mabbett | Talk to Andy Mabbett 22:53, 16 August 2007 (UTC)

Change of topic from style to need

Such indicators are not needed. Wikipedia is filled with articles that in addition to the main topic of the article handle subtopics that are either a part of the topic or related to it. There has never been any need to give self-referential hints to readers that the article provides more complete information than its name might imply; the readers can see that themselves after having looked at the article for a moment. Also, there was big controversy over having coordinates in articles' titles at all when they were first introduced. Each mention of coordinates now links to a list of dozens of tools, with no other special presentation in articles. Having this kml thing in External links is questionable already, so a big box to showcase the same external links and proprietary formats in an even more visible way will most certainly not pass. --Para 07:46, 13 August 2007 (UTC)
"Having this kml thing in External links is questionable already..." Others seem to think not; your motion to delete the template having been soundly defeated; and you have yet to provide an form of viable alternative. Andy Mabbett | Talk to Andy Mabbett 11:03, 13 August 2007 (UTC)
If you say no indicator is needed, please show me where to click in List of sequoia groves to view all the coordinates in the article. When I click on a single coordinate I get a GeoTemplate list, which only lets me see that one point which I selected. I think an indicator is needed of where I should click to view all the coordinates. (SEWilco 18:39, 13 August 2007 (UTC))
The interface in Wikipedia to have more information of coordinates is to click on any of them and choose a service of your preference. Indicators aren't used for any other similar minor details in articles, and the variety of available services for these minor details doesn't make them any more special. Adding the KML service links to the standard list is unfortunately not possible yet, as a single [personal attack removed] keeps blocking the required coord|name= modification by making it seem to admins as if discussion was still going on or that his objections were worth noting. Still, the link to the services won't be some separate and different indicator of an available service type, but the same Wikipedia coordinates interface everyone knows already. --Para 19:25, 13 August 2007 (UTC)
The coord|name= modification only affects the labeling of the points, not their being exported as a collection of points. (SEWilco 19:33, 13 August 2007 (UTC))
This is a technicality, but nothing in Wikipedia exports a collection of points; the generated links only give the name of the containing article to the service, which in turn is used to retrieve the page and its coordinates. If you look at the proposed coord modification, that's what it does in addition to the labeling. --Para 19:42, 13 August 2007 (UTC)
Your sandbox test link only produces a GeoHack page with links to show individual points. Your proposed change to coord does not provide access to the collection of coordinates on a page. However, I think your proposed change does label individual points for export tools. (SEWilco 20:23, 13 August 2007 (UTC))
You are looking at a link from months ago, whereas kmlexport and its demonstration are much newer. See my comment on Template_talk:Coord with a proper link to the GeoHack sandbox where the link works perfectly. How in your opinion does it not provide access to a collection of coordinates? --Para 00:29, 14 August 2007 (UTC)
That whole page is about a single location, stated in the intro (in this example) as "-54.25°, -36.75°"; yet you suddenly offer the reader a link to a series of coordinates with no apparent relation to that point. As pointed out to you many times recently, by several people, it's ludicrous to do so. Your silly change to the introductory wording of that page, making it read "You may be able to find maps and data about the location(s) on Earth..." instead of {{GeoTemplate}}'s "You may be able to find maps and data about the location..." are a rather facile attempt to overcome this incompatibility; but do at least give some indication that you are aware of the issue, much though you try to deny it. Quite clearly, only one location has the coordinates "-54.25°, -36.75°". It's a singularity. Andy Mabbett | Talk to Andy Mabbett 08:12, 14 August 2007 (UTC)
That link to the GeoHack sandbox seems OK, if {{kml}} link goes to that section of GeoHack so the relevant section is being referenced. What is kmlexport and where is it described? Do you mean MW:Extension:KML Export has been enabled, so {{kml}} should refer to that special page? (SEWilco 15:33, 14 August 2007 (UTC))
On the contrary; that page is for single waypoints. Andy Mabbett | Talk to Andy Mabbett 16:19, 14 August 2007 (UTC)
Says who? It's not written in stone, you know. Two different infrastructures for such closely related things (coordinates, whether it's one or many) doesn't make much sense. I'd rather expand the geohack on the toolserver instead of introducing a completely new system. --Dschwen 16:33, 14 August 2007 (UTC)
Says all the evidence cited in regard to this issue over the last few weeks; and many of the people speaking - successfully - against the deletion of {{kml}} . Single waypoints and collections of multiple waypoints are sufficiently different that it makes sense to have different pages for tools displaying them. No new "system" is needed; just a new template-page, if and when the number of such services makes one appropriate. Andy Mabbett | Talk to Andy Mabbett 17:18, 14 August 2007 (UTC)
Sorry, instead of "That link" I should have provided that link to the GeoTemplate sandbox example for multiple coordinates. Ir order to support more tools, they have to be moved out of sight so the notice in the article doesn't grow to many lines. That way {{kml}} can emit a small notice for however many coordinate collection tools appear, and with two clicks any of them can be accessed. If the link goes to that section for multiple coordinates then one won't have to hunt for them. Which tool produces the KML file is irrelevant to the reader, as long as it works. (SEWilco 02:01, 15 August 2007 (UTC))
Kmlexport is the toolserver tool I wrote to improve the one that was previously used on {{kml}}. It's described on the documentation page of the template, with better description pending proper implementation of coordinate annotation on Wikipedia. I wasn't aware a MediaWiki extension had been written as well to export kml, and nobody pointed it out in the deletion discussion. Is there a reason why it's not installed on Wikipedia? Exporting parts of articles would fit best in the user interface toolbox instead of inside articles. --Para 17:46, 14 August 2007 (UTC)
Kmlexport is only partially described on {{kml}}'s /doc page; and I still await your full reply to my question about its inputs; a question put to you both there are and elsewhere. coordinates on Wikipedia can already be fully annotated, as shown when exporting KML files suing the previous tool, links to which you removed. Andy Mabbett | Talk to Andy Mabbett 17:55, 14 August 2007 (UTC)
Clicking on a single coordinates link , only to be given a choice of seeing a service relating to those coordinates, or a range of coordinates, is counter-intuitive; and will put an extra layer in the way of people wanting the former. Indicators aren't used for "any other similar minor (sic) details in articles", because there are no comparable series details (feel free to provide an example if you disagree. Your ad hominem abuse is outrageous and unacceptable. Your coord|name= proposal remains broken, and using it as you propose would not resolve the aforesaid issue. Andy Mabbett | Talk to Andy Mabbett 19:36, 13 August 2007 (UTC)

tools.wikimedia.de/~magnus/geo/geohack.php down

Shall we switch {{coor URL}} to the following:

http://www.nsesoftware.nl/wiki/maps.asp?src={{FULLPAGENAMEE}}params=

It's used by the Dutch Wikipedia. -- User:Docu

Besides those listed on nl:Sjabloon:MapsServer, an alternative would be the one of the GeoTemplate sandbox at:

http://tools.wikimedia.de/~dispenser/maps.php?params=

As the job queue (at Special:Statistics#Site_statistics) is already quite long (2,507,564), editing {{Coor URL}} may not be a good idea for now. The WikiMiniAtlas still works btw. -- User:Docu

This is a good reminder that core functionality such as coordinate links in a prominent place at the top of articles should not rely on the toolserver or any other single server for that matter, but be run on the same servers Wikipedia itself is. What can be done to make that happen? --Para 00:15, 17 September 2007 (UTC)

There is a discussion on Wikipedia:Village_pump_(technical)#Co-ordinate_links_problem as well with even a better solution. I will change it to the URL suggested there for now. -- User:Docu

News from Wikipedia-World

Thanks to all helpers! Now we are supporting over 200.000 articles in Wikipedia-World.

New is the support of thumbnails-previews in Google Earth, see Link or Screenshot. Unfortunally we can't use images from english Wikipedia, the reason is the "fairuse" licences of some pictures. An other new feature is the possibility to show only articles without a photo (Link), so you have a chance to plan your next photo-safari in your surrounding area. --Greetings from Germany and sorry for my bad english. de:Benutzer:Kolossos --12:31, 31 May 2007 (UTC)

Good job! For a more accurate photo safari, free geocoded images from Commons are also available (as opposed to images used in geocoded articles), on Commons:WikiMiniAtlas or the Commons Google Earth layer, but the amount isn't even close to Wikipedia-World yet. You can help on Wikipedia by using the Maybe-Checker, or on Commons by geocoding any good image. --Para 19:08, 31 May 2007 (UTC)


Possible manual geodata errors

See User:The Anome/Possible manually-generated geodata errors for a subset of entries from User:The Anome/Geodata error triage that have been flagged as errors by the KML user community (via the Google Earth Data Problems Compendium page), but have never (as far as my records show) been edited by the Anomebot.

Some of these will already have been fixed, but they should all be checked by hand just in case.

In the meantime, I have been working on further triaging and fixing of the entries in User:The Anome/Possible bot-generated geodata errors, of which I have currently fixed about 80%. -- The Anome 10:39, 4 August 2007 (UTC)


New template: {{geodata-check}}

A new template, {{geodata-check}}, now provides a way of marking pages as having possibly erroneous geodata. Its only effect is to add pages to Category:Pages requiring geodata verification, and to provide a place for putting hint information in its "was" and "suggest" parameters -- it does not make any visible change to the page content.

The intent of this tag is to call for manual supervision. Bot edits should only be made to fix pages listed with this tag if they are very low risk edits, with some form of verification available from an independent data source. I've now tagged all the pages reported as dubious by the Google Earth users' group that I have not personally fixed, either with bot edits, or manually.

Most/many of these are now fixed, but this is a trial run for this mechanism: please remove the tag from pages which can be verified as already correct or have already been fixed, or correct the coordinates if they are incorrect.

This tag is intended to be bot-friendly, and will be integrated into the Anomebot system soon. -- The Anome 09:18, 13 August 2007 (UTC)

It would be good to have a reason or source for the doubt mentioned in the template, with a date of the comparison included. When the bot has a suggestion already, it would also be good if it compared that against the current coordinates. Cairns Central for example was tagged with this template suggesting a fix of coordinates that had been done two months earlier already. --Para 14:21, 27 August 2007 (UTC)

New template: {{geodata-request}}

The experimental template {{geodata-request}} is intended to be used to flag pages that should have geodata, but are not yet tagged with any of the coordinates templates. Unlike the now-deprecated {{LocateMe}} tag, it is intended to be placed in the article body: it does make any visible change to the article, other than adding it to a category. This tag is intended to be bot-friendly, and will be integrated into the Anomebot system soon. -- The Anome 10:22, 13 August 2007 (UTC)

Since when was LocateMe, or other templates in that family, deprecated? Andy Mabbett | Talk to Andy Mabbett 11:09, 13 August 2007 (UTC)
The idea behind this tag is to be discreet, and not to bother regular readers with large banners or boxes in the article. People didn't like {{LocateMe}} being stuck in the article for this reason, so {{LocateMe}} got chopped out of a large number of articles, and put on the talk page instead. In my opinion, putting maintenance tags on talk pages adds an extra level of complexity which I'd rather avoid unless strictly necessary. If we want to put a page in a category, we should put the page into the category. It's easier for bots, and easier for people. -- The Anome 11:12, 13 August 2007 (UTC)
Agreed. Categories should be on articles not talk pages. Having an additional locateme banner on the talk page itself wouldn't be bad, however. --Gmaxwell 20:30, 13 August 2007 (UTC)
There's no reason (other than the dogged insistence of one editor) not to have a discrete template like {{LocateMeText}} on articles; it's no different, to, say, {{ISBN}} or {{listdev}}. Andy Mabbett | Talk to Andy Mabbett 20:38, 13 August 2007 (UTC)
The obvious difference is that {{ISBN}} and {[tl|Expand list}} are referring to visible things which are already in the article. They're asking for improvements to article text. Asking for the addition of something which is not in the text is somewhat different, but for a location-oriented article there is an implied location in the article. This difference should be emphasized in the usage instructions. For non-location-oriented articles the requests for additions should be in the Talk page. (SEWilco 21:24, 13 August 2007 (UTC))
The above phrasing "it does make any visible change to the article, other than" seems contradictory. Does it need correction? (SEWilco 20:33, 13 August 2007 (UTC))


Question about which coordinates system to use

I was wondering which coordinates system between Template:Geolinks-US-streetscale (and the related ones) and Template:Coord (or any others) is the best one to use for tagging stuff? I had been tagging a few things, but I noticed that some stuff is tagged one way and some is tagged the other. (among other ways) Thanks. (Cardsplayer4life 17:08, 18 August 2007 (UTC))

Initially, articles had neither coordinates on one of the top corners nor links to the WikiMiniAtlas. Then the geolink-templates were the easiest way to get to a map. Coordinates could only be added somewhere in the article.
After the {{coor title dm|a1|a2|N/S|b1|b2|E/W|type:landmark_region:US}} was introduced, it was added to the some articles through existing geolink templates.
To add new coordinates, I'd suggest using {{coor title dm|a1|a2|N/S|b1|b2|E/W|type:landmark_region:US}} or one of the similar templates. -- User:Docu
How is that different from {{coord|12|34|N/S|45|33|E/W|type:landmark_region:US|display=title}}? (SEWilco 18:06, 27 August 2007 (UTC))
It uses 6 characters and 7 templates less. -- User:Docu
Definitely. It also makes my head hurt less. (SEWilco 04:37, 28 August 2007 (UTC))

Agreed, the coor title or coord templates are better. The geolinks templates add too much clutter to the "External links" section, their title display format is non-adjustable and IMO not very user friendly, and most importantly, I don't think you are really geocoding an article when using geolinks. Don't think Google Earth recognizes these tags as geocoding anyway. --GregU 05:22, 28 August 2007 (UTC)

In defense of geolinks --- Originally, when Egil made the first version of the geohack server, it used the region parameter and the type parameter to limit which maps to show. When Egil's server died, and the geohack moved over to toolserver, that feature was lost. That's when I became a big fan of geolinks --- geolinks shows a small number of links that are useful to a reader, instead of forcing them to wade through a large list of map for countries that are not relevant. Sadly, since then, the habit of using the region and type parameters has been lost.
I strongly encourage people to use both {{coord}} and geolinks until 1) geohack parses the region and type parameter to remove irrelevant maps, and 2) someone runs a bot over uses of {{coord}} and inserts relevant region and type parameters (this may be difficult). hike395 05:33, 28 August 2007 (UTC)
But you can't use both, as both try to display coordinates in the title area. It might be nice if you could use geolinks in a way that only displays inline, so that use of geolinks does not prevent you from geocoding the article with coor(d). --GregU 13:15, 28 August 2007 (UTC)
What we do in the Mountains wikiproject is use {{coord}} without the display=title parameter in the infobox, to let geolinks display in the title area. If you think this is a bad idea, you could propose a change to {{geolinks-start}} to accept an optional "notitle" parameter, but you would have to touch all of the geolinks templates to call it (and take their own "notitle" parameter. hike395 14:23, 28 August 2007 (UTC)
Yeah, the problem with that is without the display=title, you are no longer effectively geotagging the article. See [2]. The notitle may be a good idea... --GregU 15:51, 28 August 2007 (UTC)
It means that at present Google Earth might not know about all the available information, but the article may contain geotags. Wikipedia can use the coordinates in List of Registered Historic Places in Kings County, New York in several ways, including by Wikipedians going to the locations and getting material for articles. Google might not be recognizing the redlinked locations because there are no geotagged articles, but Wikipedia readers (I think we also include map-oriented users as "readers") and editors can use the coordinates. (SEWilco 19:19, 28 August 2007 (UTC))
Seems to me that Google should parse {{geolinks-start}} in addition to {{coord}} with display=title. The earth.google.com link seems to think that coord is the only form of geotagging, which is not true. hike395 04:10, 29 August 2007 (UTC)
Google must have been mislead somehow, as {{coord}} is neither the main nor the only template for coordinates. In the past, it appears that the FAQ read the Google is parsing them, but practically didn't do so. Possibly this has changed now. -- User:Docu

Coord RfC

There is a request for comment at Template_talk:Coord#Request for Comment to annotate coordinates on Wikipedia for use as a title in map services and microformat readers. As it's related to this wikiproject, opinions would be appreciated. --Para 10:52, 19 August 2007 (UTC)

The RfC has concluded and "|name=" has been added to {{coord}}. (SEWilco 15:33, 4 September 2007 (UTC))

Template:French commune

The users of the {{French commune}} template are enthusiatically adding geodata to articles on French communes. Unfortunately, they're doing it in a way that does not use the geodata templates, and stops my bot from adding its own coordinates. I had a go at fixing this from within the template, but couldn't get it to work. Can someone else have a go at fixing this, please? -- The Anome 15:03, 9 September 2007 (UTC)


The template uses coordinates mainly through one of the following sets of fields:
  1. "lat_long" appears to hold the usual coordinates templates (mainly {{coor dms}}). I fixed a few exceptions.
  2. "latitude", "longitude": in the French version this is a decimal value that renders as a link. In July, [3] the fields mixed DMS format, decimal and combined versions in the same field. To make things work, there are about 1200 articles with fields in text form such as 43° 42' 14" N or 45° 15" N (45.27) that could be converted to the "45.27" format.
  3. "lon-deg", "lon-min", "lon-sec", "lon", "lat-deg", "lat-min", "lat-sec", "lat". This is used in the German wikipedia to generate coordinates. I removed two occurrences present in the July dump.
-- User:Docu

Version 1 should now use {{coor dms}}/{{coor dm}}/{{coor d}} and display a second set of coordinates in the top corner of the page if it's defined. I removed instances of {{coor at dms}} and {{coord}} to avoid conflicts, a few may still exist with geolinks templates. --- User:Docu

Wikipedia use of coord

I found another use within Wikipedia for the geographical coordinate tools. In pages such as Wikipedia:Requested pictures, adding geographical coordinates makes it easier to see if requested items are near you. In the Talk page there someone has inquired about mapping members of a "need" Category, but that's beyond the ability of the present tool. (SEWilco 17:35, 17 September 2007 (UTC))

Good idea, I extended the tool. It uses the database to find category contents and the rarely updated dumps to find the coordinates of the articles. Now what people have to decide is how to put the link on category pages, or if it's sufficient to just mention the tool somewhere and have people copy and paste category names to it. GeoHack has the link already, but most category pages don't have coordinates and putting a dummy one on them wouldn't make much sense. This is the first time I think using a template like {{GeoGroupTemplate}} would actually be justified. --Para 23:56, 17 September 2007 (UTC)

Progress on standardization and other goals?

As I'm relatively new to this project, I'd like to know the progress on this project's goals. It doesn't really seem like {{coord}} is the completely accepted template. My idea would be to show the most used links when you click the coordinates. There would be a little box pops up below them and shows links to them. You wouldn't have to leave the page. There would be a link to show all the links on a different page. Also, when will there be an option in your preferences to select between the decimal and dms form of showing coordinates? Psychless 23:50, 18 September 2007 (UTC)

What do you mean by "most used"? Coordinates for which people use map tools? Some map tools show all the coordinates on a page so the individual coordinates are never clicked on. And for what encyclopedia use is it helpful to know which locations are clicked on? (SEWilco 05:22, 19 September 2007 (UTC))
You misunderstood me. When I said "the most used links", I meant the links that are generated by the Geolinks templates. Psychless 22:57, 19 September 2007 (UTC)
What meaning of "used" are you using? (SEWilco 04:39, 20 September 2007 (UTC))
Are you asking for information to appear in encyclopedia pages about "used" links, or were you asking about how many times each template is being used? (SEWilco 16:31, 20 September 2007 (UTC))
Let me rephrase my idea. Clicking the coordinates takes you to the geohack page which has links to many websites that will give you a map, satellite image, etc. of the place you were reading about. If you use one of the Geolinks templates it gives you links to Google Maps, Map Quest, etc. Most people use those websites for maps and satellite images. With my proposal, the links generated by the geolink template would be in the box. There would be a link that would take you to the geohack server that shows the full list of links. That way, it would be easier to find the link you want without wading through 100 links. It also eliminates the necessity of using {{coord}} or equivalent and geolinks. You would just need to use coord. Psychless 22:04, 20 September 2007 (UTC)
I wrote such a script on Commons once, to add the links to the coordinates box used there: commons:MediaWiki:Geolinks-US-hoodscale.js (for example from this to this). It's opt-in though, but since the WikiMiniAtlas already hooks on coordinate links, we could generalise that and make the Javascript do more. It could for example fetch a heavily cached and pre-parsed version of Template:GeoTemplate. --Para 19:04, 23 September 2007 (UTC)

See also commons:User:Dschwen/coordinates.js which makes finding the coords to use quite easy, paste a google maps URL in, and it sticks a template into the curenntly being edited article. Requires a change to your monobook as currently written but may be useful to thought start things. ++Lar: t/c 20:39, 23 September 2007 (UTC)

Wikipedia London Placemarkers on Google Earth

Whilst I haven't done a very thorough search, it seems that in my part of North London, the only places showing up with placemark links to Wikipedia on Google Earth are those where a co-ordinates template has been manually added. The co-ordinates info seems to be generated through the infobox, but it seems to be done in a way that the Google Earth scrape doesn't recognise. (To see why I think what I think, compare Crouch End with, say Muswell Hill or Harringay). All railway & tube stops seem fine, although their coordinates also seem to be generated through one of the templates. I tried adding the Coordinates template manually, but it seems to overwrite most of the infobox and make it disappear. Anybody know more about this and how to fix it? hjuk 21:53, 25 September 2007 (UTC)

For anyone who's interested, I think the answer may at Template talk:Infobox UK place/Archive 4#Google Earth compatibility: geotags are invisible hjuk 11:34, 26 September 2007 (UTC)

To standardize the infobox, I'd convert it to use "lat_d" and "long_d". -- User:Docu

Tibetan places on the wiki map

Hi I've recently been adding the Tibetan towns and villages to wikipedia complete with coordinates. However the titles of the new villages I have been adding aren't showing on the wiki mini atlas in the globe. If you look at Tibet on the map only the larger places like Lhasa, Dhingri, Shigatse, Golmud etc are showing when it ought to show the titles of smaller places like Alamdo, Azog, Baicang etc and tens of others i have been adding when you zoom in. PLease can you help me because I am trying to draw up a detailed map of Tibet as I add these articles but they are just not registering as places on the map ♦ Sir Blofeld ♦ "Talk"? 09:38, 26 September 2007 (UTC)

On Alamdo, the longitude designation "E" is missing from the coordinate. I see it is being specified in the template parameter, so someone needs to look at the template. (SEWilco 15:53, 26 September 2007 (UTC))
I fixed Lhasa and Alamdo by including {{coor title dm}} and {{coor at dms}}. However, I think we should update {{Geobox Settlement}} to display the coordinates on the top corner of articles. This would avoid adding the coordinates once more. -- User:Docu

UserBox

I think that WP:GEO should have a UserBox. I have no clue how to make one, so if someone else could it would be wonderful. --Nick4404 02:41, 6 October 2007 (UTC)

Formatting problem

Currently, coordinates displayed using the {{coord}} template are being displayed as "52°28′59″N 1°53′37″W": they should surely be displayed as "52° 28′ 59″ N 1° 53′ 37″ W" instead, with spaces between the degrees, minutes, and seconds groups and the compass direction. -- Karada 10:35, 6 October 2007 (UTC)

That's a style issue. I see {{coord}} points out [[Wikipedia:Manual of Style (dates and numbers)#Geographical coordinates]] but that merely says to use a template, without explaining why this format was chosen for the template's display. I think this is a case where the relatively narrow text windows of most browsers places a greater priority on using a narrower format, thus the symbols between numbers are being used as visual separators in place of the more grammatically correct spaces. People who actually made those decisions would have to state the actual reasons (there might be discussion in the old Talk pages here but more likely in MOS, coord, or coor). The reasons for the current design should be mentioned in the MOS. (SEWilco 05:07, 7 October 2007 (UTC))
In the archives of this talk page, there are lenghty discussions about various formats. -- User:Docu

Infobox audit

I've now written some auditing tools for templates, and have been running them on the most recent en: dump. The first result of this process is User:The Anome/Infobox audit, which tries to spot plausible uses of geodata-related parameters in Wikipedia templates, other than those using the standard coordinate templates.

Clearly there is a lot of standardization work to be done. -- The Anome 22:54, 10 October 2007 (UTC)

Geobox mention?

Should the {{Geobox}} family be mentioned on the project page? I haven't found where they are all described. And the template Talk page mentions a box conversion tool which may be of interest. (SEWilco 21:40, 16 October 2007 (UTC))

Google Earth

How come the link at the top is no longer one of a satellite image provided by Google Earth like it used to be? Wikipediarules2221 20:48, 18 October 2007 (UTC)

At the top of what page? (SEWilco 21:09, 18 October 2007 (UTC))

Geolinks: redirect or not?

What about all the Geolinks templates? There are many articles that have coordinates in Geolinks format only. I don't know if there's a way around the people who want to keep the links to map services in the articles, so how about just duplicating the data to a known format? Many of the Geolinks articles already have another coordinate template. --Para 18:42, 23 September 2007 (UTC)
According to Category:Geolinks templates the main page for that group is Wikipedia:Coordinate-referenced map templates. You might rais issues in that Talk page (and tickle past participants). I see that Template talk:Geolinks-start directs people here. (SEWilco 03:08, 24 September 2007 (UTC))
Personally, I'd favor merging the geolinks templates with one of the other templates above (preferably {{coor title d}}). -- User:Docu
Good idea. This seems the active place for discussion but we're not hearing comments. Maybe one or two of the lesser-used geolinks should be converted, with the summary directing comments here. (SEWilco 05:47, 26 September 2007 (UTC))
My opinion: it is a good thing if Geolinks calls {{coord}} with display=title, in order to geotag articles, but please don't delete the Geolinks themselves. hike395 06:12, 26 September 2007 (UTC)
Are you aware that the map links displayed by Geolinks are redundant and minimalist, as clicking on any {{coord}}inate provides a wider selection of mapping tools? Some of those tools are better for certain tasks than are the Geolinks list. (SEWilco 15:29, 26 September 2007 (UTC))
The minimalist solution may be appropriate for some subject matters, but, in general, I think the mapsource list is indeed preferable.
Compared to earlier version, just adding {{coord}} doesn't do that much, it just adds a lot of overhead. Earlier versions of the geolinks templates already displayed coordinates in the top (left) corner. -- User:docu
By "adding coord" do you mean "adding coord to articles" or "adding coord to template Geolinks"? (SEWilco 17:08, 27 September 2007 (UTC))
"adding coord to template Geolinks" hike395 mentioned. -- User:Docu
Indeed, I believe that the minimal obvious list of maps provided by Geolinks is a service to our users. Geolinks shows the most common links that people want: I often want to click directly on topozone for USian articles, rather than having to scroll down thru 2 pages of not-terribly-relevant links on geohack. Again, if geohack parses type and region and filters the list, then I would be much happier and Geolinks can go away at that point (as far as I am concerned). Thanks for listening! hike395 02:48, 28 September 2007 (UTC)
The problem with the minimalist solution is that it's likely to supply the link everyone wants (e.g. Google Maps) and the one you'd want (e.g. Wikimapia), but not everyone else prefers.
As Google Maps is easily accessible on Template:GeoTemplate, there isn't much of a reason to include it on geolinks as well. For the later one, it might just be worth to improve the organization of Template:GeoTemplate. For a quick map, we still have WikiMiniAtlas. -- User:Docu

At Template:Geolinks-US-cityscale/Test, I made a version to update Template:Geolinks-US-cityscale, what do you think of it? Try replacing, e.g. {{Geolinks-US-cityscale|42.027335|-93.631586}} with {{Geolinks-US-cityscale/Test|42.027335|-93.631586}} to test.-- User:Docu

Are the Geolinks no longer supposed to show up in "External links" sections? If so, this should be discussed--the change is going to leave hundreds of empty external links sections and will need cleanup. I'd prefer the links show up. (example: Abert Rim) Katr67 17:03, 10 October 2007 (UTC)
As I understand it, from its inception, coor title d, used on Abert Rim, was designed to "place the coordinates in the upper-right of the article, just below the horizontal rule running under the article's title" - that from the first version of the template. In the case of Abert Rim, seems to me that the external links heading relates to the commons|Abert Rim template, which places a right justified link box. So I'm not convinced that any change has been made which removes inline coordinates (but others may know better). I note that templates such as coord have parameters facilitating the placement of the coordinates inline at the point of the template. --Tagishsimon (talk) 17:18, 10 October 2007 (UTC)
Ooops! Sorry, bad example, I do mean the Geolinks templates. I'll find a better example. Abert Rim's external links section is empty for some other reason... Katr67 17:40, 10 October 2007 (UTC)
I think Abert Rim's External Links is not empty, but the only thing in it is a Commons template. That template is usually placed in External Links. (SEWilco 17:46, 10 October 2007 (UTC))
Yes, I see that now. I tend not to "see" the commons template for some reason. It would be nice to have an option to move it left if the section is otherwise empty. Katr67 17:48, 10 October 2007 (UTC)
Here's one I wrote recently: Bull Run, Oregon. I use Geolinks templates all the time, and I like having the minimalist links at the bottom. I think it helps our readers, as hike365 said above. I think this a major change and it may need to be discussed in a larger venue, it there's an appropriate place for it. Katr67 17:44, 10 October 2007 (UTC)
It's one of the stated goals of this WikiProject to do away with external links to maps ("4. Should be able to have a uniform, extensible way of accessing all types of map resources, avoiding having direct external links to maps in articles")
If the few empty section headers are perceived as a problem, I could go through removing them.
BTW, replacing {{commonscat}} with {{commonscat-inline}} shifts the commons link to the left. -- User:Docu

Thanks for the help with the commonscat. So this change is a done deal? I can't say that I like it, but I sense there's no use fighting it. I still think this should be discussed outside this project, but oh well. There will be more than a few empty headers but if this is indeed irrevocable, then please do take on the cleanup. I'll probably stop using the template, BTW, and let the bots handle coord duties. It was nice while it lasted. Thanks again. Katr67 18:54, 10 October 2007 (UTC)

I see that we have this decision to do away with the links. Could we please temporarily have a reversion to the with-links form, at least for a few days, until the empty section headers are removed? Many thousands of US place articles (enough that would take Docu many days to do, working 24-7) have an external links section with nothing except the mapit template; as someone who watches place articles for vandalism, it's highly confusing because it looks as if someone vandalised the external links. I definitely would appreciate it if someone wrote a bot to go around and remove all of those now-empty sections. Nyttend 00:53, 11 October 2007 (UTC)
I strongly object to removing the links. It may be a stated goal of this project, but other WikiProjects are expecting these links: see, e.g., Wikipedia:WikiProject_Cities/Guideline, where these links are recommended.
This is a large enough change to Wikipedia where it requires more community input: I do not believe that we have achieved consensus --- both Katr67 and I object, and not that many people have been informed. hike395 02:20, 11 October 2007 (UTC)
Let me get this right. A WikiProject can make goals that everyone else has to abide by. Could you point me to some WikiPolicy where it says that, I can't seem to find it under WP:CONSENSUS? If you get the sarcasm, well then here is some more reson why that arguement is tossed and the reversion needs to happen until there is consensus:
Consensus decisions in specific cases are not expected to override consensus on a wider scale very quickly - for instance, a local debate on a Wikiproject does not override the larger consensus behind a policy or guideline. The project cannot decide that for "their" articles, said policy does not apply.
That comes from an actual WikiPolicy, WP:CONSENSUS. You see, otherwise another wikiproject can decide something else, and then another something else, and so on until you have twenty different rules for say a biography about a killer from Chicago, Illinois who went to Columbia University and was a botanist. That's six projects making rules for one article, and that's not how it works. Being bold is one ting, but even WP:BB has a caveat to be less bold when dealing with templates, since they can affect many articles. Aboutmovies 03:29, 11 October 2007 (UTC)
If everyone agrees that we should have them, obviously we should keep them. -- User:Docu
I think we should attempt to come to a consensus: let's have a wide discussion about this. I don't think we should wait for "everyone" to agree --- please please please revert until we reach consensus. It's the WP way. hike395 17:20, 11 October 2007 (UTC)
I agree. Personally, I find it much easier to click directly on a Google Maps link, rather than going first to yet another page, which loads slowly for me here in North America, and is sometimes down. More discussion, please! -- Ken g6 21:54, 12 October 2007 (UTC)

The way coordinates are handled is very different now from when the geolinks/mapit template was first created. The map source page is now on the toolserver (it used to be on kvaleberg). In addition, there is a link to WikiMiniatlas on every coordinate. This is much more than we had when we first added the coordinates with geolinks. -- User:Docu

Several WP probably have standards which were written based upon the technology which was then available, just as Census 1990 might have been defined as a standard source before Census 2000. We should point out the coordinate-embedded map tech to the other WikiProjects. These last two paragraphs should also be split off to a new topic at the bottom of this page so it can be linked to for discussions. (SEWilco 15:10, 11 October 2007 (UTC))
I'll repeat what I've said before. When Egil's original geohack page was made, I was one of the first to argue to ditch the geolinks. But, Egil's page was more functional than the current geohacks page on the tools server. It paid attention to the "region" and "type" parameters, to filter down the list of links to relevant ones and to set the scale of the maps. This functionality is gone.
Right now, you have to wade through pages of irrelevant links to find a relevant map. This is very user unfriendly. Take my own browsing behavior as an example: I love to look at topo maps for geographical locations in the US. If I click thru to the geohacks page, I have to scroll down past pages of links. If I use geolinks, I can immediately go to the topo maps for USian spots, and the scale is set correctly.
My proposed compromise is: if geohacks is modified to do the right thing with "region" and "type" (i.e., if region is given, then show the country-specific maps first, then the worldwide maps), then we can redirect geolinks to point to geohacks.
Thanks for your attention. hike395 17:28, 11 October 2007 (UTC)
P.S. I would also suggest the geolinks never be a true redirect, in order to avoid the empty external links problem. I would recommend keeping it at one line, that says something like
*[http://tools.wikimedia.de/whatever Maps and photos] of {{PAGENAME}} at Wikimedia Tools server
But, you can eventually get rid of the direct links to maps. hike395 17:38, 11 October 2007 (UTC)
Seeing what others have said since my previous comment, I'll note this: I strongly oppose the removal of these links in the first place, and request their restoration. Nyttend 18:01, 11 October 2007 (UTC)
Hike395, I'm not sure if I understand you in relation to "Geolinks-US-cityscale". Prior to conversion, this included "Maps from WikiMapia, Google Maps, Live Search Maps, Yahoo! Maps, or MapQuest Topographic maps from TopoZone or TerraServer-USA"". These are easily accessible on the top of Template:GeoTemplate. Why would you need additional support for regions? -- User:Docu
Docu: Topozone is not easily accessible, it's four pages down, or an additional click. And it's even worse for Switzerland: I was working on Swiss mountain pages for a while, and was looking at a Swiss topo map server a lot: the Swiss topo map link is 9 pages down for me. It seems bad enough to make readers click thru once to the Geotemplate (I can sort of live with that), but twice? Just to avoid implementing regions? Again, it seems reader-unfriendly to me. hike395 18:04, 12 October 2007 (UTC)
The geolinks templates have needed replacing for some time, as part of the general standardization of geodata. I'm prepared to make all the necessary edits using my geodata bot when you've improved the map interface sufficiently: just let me know on my talk page when you're ready. -- The Anome 19:26, 11 October 2007 (UTC)
Type is still taken into account; it affects the scale, which is passed on in one form or another to most of the services listed in GeoTemplate. For the region I just hacked together a proof of concept, by adding section ids to GeoTemplate and a bit of Javascript to GeoHack to shuffle a section to the top based on the region. See for example London or Paris. It will be possible later to guesstimate the region automatically from the coordinates, but that's to be implemented later. Does this solve the concerns with using the more extensive list? --Para 21:05, 11 October 2007 (UTC)
I far as I'm concerned, I would be (mostly) happy with this sort of region-sensitive Geohack. Can we implement this for real before crushing geolinks? hike395 18:04, 12 October 2007 (UTC)
It is now implemented for all coordinate links server-side. Some areas may need the region parameter added to coordinate entry. --Para 21:21, 12 October 2007 (UTC)
See User:The Anome/Geolinks audit for some quick stats on the number of direct uses of each template (NB: does not count indirect uses via other templates). -- The Anome 21:18, 11 October 2007 (UTC)
Counting all pages that use it, Geolinks-US-cityscale is used on 27,000 pages. I just did some major work on US place articles and noticed at thousands of articles (more like tens of thousands) with empty External links sections now that the Geolinks-US-cityscale template was modified. I'd like to see it contain at least one line with a link to a map so as not to break thousands of articles all at once. --CapitalR 04:42, 13 October 2007 (UTC)

Is anything happening with this? I'd like to see a single line in the external links section myself. Meanwhile, they sit there being empty. Can we decide so this can either be reverted or cleaned up? Katr67 22:12, 16 October 2007 (UTC)

There doesn't seem to be much (any?) objection to the template having only a single line: you could put a {{editprotected}} at Template talk:Geolinks-US-cityscale asking a passing admin to change it back to a single line. hike395 03:47, 17 October 2007 (UTC)
Docu interrupted that process last time. Do we have consensus with the "no links whatsoever" people? Katr67 14:17, 17 October 2007 (UTC)
Below I tried to summarize the above. (SEWilco 15:42, 17 October 2007 (UTC))

Data mining infoboxes

As of the most recent article data dump, Wikipedia had 166420 articles containing geodata tags and/or infoboxes with embedded coordinates (infoboxes without parsable coordinates don't count; figures for geotags may differ from those given above because the counting basis is different) Of these 166420:

  • 124200 (74.6%) have just a geotag or geotags
  • 19921 (12.0%) have just an infobox with embedded coordinates
  • 22299 (13.4%) have both a geotag and an infobox

Thus, combining these:

  • 146499 (88%) overall have at least one geotag
  • 42220 (25.4%) overall have at least an infobox

(Last two figures do not sum to 100% because they include the 13.4% overlap from the earlier figures)

Although I believe the Kolossus project takes infoboxes into account, I believe that infoboxes without geotags are not parsed by third-party reusers such as Google. If we were to datamine all the parsable infoboxes in articles that do not yet have a geotag, and convert them to use geotags, we could increase the total number of easily source-code-parsable geotagged articles by 19921, from 146499 to 166420, an increase of 13.5% over the current count.

The effect to external reusers would actually be more noticeable than this, because we should be able in almost all cases to take infobox coordinates as representing the one, true, location of the subject of the article, allowing them to be tagged as "display=title,inline".

However: this is not at easy as it might at first seem, because there are many non-standard infobox formats with different parameters, some with nasty features such as implicit East/West or North/South directions, which will cause simple-minded bot scans to generate bogus coordinates, and many of these templates are themselves misused, and contain garbage or non-standard data.

Getting all of these cases right, with appropriate sanity checking and cross-checking, is going to need to be a lengthy, measured, process; shortcuts will potentially generate large amounts of bad data, which would be counterproductive.

First step: finding all the currently used infobox templates with provisions for coordinates, and categorizing them. Does anyone have a list?

-- The Anome 22:24, 22 September 2007 (UTC)

I think I saw discussion of assorted infoboxes recently, probably in Template talk:coord. (SEWilco 04:25, 24 September 2007 (UTC))
By standardizing infobox fields to the suggested names (lat_d, lat_m, lat_s, lat_NS, long_d, long_m, long_s, long_EW) extraction would be made easier. It may mean adding lat_NS, long_EW if this was implied before. -- User:Docu
I did a quick list once based on the parent category and template names, but the participation in looking them through was discouraging. --Para 16:30, 26 September 2007 (UTC)
As the above names were defined not that long ago, it's likely that we will need to update quite templates to standardize the names.
If there is another set that is used more often, I'd go for that.
-- User:Docu
Also, I've noticed that the Google Earth layer ignores images embedded in infoboxes, instead displaying later images in the article. Fixing this would be a nice aesthetic improvement. --Padraic 00:38, 24 October 2007 (UTC)

Geobox question in VP

A {{Geobox}} question appeared in Village Pump: [4] (SEWilco 17:07, 25 October 2007 (UTC))

Bug report: WikiMiniAtlas/infobox interaction

Here's an interesting bug. Go to Shillong, and take a look at the locator dot on the map in the infobox. Now pop up the WikiMiniAtlas from the title line globe -- even though the WikiMiniAtlas now covers the infobox, the infobox's locator dot remains visible over the WikiMiniAtlas, complete with a popup-on-hover title of "Location of Shillong". This is confusing, and might well lead some readers to mistake the (completely arbitrary) location of the locator dot on the WikiMiniAtlas map for the actual location of Shillong. In the case of Shillong, this is particularly misleading, because the label link for the Shillong article does not appear on the WikiMiniAtlas as the default zoom, and the infobox locator dot is more salient than the translucent red splodge used as default locator by the WikiMiniAtlas.

This can also be seen in other suitably-aligned instances of {{Infobox Indian Jurisdiction}}: for example, see Babina and Jaipur. (Browser info: Firefox 2.0.0.8 running on Debian Etch.)

I don't know if this is specific to {{Infobox Indian Jurisdiction}}, or a symptom of a more widespread bug with locator maps in general: the templates used within that infobox are so intricately nested that I'll have to leave this to someone more expert with debugging WP templates. -- The Anome 09:50, 26 October 2007 (UTC)

Probably someone just cranked up the z-index of the infobox-locator-point unreasonably high (z-index inflation!). That should be corrected in th elocatormap/infobox source. The WikiMiniAtlas uses a z-index of 10 or 20 I think, and there is no reason for a locator point to have a z-index above let's say three. --Dschwen 14:04, 26 October 2007 (UTC)
Oh geez, that was exactly it. The infobox used a z-index of 200! I set it to 2 (and 3 for the dot) and it still works fine. Plus the WMA related bug is gone. --Dschwen 14:13, 26 October 2007 (UTC)

WPcoord

I created Template:WPcoord, rephrase it as appropriate. I avoided WPgeo due to similarity to the Geology project. (SEWilco 15:52, 26 October 2007 (UTC))

Template:Geolocation abandoned

I think Template:Geolocation was unused and is now orphaned and abandoned. Should it be nominated for deletion? (SEWilco 15:39, 26 October 2007 (UTC))

I've nominated it for deletion. -- The Anome 11:58, 27 October 2007 (UTC)

Coordinates for Group, Linear and Area items

Is there any way of tagging an article with coodinates for groups, linear objects or area objects? E.g:

Perhaps these could be investigated for future inclusion? --Ozhiker 19:36, 26 October 2007 (UTC)

This was discussed on the german project, on [[:commons:commons:Geocoding], and on Template:coord before. I'm all for it.... --Dschwen 15:20, 27 October 2007 (UTC)

Coord loc on VP

Someone notes in VP [5] that title coords have moved to a bad place. The reference to Jimbo implies that the reader has the normal fundraising banner visible and a browser window which is 800 pixels wide (a common width). Even without the fundraising banner, the present location above the line puts the coordinates in conflict with article titles. The location below the line was better due to the shorter and smaller text ("From Wikipedia,...") on the left side of the page. I think this same issue is in a template Talk archive, I'm sure I've seen it before. (SEWilco 14:33, 1 November 2007 (UTC))

Oh, I see. The CSS is using absolute positioning of the coordinates. So when the fundraising banner is present, what is on the left depends upon whether the banner is large or small. When the fundraising banner vanishes the header will get smaller and the coordinates will again be below the header horizontal line. (SEWilco 20:12, 1 November 2007 (UTC))

Template lacks

Gentlemen, you lack the following templates:

The user sees {{coor d|24|N|120|E}} and when they click, it's just as if they clicked {{coor d|24.18170479|N|120.86603958|E}}. I.e., a way to set display precision.

The user sees GREAT LOCATION and when they click, it's just as if they clicked {{coor d|24.18170479|N|120.86603958|E}}. I.e., a way to set display title.

Jidanni 01:32, 10 November 2007 (UTC)

For precision see WP:GEO#Precision. Otherwise, shouldn't all coordinates be shown as such? If not, which type of coordinate use needs a more compact presentation? What would be the rule or guideline for the formatting, so that it's not up to single editors? What about printed articles; would the coordinate information just be excluded? If it's that insignificant, should it really be included at all? See also Wikipedia talk:WikiProject Geographical coordinates/archive012#Inline coordinate display and the linked previous discussions. --Para 15:39, 10 November 2007 (UTC)

Coord/GeoHack scale

It looks like GeoHack isn't passing type/scale scaling information to the Google Earth exporting tool. GE keeps presenting a view from the default altitude. (SEWilco (talk) 18:49, 19 November 2007 (UTC))

There are two Google Earth links on that page. The first one is from de:User:Kolossos and doesn't support the scale parameter, so it always uses the tool's default altitude. He has commented before that scale makes no sense when used with a varying amount of pixels, and that the German Wikipedia currently has a mix of scale parameters and dim parameters (where dim is the dimension or diameter of the object in metres). This confusion is probably why the tool doesn't support any scale at all. The second tool a few rows below is mine, and estimates an altitude from the GeoHack scale, while also returning KML links to other resources. The additional links could be a reason enough for people to keep using the first tool instead. --Para (talk) 01:30, 20 November 2007 (UTC)
I'll compare the two URLs when I get past "Unable to connect to the server at tools.wikimedia.de." (SEWilco (talk) 05:22, 20 November 2007 (UTC))
There is a scheduled network downtime announced for tuesday morning on the ts mailinglist. This is probably it. --Dschwen 13:23, 20 November 2007 (UTC)
You're right, the first Google Earth link doesn't know about scaling. (SEWilco (talk) 16:11, 23 November 2007 (UTC))

Can someone help me?

Hi. I'm not sure if that's the right place to ask for help but if anyone here can do the thing with making parts of maps clickable? (like in the first map of the article US State) I'd like the map in the article Constantine Province clickable, with the articles (shown in the section "Adminsitrative divisions") clickable as in the map. Thanks in advance!--escondites 15:30, 23 November 2007 (UTC)

Free maps tool for article maps?

Not long ago someone pointed out that some of the maps being generated by Wikipedia-linked mapping tools could be usable in Wikipedia articles. Issues have arisen in Template talk:Infobox UK place where a map with a red dot marking a location would be helpful. That template is using existing tools, but are there better tools? Does the not-supported-in-en:Wikipedia <geo> extension have this ability? Are there existing free map tools which could be used to create locator maps? Generating maps on demand might have problems; might a tool/bot be able to create maps into Commons (in a reserved namespace perhaps?) which could be used in articles? (SEWilco 16:20, 3 October 2007 (UTC))

Does the toolserver already have a map generator with country outlines, whose maps could be placed under a Commons-compatible license? That would be sufficient for some locator maps. (SEWilco 19:12, 8 October 2007 (UTC))
Note that "Red dot" location maps are already available for many countries at {{location map}}. These can also be called via {{infobox settlement}} and its derivatives. Jheald (talk) 15:22, 24 November 2007 (UTC)

Geotagging software for Linux?

Anybody know the easiest way to geotag photos in Linux (preferably drag and drop on a map instead of manually adding coords). In Windows, I love Picasa+Google Earth, but the Linux version of Picasa doesn't seem to have this feature. --Padraic 16:07, 5 November 2007 (UTC)

There is a Wikipedia tool for Google Earth which shows the current location. Maybe there is a similar tool which shows a text balloon with whatever text has to be pasted in a photo tool...or provides a geotagging URL for Picasa. (SEWilco 06:12, 8 November 2007 (UTC))
Or I can write a similar tool, if there is some sort of URL or text which the server could emit which would be useful in geotagging. I'm not familiar with the Picasa interface, but I think I saw some sort of Picasa web service so can geotagging be done through their web service? (SEWilco 04:57, 12 November 2007 (UTC))
I just noticed that there is an addon for digiKam.[6] [7] (SEWilco (talk) 20:33, 23 November 2007 (UTC))
Thanks for the tip - I will have to try out the digiKam addon. Too bad I can't get Google Earth working in Ubuntu anymore! --Padraic 21:51, 23 November 2007 (UTC)
I think Linux GE needs OpenGL and there is no version for 64-bit Linux. (SEWilco (talk) 16:39, 29 November 2007 (UTC))

Currently used templates

Here is a list of the (approximate) current usage of geodata templates, and some recommendations for standarization. (I've already removed a number of other templates which either had very low usage levels, or were caused by typos.)

Template Number of matches Suggested action
{{coor}} 327 upgrade to {{coord}} now
{{coor URL}} 8 upgrade to {{coord}} ASAP, then delete template upgrade direct use in articles to {{coord}}, no action with template use
{{coor at d}} 346 nothing as yet
{{coor at dm}} 885 nothing as yet
{{coor at dms}} 1275 nothing as yet
{{coor city}} 1 in only 1 article: fixed
{{coor d}} 9152 nothing as yet
{{coor d Antarctic}} 32 used in only 3 articles; upgrade to {{coord}} ASAP, then delete template
{{coor dm}} 18718 nothing as yet
{{coor dm Antarctic}} 12 used in only 2 articles; upgrade to {{coord}} ASAP, then delete template
{{coor dms}} 58874 nothing as yet
{{coor title}} 1 in only 1 article: fixed
{{coor title d}} 8999 nothing as yet
{{coor title dm}} 39046 nothing as yet
{{coor title dms}} 25701 nothing as yet
{{coorHeader}} 2281 upgrade to {{coord}} now
{{coord}} 33820 none
{{coordinates}} 10 no actual geodata uses remain: delete template redirect now

-- The Anome 15:25, 20 September 2007 (UTC)

I changed the above from list format to a sortable table. (SEWilco 16:07, 20 September 2007 (UTC))
The suggested actions sound like good ideas. Replace those little-used variants. (SEWilco 00:25, 23 September 2007 (UTC))
How updated is this? S♦s♦e♦b♦a♦l♦l♦o♦s (Talk to Me) 20:08, 1 December 2007 (UTC)

More discussion moved further down to #Geolinks:_redirect_or_not?

Geolinks-UK-buildingscale borked

{{Geolinks-UK-buildingscale}} is producing the error:

Coordinates: ERROR in {{coord}} invocation. Please see Template:Coord for usage. Arguments supplied as: <snip>

Would someone who knows please fix it. thanks --Tagishsimon (talk) 11:45, 30 November 2007 (UTC)

 Done --Para (talk) 11:54, 30 November 2007 (UTC)
Thanks --Tagishsimon (talk) 11:56, 30 November 2007 (UTC)

CLICK ON COORDINATES

The above proposed one-liner "*Maps and photos of {{PAGENAME}} at {{coord|...|display=inline,title}}" is text which looks awkward in a printed page and doesn't tell the reader CLICK ON THE COORDINATES FOR MAPS. "Maps and photos of Washington Monument at (some numbers)"? Suggestions for phrasing? (SEWilco 15:46, 22 October 2007 (UTC))

  • "* Find {{PAGENAME}} at coordinates {{coord|...|display=inline,title}}. (click for maps)" with the (click for maps) phrase wrapped in <span class="noprint">...</span> so it won't be on the printable version. (SEWilco 15:46, 22 October 2007 (UTC))
  • Same as above but "* PAGENAME is at coordinates..." so as to not order reader to Find it. (SEWilco 15:46, 22 October 2007 (UTC))
  • "* Maps and aerial photos for {{coord|{{{1}}}|{{{2}}}|{{{3|}}}|display=inline,title}}" is the current phrasing used in Template:Geolinks-start. I think the noprint (click for maps) should be added. (SEWilco 20:19, 7 November 2007 (UTC))
  • Comment I think you are not getting any feed back on this because it is confusing. Can you set up some "live" examples so we can better see what these will look like? Katr67 03:05, 13 November 2007 (UTC)

I'll rephrase: The grammar on the proposed phrasing (number 1 below) does not seem quite right. Is there better phrasing? The text is bolded for this example but would not be bolded in articles. (SEWilco 03:50, 13 November 2007 (UTC))

  1. * Maps and photos of Baltimore, Maryland at 39°17′11″N 76°36′54″W. (click for maps)
  2. * Find Baltimore, Maryland at coordinates 39°17′11″N 76°36′54″W. (click for maps)
  3. * Baltimore, Maryland is at coordinates 39°17′11″N 76°36′54″W. (click for maps)
  4. * Maps and aerial photos for 39°17′11″N 76°36′54″W' is the current phrasing used in Template:Geolinks-start. I think the noprint (click for maps) should be added.

For most coordinates templates, the standard span (mouse over) title already reads "Maps, aerial photos, and other data for this location" (see talk). Stating where someone should click is contrary to the concept of wiki (and HTML). In your sample, the following formating should be sufficient:

  1. * Maps and aerial photos for {{coord|39|17|11|N|76|36|54|W|type:city_region:US}}

at least, IMHO. -- User:Docu

For that matter, if we ignore the implied meaning of the hyperlinks we end up with phrases which are not grammatically correct: Maps and photos of Baltimore, Maryland at 39°17′11″N 76°36′54″W. What makes sense is the simple statement of fact: Baltimore, Maryland is at coordinates 39°17′11″N 76°36′54″W. Maybe mention of maps or photos should be wrapped in noprint so it doesn't show up in printed copies; why mention that maps exist of Baltimore? (SEWilco 17:14, 13 November 2007 (UTC))
I like the simple statement of fact: can we proceed with substituting it? This template has been broken for months. (I think substitution with a bot is not a great idea, but it's much better than inaction and deadlock on the status quo). hike395 (talk) 05:16, 29 November 2007 (UTC)
The changes are under way. (SEWilco (talk) 02:07, 30 November 2007 (UTC))
checkY - change made, please take a look & see if this is working as you wanted. SkierRMH (talk) 06:30, 30 November 2007 (UTC)
I, for one, don't like that particular statement. It's not too bad in itself, but it's very similar to a statement frequently present in the Geography section, roughly, "{{PAGENAME}} is located at {{coord...}} (lat, long)". Example. That looks redundant, which is almost as bad as being empty. Even worse, some people had been putting the blank template at the end of the Geography section, which puts the redundant statements right next to each other. Since this template is/was usually in the External Links section, a single link might be better. Would it be possible to make the statement simply "*[(geohack URL) Maps of {{PAGENAME}}]", no coord template, with the whole statement a link to GeoHack? -- Ken g6 04:59, 3 December 2007 (UTC)

ifexist limit issues

Several geo templates are mentioned as broken in the first subsection of Wikipedia:Village_pump_(technical)#.23ifexist_limit -- SEWilco 06:33, 3 December 2007 (UTC)

{{coord}} was mentioned only because its documentation pages use {{Template example row}}, which in turn does up to 10 ifexists per call. I've converted some of the pages to plain wikitext, but either way the limit doesn't change the template's functionality, only the documentation pages. --Para (talk) 20:07, 5 December 2007 (UTC)

Geolinks-coord Issues

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


The Geolinks and {{mapit}} templates display in articles links to a few mapping services, placed in the "External links" section (the preceding are referred to as "Geolinks" below). The recent {{coord}} templates show geographic coordinates in article text and/or on the top of an article, with links to a page with many mapping services. Using both in an article may be redundant.

  • Map service links shown by Geolinks are redundant and fewer than those available by clicking on coord's coordinates.
    • Some people prefer the Geolinks in-article links to map services.
      • Geolinks might not show the map services which a user prefers.
    • Some people prefer to reduce clutter in articles and have all mapping services on a separate page.
    • Having all mapping services on a single page makes finding a service difficult.
      • The page with all mapping services now displays at the top the links for a region when one is specified with a "region" option or found automatically based upon coordinates.
  • {{Geobox}} and other infoboxes are emitting coord-style coordinates which are linked to the page of map services. In this discussion those are discussed as if coord is being used, and alteration of Geolinks is relevant to those pages which have Geolinks.
    • Some infoboxes added coordinate usage after Geolinks already existed on pages which used the infobox, and article editors may not have been aware of the two tools.

Policies and Guidelines

There is a preference for Wikipedia to not be a link directory; it is recognized that sometimes it is useful to have a link to a directory such as DMOZ. That discourages the in-article links which Geolinks emits. The large list shown by coord is a specialized link directory, although a location-oriented service which is also not in the Article space.

It's one of the stated goals of this WikiProject to do away with external links to maps ("4. Should be able to have a uniform, extensible way of accessing all types of map resources, avoiding having direct external links to maps in articles")

Proposals

Geolinks temporary single line

Interim proposal: Change Geolinks to emit a single line. This has been proposed as an immediate change, while the rest of this discussion proceeds.

  • Support - Reduce article clutter and get opinion of more people who notice the change. (SEWilco 15:52, 17 October 2007 (UTC))
  • Support - Katr67 18:17, 17 October 2007 (UTC)
  • Comment - addressing the concerns this is redundant: It would be little work to change the template so it shows something (even revert to the old version if it's too much work to render a single line?) and then change it again to the final version. Meanwhile, we don't know how long this process will take, and the external links sections sit there looking empty and vandalized. Why can't we just act on this while the discussion continues? This has already gone on for a week... Katr67 13:50, 18 October 2007 (UTC)
  • Support - CapitalR 21:51, 17 October 2007 (UTC)
  • Oppose - Why change it twice unless it also says there's a discussion of whether to eliminate this? dm 22:38, 17 October 2007 (UTC)
    • Comment - because the current state has left hundreds or thousands of articles with empty EL sections, and has been in discussion limbo for weeks now. Can we agree to this, at least? hike395 18:42, 21 October 2007 (UTC)
  • Oppose - If we are to replace it anyway, there isn't much use for such a intermediate solution. -- User:Docu
  • Support: The interim solution is a good compromise, while we get more input. I share Katr67's and dm's concern that there is not enough community input. hike395 10:17, 18 October 2007 (UTC)
  • Oppose -- mostly because there little point to changing twice. olderwiser 12:51, 21 October 2007 (UTC)
  • Oppose - this is a really bad way of making a change (re getting more opinions - all you will get is heat - it's a method of making changes which happens too often on Wikipedia and convinces ordinary users that we're not actually interested in what they think). Orderinchaos 22:05, 23 October 2007 (UTC)
  • Strong Oppose - what a stupid suggestion. This template (and the Mapit equivalent) is really useful and does not need to be changed in any way. JRG 05:59, 24 October 2007 (UTC)
  • Support - a discussion may ensue, but it will avoid the appearance of a WP:CABAL. Walter Siegmund (talk) 03:06, 30 October 2007 (UTC)
  • Support one-line-visible fix — Invisible Mapits (which are redirected to Geolinks, remember) are causing layout breakage (empty External links) that even editors fairly familiar with Wikipedia (like me) were not told about. I'm a regular editor and yet I just discovered this accidental-blanking-looking thing just today. Templates and layout that work as expected are far more important than the desire to mass-remove information that does no harm; and apparently, whoever did this "fix" didn't get it right the first time, so let's keep it functioning like it was designed until it's actually decided for good. Add a link in small type about ongoing proposals if you want to see a discussion. --Closeapple 01:57, 5 November 2007 (UTC)

Replace Geolinks with a title coord

Proposed: Replace Geolinks with coord using display=title, so coordinates show on top of the page with link to map services.

  • Support - Reduce article clutter. (SEWilco 15:52, 17 October 2007 (UTC)) And User:Para reminds us of the WP:ISBN focusing of book sources on a separate page. (SEWilco 15:11, 22 October 2007 (UTC))
  • Oppose - Casual users of Wikipedia might not know map resouces are available by clicking coords link. Katr67 22:17, 17 October 2007 (UTC)
  • Oppose - Having both is not a distraction in my book, but making geolinks collapsible rather than in external links is an idea dm 22:38, 17 October 2007 (UTC)
  • Neutral. It may be preferable to keep the redirect to {{coor title d}} (less overhead) and replace the geolinks-templates with a new coordinates template once we have adopted a single one. -- User:Docu
  • Oppose: per Katr67, one line is not that much clutter, and is helpful to casual readers. hike395 10:20, 18 October 2007 (UTC)
  • Oppose -- a little redundancy is not inherently bad. And personally I find the toolserver coordinates page rather daunting to use, even after repeated use -- I can only imagine what it is like for an inexperienced user. olderwiser 12:53, 21 October 2007 (UTC)
  • Oppose per Katr67. The coord page (especially for countries such as Australia which are WAY down the list) is very hard to navigate - I only ever use coord|title when I'm sure almost noone will look for it and really just want to know roughly where it is. Also coord is unconfigurable for size. Orderinchaos 22:07, 23 October 2007 (UTC)
    • Question: Have you clicked on coordinates lately? -- User:Docu
  • Strong Oppose JRG 06:00, 24 October 2007 (UTC)
  • Oppose: per Katr67 and Hike395 Walter Siegmund (talk) 03:09, 30 October 2007 (UTC)

Replace uses of Geolinks with a text and coord

Proposed: Replace Geolinks with a line such as *Maps and photos of {{PAGENAME}} at {{coord|...|display=inline,title}}

Discussion of the phrasing is below in section #CLICK ON COORDINATES.
  • Support - Reduces number of coordinate templates used while preserving a map service link in the external links preferred by some people. --Para 17:57, 17 October 2007 (UTC)
  • Support - Although prefer preceding replacement with coord. (SEWilco 19:10, 17 October 2007 (UTC))
  • Support - Though I don't relish getting used to scrolling through the list to find what I usually use, it's better than not having anything in the external links section at all. Will also be more useful to casual Wikipedia users. Comment - should say "aerial photos". Katr67 22:17, 17 October 2007 (UTC)
  • 'Neutral - If you did this, I'd prefer to make this somehow user configurable, the very long list of mapping services is questionable dm 22:38, 17 October 2007 (UTC)
  • Oppose This just readds redundancy. -- User:Docu
    • Partial Support It's an improvement to the (current) previous versions of the geolinks templates. 5 Dec 2007 -- User:Docu
  • Support - Comment: why replace (i.e., force a subst) Geolinks, rather than have Geolinks emit this? This seems like the best idea: I prefer this to the proposal which keeps geolinks without using {{coord}}. hike395 10:17, 18 October 2007 (UTC)
  • Support (although 'geolink' is a nice name similar to 'geobookmark') --Geonick 22:59, 20 October 2007 (UTC)
  • Oppose, although this is perhaps the least objectionable of the proposals that replace geolinks with coord. olderwiser 12:55, 21 October 2007 (UTC)
  • Oppose The coord page (especially for countries such as Australia which are WAY down the list) is very hard to navigate, and the links which result are unconfigurable - it'll result ultimately in a major reduction in usability for users, and is also inflexible as the size of maps emitted by the toolserver is at the wrong scale for what we use. I'm not against streamlining/improvement of Geolinks-style templates, but this just strikes me as a faulty application of policy to support a minority's point of view which results in an imposition on the majority, who are contributing users and broadly speaking are getting sick of bureaucracy creep on Wikipedia. Orderinchaos 22:13, 23 October 2007 (UTC)
    • Question have you clicked on coordinates lately? If you use it from Australian pages, Australia is all the way on top. -- User:Docu
    • Comment The scale used with the links on the GeoHack page is configurable; unlike with Geolinks, it is not given by choosing among coordinate templates of different scale and location, but by using the single coordinate template that can be used anywhere on Wikipedia and giving it the type and/or scale of the object the coordinates are representing. Normally, only type is needed as it's reflected to many scale parameters used by various services, but in exceptional cases a specific scale can also be given. I think this and the dynamic section placement Docu pointed out solve both of the concerns mentioned. --Para 22:40, 2 November 2007 (UTC)
  • Strong Oppose. JRG 06:01, 24 October 2007 (UTC)
  • Support per Katr67 and Hike395. Walter Siegmund (talk) 03:11, 30 October 2007 (UTC)
  • Support per Para. --Dschwen 03:16, 3 November 2007 (UTC)
  • Strong Oppose. S♦s♦e♦b♦a♦l♦l♦o♦s (Talk to Me) 20:11, 1 December 2007 (UTC)

Replace uses of Geolinks with Template:gnis and coord

Proposed: Replace for US locations, replace Geolinks with {{gnis}} and {{coor title d}}.

  • Support - This avoids having to remove empty ==External links==. -- User:Docu
  • Oppose - Not a bad idea, except that there are many pages that already have GNIS links, and so I worry about a bot accidently leaving 2 in the EL section hike395 10:17, 18 October 2007 (UTC)
    • Comment - Just tell the bot author about your concern. Using existing bot code, I'm aware of two solutions. (SEWilco 18:15, 18 October 2007 (UTC))
  • Oppose - Many locations do not have GNIS entries and the GNIS is redundant with the name, coordinates, and description which should be in the article. (SEWilco 21:13, 18 October 2007 (UTC))
    • Comment - If there is no other external link, this would be a minimal reference for the article. -- User:Docu
      • Comment - Maybe a sweep should be done to add {{gnis}} to relevant articles, but that is a separate issue from coord/Geolinks. Except that existing coordinates in an article could be used by a gnis bot to automatically confirm that the article refers to a GNIS entity. (SEWilco 15:14, 22 October 2007 (UTC))
  • Oppose We're replacing with a deprecated template? Orderinchaos 22:42, 23 October 2007 (UTC)
  • Strong Oppose. JRG 06:02, 24 October 2007 (UTC)

Geolinks single line

Proposed: Have Geolinks emit a single line such as *[http://tools.wikimedia.de/whatever Maps and photos] of {{PAGENAME}} at Wikimedia Tools server as the new display format of Geolinks.

  • Oppose - Does not help consolidating a small set of templates for coordinate entry. --Para 17:57, 17 October 2007 (UTC)
  • Oppose - Redundant when coord's links are available. (SEWilco 19:10, 17 October 2007 (UTC))
  • Oppose - Redundant indeed. -- User:Docu
  • Oppose - if this is my proposal (?), I would withdraw it in favor of emitting a single line with {{coord}} (to address Para's concern) hike395 10:17, 18 October 2007 (UTC)
  • Strong Oppose. JRG 06:02, 24 October 2007 (UTC)

Both Geolinks and top-of-page coord

Proposed: Make Geolinks use coord with display=title, but continue to display in-page Geolinks links to a few map services.

  • Oppose - More clutter than needed in articles. (SEWilco 18:02, 17 October 2007 (UTC))
  • Support - More useful than going through the long list of every mapping service dm 22:38, 17 October 2007 (UTC)
  • Oppose - In general, this just adds clutter. In a few cases, a link to map specific to an article may be suitable, but in general, map links shouldn't be made through Template:GeoTemplate. -- User:Docu
  • Oppose - now that region is a useful parameter, I can live with the geohack list. hike395 10:20, 18 October 2007 (UTC)
  • Support, for the simple reason that the current toolserver pages are quite confusing at present. However, some of the geolinks templates could be trimmed down to be less verbose. If the toolserver pages settle down to a workably user-friendly structure, then perhaps the geolinks templates would be unnecessary -- but until then, no. olderwiser 13:02, 21 October 2007 (UTC)
  • Oppose - Links in articles to general information services can never satisfy all the readers. This is why book sources, which all ISBNs link to, have been centralised on a single page instead of listing the "most popular" services in all articles about books. Map services are no different. Coord provides the link to the centralised list, making additional service links redundant. If the current list is confusing, report what the problem is and propose a list change. --Para 15:17, 21 October 2007 (UTC)
  • Support Isn't this the status quo? Agree with older-wiser on all counts. Orderinchaos 22:08, 23 October 2007 (UTC)
  • Neutral - I don't think there is nothing wrong with the current list, but if this is the status quo then I'm happy to support this. JRG 06:03, 24 October 2007 (UTC)
  • Support - One-click access to the maps I use, rather than having to scroll down to the appropriate section of the general map-links page. —wwoods 14:48, 24 October 2007 (UTC)

Side effect: Remove empty External links

Side effect: If Geolinks no longer emits visible text in an article, a bot should be requested to move it out of the "External links" section and the section headline of an empty section should be deleted.

  • Support - This is a natural consequence of an empty section, just as already happens when links are removed. Someone will request this unless we get a lot of disapprovals of the idea. Others can omit commenting on this side effect unless we get comments to reply to. (SEWilco 15:52, 17 October 2007 (UTC))
  • Support -CapitalR 21:51, 17 October 2007 (UTC)
  • Support unless replacement with {{gnis}} is done. -- User:Docu
  • Support unless some fix is done. Anything to avoid empty EL sections, which makes WP look bad. hike395 10:17, 18 October 2007 (UTC)
  • Support. Alternatively, one could just comment out. -- Ken g6 23:49, 20 October 2007 (UTC)
  • Support. Since there are way too many of these empty links, using a bot may be the bestest of ideas. Aditya(talkcontribs) 15:23, 1 November 2007 (UTC)
  • Support. I actually only became aware of this issue because of the huge number of empty "External Links" sections that suddenly appeared; having a bot handle the cleanup sounds good. Huwmanbeing  21:53, 5 November 2007 (UTC)

Discussion

I tried to summarize the issues above. I suggest cautious editing of items above Proposals. Voting-type feedback in Proposals with comments; readers remember that meanings might change a little if the preceding summary is edited, and try to avoid simply referring to a previous person's comment in case they need to change their comment. (SEWilco 15:42, 17 October 2007 (UTC))

We should invite discussion in affected WikiProjects. I'll invite ones which I find. (SEWilco 15:54, 17 October 2007 (UTC))

  • Comment How do the two single line proposals differ? Can we merge the two? Katr67 17:52, 17 October 2007 (UTC)
    • The Interim proposal is for an immediate change (I'll alter the wording). The second one-line proposal is for it to become the new format for Geolinks. An immediate change seemed to be suggested in previous discussions. (SEWilco 17:57, 17 October 2007 (UTC))
    • I don't see much difference between "Geolinks with a text and coord" "Geolinks single line" because the latter seems like an ambiguous proposal from the discussion where the exact format of the single line was not particularly important. Isn't the concept behind the two point-at-detailed-list suggestions the same? (SEWilco 18:07, 17 October 2007 (UTC))
      • The single line proposal in its current form isn't to replace the geolinks templates, but their contents. That helps only with external link clutter but not with template standardization. The other proposal of replacing with coord and text is for replacing all the uses of the geolinks template with a readable coord text. Currently many articles have an "invisible" display=title at the end, but if people prefer to see a link at the end, the "text and coord" proposal would do that. --Para 18:25, 17 October 2007 (UTC)
  • Someone observed that readers might not know that clicking on coordinates will show map info. Should this information be in Wikipedia:Basic navigation or a related page? (SEWilco 21:20, 18 October 2007 (UTC))
    • If the Geolinks message tells people to click on the coordinates, there will be many articles with that instruction which will teach people about the clickable coordinate links. This reduces the need to increase the size of the instructions for Wikipedia beginners. (SEWilco 15:49, 22 October 2007 (UTC))

Deadlock

There seems to be a deadlock in the discussion of the proposals: if I can make a caricature, most of the people in this WikiProject want to change geolinks, while most of the people outside the WikiProject don't want to change.

How can this be resolved? The current state (doing nothing) isn't a consensus, but an artifact of the protected state of the template, and that most of us are not admins. Is there some compromise that can be reached? hike395 20:03, 27 October 2007 (UTC)

Whatever the answer is, please do something so that people like me don't waste 30 minutes trying to figure out what to do about empty External Links bullets like the one I found in Centralia, Pennsylvania. Jordan Brown 16:19, 28 October 2007 (UTC)
Agreed. This has dragged on for too long. Since there isn't consensus, I suggest reverting the template to its previous version until this is resolved. This may need to be brought up to the whole wiki community to break the deadlock. Katr67 16:34, 28 October 2007 (UTC)
If we follow the commonly used WP:BRD pattern, we should revert to the previous state, and then continue discussion. hike395 17:59, 28 October 2007 (UTC)
This probably shouldn't have been set up as a poll with set choices, it discourages discussion and shows yet again, why Wikipedia is not a democracy. IvoShandor 17:18, 6 November 2007 (UTC)
This was actually set up to try to untangle the many issues in the preceding discussion. (SEWilco 17:21, 6 November 2007 (UTC))

Deadlock broken

There is 7-4 support for #Replace uses of Geolinks with a text and coord (and recent changes to GeoHack might affect a Neutral and Oppose). I'll soon create a request for that change; if you have comments on the currently poor phrasing please discuss at #CLICK ON COORDINATES below. (SEWilco 20:13, 7 November 2007 (UTC))

Question: do you mean to replace all instances of Geolinks with text + coord (using a bot), or make Geolinks emit text + coord ? It wasn't clear to me which we were discussing: I prefer the latter. hike395 03:52, 8 November 2007 (UTC)
I suggest discussing that along with the phrasing at #CLICK ON COORDINATES. Because output formats is the reason templates were created, I was going to initially request changing the geolinks templates to emit the same message. This also reduces difficulties if further changes are needed. Then geolinks can be merged or replaced with text. (SEWilco 06:06, 8 November 2007 (UTC))
Changing the Geolinks templates to emit something different was proposed at #Geolinks single line and #Geolinks temporary single line. The proposal SEWilco mentioned would "replace uses of Geolinks with a text and coord" using a bot. The phrasing is to be discussed. --Para 10:35, 8 November 2007 (UTC)
I claim that the polling, above, confused three issues: the phrasing of the line, whether {{coord}} should be called or not, and whether there should be a geolinks template. I supported #Replace uses of Geolinks with a text and coord because I liked the phrasing and the calling of {{coord}}. I don't see why we have to get rid of geolinks if it simply calls coord: it's a convenience template.
In fact, I would claim that getting rid of geolinks entirely is bad for this project: without a standard template that calls coord, editors may start to drift away from the usage that you want to proscribe. It's much better to enforce uniformity through a template, rather than through guidelines. hike395 05:53, 10 November 2007 (UTC)
Yes, the several topics were entangled and split because that's what the result seemed to be of the discussion. How about starting a new topic only about retaining Geolinks with a one-line phrase? There is time for that discussion because I'll be starting with that change and not initiating Geolinks replacement&deletion until after a reasonable delay. Please comment on the one-line phrasing in #CLICK ON COORDINATES and start a separate section on whether Geolinks should be kept. (SEWilco 06:04, 10 November 2007 (UTC))
Comment: I'm not sure if having several different options is helping here, especially if you're asserting there's consensus. It's confusing and somewhat arbitrary. Perhaps you need to make it a straight poll on whether we should have geolinks, geohack, or both. Plus, 11 people sounds like a really weak population. On a tangent, I've been using the geohack page quite a bit to make sure I understand the opposite point of view. I find the lack of "scale" to be quite annoying. When using geolinks while editing articles, I've been able to pick the appropriate scale for the feature being pinpointed. I'm not sure if there's something I'm missing, but I dont see this feature in geohacks. Why are we trying to kill geolinks again? dm 05:56, 8 November 2007 (UTC)
The consensus is leaning toward replacing Geolinks with a GeoHack-using message. Yes, we haven't gotten many participants but that seems to be those who care of those who found the discussion during mention in a VP, several Projects, and several Templates. There will be time for further reaction between changing of Geolinks and their replacement. I thought I saw a scale option in coord, but I think it's now automatic based on the coordinate precision (number of digits after decimal point). (SEWilco 06:06, 8 November 2007 (UTC))
My point is that I can equally argue that 7-1 oppose #Replace Geolinks with a title coord or that we are 4-4 #Both Geolinks and top-of-page coord. I do not believe the deadlock has been broken and I suspect that the various choices have with good intentions, put us in a spot where no good decision can be made. dm 13:31, 8 November 2007 (UTC)
Yes, people who commented did oppose some options more than others. I haven't compared user names between options, but of these options there is one where there are more supporting comments than opposing. (SEWilco 15:03, 8 November 2007 (UTC))
There seems to be a common misunderstanding that scale wouldn't be supported with GeoHack. GeoHack supports scale: click on any coordinates on Wikipedia, and you'll see the scale at the top of the page, used by services that support a scale. Most coordinates on Wikipedia however do not set a scale explicitly, which might be the source of the misconception, but this doesn't mean that no scale is given at all. Most coordinates use an implied scale, that is, they set the type of the object (see Wikipedia:WikiProject Geographical coordinates#type:T and Template:GeoTemplate/doc#Scaling), which implies its size and thus the scale needed to show it on a map. --Para 10:35, 8 November 2007 (UTC)
Great, thanks for the info. Just for clarity, can someone pls confirm the proposed update to the geolinks template will automatically translate the various scales to the geohacks version so that all of those thousands of edits out there will not have been in vain? Thanks dm 13:31, 8 November 2007 (UTC)
I will be translating the Geolinks parameters in my change requests. The scale parameter will be supported. (SEWilco 15:03, 8 November 2007 (UTC))
Thanks, that would certainly help. Do we have an example that you could point to of how this would look? dm 04:30, 10 November 2007 (UTC)
There are several examples below in the section #CLICK ON COORDINATES, where I am getting no feedback on the phrasing. (SEWilco 05:58, 10 November 2007 (UTC))

Removing empty headers for the template that was already changed seems to have a lot of support as well.

We should probably not take in account "votes" of people that clearly haven't used the mapsource page recently, such as stating "The coord page (especially for countries such as Australia which are WAY down the list) is very hard to navigate". -- User:Docu

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Disenfranchising users because they disagree with you or to try to generate an artificial consensus in favour of your proposal does not conform with any standard of consensus building or good faith. I am rather disturbed at the above comment. I know this has been archived, but I was very busy with work and then on holiday for just over a month so didn't see the end of this discussion. Orderinchaos 12:33, 27 December 2007 (UTC)
I ignored that qualification comment when studying the results of the discussion because in context the criticized comment was not relevant to the results. -- SEWilco (talk) 15:42, 27 December 2007 (UTC)
I recognised that, but I was addressing the fact the comment was made to begin with, and the attitude it betrayed on the part of the user concerned. Orderinchaos 18:34, 27 December 2007 (UTC)

Accuracy of Google vs Yahoo vs Topozone vs MapQuest

I'm new at this, but when I plot coordinates, I find that each vendor points to a slightly different place. For example, I tried to aim the coordinates for Ramona High School (Ramona, California) to a large circular building in the center of the school complex. See {{coord|33|01|36.9|N|116|52|08.8|W|}}. I centered it in Google's satellite view, but off center in the others. Does anybody have any knowledge of which mapping source is the most accurate for the US? Thanks, Project Coordinates (talk) 01:46, 17 November 2007 (UTC)

I tend to use Google Earth first myself, which is the same as Google Maps, and I cross-check with Yahoo and Live Search. I'm not sure if one is consistently more accurate than another. Since they vary you probably shouldn't try to be so precise. I'd just use {{coord|33|01|38|N|116|52|09|W|region:US-CA_type:landmark}} for this school since that is the usual precision for something of this size.
Having said that, there is one way you can get an idea of which source is the most accurate, if there is an airport nearby. The exact coordinates for airport runways are available at AirNav.com (for US airports) or at World Aero Data (for elsewhere in the world). Looking up the Ramona Airport in AirNav and testing those coordinates, it appears that the Google imagery here is about 10 ft too far SE, Yahoo is about 55 ft too far ESE, and Live Search is 12 ft too far west. So in this case at least, Yahoo is the one that is the most off, and Google is a good choice to go with. --GregU (talk) 14:16, 25 November 2007 (UTC)
Thanks! I'm going to change my username now, btw. I don't like it anymore. Project Coordinates (talk) 02:27, 17 December 2007 (UTC)

UK co-ordinate conversions faulty?

I'm not sure if this is the right place to raise this (if not, then please forward this appropriately, someone), but GeoHack's co-ordinate conversions seem to be a little bit off.

For locations in London, maps called via UK National Grid co-ordinates (eg Streetmap, GeoGraph) seem to locate places a couple of hundred metres west and north of where they get indicated on eg Google Maps using degrees, minutes and seconds.

This is somewhat disconcerting when trying to add location co-ordinates. Can we find out where the mismatch is occurring? Jheald (talk) 16:00, 24 November 2007 (UTC)

For example, for Big Ben, without decimals we have {{coord|51|30|02|N|00|07|28|W|type:landmark_scale:3000}}, which WikiMapia places just to the East of the clock tower. Geohack converts this as TQ 30168 79678; but Streetmap, GeoGraph etc show that as the intersection of Bridge Street and Parliament Square, about 200m to the West, and 50m to the North.
Putting N51:30:02 W00:07:28 into Streetmap's own converter [8] gives TQ 30281 79624, which matches the WikiMapia position. This looks like a bug in Geohack. Jheald (talk) 09:04, 25 November 2007 (UTC)
I wonder if this is a datum issue, where one system is using the WGS84 datum to perform conversions, and the other is using OSGB36? Lat/long coordinates in Wikipedia should use WGS84 throughout. -- The Anome (talk) 09:11, 25 November 2007 (UTC)
Both pages say that they're using WGS84 for lat/long. But perhaps GeoHack is actually converting as if from OSGB36? Jheald (talk) 09:57, 25 November 2007 (UTC)
That does indeed look possible. GeoHack's grid conversion is mapping {{coord|51|28|38|N|0|00|00|E|region:GB_scale:2000}} squarely to the centre of the Royal Greenwich Observatory building, when according to Prime Meridian WGS 0° should point to a rubbish basket about 102.5 to the East of the brass strip. The OSGB36 meridian is actually 6m to the west of the brass strip; and according to OSGB36 the transformation most commonly used (eg by Streetfinder?) can add another 7m error. That compares pretty closely with the 113m difference found between the two Eastings for Big Ben. Jheald (talk) 11:24, 25 November 2007 (UTC)
Just for completeness: GeoHack is translating that lat/long to TQ 38875 77313. The Ordnance Survey "gold standard" converter [9] says TQ 38987 77259. And Streetmap's converter says TQ 38989 77258. Jheald (talk) 11:48, 25 November 2007 (UTC)
I have been working to produce my own tool to convert Grid to WGS84 see OS to Wiki Templates (WGS84) Toolfor a Beta version. It was to put inlines into a page en:River Bourne. The maths is complete- I am tweaking the UI. Indeed I have a discrepancy but have not analysed it- gut feeling suggests it could be 113m too. As I used Roger Haworth's Javascript code for the clever bits- could it be that there has been a typo introduced into that or Fishers c code? ClemRutter (talk) 18:19, 25 November 2007 (UTC)
Note that the 113m is correct for London, but the discrepancy varies with longitude (as one would expect for an WGS84-OSGB36 difference). So for a point near Lands End, {{coord|50|4|7|N|5|42|58|W|region:GB_scale:20000}} translates to SW 34114 25409 according to GeoHack, SW 34177 25338 according to StreetMap, and SW 34182 25340 according to the Ordnance Survey -- i.e. an East-West error of only 63m. -- Jheald (talk) 19:05, 25 November 2007 (UTC)
I've had a quick look at the Fisher convert.c code, and I think you're right: it looks like it converts from the Grid coordinates to OSGB36 using the Airy 1830 ellipsoid . But there's no way it converts to WGS84 -- there's nothing in there to define the WGS84 ellipsoid. Jheald (talk) 19:56, 25 November 2007 (UTC)
The file that will need to be fixed is geo/transmercator.php [10]. As surmised, it has a routine to convert from OSGB36 lat/long -> OSGB grid coordinates; but no routine to convert from WGS84 lat/long to OSGB36 lat/long. Somebody should also verify whether there is a similar problem for the Swiss co-ordinate system, which uses the CH1903 ellipsoid.

Bug filed on JIRA: [11]. Jheald (talk) 14:56, 29 November 2007 (UTC)

There's GPL'd PHP code that can be spliced in to do the conversion here [12] (also Java and Javascript translations). Other implementations, but in Javascript, can be found here [13] and, with explanation, here [14].
Template {{oscoor}} has a similar issue - it's converting to OSGB36 lat/longs, not WGS84 ones (see here). This code may have been used to convert a number of UK national grid references to lat/longs -- if so, they are all going to be slightly wrong. Jheald (talk) 14:06, 26 November 2007 (UTC) However, conversions done automatically by The Anomebot2 are apparently correct. Jheald (talk) 14:23, 26 November 2007 (UTC)
Thanks for that! I rather hoped that was the case. -- The Anome (talk) 18:40, 28 November 2007 (UTC)
For what it's worth, I raised this issue with RHaworth, whose external site performs the (faulty) gridref-to-latlong conversions, back in March, but he hasn't done anything about it yet. See User talk:RHaworth/Archive to 2007 April#OSGB36 and WGS84. I use http://www.nearby.org.uk/ whenever I need to do a manual conversion in either direction; I don't rely on Wikipedia's own conversions. --Dr Greg (talk) 18:07, 26 November 2007 (UTC)
I have posted a copy of the conversion code I used to do the earlier National Grid --> lat/long conversions, at User:The Anome/lat-long.py, which I hope performs a reasonable conversion from both OSGB and Ordnance Survey Ireland grid refs to WGS 84 lat/long. It's in Python, and was (mostly) auto-converted from some GPL'd code written in PHP, by a variety of earlier authors: see the original comments within the source file for its origin, and the original authors. I've done a few bits of manual cleanup to the overall program flow, but the maths is pretty much verbatim.
If anyone wants to use it, could they please spot-check a few locations, just to check that it works OK? -- The Anome (talk) 18:59, 28 November 2007 (UTC)
I've just checked Colchester Castle, which was one of your conversions, and your numbers exactly match Streetmap's conversion [15].
BTW. There's another wrinkle in {{oscoor}} -- it's adding 50m to the Easting and the Northing of a 6-figure gridref when it passes the data on to GeoHack (ie it's assuming the Gridref is indicating a 100m x 100m square to its north and east, and giving the centre of that, as if somebody has got the gridref by doing a floor rather than a round . I am not sure that is correct -- I don't think as a rule people do go to the south and west when they give map references; so I don't think {{oscoor}} should be adding those extra 50m. Streetmap doesn't, when it's doing conversions. Jheald (talk) 14:49, 29 November 2007 (UTC)
Thats not a bug- its a feature!. Wikipedia convention is to tag or reference or mark the centre of a map not the left bottom corner. The code I have been examining tags the centre of the TQ 675 123 square, not the left hand corner! So we have TQ 6755 1235! I havent had time to examine Anome s Python code other to see it is very clear and well written and should be very easy to convert into Javascript and retrofit into my code and RHaworth code. Give me a couple of days. —Preceding unsigned comment added by ClemRutter (talkcontribs) 15:23, 29 November 2007 (UTC)
ClemRutter (talk) 15:37, 29 November 2007 (UTC)
I think that's wrong. If WP has a grid reference, the map should show where that grid reference is. We don't know whether the grid reference cited was meant to indicate the gridline intersection to the bottom left of an object on the map (which is what you're assuming). It could equally well have been chosen to indicate the nearest gridline intersection. We should just convert the number. Jheald (talk) 15:42, 29 November 2007 (UTC)
Note also that there are three versions of code already in Javascript linked to above for the datum change, [16], [17], [18] (documentation). Wouldn't it be easier to start with one of those? Jheald (talk) 16:06, 29 November 2007 (UTC)
Many questions.I am trying to locate the errors, and to do it I have written a bit a code to do a fixed job. In doing so I now am suspicious of every piece of code- including my own. It is a design decision that every programmer must make as to what OSGB36 point the four, six, or eight figure refs refer to. Each is valid, it is a POV as to which one to choose, whether you floor it, round it or average it. In my tool, designed to provide a inline reference to go alongside a 6fig GridRef transcribed from 1950s reprints of 1930s reference book that had references in the form '5 furlongs NNE of the church'. When the original reference was calculated that way, it seems reasonable to use the 'average'. Personally I prefer 'floor'. There is no definitive 'number'. We are left with two approaches to these numbers.
  1. Identify the error, and patch a correction.
  2. Identify size of the error (in each case) and post process a further filter, to pull the erroneous WGS back to actual by a simple transformation using an array of constants fixed to each letter square!
ClemRutter 13:21, 30 November 2007 (UTC)
Request for control points to use as test data
Does anyone have the precise grid references, and WGS84 coordinates of a set of control points to act as testdata for the various calculations floating around. All the texts are clear that latitude and longitude can only be expressed within a margin of error, and change with height and time, so the best we can achieve is to define accuracy of each method with reference to a control point. This will apply to our method of data collection, and chosen method of data display. ClemRutter (talk) 11:26, 17 December 2007 (UTC)
I suggest we use the StreetMap conversions as our target. They are well defined mathematically, easy to check against, and correspond to within ~7 metres with the (distorted) historical grid defined by the 1938-1966 surveying. Jheald (talk) 12:09, 17 December 2007 (UTC)

Map link conversion to coordinates

There's currently a huge number of direct map service links on Wikipedia because that's the format easiest for people to add. They are used in prose as linked place names, numbered external links, external links named after the service, and in the references and external links sections. This kind of linking is hardly ever justifiable, as similar information is often available from many other services, and most services don't allow the user to request data from a specific date. If the contents of the link may change at any time, the only reason to continue linking to that service is if the section is about that particular service, like maybe in Satellite map images with missing or unclear data. All other direct map service links should be converted to coordinates, but it can not be done with a bot as the usage is so diverse.

I have put together a simple tool that gives a random set of such links from the database: maplinks-report. Would be good if people could convert a few every now and then; there are thousands. With some obscure links this may introduce unwanted sets of numbers in prose, which will perhaps also revive the inline coordinate display discussion. --Para (talk) 04:20, 15 December 2007 (UTC)

I have taken a look at several of the maplink reports. But how do you suggest that one can start. All seem to need the co-ords added to the infobox- but that is missing too. Often the article is one of a massive group, and they all need doing. Or are you suggesting that the link, usually in External Links, should just be converted to standard format, if so which? But couldn't that be done automatically? I've never written a bot so wouldn't know how to start?

ClemRutter (talk) 10:40, 17 December 2007 (UTC)

Based on the links I've converted so far, the use is so varying that they can't all be converted with a bot. You could however write a bot to convert a single subset. Articles with a map service link and no coordinates would probably be easiest, when the link is found in the external links section and the coordinates in the possibly many links match. In that case the link can just be converted to title coordinates, and someone can later move them to an infobox if necessary. Most bots run with the pywikipediabot framework, but AWB could be a big help already. Data can be found from Special:Linksearch or my maplinks-report tool. --Para (talk) 21:37, 27 December 2007 (UTC)

Problem with format of coordinates templates on page

I don't know if this has been raised before, if so I couldn't find it, apologies. The templates Template:Coord, Template:Coor_title_dm, [[Template:Coor_title_dms, Template:Coor at d, Template:Coor at dm and Template:Coor at dms all place the link at the top right of pages and it overlaps the XX,XXX have donated link/s. I suspect at at higher screen res than mine (1024x768) its OK but going lower only makes the problem worse. I'm not sure if fixing this is in the scope of this project or whether it needs to go higher, but it certainly needs fixing. Talltim (talk) 17:51, 30 December 2007 (UTC)

It was mentioned when the fundraising advertising appeared. You're still seeing that behavior because no good solution has been found. -- SEWilco (talk) 16:31, 31 December 2007 (UTC)
Which browser version do you use? (If you're not sure - click Help -> About in the top bar of your browser) Orderinchaos 20:32, 5 January 2008 (UTC)

Geolinks/mapit changes

The Geolinks and mapit changes discussed above are being made. (SEWilco (talk) 02:49, 30 November 2007 (UTC))

Issues:

All uses are now converted to the "statement of fact" format. Most articles had the OSGB reference in the infobox already, but some stubs had it hidden inside a map service link without being shown, so I added {{oscoor}} to those. --Para (talk) 12:27, 30 November 2007 (UTC)
Seems to be an external equivalent of GeoHack, with the added feature to see a service list for nearby landmarks as well. It's already listed in GeoTemplate and doesn't need to be advertised in articles, so we can remove it from articles that have coordinates already, or replace it with coord when there's no other coordinates. --Para 03:49, 1 December 2007 (UTC)
Orphaned. --Para (talk) 21:03, 5 December 2007 (UTC)
This will be easy to convert to use coord directly, when a bot replaces all the uses as noted below. --Para 03:49, 1 December 2007 (UTC)
The linked service is listed in GeoTemplate (#4 in the US section!), but GeoHack doesn't support the format of the scale parameter. Their documentation says that they need the wid parameter to be the width of the map coverage in degrees, so we'll have to add such a scale-derived parameter to GeoHack for this service to work correctly. What would be an appropriate estimate? --Para 03:49, 1 December 2007 (UTC)
  • {{Geolinks-US-river}} - Special template that takes two named coordinates: the beginning and end of a river. Some of the articles have an infobox with the same information. Should probably be converted to two external links of the statement of fact style, with (mouth/source) at the end. --Para 05:36, 1 December 2007 (UTC)
Done. The articles using this template pass linked article names within parentheses, so the bot run will have to take that into account to use the plain names as a coord parameter. --Para (talk) 03:50, 15 December 2007 (UTC)

Several requests are awaiting administrator action. When the changes are done someone might want to check which templates can be merged, as many of the templates which specify a region might no longer be needed due to automatic region detection. (SEWilco (talk) 04:35, 30 November 2007 (UTC))

The modifications have now been done. People who haven't in the last two months seen any of the notifications of the planned change will now have a chance to comment. If we continue to have consensus and can go by #Replace uses of Geolinks with a text and coord, a bot can substitute the uses of all the coordinate templates in External links sections to the "statement of fact" format with coord. Then Wikipedia's coordinates will be easily available for Google Earth and the like. --Para 03:49, 1 December 2007 (UTC)
As I stated above, I don't like the current setup because the current statement is very similar to a statement in the Geography section of most cities/towns/villages/etc. One way to fix this is to change the statement. Another way would be for the bot replacement to merge the two statements. I've done this for Peetz, Colorado (diff) as a first example. My questions are:
  1. Does the community like this?
  2. Is it at least acceptable enough for me to keep doing it manually?
-- Ken g6 (talk) 04:28, 8 December 2007 (UTC)
It adds a bit of inconsistency. At the moment there's three places in location related articles where the coordinates can be found with some certainty: title area, infobox, external links, in that order. Some articles may have them hidden somewhere in the text, but without reading a few sentences around them you won't even know if they're for the whole article or for some small detail related to it. How many articles out of all location related ones have a Geography section, is its placement predictable, and does it contain something else than the data from the infobox in a list like manner? Also, the duplication of coordinates in different formats isn't really necessary. The Coord template creates some hidden blocks with coordinates in the other format, which readers can control with css rules. Now, I'm not against moving coordinates out from external links, but I don't think the Geography section is much better. --Para (talk) 23:48, 8 December 2007 (UTC)
The last step of the requested conversion, substitution of the templates, so the coord template will be recognized by search engines, will begin after the start of the calendar year. -- SEWilco (talk) 15:19, 20 December 2007 (UTC)
  • Note to project of similar templates that should be handled: Template:WikiMapia 1078 uses, all the articles have at least one coordinate template already, should be removed from articles in the bot run and then deleted. Template:OnGoogleEarth no uses, for deletion. --Para (talk) 19:58, 9 January 2008 (UTC)
  • Some old geolinks template seems to have been subst'd all over, and will be more difficult to replace. Articles where it has been used should be easy to find though, as it links to a rarely used hostname. See links to virtualearth.msn.com for a list: there are currently 664 articles with the substed template. --Para (talk) 00:06, 21 January 2008 (UTC)

No concensus on Geolinks changes

I have finally found a place to comment on the changes that have been done to a template I have been looking after for two or three years now: {{geolinks-cityscale}}. This was originally developed (by myself) to insert links to Google Maps and its equivalents. Less than thirty people seem to have had a discussion above and reached a 7:4 vote. Changes have therefore been made. I didn't have a vote. If I had, I just needed to find 5 friends to change this vote the other way. This is not democracy...

There is a reason to use geolinks-cityscale. If people want a quick link to maps of an area, they click a link. Map nerds can instead access geohack and have hundreds of options. The "compromise" reached is that the convenience of "one-click" mapping has been removed and the user has to look at a confusing list of hundreds of links. I have been busy for years adding this template to pages, dilegently finding co-ordinates to find that this month it has been completely undone. Not everybody is interested in maps. Most users of the Wikipedia want information.

So what is the problem that this change has fixed?

  • One click mapping has become two click mapping
  • A simple list has become a myriad of options.

I think people who are overwhelmingly interested in maps (or perhaps "order") have put themselves in control. If it ain't broke, why fix it?

I have reverted cityscale. It breaks my heart to see all my good work undone. --Scotthatton (talk) 14:14, 20 December 2007 (UTC)

There is a quick link to a map. Click on the globe icon next to the coordinates. There are practical needs for a time limit on voting; if you don't show up to vote during Election Day your vote cannot be processed. -- SEWilco (talk) 15:01, 20 December 2007 (UTC)
Isn't the Wikipedia supposed to be democratic? How can so few self-appointed people decide on changes that affect so many? I can't think of another walk in life where this would be so. --Scotthatton (talk) 15:04, 20 December 2007 (UTC)
Someone had to decide, and the current decision is not my favorite either (as you can see from my above proposals). You're insisting that your one voice should override what several have decided. What is your definition of a democracy? We also can't hear those who don't speak during the long discussion period. The reasons given for the decisions are above. -- SEWilco (talk) 15:13, 20 December 2007 (UTC)
I am not saying my voice is more important. Of course I don't agree with it but that's life. I am very distressed that people started to implement changes. If there was no concensus, why isn't the status quo the default condition? In my company, everybody affected by a change is brought into a discussion. Nobody could have put more work into this than I and I feel it's been destroyed for no real reason. --Scotthatton (talk) 15:24, 20 December 2007 (UTC)
The coordinate information is what is being preserved, it is being placed in a different wrapper. We've all spent many hours tending various coordinate items (a few weeks ago I checked a set of government coordinates and sent corrections to that government agency as a side effect of adding them to Wikipedia). -- SEWilco (talk) 15:37, 20 December 2007 (UTC)
I'm sorry if my remarks have seemed directed against people in particular. They are not. I still cannot see what problem has been fixed by making these changes to cityscale and I feel disenfranchised. It's been an abstract discussion which cityscale has ended up being part of because it used coord. Nevertheless, as a result, an extra step has been added for a normal Wikipedia user who cares not for how useful it will be for Google Earth coordinate systems etc. I like maps as well but most people just want convenience. This is a backwards step. If I made any further revert back people can now say "Look - here it is being discussed and you missed the bus". So what my opinion is now counts for nothing. Absolutely and completely nothing. That is very depressing. --Scotthatton (talk) 16:21, 20 December 2007 (UTC)
The GeoHack mess is similar to the ISBN problem: given a book/location identifier, how does one help users with many needs to find a useful resource? There will be continuing discussions about improving the tools in various ways, as all this is being developed. The globe icon's map isn't my favorite presentation either, but Wikipedia's map support is still evolving. A User Preference for map presentation would be nice (someone let me know if there's a Bugzilla to vote for), but maybe that is in the Mediawiki gis extension which has not been installed here in en.wikipedia. Indeed, I suspect it is most likely the geo software will be added after these location templates settle into similar and stable conditions. My favorite recent improvement to the map interfaces was to have the proper region's services pop to the top of the GeoHack page, although I haven't been using it much due to always hunting down the Google Earth options. Not that that interface is the best yet either. -- SEWilco (talk) 16:56, 20 December 2007 (UTC)

Scott, I share your frustration, but you have heard the expression Wikipedia is not a Democracy? Katr67 (talk) 18:33, 20 December 2007 (UTC)

You should look at the "vote" more as a list of points for or against the proposals instead of counting people. The selection of map services is very much a reader choice, and though the people who have maintained the geolinks templates have done a good job, the editor chosen short list of links can never serve the entire world. Except with very specialized services, map links in articles are not information about the articles' topics, whereas coordinates are. Perhaps we should work on making this clear on Wikipedia:External links and maybe guide people who add direct map links without using any templates at all? Anyway, to get the selection more to the direction of the reader, on Commons there was a request for configurable map links, so I wrote Google Maps Love.js to add a Google icon next to the globe icon. Something similar could be made here to add a set of links to External links or popups. --Para (talk) 20:00, 20 December 2007 (UTC)

The selection of map services is indeed very much a reader choice. Just a long as a link is made to Geohack, coordinates for use by KML files etc. people should not be forced along a particular path. We might decide that the Netherlands deserves "one-click" map links different from Alabama. Geohack has its place but not as the first choice for all users. Indeed more discussion needs to be done but first of all, I want the old cityscale back. And the freedom to put it back. Katr67's link is very interesting. And thanks Para for the javascript ideas. --Scotthatton (talk) 23:10, 20 December 2007 (UTC)
Most readers who want to know where a place is really don't care which g'dam map they see (WP:OR). What they want when they click on a link that says "map here" - is a MAP! Until there is a single non-commercial map we can link to then let each editor decide for themselves. And if you change one of my location links to a link to a page of gobbledeegook don't get too surprised if you are reverted. Sarah777 (talk) 20:49, 15 January 2008 (UTC)
You're in luck: All Wikipedia pages with coordinates already link to a single non-commercial map, the WikiMiniAtlas. Try clicking on the globe icon next to any coordinates to open the map. Unfortunately we can't have instructive messages in articles to point readers towards map services, as they would belong to the user interface and are not information about the topic of the article. For the case when a user is not happy with our maps and wants to use external ones, what should we do to make the list of available services more usable? --Para (talk) 04:42, 16 January 2008 (UTC)

Geolinks-cityscale

Note: A similar discussion is at Template talk:Mapit-AUS-suburbscale#Moving forward. -- SEWilco (talk) 15:50, 28 December 2007 (UTC)

This proposal notes the following:-

  • Following a discussion in October and November, Geolinks and the templates such as geolinks-cityscale using it, were changed to emit a single line
  • Geolinks now outputs the latitude and longitude of a place in the top right of an article and also at the position of the template in the article
  • Geolinks outputs a format usable by third party software such as Google Earth

This proposal recognises the following:-

  • The Wikipedia's aim is to be an easy-to-use source of information to its readers
  • Geohack in its current form is of interest to people who wish to see multiple map sources
  • The recent change to Geolinks means that users uninterested in mapping options are two clicks away from seeing links to maps, may wish to easily find a map of a place, are generally not aware that clicking a coordinate brings them to a page of mapping options and lastly may not require so many mapping options
  • The discussion in October/November came to a inconclusive decision which made changes to the status quo
  • Discussions here are made by people who have a keen interest in mapping and may be not representative of general users.

This proposal suggests the following:-

  • Until Geohack matures into a easier-to-use, maybe inline version (discussions have been progressing at Geohack [citation needed] on this subject), no changes should have been made which force its use.
  • A solution needs to be found which offers links to mapping on the article page.

This proposal concludes the following:-

  • There are multiple needs. Users who want easy links to maps and users who want further mapping options.
  • Recent changes to geolinks serve the second community but not the first
  • Geolinks-cityscale served both communities before the recent changes
  • Geolinks-cityscale should have direct mapping links restored while not affecting the links to Geohack nor compromising third party uses such as that by KML/Google Earth
  • Geolinks-cityscale has been well-looked after since its inception and has no known issues with missing data

Interim proposal: The geolinks-cityscale template has the direct mapping links it had before the November change restored until Geohack or an equivalent product matures further.

  • Support - As the (biased) originator of geolinks-cityscale, recent changes have lessened the usefulness of the Wikipedia. I am only proposing this change for cityscale. Hence if links are restored to this alone, a useful comparison can be made down the line to other templates still emitting a single line. --Scotthatton (talk) 12:25, 24 December 2007 (UTC)
  • Oppose - The above is incorrect. Single-click map is available by clicking on the globe icon. That is the major issue specified above (and no link to a progressing Geohack discussion is provided). -- SEWilco (talk) 18:07, 26 December 2007 (UTC)
  • Support - Previous consensus-building process was flawed (it did not in fact come to a consensus, and 11 users is not a basis on which to enact such a wide-reaching change) and failed to recognise wider user/community needs, focussing on narrow development/standardisation goals. We now have users running off and doing their own thing as a direct result of the imposition of the last one, which cannot be a good thing. This is what happens when Wikipedia's processes for doing things cooperatively are abandoned in favour of totalitarian if mechanically efficient solutions. Nobody was ever able to highlight any problems with the existing system, and through careful management, linkspam was avoided. Orderinchaos 18:30, 27 December 2007 (UTC)
  • Support. Paraphrasing what I said at Template talk:Mapit-AUS-suburbscale, what we do here should be done for the convenience of readers, ahead of the preferences of User:s or developers - if I was a first-time reader, which of the following would best *inform me* where I can find map information?
or
  • Maps and aerial photos
  • Street map from Street Directory, Google Maps and Multimap.
  • Satellite image from Google Maps and WikiMapia.
  • Topographic and bathymetric map from Bonzle Digital Atlas of Australia. --Melburnian (talk) 09:17, 28 December 2007 (UTC)
  • Oppose. Clutter. Why should we sponsor certain map services and not others? What about Mapquest, Yahoo, Map24, etc.? Furthermore putting a verbose list of geocoding links in the article gives it too much space. It's usefull yes, but keep it in proportion please. --Dschwen 12:36, 28 December 2007 (UTC)
  • Oppose - Wikipedia offers information, and for external map service links to be information about the topic of the article, the chosen links would have to reflect the quality of the services' imagery for that location. The assumption that a single editor chosen set of map services could ever serve all cities around the world is however severely flawed: some areas are better covered by some services than others, but those services don't always have better coverage than the others, so linking to the selected services isn't information about the topics of the articles at all, but linkspam. If we had a structure in place to allow users to evaluate the quality of each map service per article or even just on city scale, and then be able to link to the top services on the dynamic list from each article, then those links could perhaps be offered in articles. But since we don't, and such a quality indicator would depend on quite a few factors anyway, making it close to impossible to implement, the only solution is to list them all and the place for that is obviously outside article space. Therefore no solution needs to be found to offer redundant mapping links in articles directly. Also an objection to the conclusions of the proposal: the coordinate template the articles will soon use directly is currently the only recognised uniform way to enter coordinates in Wikipedia. The geolinks templates are not and cannot be made uniform, so they do not serve the alleged second community of people who are not content with links chosen by a handful of editors, but want to see the whole of Wikipedia coordinate information in other services such as the WikiMiniAtlas, Google Earth, or any other service not included in the geolinks list. Coordinate template standardisation serves the entire Wikipedia community, making coordinate entry the same no matter what region the location is in or what its scale is.
    Since the people opposing the #Replace uses of Geolinks with a text and coord proposal either had no reasoning or weren't up to date with the recent page navigation developments on the map sources page, the change has been implemented partially, pending a bot subst run. The dislike of Wikimedia's own mapping service or change from one to two mouse clicks for the rest is hardly reason enough not to go on with the change. --Para (talk) 21:43, 28 December 2007 (UTC)
    As a slightly vision impaired person, I do find geohack unreasonably difficult to use - just way too much distraction. So it's not just an issue of "one or two mouse clicks", it's an issue of usability - and that's even with the changes that were made recently to it. Orderinchaos 04:12, 29 December 2007 (UTC)
    Okay, that point hasn't been made before, let's work on improving the usability. A few months ago there wasn't input from many people at Template talk:GeoTemplate#Redesign.3F, but perhaps now we can look at it again: what can be done to have the page less distracting, while keeping all the services? My proposals at the time were a list with icons or the same in columns. (If people do have ideas on improving the GeoTemplate, let's discuss it at its own topic somewhere, rather than related to this proposal.) --Para (talk) 14:18, 29 December 2007 (UTC)
  • Support - Exceedingly glad I found this discussion - I was wondering where the links had gone. I want to find links to maps easily. Why are people so opposed to Google Maps? It's by far the best way to find where a location is. If it's the best external site to Wikipedia, why remove links to it? Or is it a prejudice against "comercial" sites. If so, the Wikipedia is full of links to external sites. --Faylawnsett (talk) 12:37, 30 December 2007 (UTC)

Note: User registered on Wikipedia 23h before posting the comment.

On what criteria would that be the best map service all the 300,000 Wikipedia articles with coordinates should link to? What about the other services listed in the geolinks templates, are they also the best? Is that criteria generalisable to the needs of all or even most of our readers? We need to be consistent on our linking to map services, and so far there's been no reason for Wikipedia to promote one commercial service over the others. --Para (talk) 14:32, 30 December 2007 (UTC)
As an editor, I am trying very hard to understand this debate, I a feel I have a duty to put forward an opinion. I use Google Maps with a passion- but for UK editing I choose Magic maps because of their superior scale, representation of watercourses, mapping detail and overlays such as SSSI's. I don't want to lose that. Can someone give me a list of example page where these templates are used. Are we talking about Geolink-UK-Cityscale or what? Where can I see the source code- as I cannot find one? How has work been lost, if the link goes to geohack?
Slightly off focus, but I do find the map that the globe icon points to particularly useless- does a solution turn around sacrificing that direct link? I wish I could be of more assistance.ClemRutter (talk) 18:56, 30 December 2007 (UTC)
In a nutshell, some people liked geolinks ability to put a select few maps inline on the article page. Some people regionalized these templates for better selections in a given area. Others liked it because you could select the scale down to a building as part of the Geolink. On the opposing point of view, there's the thought that rather than make arbitrary choices about which maps are featured, make everyone go to the giant list of all mapping services. Improvements were made to that page to allow for scaling and a form of regionalization, though perhaps not as much as could be hoped for. There's a lot of red herrings and partial solutions offered, but I suspect no one will be happy here. One specific concern is that only 10-15 people have been active in this discussion. dm (talk) 19:22, 30 December 2007 (UTC)
As documented in Wikipedia:WikiProject Geographical coordinates#Parameters, you can add |region:GB to make the British options appear at the top of the Geohack list. {{Geolinks-UK-cityscale}} is using that, and without it an automatic process tries to do the same. -- SEWilco (talk) 05:04, 31 December 2007 (UTC)
  • Support. "300,000 articles" - these are custom templates for different countries and purposes, so that the most appropriate services can be chosen for each country. And each country's editors can come to consensus amongst themselves rather than having to deal with the central and macro-heavy Template:GeoTemplate. If the changes were just for the default template I'd agree with them, but preventing specialised templates from promoting particular appropriate services is too limiting. It's not like the Geolinks service isn't still available, it's still in the standard top-right location for all coordinates. TRS-80 (talk) 19:55, 30 December 2007 (UTC)
What do you mean "still in the standard top-right location"? The numerical coordinates were not being displayed by Geolinks in the top-right corner of articles until the change was done. And your comment about each country suggests more documentation needs to be added to the GeoTemplate's presentation of the most specific data first (I don't remember whether it presents the relevant country or region). -- SEWilco (talk) 04:48, 31 December 2007 (UTC)
Please note that this is not correct. Co-ordinates have always been displayed on the top right by the template underneath - indeed before I wrote cityscale originally. --Scotthatton (talk) 13:31, 2 January 2008 (UTC)
Ah, there it is: Wikipedia:WikiProject Geographical coordinates#Parameters says to try the two-letter country abbreviation in the region specification. -- SEWilco (talk) 05:04, 31 December 2007 (UTC)
Orderinchaos's comment on #Both_Geolinks_and_top-of-page_coord says that's how things were, and it's my recollection too, old versions of Mapit-AUS-suburbscale included {{coord}} as {{coord|{{{lat}}}|{{{long}}}|type:landmark_region:AU|display=title|format=dms}}. Country selection isn't good enough, different services are appropriate for differently-sized and located regions - coverage of towns in rural Australia differs a lot between mapping services. To re-iterate - I support the change to the global template, but leave the country-specific ones alone, as they are better maintained and more appropriate for their regions. TRS-80 (talk) 09:51, 31 December 2007 (UTC)
I'm willing to accept that the top-right coordinates were present in some Geolinks code; I edited so many templates that I might be remembering what a different template was doing. -- SEWilco (talk) 17:44, 2 January 2008 (UTC)
I can think of many many examples where country selection is not enough. You'd want an Ordnance Survey map to give justice to a remote area like northern Scotland. You'd want Streetmap to link to street maps of London. Both are in the UK. The solution does not lie in scaling as streetmap does not supply street-level mapping of Edinburgh. You'd need a London version alongside a UK generic to provide maximum service. --Scotthatton (talk) 14:37, 2 January 2008 (UTC)
No geolinks templates exist for areas more detailed than country level though, so this is all hypothetical. If that kind of detail was wanted and we had the service coverage information required for such a feature, it could easily be added to GeoHack, as the more detailed region information is already available (see with Edinburgh for example) and filtering services out of the list would be a simple comparison of scale values. This could all be done with geolinks too of course, but requiring edits to the related articles, and with highly subjective results because of the editor chosen services. Anyway, it would not be a good decision to not provide links to services that don't have very detailed data of a location, as we can't know what kind of detail the user wants to see, and some users may be accustomed to using a specific service (which may not, again, match with what the geolinks editor chose). --Para (talk) 22:23, 3 January 2008 (UTC)
It's not hypothetical, see directly below at #Geolinks_coverage where there's a listing of the various country templates at various scales - building, street, city etc. TRS-80 (talk) 02:46, 6 January 2008 (UTC)
Scotthatton was talking about lists of services on a sub-country level, to see a different selection of services depending on the location of the region within the country. Currently neither GeoHack nor the geolinks templates support this. What you seem to be talking about is one of:
  • geolinks templates imply a scale of the object with their name. This translates to the scale parameter in all the coordinate templates, and is relayed to map services through GeoHack.
  • geolinks templates for small scale objects do not link to services that are appropriate for the region and are included in their larger scale counterparts, but don't have small scale data. This practice is incorrect, as it assumes that readers expect to see the object with that small scale only, and not just its general location.
  • geolinks templates for large scale objects do not link to services that are included in their smaller scale counterparts, because ...? Absent any criteria for inclusion, I'm guessing this is because the large scale template editors like the services they chose, and the small scale template editors don't like them.
We can give hints in some way on how one service might be better than another, but we should not leave services out because of personal preference. --Para (talk) 17:20, 7 January 2008 (UTC)
"preventing specialised templates from promoting particular appropriate services is too limiting" ?? It's not for Wikipedia to promote external services! --Para (talk) 17:20, 7 January 2008 (UTC)

Geolinks coverage

In theory it's a nice idea that there would be a maintained geolinks template for all scales of all the world's regions, but in practice it's unmanageable. I looked at all the Geolinks templates from before the change, and here's the results:

Geolinks coverage
Continent Region Template scale Google Maps Live Wiki
mapia
Yahoo Maps Map
Quest
Topo
Zone
Global
Guide
Multi
map
Street Directory Bonzle Terra
Server
MSN Maps Map
tech
Virtual Earth Virtual
Globe
trotting
US Census
Geolinks-buildingscale landmark x x x x x x x
Geolinks-cityscale city x x x x x x x
Oceania Geolinks-AU-streetscale landmark x x x
Mapit-AUS-suburbscale landmark x x x x x
Geolinks-NZ-streetscale landmark x x x
Asia Geolinks-Asia-cityscale landmark x x x
Geolinks-IN-landmarks landmark
Geolinks-IN-streetscale landmark x x x
Europe Geolinks-Europe-buildingscale landmark x x x x x
Geolinks-Europe-cityscale city x x x x x x x x
Geolinks-Europe-mountain mountain x x x x x
British Isles Geolinks-UK-buildingscale landmark x x x x
Geolinks-UK-streetscale landmark x x x
Geolinks-Ireland-streetscale landmark x x
Geolinks-UK-cityscale city x x x x x x x x
Geolinks-UK-mountain mountain x
North America Canada Geolinks-Canada-streetscale landmark x x x x
Geolinks-Canada-cityscale city x x x x
Geolinks-Canada-region city x x x
Geolinks-Canada-townscale city x x x x
Geolinks-CanadaMore-cityscale city x x x x x x x x x
United States Geolinks-US-buildingscale landmark x x x x x x x
Geolinks-US-hoodscale landmark x x x x x x x
Geolinks-US-photo landmark x x x x
Geolinks-US-river landmark x x x x x
Geolinks-US-streetscale landmark x x x x x x x
Geolinks-US-trails landmark x x x x x
Geolinks-US-cityscale city x x x x x
Geolinks-US-countyscale city x x x x x x
Geolinks-US-mountain mountain x x x x x
Geolinks-US-colorphoto N/A x
Geolinks-US-surrounds N/A x

What the table doesn't show is all the areas not covered by the geolinks templates. There is no consistency, not in the selection of map services within a region, not in the selection of map services within articles of a certain scale, and not in inclusion of services local to an area, except in very few cases. Most of the included services are global, and their imagery can change at any time without any notice. The problem isn't that Wikipedia wouldn't have articles from the regions missing in geolinks templates (see map of coordinate coverage), but that there is nobody to maintain the templates. People supporting reversion here are mostly interested of the area they're taking care of themselves, ignoring all the remaining ones. Many of the regions the geolinks templates propose are also too big to really include the best services available for some of the areas listed in GeoTemplate. When a random reader comes to Wikipedia and wants to find the location of an article or a better view of the area, we should provide a predictable link to better map services, and Geolinks cannot do that. --Para (talk) 16:23, 31 December 2007 (UTC)

Maybe this is the crux of the entire discussion in different topics scattered throughout this article. I am the originator and maintainer of cityscale and have indeed maintained it throughout its existence. I have fixed mistakes, improved co-ordinates, disposed of linkspam etc. for a long time now. From discussions I see that the Australian maintainers have been doing the same job. Other templates have not had this care and attention. All geolinks templates are not equal. There is a strong case for getting rid of some - the Europe ones are too wide in their remit.
As for "When a random reader comes to Wikipedia and wants to find the location of an article or a better view of the area, we should provide a predictable link to better map services" I can 100% agree. But it should be on the article page. I trust the Australian maintainers to find great "predictable" Australia-wide sources plus the biggies like Google Maps etc. I don't know Australia and so trust Australians to know their best providers. In the UK I'd want to see Ordnance Survey; in the Netherlands lokatienet. these are great local services. You can with Geohack bring mapping to the top. The problem is that's it's still one click too many away... --Scotthatton (talk) 14:01, 2 January 2008 (UTC)
All articles with coordinates related to the whole article should be treated equal, to provide readers consistent and predictable map links. "Predictable" here could mean that a global map service found in one location related article should then be found in all location related articles, and a regional one in all articles in or somehow connected to that region. Any partial deletion of geolinks isn't progress at all. If some people want geolinks in articles, but there are no editors to create and maintain templates for all the world's regions in a consistent way, then that's an impossible scenario and we'll have to use the central list used by Wikipedias in many languages and other Wikimedia projects. Then map links (as coordinate links) can be truly predictable, to always show the same global services and applicable local ones. We can later work on getting the services listed in an order following some yet-to-be-defined criteria. --Para (talk) 22:32, 3 January 2008 (UTC)
As long as the attributes can be linked in the title and the user has the option of going to the blindingly confusing geohack page (on which I can't even find Wikimapia any more - I think I managed to once - but most times I have to enter the link directly and enter coordinates manually - how is this an improvement?!), or using our somewhat easier to use links, isn't that good for Wikipedia overall? I don't really mind what happens in areas which didn't have coverage or didn't significantly use the templates - for those an international template can be used. However, for regions (or past use of templates) where there is a strong group of readers and editors and where consensus is not unhappy with what they previously had and clearly does not want the new version, then telling them "we know what's best for you and you're getting it whether you like it or not even though we can't even get an international consensus amongst other regions' editors" smacks of arrogance and elitism, and is not and should not be how Wikipedia works. Orderinchaos 20:29, 5 January 2008 (UTC)
No, it's not good for Wikipedia to have two separate ways for reaching map sites, when one of those isn't guaranteed to exist in all location related articles, may not be up to date, is based on personal preferences of a handful of editors, and links directly to those arbitrarily chosen advertising supported services. If there are any problems with the GeoHack interface, please report the specific problems somewhere so that they can be fixed. The motives of the main geolinks contributors are highly questionable when they are not interested of mapping links Wikipedia wide, but only for their particular region. Since the links in the geolinks templates don't add anything the coordinate templates don't already have, they are nothing but convenience links as interface elements that should be uniform throughout Wikipedia. There have been cases on Wikipedia before when strong groups of readers and editors were unhappy with fundamental Wikipedia policies, wanted to see them changed, and felt offended when their efforts were turned down, calling it arrogance or elitism. Links to map services are not information. --Para (talk) 04:05, 8 January 2008 (UTC)
Orderinchaos is mainly concerned with an Australia-wide template. I am mainly focused upon a worldwide template. Though we are both on the other side of the debate from Para, we are coming from two different angles. Much as I enjoy being told what I think and why I am thinking it, I have come to the end of this debate. Para does not agree with me and I don't agree with Para. This is understood now. --Scotthatton (talk) 14:31, 8 January 2008 (UTC)