Wikipedia talk:WikiProject Geographical coordinates/Archive 27

Archive 20

←

Archive 25

Archive 26

Archive 27

Archive 28

Archive 29

Archive 30

Question about article tagging

New Jersey Coastal Heritage Trail Route currently flags up as missing geographical coordinates, despite the fact that its a listing of 28 locations along a heritage trail in NJ. Wouldn't it be more appropriate to have these coordinates in the individual articles about each location? Or should they be in both places? MeegsC | Talk 21:01, 3 August 2011 (UTC)

See #"Missing" coordinates for roads and railways? above. --Redrose64 (talk) 21:22, 3 August 2011 (UTC)

Um... Okay, but having read that I'm still none the wiser. A midpoint and two endpoints seems pretty unhelpful for a listing like this! MeegsC | Talk 21:59, 3 August 2011 (UTC)

Note that that guideline suggests several alternative presentations. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:53, 11 August 2011 (UTC)

Because of this problem, there is no consensus for geotagging road articles at this time. --Rschen7754 00:32, 12 August 2011 (UTC)

...nor against. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 18:00, 19 August 2011 (UTC)

Wikipedia talk:WikiProject U.S. Roads#Archive 14#Geo-coordinates? for one, I'm sure there's a few others throughout the WT:USRD and WT:HWY archives. --Rschen7754 01:43, 20 August 2011 (UTC)

Bad link; presumably you mean Wikipedia talk:WikiProject U.S. Roads/Archive 14#Geo co-ordinates.3F However, it's not clear, from your indentation, to what you are replying, nor, for your text nor from the content of the linked section, how you think this helps us. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:55, 20 August 2011 (UTC)

... it shows a clear consensus against geotagging U.S. road articles. --Rschen7754 23:51, 21 August 2011 (UTC)

You are demonstrating a remarkable talent for reinterpreting history to suit your own world-view. The cited section shows no such thing. Indeed, one commentator says "I would be fine with a few points of a highway being tagged". That commentator was you. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 10:19, 22 August 2011 (UTC)

Ban Geographical coordinates

Just as a heads up for this project. A major thrust of the discussion at Wikipedia talk:Manual of Style (road junction lists)#Proposal is a ban on the inclusion of some or all geographical coordinates in tables of road junction lists. To the extent you have an interest in geographical coordinates, you may wish to engage in the discussion. Failure to engage will presumably lead to a group of editors uninterested in geographical coordinates setting policy on geographical coordinates.

The entire section Wikipedia_talk:Manual_of_Style_(road_junction_lists)#Sub-section_on_coordinate_templates. and the section on this page, Wikipedia_talk:WikiProject_Geographical_coordinates#"Missing" coordinates for roads and railways?, form part of the discussion. --Tagishsimon (talk) 12:00, 22 August 2011 (UTC)

For the record, the above is not a neutral posting, and is a violation of WP:CANVASS. --Rschen7754 13:39, 22 August 2011 (UTC)

I rather anticipated exactly that response from you, Rschen. Your antipathy for geo-coordinates is by now well known. My post does not fail canvass since I'm not seeking to influence the determinations of those who might enter the debate, but merely seeking to make users aware of the debate and its potential impact. I leave readers to determine whether my post is neutral having studied the proposed policy, notably the section Under no circumstances should every junction be tagged if this results in more than 20-25 coordinates, or lower depending on the length of the route. --Tagishsimon (talk) 13:56, 22 August 2011 (UTC)

The direction a group of editors wish to pursue is not neutral nor non-neutral. It is a discussion arriving at a conclusion. "Failure to engage will presumably lead to a group of editors uninterested in geographical coordinates setting policy on geographical coordinates." is very much a violation of WP:CANVAS. Not only that, but it presumes that the arguments made against the inclusion of said coordinates is a case of WP:IDONTLIKEIT, as opposed to readability and clutter. - ʄɭoʏɗiaɲ ^τ _¢ 14:51, 22 August 2011 (UTC)

We'll have to agree to differ on this, Floydian. I stand by my words. --Tagishsimon (talk) 14:55, 22 August 2011 (UTC)

It is very much a case of WP:IDONTLIKEIT, as the use of subjective terms like "clutter" evidences. Also, your edit summary says "this very much violates CANVAS as it appeals to a specific demographic of editors (those who have an interest in geographical coordinates)". CANVASS explicitly allows this: "Appropriate notification ... An editor who may wish to draw a wider range of informed, but uninvolved, editors to a discussion might place a message at one of the following: The talk page of one or more WikiProjects ... directly related to the topic under discussion.". You should apologise to Tagishsimon. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 22:32, 22 August 2011 (UTC)

Yes, you can post a neutral message, but you can't include your own commentary. --Rschen7754 22:33, 22 August 2011 (UTC)

"Yes", you agree that Floydian's edit summary was dishonest and he should apologise? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 22:36, 22 August 2011 (UTC)

... no, and please don't twist my words. --Rschen7754 22:39, 22 August 2011 (UTC)

Twist your words? You replied "Yes" to my post; so I asked (note question mark) for a clarification. So, do you agree that Floydian's edit summary was dishonest, or do you think he was correct? If he was dishonest, don't you think he should apologise? Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 23:44, 22 August 2011 (UTC)

I agree that the post by Pigsonthewing that I am replying to now has a quite obvious logical fallacy. --Rschen7754 23:53, 22 August 2011 (UTC)

I've reread Wikipedia:Canvassing again just now, for the hell of it. It says it is fine to post on the talk page of one or more WikiProjects directly related to the topic under discussion. It asks that notices be polite, neutrally worded with a neutral title, clear in presentation, and brief. My title is neutral: there is an attempt to ban geographical coordinates. The post is neutral in that it does not make a case one way or another. It is brief. It does, I grant, contain the remark "Failure to engage will presumably lead to a group of editors uninterested in geographical coordinates setting policy on geographical coordinates." Being very familiar with the tone of the attempt to set policy on the page I referred to, I think that is an entirely accurate statement and and appropriate thing to bring to the attention of editors who by virtue of having this page on their watch list may be expected to have an interest in geo-coords. I can understand that if you're against geo-coords, Rschen, you might not much like the tone of my post. I'm not going to lose any more sleep over it than you have lost as a result of attempting to ban geo-coordinates without having the courtesy to inform this wikiproject. --Tagishsimon (talk) 23:02, 22 August 2011 (UTC)

To be clear, this is not an attempt to ban geographical coordinates. It is an attempt to limit their use in highway articles. Coordinates will be allowed in highway articles. --Rschen7754 23:06, 22 August 2011 (UTC)

To be crystal clear, it is an attempt to ban coordinates, and any attempt to sell it otherwise is sophistry. Bullet point 2 reads "(The following locations on a road should be tagged in the junction list:) 2. The junctions that are important enough to be listed in the infobox (no more than 10 at most)" (my emphasis). It is clear from this that any attempt to, for instance, provide coords for every junction of the M1 in the UK would be against this policy. How is that not a ban? If I want to coord all twenty or fifty something junctions of the M1 motorway, how is this not banning that? "Limiting their use" is identically equal to banning those that fall outside the arbitrary limit you are trying to set.

I see some of the proposed policy has in recent hours been watered down somewhat - the tail end currently reads:

Note that not every junction needs to be tagged; furthermore, not every junction should be tagged if there are more than 10 junctions. specific attention should be given to the number of tags needed to represent the route without providing too much visual clutter, both in the article and in the resulting coordinate map. Under no circumstances should every junction be tagged if this results in more than 20-25 coordinates, or lower depending on the length of the route.

It is clear from the scored out sections what the underlying thrust was at the time I first posted this thread; and I'm absolutely certain that it will be used to ban coordinates on an article by article basis. As you have said on a couple of occasions, you can always raise an army of like minded people to force a "consensus" when you wish to.

It sucks, btw, that a manual of style is being used to limit content.

Finally, if you were genuinely concerned about "clutter", you would not be favouring a typographically illiterate proposal which would yield a gap-toothed table in which some junctions and features have coordinates and some do not. Since when is that sort of ragged pattern better than a completely regular pattern? Sheesh. --Tagishsimon (talk) 23:28, 22 August 2011 (UTC)

I think you - Rschen7754 - mean "Coordinates will still be allowed in highway articles", because - as I've pointed out to you more than once recently, they already are. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 23:46, 22 August 2011 (UTC)

Help with "Coord" template on sn.wp

The talk page for {{Coord}} page is not editable. So, hopefully this is a good spot to ask this question.

I moved all the relevant Coordinate templates to the Shona Wikipedia and it doesn't display correctly. I think there might be a .css issue but I am not sure. Can someone knowledgeable about these templates take a look at sn:Template:Coord and help me get the links to display like in en.wp? --MarsRover (talk) 00:22, 16 October 2011 (UTC)

I have removed the talk page protection on template talk:Coord. (I could not find any reason for it.)

Your request here will attract a wider potential audience, and a superset of Coord's talk page. —EncMstr (talk) 00:42, 16 October 2011 (UTC)

Help with coordinates

I'd like to add coordinates to some articles, and I found the template okay, but I'm unsure how to get the coordinates from maps into the template. What's the most accurate source of coordinates? For example, I looked up The Boathouse, Twickenham and got 51.4623489379883 -0.302780002355576, but I don't know if this is the neighborhood, or the address, or what. Also, it's not in the format I see for other coordinates. Could someone help with this? Pkeets (talk) 20:48, 26 October 2011 (UTC)

I'd opine 4 significant figures is enough. The coord template would be {{coord|51.4623|N|0.3028|W|type:landmark_region:GB|display=title}}. See also Wikipedia:WikiProject_Geographical_coordinates#Precision. But your coords point to a street called "The Quadrant" and not to a building, so there's a problem. --Tagishsimon (talk) 21:03, 26 October 2011 (UTC)

Try these for size -Tagishsimon (talk) 21:22, 26 October 2011 (UTC)

• 5sf 51.46249 N W 0.31891 51.46249°N 0.31891°W / 51.46249; -0.31891 - within a metre
• 4sf 51.4625 N 0.3189 W 51.4625°N 0.3189°W / 51.4625; -0.3189 - within about 7 metres
• 3sf 51.463 N| .319 W 51.463°N 0.319°W / 51.463; -0.319 - in the river, some way off
• 2sf 51.46 N| .32 W 51.46°N 0.32°W / 51.46; -0.32 - getting on for a kilometre away
• 1sf 51.5 N 0.3 W 51.5°N 0.3°W / 51.5; -0.3 - call a taxi

I had found something that got me to the corner. The first one in this list works really well. How did you find them? Pkeets (talk) 22:00, 26 October 2011 (UTC)

I followed one of the external links to find a photo of the location I was looking for (Exterior from the Richmond Lock and Footbridge at low tide), then found it using the birds-eye view in Bing (led by the article description of the road it lay on), then got the coordinates from ACME. --Tagishsimon (talk) 22:23, 26 October 2011 (UTC)

GeoLocator is a useful tool. If you've obtained coordinates from elsewhere, you can enter them to check that they point to the right location and, if they're off a bit, can move the marker to get a refined set of coordinates. Or if you can recognize the place in a Google "satellite" view, you can zero in on it by repeatedly double-clicking on the map, then place the marker on it and read off the coordinates. It also includes some basic forms of {{coord}} with the coordinates of the marker already filled in, which you can just copy and paste into an article. Deor (talk) 23:00, 26 October 2011 (UTC)

I like the GeoLocator tool. One problem I discovered the other day while using it is that for places in most or all of China the satellite imagery in GeoLocator (and in Google Maps, ACME Mapper, Bing, and all others tried) is offset from true by something like 1,000 meters or so. The map view is apparently correct. I checked Google Maps "report a problem" pages and found many people have brought it up over the years but I couldn't find an explanation. Weird. Anyway, something to keep in mind when working on coordinates for places in China--using GeoLocator or most (all?) other online mapping tools. Perhaps this is a known issue here, but I thought I'd mention it anyway. Pfly (talk) 23:36, 26 October 2011 (UTC)

Thanks. Much appreciate the help. Pkeets (talk) 01:14, 27 October 2011 (UTC)

The claim at discussions elsewhere is the opposite, at least for Google Maps--- that the map view is transformed from the real coordinates, while the satellite imagery is untransformed. Does anybody have more solid information? --Delirium (talk) 14:18, 4 November 2011 (UTC)

Oxford Internet Institute study on geo-tagged articles

Boffins get around to doing what Wikipedia-World has been doing for ages, but use yellow dots instead and draw fairly obvious conclusions. Also at the HuffPo. --Tagishsimon (talk) 12:53, 14 November 2011 (UTC)

geo bounding box

Do we have a template that creates a bounding box, or multiple geocoords on the same map? At Wikipedia:Geonotice, it would be nice to have top and bottom geocoords put onto a map at the request phase. e.g. this map shows A and B to describe the bounding box. Its not perfect. I think the best solution will be to have geonotices.php improved to show also requests in a different colour. John Vandenberg ^(chat) 22:00, 14 November 2011 (UTC)

The nearest I know of is {{GeoGroupTemplate}} which will in Bing or Google place multiple pins in a map. Examples found at the foot of M11 motorway, for instance. --Tagishsimon (talk) 13:53, 15 November 2011 (UTC)

Thanks! The underlying tool in that template works wonderfully. John Vandenberg ^(chat) 22:09, 15 November 2011 (UTC)

Using the emitted microformats (as that template also does) is better. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 01:31, 16 November 2011 (UTC)

Coordinates for roads/ highways

The issue of coordinates for roads/ highways is again being discussed, at Wikipedia talk:Manual of Style/Road junction lists#M23 revocations (18 Nov 2011). Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 11:21, 20 November 2011 (UTC)

Discussion concerning deletion of Template:Infobox ukcave

There is a discussion at Wikipedia:Templates for discussion/Log/2011 November 22#Template:Infobox ukcave about whether it would be better if there were not two separate infoboxes: {{Infobox ukcave}} and {{Infobox cave}}. A difference being discussed is that one infobox allows precise cave location coordinates to be given and the other deliberately does not. There is discussion as to whether or not it is undesirable or contrary to policy for this difference to be maintained. The matter of location has previously been discussed at Wikipedia talk:WikiProject Caves and at Template talk:Infobox cave. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:08, 25 November 2011 (UTC)

Automatically generate list of all pages a user has edited and extract coords, if any

Hello, I have a somewhat strange and technical question. I'd like to be able to automatically (or semi-automatically) create a list of all the article pages I've ever edited and extract each page's coordinates (the {{coord}} template at least, and ideally coordinates in geoboxes), if a page has coordinates. The idea is to map the coordinates with an application like Google Maps. I tend to edit geographic articles and am curious to see the distribution over my years here. I'm also thinking of making a map like this, if it isn't too hard, for a friend who quit Wikipedia some time ago but had amassed at least 70,000 edits, a great many of which were geographic and focused on British Columbia. I was thinking it would be a nice "memorial" for his work--a way to say thanks for all that! Obviously I would get his permission and participation in gathering the list and coords--I assume I would need to. So my question is--is this possible? If so, ideas on how to do it? Would it be relatively easy or technically challenging? I have some background with geographic data manipulation, so given a list of coords I should be able to make a map. I just don't know how I'd generate such a list. I know there are lots of tools over at toolserver.org, but I haven't spent a lot of time over there. If this process isn't too hard and can be automated, it could make an interesting tool for others to use as well. Clues? Thanks. (Just to cover my bases, I also posted this at the Help Desk. My apologies for cross-posting--I suspect the number of active responders both here and there is rather small) Pfly (talk) 05:22, 18 November 2011 (UTC)

Para has a tool which is close: normally it extracts multiple coordinates from an article or rounds up all coordinates from articles in a category—optionally, all its subcategories. The tool is used by {{GeoGroupTemplate}}. I played with the tool a bit to see if I could persuade it to do an extraction of your type. This is close: http://toolserver.org/~para/cgi-bin/kmlexport?article=Special:Contributions/EncMstr&linksfrom=1 but it returns a kml file indicating an error:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
       <name><![CDATA[Special:Contributions/EncMstr]]></name>
       <open>1</open>
       <Folder>
               <name>No geocoded items found</name>
       </Folder>
</Document>

I suspect Para will have to add a minor extension to be able to do this. —EncMstr (talk) 07:11, 18 November 2011 (UTC)

If it helps, once you have the coordinates, OpenStreetMap has a "heatmap" tool to do this for its editors' contributions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:36, 18 December 2011 (UTC)

List of tunnels in the United Kingdom

I've started to add centre-point coords to List of tunnels in the United Kingdom, should anyone wish to join in. The list is dauntingly long. --Tagishsimon (talk) 22:55, 1 December 2011 (UTC)

Dauntingly long- but a fraction of the tunnels in existence as the criteria is so broad. I have just been given Warrenders book on Underground Manchester 978-0-946361-41-0, that gives potential 40 potential tunnels- and then I look at the Pennine canals- and if we just limit it to +160m we are still overwelmed. And then what do we do about redundant Victorian sewers-- POT tunnels-- cold war defence tunnels still classified-- I just can't see daylight!--ClemRutter (talk) 14:59, 2 December 2011 (UTC)

There are two or three different issues there; the incompleteness of the current list; criteria for inclusion; and the time necessary to add coordinates to those on the list. I'm currently looking just at the last of these; about 12 evenings work, by my calculations, as it stands. I'd welcome the second and then the first issue being attended to, though. --Tagishsimon (talk) 15:27, 2 December 2011 (UTC)

That's a relief- I thought you were heading for total burnout! To add to #1- File:BSicon utSTR.svg and his mates at Template:Waterways legend give an indication of which articles refer to waterway tunnels- and thus their locations- utSTR.svg is on over 100 pages. If one adds drifts adits and soughs ... time for a paracetamol. :) --ClemRutter (talk) 02:42, 3 December 2011 (UTC)

The ut-prefix BSicons need not refer to tunnels on waterways; they also refer to tunnels on metro/light rail systems, including the London underground - see, for example, Central London Railway#Improvements and integration, 1920–33. --Redrose64 (talk) 14:01, 3 December 2011 (UTC)

West Midlands done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:34, 18 December 2011 (UTC)

Japanese railway stations missing coordinates

Here's what I hope is a nice set of bite-size challenges for anyone interested.

The great majority of Japanese railway stations now have coordinates: for a list of the remaining 100-odd currently still without them, please see User:The Anome/Japan railway stations missing coordinates. -- The Anome (talk) 12:34, 11 December 2011 (UTC)

Thanks mostly to Deor, there are now only 28 stations left on the list. Are there any Japanese railway specialists here who could help finish the list off? -- The Anome (talk) 11:14, 14 December 2011 (UTC)

User:Bamse has now finished off the entire list. Kudos to everyone who worked on this. -- The Anome (talk) 21:35, 17 December 2011 (UTC)

Automagically converting OSGB36 to coord?

I've had a quick search of the archive of this page & wider wp search and given up - so can I ask for some help. I have contributed to lots of lists relating to geographic features (mostly in Somerset) and have been returning to these after some time. Following various discussions I have now been convinced of the advantages of coord over OSGB36, even though is probably better known in the UK. The world wide audience & ability to map items using kml etc have won me over. I am daunted by the prospect of manually changing hundreds (? thousands) of OSGB36 grid refs to coord and wondered if there is an automated process (bot, AWB or whatever) which could handle the process? Examples of the lists concerned include: Grade I listed buildings in Taunton Deane, Grade I listed buildings in Bath and North East Somerset, Grade I listed buildings in Mendip, Grade I listed buildings in North Somerset, Grade I listed buildings in Sedgemoor, Grade I listed buildings in South Somerset, Grade I listed buildings in West Somerset, List of Sites of Special Scientific Interest in Avon, List of Sites of Special Scientific Interest in Somerset, List of locks on the Kennet and Avon Canal, etc, etc.— Rod ^talk 15:25, 18 December 2011 (UTC)

I can do it using my bot if needed. However, before I do so, I suggest we first get consensus here that this is a good thing to do. Then we can take it to the bot task approvals process, which, if we've got a good consensus and rationale worked out here, should be a formality, and I can get then started on re-coding the coordinates. -- The Anome (talk) 15:54, 18 December 2011 (UTC)

Thanks. I will put a note on the talk pages of the lists identified above + relevant wikiprojects asking anyone interested to join in this discussion. If I spot others where this applies I will do them as well and note them here.— Rod ^talk 16:03, 18 December 2011 (UTC)

Can we add Grade I listed buildings in Bristol to the list?— Rod ^talk 16:27, 18 December 2011 (UTC)

Rather than a simple convert, why not add the Coord alongside the OS? GraemeLeggett (talk) 16:57, 18 December 2011 (UTC)

I support the use of WGS84/ {{Coord}}, but are you talking about replacing OSGB36 gird refs with WGS84 coordinates, or adding WGS84 coordinates? I should think the latter will be more likely to gain consensus. Of course, a {{Convert}} style template, allowing entry in either and output in both (including via {{Coord}}) would be even better, but may be overly complex to code. In either case please supply the diff of a sample change, so others can easily see what's involved. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:00, 18 December 2011 (UTC)

I was thinking of replacing the OS grid ref with coord, but could be persuaded to have both if that is the consensus it just clutters the display. As a demo I have added the coord template to the first entry on Grade I listed buildings in Taunton Deane (Church of St Mary in Bishops Lydeard - as the list is sortable).— Rod ^talk 17:10, 18 December 2011 (UTC)

I ask why? If there is a !vote, I will object. There are vast numbers of people in the UK who like to use paper maps - The only maps for the UK are made by OS. OS maps only use OS co-ordinates = end of story, people won't want to start having to convert coords to OSGB36 all the time. I could just imagine the national uproar if OS suddenly decided to change all the maps to coords - it wouldn't happen. When using the PC, the OSGB36 links happily to Google maps, Streetmap etc., and works OK - if one wants the co-ords the Streetmap will convert for you. Hand help GPS devices will work with either OS or coord.  Ronhjones  ^(Talk) 17:06, 18 December 2011 (UTC)

The rationale I have been given is for readers outside the UK who have no idea what OS grid refs mean. The practical reason I've been using on more recent lists (eg List of churches preserved by the Churches Conservation Trust in Southwest England or List of civil parishes in Somerset) is the ability to add a template which will display all the items in the list on google/bing maps which doesn't work with OS grid refs.— Rod ^talk 17:14, 18 December 2011 (UTC)

Just try List of locks on the Kennet and Avon Canal - click on an OS ref, and select Google or Bing UK Maps - they are more than happy to work just fine - because GeoHack has done the conversion on the fly for you.  Ronhjones  ^(Talk) 17:52, 18 December 2011 (UTC)

I know that works for a single coordinate/Gird Ref but you can't map all of them at the same time. Try List of churches preserved by the Churches Conservation Trust in Southwest England & then map of all coordinates from Google ( or bing), via the box top right of the list, to see all the entries on the list on one map. If you did this for the locks of the K&A it would show the distribution across southern England.— Rod ^talk 17:57, 18 December 2011 (UTC)

• Oppose OS grid refs are easy to derive from an OS map. You look in the sheet corner to find the letters, then along the sheet edges to find the four major digits - this gives a 1 km accuracy like grid reference SU5290 - if 100 m accuracy is desired, you can get a rule and measure in 2 mm increments for two more digits, like SU525905. Either way, that produces a link to the GeoHack page, which allows a variety of mapping services to be used, and this even works with those that don't understand OS grid refs. By contrast, although OS maps show lat/long, these are along the sheet edges only, there is no network of lines, only a series of widely-spaced + signs, at 5-minute intervals. Here is one: 51°35′N 1°15′W (go to the OS Maps column in the Bing Maps UK row, and it's just to the left of the marker balloon). Not at all easy to obtain the coordinates of a feature more than a few millimetres away from that cross. --Redrose64 (talk) 18:23, 18 December 2011 (UTC)

• I'm familiar with OS maps (I've been using them for 40yrs or so) but readers from outside the UK will have no idea. If you use {{coord|51|35|N|1|15|W|region:GB_scale:50000|display=inline}} you can add seconds to get more detail although I would use {{coord|51.583333|-1.25|type:landmark_region:GB|display=inline}} which can be used to any number of decimal places for more accuracy down to cm scale (although I never use more than 4 places). Would you advocate converting those lists of UK places which currently use WGS84 coordinates to OS grid refs? — Rod ^talk 18:37, 18 December 2011 (UTC)

• I am aware that several places of decimals may be specified either for degrees (without minutes or seconds) or for the seconds component of a d/m/s coordinate. I have seen many features given coordinates which are far too precise (e.g. degrees to six/seven/eight places for a railway station 250 m long; one second of arc for a coalfield), showing that the person entering them has not read (or not understood) WP:OPCOORD. I gave 51°35′N 1°15′W to an accuracy of one minute because the feature I was indicating is not a point on the ground, but a symbol on the map to show where lat. 51°35'N and long. 1°15'W intersect; it is unnecessary, and misleading, to specify seconds of arc for this particular example. By showing where to locate this symbol on an OS 1:50000 map, I was demonstrating the difficulty of obtaining lat/long from such maps, because the lines are discontinuous. The grid lines are, by contrast, continuous and the nearest is always less than 1 km in any direction. --Redrose64 (talk) 20:33, 18 December 2011 (UTC)

Yes, what if those people come to the UK, with the intention of visiting some of the places we have shown, and they have made a nice list based on our pages (or even printed out the pages) - they head into the bookshop at the airport when they land and find only maps with OSGB36 system. If there was competition of maps available, then there might be a case to answer - but we have a monopoly here - if you want a map, you buy an OS one.  Ronhjones  ^(Talk) 19:16, 18 December 2011 (UTC)

Or, increasingly, instead of buying dead trees, they take out their WGS84-GPS capable mobile devices and use those. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:23, 18 December 2011 (UTC)

I find the use of OSGB on Wikipedia anachronistic. People who want coords in that format are fully catered for - all they need do is click through a set of hyperlinked coordinates e.g. 51.1456°N 2.7144°W / 51.1456; -2.7144 and on the resulting GeoHack page you will see the OS coord (ST5002938777) . I definitely support a wholesale change in list articles to use "proper" coordinates --Bob Re-born (talk) 19:13, 18 December 2011 (UTC)

That's only your view of "proper", that's not the UK mapping system  Ronhjones  ^(Talk) 19:18, 18 December 2011 (UTC)

Agreed Can you imagine having a different system for every country in the world? If the answer is no, why should a special exception be made here? On Wikipedia $US are used for GDP and (sq) mi and km for length (area) everywhere and I see no reason whatever to act differently here. --U5K0'sTalk_{Make WikiLove not WikiWar} 19:43, 18 December 2011 (UTC)

Also, it isn't as if there have been very many complaints about the coordinate system used to identify the location of the Bank of England, the BBC Television Centre, Big Ben, the British Library, Brunel University, Buckingham Palace as well as many other landmarks which do not begin with a B or are outside London. This is why I find it difficult to accept that this proposal is anything other than a simple request for standardization. --U5K0'sTalk_{Make WikiLove not WikiWar} 20:19, 18 December 2011 (UTC)

Thinking about it: unfortunately, a numerically accurate WGS84-to-OSGB converter involves quote a lot of code, including looping to extract roots to numerically invert functions, so it couldn't be done using a simple template. It's just possible that a half-way-decent approximate WGS84-to-OSGB converter might be implementable using polynomial approximations to the correct function, but it seems like complexity overkill to me. However, an in-page convertor could easily be implemented using Javascript, if people needed one: see http://www.jstott.me.uk/jscoord/ , for example. -- The Anome (talk) 20:31, 18 December 2011 (UTC)

OK thanks for attempting a tool to do this. I could go through and change them manually using the export function of Geohack, but in the light of the discussion above I might just keep my head down and live with different systems on lists about the same county (& wish I'd never started this).— Rod ^talk 20:52, 18 December 2011 (UTC)

I think it's indisputable that WGS84 is now the universal global de-facto standard for geographic coordinates, and that Wikipedia coordinates' master data should be stored in that format. I think the big issue to discuss here is the need for display of OSGB36 coordinates in the page itself for those who want to use paper maps.

I can think of two ways to proceed: one is to hold the OSGB (or other local grid system) coordinates as a separate field in the coord template, and the other is to somehow produce those local grid coordinates using a template or other post-processor.

The UK extends from roughly -8 to +2 degrees longitude, and roughly 50 to 61 degrees latitude. If we were to tabulate the eastings and northings for all of these at 1° intervals, we would end up with a grid with 11 x 12 = 132 reference points, small enough to store on a wikipage. Given that bilinear (or bicubic) interpolation are really quite simple, and easy enough to implement in template math, and that converting the metre-level eastings and northings to grid square and residual format is also within the capability of a template, we could just about implement a WGS84-to-OSGB36 grid reference converter entirely with templates. I wonder what the typical error of such an approximation would be using bilinear or bicubic interpolation for a 1° reference grid? (Also: if the errors are still too big, increasing the resolution of the grid of calibration points should make disproportionate improvements to the error, e.g. if we were using bicubic polynomial interpolation, I would expect errors to be roughly fourth-order.) -- The Anome (talk) 21:14, 18 December 2011 (UTC)

I'm afraid I'm not even going to pretend to understand any of that and I shall leave further discussion to those that might.— Rod ^talk 21:40, 18 December 2011 (UTC)

I've just had a quick look at the template-based converter. It's entirely do-able, but would be a good candidate for setting some kind of record for template abuse: you'd need to write several small programs just to generate the set of templates in the first place, the resulting templates would be completely unintelligible and unmaintainable, other than by keeping the program that generated them around, and using it to regenerate them when changes were needed. Finally, the run-time of the templates would be quite high. -- The Anome (talk) 23:54, 18 December 2011 (UTC)

I agree that coordinates should be available in WGS84 as a standard, but also that localisation to OSGB should be preserved (and encouraged) in British articles. Anybody (resident or tourist) wanting to go out with printed articles or beyond the reach or cost of a mobile online connection will be relying on paper Ordnance Survey maps which exclusively use the OSGB grid system. A template conversion showing both would be wonderful, but would need to be accurate. Oosoom ^Talk 22:31, 18 December 2011 (UTC)

Never mind the cost - the nicest bits of UK countryside are often devoid of any mobile phone signal!  Ronhjones  ^(Talk) 20:24, 19 December 2011 (UTC)

Maybe I have missed something here- but I coded up a Javascript tool that could be adapted. ostowiki convertor the copyright statement of the clever stuff is clear. It must be trivial to translate this into whatever language the toolserver speaks. But I think the greater need is on geograph.co.uk uploads to commons, which often give a lat/long in OSGB36, which commons assumes is WGS84. (Usually 112 m out) My ideal solution would be to convert everything outside the infobox to WGS84, but on a cursor rollover have a Grid reference as a hint.--ClemRutter (talk) 22:51, 18 December 2011 (UTC)

Rollover no use on printout or Wikipedia:Books print. Oosoom ^Talk 23:10, 18 December 2011 (UTC)

Would you be happy with a Javascript-generated side-by-side OS grid reference? This wouldn't be in the page HTML, but would be in any displayed or printed page generated by any modern browser. But it probably would not be in Wikipedia:Books printouts.-- The Anome (talk) 23:56, 18 December 2011 (UTC)

Sounds good. I don't use :Books much myself, prefering to print out a few pages of individual articles in anticipation of being in the area along with my OS map collection, but it would be nice to have consistency in both print methods. Full MediaWiki support would be ideal though. Many countries have their own grid systems. Oosoom ^Talk 10:57, 19 December 2011 (UTC)

We can already style things so they work as a roll-over on screen, but show when printed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:50, 19 December 2011 (UTC)

Google maps app on mobile devices allows the user to pre-cache maps while on a landline connection, for use while mobile. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:50, 19 December 2011 (UTC)

An alternative: side-by-side display generated from something like this, with the OSGB coordinates baked-in: {{coord|51.583333|-1.25|type:landmark_region:GB|othergrid=OSGB|otherref=SU 51959 87483|display=inline}}? Advantages: trivial to code, backwards-compatible, would work in all formats, could be extended to allow for other national grid formats for other countries. Disadvantages: maintenance -- too easy to let the OSGB and lat-long coordinates get out of sync (particularly in the face of well-intentioned corrections of bad data), and lack of clarity about which was the master coordinate system if the two differ.

The final option, and probably the best, would be to create a MediaWiki extension that would do the job server-side in PHP, say with a parser function. But this would require major heavy lifting. -- The Anome (talk) 00:02, 19 December 2011 (UTC)

I would mention how many source documents (eg SSSI citations, ancient monuments, listings, etc) use OS Grid refs as their primary identification, and so their original form and level of precision should be retained, and I would think there is considerable use in it being in a text-searchable form. RobinLeicester (talk) 00:32, 19 December 2011 (UTC)

That can be catered for in refernces, for example {{coord|51.583333|-1.25|type:landmark_region:GB|display=inline}}<ref>SU 51959 87483, in ''List of Foos'', Madeup Press, 1997</ref>

But that misses the point that the OS grid ref is itself encyclopaedic content, and may be the specific fact a reader was hoping to find. The infobox seems ideally suited to include both systems without confusion or clutter. The harder issue is in lists, where at present the Grid Ref is often the only system used, generally using gbmappingsmall. Could that be adapted to calculate a printable rollover to show the other system, and let editors decide which should be on show? (I realise I have no understanding of if or how that would be done) Would that then give the kml features that Rodw described? RobinLeicester (talk) 12:47, 19 December 2011 (UTC)

If the infoboxes are fine, then why not just add an extra column to the lists, and have both systems. That would also be a lot less articles.  Ronhjones  ^(Talk) 20:28, 19 December 2011 (UTC)

I think that has happened in some. The problem is that faced with a list of several hundred SSSIs per county (for example), editors have used the Grid Ref from a list, but not felt up to doing the conversion for each one in turn - which makes an adaptation of gbmappingsmall so appealing - but perhaps there are all sorts of technical obstacles to that. RobinLeicester (talk) 21:01, 19 December 2011 (UTC)

Comment I just wanted to point out the fact that many people outhside the UK who see the OS grid reference may not know that they're looking at a coordinate equivalent link. Maybe a little globe could be added to these templates as well. --U5K0'sTalk_{Make WikiLove not WikiWar} 13:34, 19 December 2011 (UTC)

Perhaps a tiny map - since it isn't "global"... GraemeLeggett (talk) 20:06, 19 December 2011 (UTC)

A proposal: template-based grid-to-WGS84 conversion

Since it doesn't look like we are going to be able to get where we want in a single go without a MediaWiki extension being written, here's a compromise proposal. I suggest that we start by massaging {{gbmappingsmall}} into a new version that takes the OS grid reference split into three parts: the letter code for the 100 km grid square, the residual easting, and the residual northing. Thus, {{gbmappingsmall|ST751647}} would become {{gbmappingsmall|ST|751|647}}.

Doing this would be a trivial change that could be done easily using a bot, without any change to the existing output, and the modified template could still accommodate the original format for the purposes of backward compatibility.

However, having made that change, the new representation would then allow national grid to WGS84 conversion to be carried out in a relatively simple way using templates, by first interpreting the residual easting and northing strings as right-justified decimal fractions of 100 km, and then using them as inputs into polynomial expansions defined using either a switch statement or a per-grid-square template. While this would be pretty gnarly, it wouldn't be anywhere near as gnarly as the previous proposal for WGS84-to-grid conversion. -- The Anome (talk) 00:03, 20 December 2011 (UTC)

I'm not going to claim to understand the third of your paragraphs, but if it produces no difference in output (onscreen, paper & machine readable) then I can't envisage any problems with it. Perhaps a demo so people can see the effect would be useful? Would the same fix work on the related templates (eg {{Gbmapping}}, {{Gbmaprim}}, {{Gbmapscaled}} & {{Oscoor gbx}})? (although I've never used some of them). Would a different approach be to adapt {{GeoGroupTemplate}} to recognise OS grid refs? - although I have no idea what work would be involved in this. Thanks again for looking at this issue and applying your expertise in this field.— Rod ^talk 08:22, 20 December 2011 (UTC)

That would also allow us to trap errors where there's an unequal number of digits in each part. But what about articles which already have OSGB and WGS84 coordinates sitting alongside each other? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:14, 20 December 2011 (UTC)

Alternative idea: why not have a template in which one value is entered, and then a bot which, like helpful pixie bot, follows up, does the lookup, and enters the other value, as static text? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:17, 20 December 2011 (UTC)

While we're talking about it...

Can we please some time fix the WGS84 -> OSGB36 converter in Geohack ?

Here's the map links page for the Airy Transit in the middle of the Royal Observatory, Greenwich [1].

As you can see, click on the Bing Maps link (which gets passed the location as a WGS84 lat/long), and it pinpoints the centre of the building exactly.

But click on the Streetmap link (which gets passed the location as an OSGB36 Ordnance Survey grid reference), and it pinpoints a spot about 100 metres to the west, and slightly north. The co-ordinates passed ought to be accurate to the metre.

What is going wrong can be simply described; what the code should be doing is

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

Instead, we're missing out the first conversion step. We're just passing that WGS84 lat/longstraight to the grid calculation step,

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

without converting for the different geoid; and as a result every grid co-ordinate we are proffering is systematically wrong.

This is a horribly embarrassing fail; what is worse is that the problem has been known for at least four years now, and we are still producing bad grid references every single time we return a UK map links page.

I'd offer to do it myself -- there is no shortage of code on the internet to do the geoid conversion, that could just be dropped in -- but I don't have a toolserver account; and to be honest, I'd rather this was done by somebody with experience and knowledge of tweaking such a critical system.

What needs to be done to take this forward? Jheald (talk) 15:47, 21 December 2011 (UTC)

I've left comments on the talk pages of Dispenser and Kolossus, who are maintainers for this. If someone has a JIRA account on the toolserver, it would be great if they can submit an issue to track fixing this, and thus also bring this to the attention of Magnus Manske, who prefers JIRA issues to talk page entries: JIRA is at https://jira.toolserver.org -- The Anome (talk) 16:57, 26 December 2011 (UTC)

Thanks. There's this open bug [2] on JIRA that I filed four years ago, but it may not be in the best or most effective place -- I see there's now a separate GeoHack bugs list it could be filed to, rather than Magnus's tools (which GeoHack is perhaps no longer one of). Not sure how to move it. Jheald (talk) 22:57, 27 December 2011 (UTC)

Keeping score

This project is continuing to make significant progress.

• As of the most recent dump of December 1st, 715,044 articles contained coordinate tags that emitted links to geohack, a higher number than ever before. Since this figure rises consistently over time, today's figure will be even higher.
• As of today, 167,963 articles contain {{coord missing}}, a lower overall proportion of the total article count than ever before at 4.384% of all articles in spite of constant machine-aided replenishment, also indicating progress as these tags are slowly being replaced with valid geotags.

This suggests that the overall tagging rate of eligible articles is now approaching 80%. At this rate, we will soon be reaching the million-article mark, where one million articles will be being curated by this project.

Kudos to every one of the participants here, and also to the hundreds of other editors silently contributing coordinates in ones and twos. -- The Anome (talk) 16:26, 26 December 2011 (UTC)

just curious

I was just wondering if there's a place where you can see the number of articles which have coordinates and possibly a graph of how many such articles there have been over time? --U5K0'sTalk_{Make WikiLove not WikiWar} 22:33, 27 December 2011 (UTC)

GeoGroup

Please note that {{GeoGroupTemplate}} has been renamed, as {{GeoGroup}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:42, 28 December 2011 (UTC)

excessive precision in latitude and longitude

I just wanted to let people know that I've made a proposal at Template talk:Infobox French commune to change the level of precision used in specifying latitude and longitude of French communes. If there's any discussion, I'd prefer for it to take place there. —Stepheng3 (talk) 19:15, 3 January 2012 (UTC)

Geobox

I have proposed that we delete {{geobox}}. That may effect articles curated by this project. You are invited to particiapte in the Geobox deletion dicussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 3 January 2012 (UTC)

Good news everyone!

I just wanted to drop a note about the fact that the Slovenia articles missing geocoordinate data Category is about to become empty. Yay! --U5K0'sTalk_{Make WikiLove not WikiWar} 21:10, 6 January 2012 (UTC)

Thank you! Have a barnstar! -- The Anome (talk) 03:10, 8 January 2012 (UTC)

Latitude and Longitude coordinates

Moved from Wikipedia:Village pump (policy) § Latitude and Longitude coordinates

Most articles now have the map coordinates of a relevant location in the upper right. Usually, a couple of clicks on that link will take you to a detailed Google satellite map of the location. The problem: when studying landing spots of my recent trip to Antarctica, I find these links sometimes miss the mark by miles. Example: Almirante Brown Antarctic Base. The cited location of 64°51' S, 62°54' W, or 64.85° S, 62.9° W, is three and a half miles northwest of the Google satellite map location where the buildings are located: 64.895° S, 62.870° W. You would have a difficult time finding the buildings using the cited location. I went ahead and fixed the link, but I wonder if the Google coordinate system is always reliable, especially at extreme latitudes.

Thanks for any comments. HowardMorland (talk) 21:54, 8 January 2012 (UTC)

This isn't really a policy issue. If the problem is not with the coordinates on the article (and I get the distinct impression that you've checked and fixed them), it's likely to be with the way that calculations are applied to those coordinates. Strictly speaking, you should bring the matter up at the discussion page for the template which performs those calculations. The template used in the External links section of Almirante Brown Antarctic Base is {{coord}} (for which the discussion page is Template talk:Coord), but that template is not necessarily buggy in itself - it could be a bug in one of the external mapping services. I think the best place to ask is at Wikipedia talk:WikiProject Geographical coordinates where there are specialists in such matters. --Redrose64 (talk) 23:03, 8 January 2012 (UTC)

I have moved the discussion as you recommended. There is no problem with the {{coord}} template. The discrepancy is between the coordinates published in an external source which is cited in the article and the coordinates you get when you right-click on the image of the buildings on the Google satellite map and then click on "What's here?" HowardMorland (talk) 14:22, 9 January 2012 (UTC)

If no one has any objection, I will just assume the Google satellite map grid is accurate and change any coordinates in Wikipedia articles to make them point to the correct spot on a Google satellite map. (Note: Bing maps always seem to agree with Google.) HowardMorland (talk) 01:07, 10 January 2012 (UTC)

I think the Google/ACME/Bing satellite grid is more accurate than many, even most official published coordinates. Coordinates from the GEOnet Names Server are almost always offset by a significant amount. BC Geographical Names coordinates are almost always rounded to the nearest minute. The only caveat about using online mapping satellite grids I know of is in China, where the satellite imagery is offset by something on the order of 1,000 m. Pfly (talk) 01:42, 10 January 2012 (UTC)

Thanks. I have noticed a grid problem with China. Another map problem with China is that high resolution satellite coverage is out of date or missing altogether for places away from the coast. That makes it difficult for me to draw maps of the artificial whitewater courses. HowardMorland (talk) 15:04, 10 January 2012 (UTC)

GeoData extension

Hi, I'm looking for your input on the new extension WMF is developing: GeoData. It will store geographical coordinates of pages and make them available via the API.

How it will work?

A parser function, {{#coordinates:}}, will be inserted into {{coord}}. It will grab the data and store it in the database. Input will be validated and if something goes wrong, a nice red error message will be displayed (just like broken <ref> tags do) and page will be added to the tracking category (default name: Category:Pages with malformed coordinate tags). So far I've come up with the following changes to the template:

Extended content
At the bottom of a <includeonly> section: {{#coordinates:{{{1|}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|{{{7|}}}|{{{8|}}}|{{{9|}}} |{{#switch:{{{display|}}} |inline,title |inline, title |title,inline |title=primary |default=}} |name={{{name|}}} }}

What kind of information will be stored?

Virtually everything our {{coord}} templates and GeoHack support: coordinates, type, name, dim, region, globe. Scale will be transformed into dim as GeoHack developers prefer dim for a good reason.

Primary vs. secondary coordinates

GeoData has the concept of primariness of coordinates, that is: coordinates that define article subject's location are considered primary, while all the other coordinates in the article are considered secondary. There can be only one primary coordinate in the article, but as many as you like secondary ones (but see below for restrictions). Primariness will be figured out from {{coord}}'s display parameter: if the coordinate is displayed by the title, it has to be primary.

What kind of checks will be performed on input?

• Coordinates out of range, e.g. 120°N - template already seems to check for it.
• Double negation, e.g. -13°S - sample fix.
• Invalid GeoHack coordinate parameters, e.g. city instead of type:city - these were introduced by SmackBot aeons ago, I've already unleashed my bot on them.
• No more than 500 coordinates per page - doesn't seem to cause any problems, so far I've seen at most 200-something coordinates on page. Would be good to think whether we really need so many though:)
• No more than one primary coordinate per article - here's the list of suspicious pages, though it has a lot of false positives due to e.g. commented out coordinates.

What will be possible to do with this data?

Initially, there will be just two API functions direly needed by our mobile services: "find articles around the given point" and "get coordinates on page". Then, we will decide what else could be done.

When?

Probably, after MediaWiki 1.19 deployment in February.

Would appreciate your comments, critics, proposals and so on. Regards, Max Semenik (talk) 11:26, 13 January 2012 (UTC)

Speaking as the instigator of {{Coord}}, this is splendid news! Just two issues to be aware of:

• The use of the name parameter is problematic; I advised against it (and still do), and it certainly shouldn't be used when the instance of {{Coord}} is inside a parent template or table-row which emits a parent microformat to Coord's geo microformat (for instance, an infobox)
• Watch how you handle instances of Coord for non-terrestrial locations (such as a lunar carter); these have a |body= parameter.

Please let me know if I can assist further. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:03, 13 January 2012 (UTC)

I'm not certain this extension will be a good thing, but I'm hopeful.

• I've added a link to Template talk:Coord referencing this discussion.
• There's actually no |body= parameter in {{Coord}}; I believe Pigsonthewing was thinking of |globe=, which you (MaxSem) are already aware of. Note that, on some globes, longitude is measured in only one direction, so the longitude parameter can sometimes exceed 180 degrees.
• {{Coord}} already generates error messages and populates a maintenance category for many common parameter coding errors. I'm wondering how to avoid duplication, if possible.
• Your notion of "primariness" makes perfect sense to me. I refer to these as "title" coordinates.
• Enwiki has articles with hundreds of coordinates, but probably not thousands. The poster child for this was List of craters on Mars, which got split into three parts due to performance issues in {{Coord}} causing the page to time out.
• One of my activities is fixing articles with multiple title coordinates, so they're pretty rare in enwiki. There's a weekly report at Wikipedia:Database reports/Articles containing overlapping coordinates. You can see from the report's edit history that it used to be much longer.
• Since the extension is presumably intended to work with other wikis besides enwiki, you should probably look at how dewiki and others handle coordinates.

—Stepheng3 (talk) 22:05, 13 January 2012 (UTC)

• Yes, I know about coordinate systems on other planets, though it's still on my todo list. Would appreciate if someone had a cheatsheet of limits on other planets.
• Tracking category is an interesting issue. I believe that since I'm not limited by wikitext, I can implement more validation in the parser function, so many of template's checks can be ditched. Or, alternatively, GeoData's tracking category can be easily disabled.
• Good to hear that problems with multiple title coordinates aren't as great as I suspected.
• Yes, I've already looked up many other wikis' templates. They generally work in two ways: JSON-like encoded parameters like here on en: or split them to separate named parameters. Both are supported, e.g. {{#coordinates:lat|lon|type:city_dim:10000}} == {{#coordinates:lat|lon|type=city|dim=10000}}, the ease of hooking up to existing infrastructure was one of primary goals. Max Semenik (talk) 12:10, 14 January 2012 (UTC)

Is this change—ah—coordinated with data scrapers, such as Google Maps? I have been led to believe that either the geo microformat or parameters to {{coord}} are how external services obtain our data. Will the revised mechanism continue to produce the microformat? Someone who once wrote here knew someone at Google Maps, but there was never any followup on some issue. Is anyone in contact with them? —EncMstr (talk) 22:26, 13 January 2012 (UTC)

GeoData will add another way to access data, it does not require the deprecation of anything currently present. Max Semenik (talk) 12:10, 14 January 2012 (UTC)

I've been in touch with them several times about their reuse of our coordinates. It's been a while since the last time, so I don't know if my contacts are still there. I don't see why this change should break what they do, but I'll see if can reach someone again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:44, 13 January 2012 (UTC)

My impression is that they probably just scrape the rendered article pages themselves, either with a geo tag parser, or just an ad-hoc hack just for Wikipedia. Scraping for geotags won't change anything even if the internal implementation here changes, but changing the URLs generated from our existing geohack URLs to some other path might break ad-hoc hacks. -- The Anome (talk) 23:53, 13 January 2012 (UTC)

Currently, there are no plans of developing an in-MediaWiki replacement for GeoHack, though this may change easily. Screen-scrapers are destined to experience breakages anyway. Max Semenik (talk) 12:10, 14 January 2012 (UTC)

Name will be saved only when set explicitly as a template parameter. Yes, I'm aware of globe. Max Semenik (talk) 12:10, 14 January 2012 (UTC)

I understood that; my point is that such use is problematic. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:52, 16 January 2012 (UTC)

Please add the name parameter to the extension, otherwise its usefulness will be limited to data extractors such as myself. Especially in articles with long lists of coordinates (coordinates in tables), it will add important semantic info to what otherwise be a meaningless heap of coordinates. --Dschwen 23:47, 12 February 2012 (UTC)

Your "sample fix" for "double negation" isn't really addressing an instance of double negation—rather, the error was specifying "E" (for positive longitude) with a negative (west) numerical value of the longitude. I've been seeing this error a lot lately for some reason (I think some geocoders have copy/pasted a {{coord}} template with N and E present and then added positive and negative values for the coordinates without noticing the contradiction), but it doesn't seem to actually affect GeoHack's leading users to maps that display the correct locations, since it appears that positive or negative numerical values override the E and W parameters. Nonetheless, it would be nice to have these errors flagged so that they can be repaired—by a bot, perhaps? (I'm not entirely sure whether the errors are currently flagged, but I don't think so.) Deor (talk) 23:15, 13 January 2012 (UTC)

Positive/negative values don't override the E/W or N/S, they flip it - try {{coord|-1|S|-1|W}} → 1°N 1°E ; {{coord|-1|N|-1|E}} → 1°S 1°W . No red error message is generated, and the page is not put in any hidden categories. Values for longitude outside the -180...+180 (or 180 W...180 E) range are not necessarily errors, since for countries close to the 180° meridian they make the calculations for pushpin maps easier.

{{coord}} complains with a red error message for longitudes outside the -359.999...+359.999 range, or latitudes outside the -90...+90 range. Such errors categorise in Category:Coord template needing repair. --Redrose64 (talk) 23:45, 13 January 2012 (UTC)

Ah, I see. I guess it's just a matter of luck that the "negative east" ones I've been seeing lately have had the effect of displaying the correct (west) longitudes. Deor (talk) 12:22, 14 January 2012 (UTC)

Note: User:MaxSem/Duplicate primary is now empty. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:52, 16 January 2012 (UTC)

Cross-referencing with OpenStreetMap

Here's a suggestion about a feature for the GeoData extension, and thus also a feature for this project.

OpenStreetMap has a mechanism for linking OpenStreetMap features to Wikipedia: we should be able to do the reverse, preferably with an optional field in the {{coord}} tag.

Having both together will enable both systems to do what they are best at -- Wikipedia at generating simple point-and-dimension coordinates, and OpenStreetMap at encoding features with complex shapes (like roads) or boundaries (like administrative areas). In addition, Wikipedia has a free-and-easy approach to feature coding, but contains this as auxiliary data added to large amounts of non-geographical article content, and -- crucially -- category data, whereas OSM has a more rigorous approach to geographical data, but contains no other content. I believe that the two can be complementary to one another, and that cross-referencing the two will help improve both.

In particular, this could forever end the discussions about how to geocode roads, rivers and railway lines and other complex linear features: we can simply point those articles to the OSM object in question.

It would clearly be easy to add an "osm" parameter to the {{coord}} tag. I'm not sure what globally unique identifier might be used to identify the OSM object in question, since NodeIDs seem to be defined to be unique only within a single OSM dataset. If this could be clearly resolved, though, it could be as easy as just adding "osm:way/23284495" within a geotag to generate a reference to (for example) the object visible at http://www.openstreetmap.org/browse/way/23284495 . (Note that the name "Jukskei River" isn't specific enough for this: ways 27522839 and 78320575 also have the name "Jukskei River")

See also Wikipedia:WikiProject OpenStreetMap and https://wiki.openstreetmap.org/wiki/Collaboration_with_Wikipedia . -- The Anome (talk) 23:34, 13 January 2012 (UTC)

As an OSM editor and advocate, I heartily endorse greater cross-linking; but for many linear features, on which we have articles, there is no single entity on OSM to which we can link. BTW, there's an ongoing RFC about coordinates for road articles (see above) where your comments would be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 01:00, 14 January 2012 (UTC)

Would it be possible to do what's needed by creating some kind of Wiki subpage with a list of ways on it, and then referencing that? Or just use something like a comma-separated list, eg. "osm:way/23284495,27522839,78320575", if the list is short enough? -- The Anome (talk) 12:16, 14 January 2012 (UTC)

Coordinates not in infoboxes

I'm still seeing a lot of articles with coordinates not in infoboxes; here's an example of one I fixed earlier. Is it time we had a push on fixing these? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:54, 16 January 2012 (UTC)

Question - I understand that technically info in infoboxes is not considered repetitive (even though in these case its the same code). But do we realy need the coordinates 2 times in articles? I like info box placement the best as its neat and tidy.Moxy (talk) 21:07, 16 January 2012 (UTC)

Yes; firstly because the location is a key fact about the subject; and that's what infoboxes are for. Also, because including them in the infobox includes them in the emitted hCard microformat. The vast majority of infoboxes about subjects with a location already include coordinates; those referred to above are a small minority. on the other hand the "title" coordinates are needed, as explained in a section above, are needed to indicate that they apply to the subject of the article, not just something discussed within it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:32, 16 January 2012 (UTC)

There are two main ways of putting coordinates in infoboxes: a general-purpose |coordinates= parameter (or similar), or a pair of |latitude=|longitude=, sometimes decimal-only, sometimes permitting d/m/s. Some infoboxes, such as {{Infobox Station}} as used by Furushō Station, allow all of these forms. Some infoboxes with the lat/long forms allow the other parameters (type, region, etc.) to be specified as well, some don't. Some infoboxes, such as {{infobox settlement}} set up the coords differently depending upon whether a parameter such as |coordinates_type= is present and non-blank, present but blank, or entirely absent. Before moving coords to an infobox, the peculiarities of the infobox must be checked. --Redrose64 (talk) 22:47, 16 January 2012 (UTC)

Indeed; Standardising that is another issue, one for which I'm steeling myself... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:49, 16 January 2012 (UTC)

Return to OS grid refs and coords: gbmappingitem

Following the discussion some way above, I have had a go at a template to display both coords and OS refs. It does not attempt the conversion - both sets of data have to be supplied. But it means it could be adapted to future display needs, whilst giving full current benefits of coord. Various formats are possible, including a two-line format suitable for use in tables. It also adds a tooltip to the grid ref, to explain what it is.

• Example 1 (ten-figure grid reference, all on one line): 51.50061°N 0.12461°W / 51.50061; -0.12461 (Big Ben), TL 042 997
• Example2 (four-figure grid ref, two-line format):

52.90°N 1.09°E / 52.90; 1.09 (Holt, Norfolk)
    TG0838

This is my first attempt at a template, so I would welcome guidance if I have got things too badly wrong. verbose documentation at template:gbmappingitem. More examples at my sandbox. RobinLeicester (talk) 16:40, 22 January 2012 (UTC)

GeoGroup with Template

Any help on getting this GeoGroup to show names rather than numbers on the map. The coords are created in the template Template:NMI list item and the list that uses it is List of National Monuments in County Dublin. I tried getting the coords built with name= but that wasn't successful. It ended up showing the coords and the place name to the right of it. Looked bad. Just want the name to be passed through to the GeoGrup. DubhEire (talk) 18:27, 24 January 2012 (UTC)

Probably not the last word on this, but I think coord does not like the [[...]] wikilinks - and unhelpfully (in this situation) adds it to the output. Without these, at least name can be passed to cord, (It may mean an extra parameter to send it separately from 'name'? Alternatively, strip the brackets out of the calling text, and add them back in within NMI list item where you need them - but that would break existing entries!). Even with name= applied, like you I still got just numbers with GeoGroup, but it did work correctly using {{kml}} instead. Is that just down to an indexing bot somewhere? RobinLeicester (talk) 21:14, 24 January 2012 (UTC)

I've tried bypassing the wiki markup, but so far I haven't had any success. Even though I have considerable experience with GeoGroupTemplate and Coord, I'm unsure what the problem is. It may be that the toolserver is taking a long time to update KML data. Time will tell. —Stepheng3 (talk) 21:18, 24 January 2012 (UTC)

Excellent. It was the [[]]. It passes through the name now with plain_name. Must have been a delay in the toolserver. So I can work with that now, thanks. Now the next / ideal is to have a link back to the article in question. Is that even possible to have individual URLs. Perhaps best wait to the solution that may come out of the Highways RFC. Possibly KML. Thanks all for helping. DubhEire (talk) 21:38, 24 January 2012 (UTC)

GeoHack allows pagename= and title=, but presumably to ensure it is always an existing link, coord only allows title to be changed (using name=) and hard-codes FULLPAGENAMEE into pagename. I guess the only way to change that would be to work on coord, and pass another parameter right through to coor_url, but I don't suppose there is any enthusiasm for that. RobinLeicester (talk) 23:31, 24 January 2012 (UTC)

Co-ordinates help

Hi, what kind of co-ordinates are these:

• X Coordinate: 283364.099
• Y Coordinate: 397006.471

I got them from this site, and they aren't in the standard used on Wikipedia on in most places, and i'd like to find a way to convert them to a usable standard for inclusion in grographical location in articles. Mabuska ^(talk) 15:20, 27 January 2012 (UTC)

Probably Ordnance Survey National Grid coordinates (all numeric, easting and northing). --Dschwen 16:01, 27 January 2012 (UTC)

Try this: http://www.fieldenmaps.info/cconv/cconv_gb.html --Dschwen 16:04, 27 January 2012 (UTC)

The co-ordinate conversion results i get don't seem to match up to where the area should be at. Putting the results into Google or anywhere else always seem to leave me in the ocean. Mabuska ^(talk) 15:28, 5 February 2012 (UTC)

That's likely because they're using the Irish grid reference system, which is used by both the UK and Irish governments for locations on the island of Ireland. -- The Anome (talk) 15:36, 5 February 2012 (UTC)

So try entering them under "Irish Grid: Full Co-ordinates" here. Deor (talk) 15:40, 5 February 2012 (UTC)

Or using this tool: http://www.lamont.me.uk/grid2latlong.php , with the radio button set to "Irish". -- The Anome (talk) 15:41, 5 February 2012 (UTC)

Thanks all. Sometimes I too get in a bit of a muddle when it comes to these conversions. Have bookmarked both suggestions now. RashersTierney (talk) 17:21, 5 February 2012 (UTC)

The Anome's link works great, turns out it actually tells you the mderidian figure should have a minus symbol which a know-nothing on the subject like me never realised. Thanks all. Mabuska ^(talk) 22:09, 7 February 2012 (UTC)

Coordinates in Mobile App

Wikipedia now has a mobile app (for Android and iPhone). v1.1, currently in alpha for Android, allows users to tap any instance of {{Coord}}, and then be shown a map with five pins, linking to, respectively, the five nearest geotagged articles. Even without this feature, coordinates on articles are being used by version 1.0 around 27 thousand times a day, since its launch last month. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:55, 2 February 2012 (UTC)

Cool! The minimap offers a similar facility on Wikipedia, but I'm not sure it's used that much, because the functionality isn't that obvious or easily discoverable. -- The Anome (talk) 12:09, 2 February 2012 (UTC)

The geographical feature when using the Android version disappoints me. It uses the same Geohack page as the normal Wikipedia rather than one designed for tiny screens as on my Samsung M910 phone. The app's lack of pinch / zoom compounds the inconvenience. I hope a later version will introduce a smaller menu with just Google Maps and whatever other mappers are already installed, relegating the various map Web pages to a subordinate menu. However, it's much nicer than having no ability at all to go from Wikiarticle to map. Jim.henderson (talk) 22:22, 5 February 2012 (UTC)

Are you sure? I don't see the Geohack page at al, in the Android app. the current release version goes straight to Google Maps (mobile); the alpha version of the next release, which I'm testing, goes to a (hosted?) mobile-friendly OSM map. Are you sure you're using the official Wikipedia app, and not a third-party one? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:50, 5 February 2012 (UTC)

An unsophisticated user, I thought the Android Mart a couple days ago said it was official and don't know how to verify. Instead, I'll uninstall and try again more attentively. It says at the top of "Application info" in the uninstaller,

• Wikipedia
  • Version 1.0.2
• Storage
  • Total 2.21 MB
  • Application 768 KB
  • Data 252 KB
  • Cache 1.21 MB
• and permisions for location, storage and full Internet access. Must recharge anyway, so after uninstall I'll power down, watch some television and .... Ah. Uninstall finished. Probably I'll turn on in an hour or two; possibly tomorrow. Jim.henderson (talk) 23:51, 5 February 2012 (UTC)

The author of the official app is "Wikimedia Foundation". It should be the first result, when you search the marketplace for "Wikipedia". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:31, 6 February 2012 (UTC)

Yes. Got a nights sleep, searched in mart for "wikimedia foundation". The three answers included one that included the words "Yellow Pages" in the description, one that defies my powers to recall an hour later, and one that used the words "Wikipedia" and "Official". Installed, it sent me to wiki.riteme.site home page. I clicked Port Moresby and below the map of its infobox clicked its coords. Waited half a minute for the note that said Toolserver wasn't responding. Powered down, had breakfast, powered up, opened the app to home page, clicked Port Said, clicked the coords below the locator map, and this time the full Geohack page came up from Toolserver.

Since as you say this is not standard, something is wrong. "About" shows the W logo and under that "Version 1.0.3", followed by the Fondation logo, "This application is copyright (C) Wikimedia Foundation and contributing developers" and finally some fine print about free software. The phone's "Settings, About phone" says

• Model number SPH-M910
• Android version 2.2.2
• Baseband version S:M910.05 5.EC07
• Kernel version 2.6.32.9
• Build number FROYO.EC07
• Hardware version M910.05

Is there a page to report this, for example with a form for this information? Jim.henderson (talk) 14:33, 6 February 2012 (UTC)

I've dropped a note on the relevant mailing list, asking for someone with a more technical understanding to take a look at this discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:11, 6 February 2012 (UTC)

The currently released version of the app has no special handling for coordinate links in articles; this is in the next version that will be released. The only map feature built in to the current version shows articles near your current location ('Nearby' in the menu). --brion (talk) 17:17, 6 February 2012 (UTC)

Ah. It wants to tell me about where I am. Not about the place I want to know. While looking at an article about Rio de Janeiro, I do Menu, Nearby, and it shows blue pointers to the Wikipedia articles describing a few Broadway theaters, since I'm sitting in Hell's Kitchen. This is very much not an interesting capability, since Google Maps already has a Wikipeda map overlay showing, in this neighborhood, nearly a hundred clickable little boxes with W inside.

When I tell Google Maps to show me Rio with this overlay, it shows W's for that place. Eventually the official Wikipedia Android app will get the feature to go quickly and simply to the Google Map (or choice among installed mappers?) about the place I'm looking at, and then to click on one of the markers that will bring up the Wikipedia article about a place near there. That's when it will become interesting to me. Sorry I misunderstood, and thankful for your attention. Jim.henderson (talk) 22:52, 6 February 2012 (UTC)

No problem; but if you read my opening sentence in this section, you'll see what's coming in v1.1, currently in alpha testing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:23, 6 February 2012 (UTC)

Broken instance of GeoGroup

Resolved

Would someone cleverer than me please figure out why {{GeoGroup}} is not working at Murder_of_Joanna_Yeates#Coordinates. Thanks --Tagishsimon (talk) 23:46, 2 February 2012 (UTC)

It seems to be working just fine. I tried the Google Maps link and the .kml link and viewed it in Google Earth. Why do you say it is "not working"? —EncMstr (talk) 05:32, 3 February 2012 (UTC)

Agree it works. Last night I was getting some sort of "no geographic coordinates" type error message. Thanks for looking at it. --Tagishsimon (talk) 08:28, 3 February 2012 (UTC)

nice use of geogroup in that article. Interesting that the template appears where it does when reading it. I couldnt find it at first. Is there a way of repositioning it? DubhEire (talk) 22:01, 5 February 2012 (UTC)

It's been moved slightly, IMO to a better place. --Tagishsimon (talk) 20:04, 6 February 2012 (UTC)

Colours

• dark colour means a currently open line / facility
• light colour means either a closed line / route / facility or one under construction / planned
• red indicates heavy rail or freight line
• blue indicates canal, light rail, metro or tram line.
• other indicates streams and non navigable rivers.

	Existing lines in current use	Lines not in use (planned or closed)
heavy rail	#BE2D2C	#D77F7E
metro/light rail & canals	#003399	#6281C0
Berlin S-Bahn	#006E34	#5ABF89
accessibility	#034EA2	#6592C5
other features	#000000	#AAAAAA
platforms	#888888	#CCCCCC
other routes & special circumstances (e.g. fare-free zones on a light-rail line)	footpaths (set f)	unwatered canals (set g)
	#008000	#2CA05A
formations and structures	#80A080
interchanges and depôts ()	border	fill
	#000000	#FFFFFF
cross-platform interchanges	border	fill
	#000000	#B3B3B3
other colours	background	watercourses
	#F9F9F9	#007CC3

I have no idea as yet for Defensive ditches and defensive ditches not in use --ClemRutter (talk) 09:53, 15 February 2012 (UTC)

Welsh Peaks

I've created around 700 articles on all the Welsh mountain peaks here. As you can see, only the OS has been included. Is there a bot which could add the corresponding geotag next to the OS, so that the peaks become visible on maps / QRpedia / AR etc? Diolch, thanks. Llywelyn2000 (talk) 09:03, 14 February 2012 (UTC)

For future casee, I have knocked up a little tool for my use, OS to Wiki that may help you. --ClemRutter (talk) 10:22, 14 February 2012 (UTC)

Thanks. Yes your ostowiki is great for ONE OS, but, as you can see from my link / artice, there are more that 700, so I'm thinksing more about a bot which could do it automatically so that we could generate a Google Map (or other at the top of the page which should group them all together. Secondly, can't we get a live Google Map on a Wikipedia page? Any ideas? Llywelyn2000 (talk) 12:17, 14 February 2012 (UTC)

Ask at the cy equivalent of WP:BOTREQ. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:29, 14 February 2012 (UTC)

Shall do. Thanks! Llywelyn2000 (talk) 12:40, 14 February 2012 (UTC)

QRpedia doesn't use coordinates; uses QR codes to link to articles and serves the user with the version of the article in their preferred language. If your articles have interwiki links to/ from them, QRpedia will know about them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 14 February 2012 (UTC)

My fault! I shouldn't have mentioned QRpedia. I really meant the other two. Yes, all 700 articles, individually have the coordinates and will be picked up, as you say. However, I would like the main Contnent page (list of peaks) also picked up. Many thanks. Llywelyn2000 (talk) 12:17, 14 February 2012 (UTC)

Picked up where? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:29, 14 February 2012 (UTC)

Here, as I've done using GeoGroupTemplate on this Stone Circle article - scroll down to the map. Llywelyn2000 (talk) 12:40, 14 February 2012 (UTC)

You just need to add cy's {{coord}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:35, 14 February 2012 (UTC)

"Just add the {{coord}}"? To over 700 articles? My question is this: Is there a bot which could add the corresponding geotag next to the OS? Llywelyn2000 (talk) 15:09, 14 February 2012 (UTC)

Again you need to ask this at the cy equivalent of WP:BOTREQ. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:24, 14 February 2012 (UTC)

I've done that; thanks for the suggestion. Without it, there's quite a mountain to climb! Llywelyn2000 (talk) 18:51, 14 February 2012 (UTC)

There is an interesting point here. I have long dreamed of being able to use HotCat and even Cat-a-lot to add a {{coord}} to articles. It is a real task when you come across a series of articles that need title tagging- any thoughts on who would like to do a little js coding for the good of (my sanity) humanity.--ClemRutter (talk) 18:04, 14 February 2012 (UTC)

Hear hear! Specially for the 2,000 articles I've created based on the Scottish peaks, which you can find here. Any help in getting coordinates / geotags onto all these 2,000 articles automatically (!) would also be appreciated. Llywelyn2000 (talk) 18:51, 14 February 2012 (UTC)

For the list sites, it wouldn't be too hard to use a semi-manual approach. Eg for the Scottish mountains, the values are already there, so copying it into a word processor and using a sequence of finds and replaces to convert to coord should be possible. Where you only have the OS refs, you could get them into a spreadsheet, and then use a batch conversion to get the coords. Turning the spreadsheet back into formatted text takes a bit of twiddling, but once it is done the job is finished! If you need more input on that approach I would be happy to help. RobinLeicester (talk) 22:59, 14 February 2012 (UTC)

There is User:Dschwen/Coord_tool which I haven't looked at in quite a while. I could add parsing of your weird map links to that script. Would probably be a lot easer than find/replace in a word processor! --Dschwen 23:19, 14 February 2012 (UTC)

The geodesy routines needed are sitting in the source code, and could be plugged into your coord tool. I tried to keep it modular and well documented. --ClemRutter (talk) 09:35, 15 February 2012 (UTC)

• Try again- too many windows open- screen lag. --ClemRutter (talk) 14:29, 15 February 2012 (UTC)

Thanks both for the links (Coord_tool and geodesy routines needed); the first has no instructions, the second a cul-de-sac (Object not found!). Llywelyn2000 (talk) 09:52, 15 February 2012 (UTC)

Dschwen. Why "weird map links"? Llywelyn2000 (talk) 09:25, 15 February 2012 (UTC)

The idea of using external links to a website plastered with adds for geocoding wikipedia articles just seemed a little weird to me, or at least a little "seven years ago". The coord tool should be self explanatory. If you follow the installation instructions it will add a button to the edit view. Let me test and confirm it still works. --Dschwen 13:39, 15 February 2012 (UTC)

I get you! Thanks again. let me know, or try it on the actual page! Llywelyn2000 (talk) 15:01, 15 February 2012 (UTC)

After all is said and done:

• batch conversion isn't able to convert the OS coordinates in my article.
• User:Dschwen/Coord tool doesn't work in my list of peaks. Insufficient instructions.
• The geodesy routines suggested is for one conversion at a time. No good.

The Welsh language Wici has only a very small percentage of Geotags - certainly no more than 10%. There's only a handful of Users left. We really need your help. Small is beautiful, but fragile. Llywelyn2000 (talk) 06:52, 17 February 2012 (UTC)

• • How did you convert the coordinates in the first section of your peak list? --Dschwen 20:33, 17 February 2012 (UTC)

I used a spreadsheet and batch convert. The interactive map is working but at present the geogroup doesn't generate a map. RobinLeicester (talk) 21:18, 17 February 2012 (UTC)

Yeah, you cannot just copy the GeoGroup template over to the welsh wikipedia. The template links to a toolserver script, that assumes the article is located on the english wikipedia. I'm not sure its maintainer User:para is still active (haven't seen him around in a long time). --Dschwen 21:52, 17 February 2012 (UTC)

Ah, there is project parameter to the kmlexport.php script. I fixed the template for you. Works now. --Dschwen 21:56, 17 February 2012 (UTC)

Thanks both! We're on the way! Llywelyn2000 (talk) 05:50, 18 February 2012 (UTC)

Coord problems

User:Azylber and I have run into a problem. Azylber has been creating some articles about airports and has been using coords from 2 different sites, and these 2 sets of coords seem to be relatively near each other. However, I checked these on Google and Bing, and come of the coords are nowhere near the actual location, according to Google/Bing. What are people's thoughts on using published coords rather than Google or Bing? For reference, some of the articles in question are Quiché Airport, Neil Armstrong Airport, Gualaco Airport, and Jurien Bay Airport. Thanks, "Pepper" @ 19:19, 21 February 2012 (UTC)

This one is probably the best example: Neil Armstrong Airport. The published coords in many websites agree. But they all seem to point to the city, not to the city's airport. User:Pepper is right, this is indeed a problem. Is it possible to cite google maps as a reference? Azylber (talk) 19:32, 21 February 2012 (UTC)

I glanced at Google Maps satellite image for the first one, Quiche Airport. It is on the runway of the right airport, a perfectly acceptable coordinate. Why do you say it is an example of a coordinate "nowhere near the actual location"?

As for the general issue of coordinate sourcing and verifiability: if an otherwise reliable source gives a coordinate which is wrong, then don't use it; if another—seemingly less reputable—source gives a coordinate which checks out, then use it. A big convenience of geographical verifiability is using a mapping service to confirm that a point is where is claims to be. Verifiability is one of the pillars of Wikipedia, but that relates to both sourcing data and the ease of checking it. —EncMstr (talk) 19:33, 21 February 2012 (UTC)

Pepper has already fixed the Quiche airport article, that's why now it's pointing to the right place. But look at this one, which hasn't been fixed: Neil Armstrong Airport

And also my question was, what do you do when you have many sources and they all agree, but the coords they all agree on appear to be wrong on google maps

Azylber (talk) 19:39, 21 February 2012 (UTC)

Coord comparison: 40°34′0″N 84°11′0″W and 40°29′36″N 84°17′55″W (from Neil Armstrong Airport). "Pepper" @ 20:21, 21 February 2012 (UTC)

FWIW, I regard Google and Bing as Reliable Sources, and would tend to defer to them. --Tagishsimon (talk) 00:40, 22 February 2012 (UTC)

Agreed. I believe that high-profile commercial mapping enterprises like Google Maps / Bing (and their underlying geodata suppliers), as well as state-level organizations such as the USGS and Ordnance Survey, should all be capable of being cited as WP:RS, particularly if more than one of them agree as to the location in question. I can also confirm anecdotally that Google have always been pretty accurate for locations where I know the exact location.

The coordinates on http://www.flightstats.com/go/Airport/airportDetails.do?airportCode=AXV , on the other hand, look like they've been converted to decimal from the degrees-and-minutes level accuracy coordinates 40° 34′ N, 84° 11′ W, perhaps suggesting that USGS GNIS coordinates for the town were used as a data source. -- The Anome (talk) 01:22, 22 February 2012 (UTC)

Okay. Thanks. "Pepper" @ 21:29, 22 February 2012 (UTC)

Cool, thanks everybody for the answers. As to my other question, you don't need to cite google maps as a source, right? We just fix the coords, correct? Azylber (talk) 05:22, 23 February 2012 (UTC)

It would not hurt to mention Google Maps as the source: {{coord|45.678|-123.456|type:landmark_region:US-OR_source:googlemaps}}. This helps other editors verify the data. —EncMstr (talk) 07:12, 23 February 2012 (UTC)

Placement of {{coord missing}}

I do a lot of stub-sorting, and when I find an article for a location or structure which hasn't got coords I add {{coord missing}} with an appropriate country/subdivision parameter. But I can find no guidance as to where in the article this should go. I realise that a coord-adder will find it most convenient if the "coord missing" is in the place where the coords will go, to save retyping ... but again, can find no guidance on this in either MOS:COORDS or Template:Coord/doc. Is there a rule anywhere, or a preferred location? PamD 00:30, 18 January 2012 (UTC)

I doubt it's specified anywhere, but in my experience {{coord}} is normally placed immediately above the categories, towards the foot of an article. --Tagishsimon (talk) 00:32, 18 January 2012 (UTC)

It should perhaps get a mention in WP:ORDER. Probably more logically before DEFAULTSORT, as the latter is closely associated with categories? Doesn't matter whether before or after PERSONDATA as the two will never (?) co-occur, so "if no other reasoning go for A-Z" and let's say "Before persondata". I might make a proposal to that effect, but will wait here a few days for any further comments. (And just off on a 4-day wikibreak anyway). PamD 11:50, 19 January 2012 (UTC)

Do we have PERSONDATA in a road article, it not being a person? --Tagishsimon (talk) 12:33, 19 January 2012 (UTC)

I think you've been spending to much time on WP:WHY ;-) We have a few biographies with coordinates for resting places, but I've never seen any tagged {{Coord missing}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:24, 19 January 2012 (UTC)

I deliberately don't add the tag to biographical articles. -- The Anome (talk) 11:09, 20 January 2012 (UTC)

I tend to {{Coord missing}} at the end, with stub templates, as like them it should not persist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:24, 19 January 2012 (UTC)

It seems that Anomebot 2 places the template above the categories / defaultsort at the end of an article, with a leading and a trailing enter to separate them. Since anomebot seems to tag a rather large share of the articles it may be convenient to just follow its lead on this matter. Excirial ^{(Contact me,Contribs)} 19:16, 19 January 2012 (UTC)

I am pretty sure that The Anomebot2 was just following the conventional lead of many editors. —EncMstr (talk) 00:31, 20 January 2012 (UTC)

That's right. -- The Anome (talk) 11:07, 20 January 2012 (UTC)

OK, I've now added to Wikipedia:Manual_of_Style/Layout#Order_of_sections, to specify that Coordinates or {{coord missing}} should go after Navboxes and before Persondata (unlikely to co-occur), Defaultsort, and Categories. Just as the AnomeBot already does. In belated response to Andy's suggestion that {{coord missing}} should go at the end as it's temporary, I would think it better that the temporary template is in the same place as its replacement, for ease of editing (as with {{stub}} being in the same place where a stub-sorter will be putting {{foo-stub}} to replace it). PamD 09:39, 23 February 2012 (UTC)

KML linear feature thing & Coord Missing

Now that we have the KML linear feature thing (see #Methods for map links for linear features & outlines), is it in order to start tagging articles with a {{kml missing}}, along the same lines as {{coord missing}}, and creating a counterpart to Category:Articles missing geocoordinate data by country? Articles tagged would be linear features (roads, railways, rivers etc) and bounded areas (counties, electoral areas, etc). The purpose would be to encourage the addition of KML map links to all such articles. --Tagishsimon (talk) 00:20, 23 February 2012 (UTC)

I think this would be a good idea... Perhaps subdividing by topic would be nice to the various projects, since the topics are so distinct. - ʄɭoʏɗiaɲ ^τ _¢ 01:04, 23 February 2012 (UTC)

The purpose of tagging with {{coord missing}} was to help people to find remaining articles needing coordinates, when most suitable candidates had been done. That's not the case with KML, as most suitable articles don't have the file, so finding ones that need doing is not an issue. What purpose would tagging them all, now, achieve? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:02, 23 February 2012 (UTC)

It's a low cost means of putting together categories of articles missing the template. Sure, we could go through existing roads & rivers categories but it'd soon get annoying picking up articles to KML, only to find that they already have KML. I don't think there's an earliest point at which we'd want such dedicated categories. The cost is that the kml missing would need to be removed when a KML is added - that does not seem to high to pay. Note, too, that the possibility is that US roads can be KMLd by a bot pretty much en masse ... that might knock out several thousand. --Tagishsimon (talk) 14:10, 23 February 2012 (UTC)

With any luck as high as 60% of all road articles. It's probably easier to add them to all articles now rather than doing half of them, then trying to sort out the remaining half to tag. - ʄɭoʏɗiaɲ ^τ _¢ 14:40, 23 February 2012 (UTC)

In the US Roads project, we currently have a yes/no parameter for whether an article has a map in its infobox, and categorizes the articles accordingly. Perhaps instead of using a mainspace tag, all applicable wikiproject could use such a parameter on their project tag. This would mean we wouldn't have to tag thousands of articles; we could just assume that any article that hasn't had |has-kml=yes (or whatever) added to its project tag to not have a KML yet. —Scott5114↗ [EXACT CHANGE ONLY] 19:20, 23 February 2012 (UTC)

That makes it a bit more of a pain to maintain; when adding KML one additional page must be edited; when checking for KML and no KML-flag, two pages must be compared rather than a single page. --Tagishsimon (talk) 19:23, 23 February 2012 (UTC)

Assuming that "tag" just means "add a hidden maintenance category", as higher-visibility maintenance messages can be annoying to many readers and some editors.

Even so, isn't it premature to bulk edit when major changes to the KML file upload process are probably immminent? A brief delay would allow most editors to learn about the new technique after its key aspects have stabilised, avoiding confusion at the likely changeover.

Alternatively, it might be easier, at least initially, instead of categorising lots of articles that are missing KML, simply to get {{AttachedKML}} to add a hidden category to all its transcluding articles indicating that KML is not missing, and then use Dschwen's Linkintersection tool to list all articles which are in a highways category (or other relevant cat) and not in the non-missing KML category.

Also, {{AttachedKML}} is inconsistent with the naming of other templates. {{Attached KML}} or similar would be less likely to be renamed in future (if it is not being merged with {{Coord}}).

— Richardguk (talk) 20:34, 23 February 2012 (UTC)

Tagging does indeed mean addition of a hidden category only. No nag-boxes. If we anticipate major changes to the way this is done, in a meaningful timescale, then perhaps we should delay. I'm not convinced that we have a timescale for such changes ... I'm not seeing much headway being made in the issue of loading KML files onto the commons.

Alternative approaches are interesting, but... right now we have an infrastructure set up for tagging and category creation, and so can for do for KML-missing what's already been done for coord-missing - and which in my estimation has led to thousands of articles being tagged - which is to say it's a reasonably beneficial approach. The tool approach doesn't give us quit the same as the tag and category approach: either we leave users to roll their own queries, or else we have to get someone to pre-roll queries compatible with the sorts of categories coord-missing gives us.

There is, too, a potential benefit in taking the tagging approach, which is that the subject line of the edit could usefully point back to instructions on how to KML, meaning that we bring the new method to the attention of editors who have the article(s) on their watchlist. By contrast, the tool method is silent and does nothing to promulgate knowledge of KML amongst the community.

For these reasons, I'd urge that we go with the tagging route, either now or (if changes are imminent) soon. And so I turn the question around: whilst admitting that there are alternative approaches, are there any strong objections to us getting on with this now?. thanks --Tagishsimon (talk) 13:06, 24 February 2012 (UTC)

Thanks for your clarification and well-reasoned reply. I certainly have no strong objections given this considered approach. But, addressing the uncertain timescale for system changes (acknowledged in your final paragraph), is anyone well placed to report back here on the MediaWiki perspective? It would be good to get some developer feedback here. (This also raises the bigger question of whether the benefits of online-editing and file uploading should be combined for other types of sanitised file, so that other xml- or text-based formats could be downloadable and editable here and/or on Commons.) — Richardguk (talk) 22:46, 24 February 2012 (UTC)

I've restarted some discussion at Bugzilla, which is where we need to get them enabled. - ʄɭoʏɗiaɲ ^τ _¢ 23:06, 24 February 2012 (UTC)

Outlines

I've not yet participated in this discussion, but have been watching with interest. I've been using PHP MapScript (from MapServer) to generated maps for Wikipedia for some years; and it turns out that the latest version of MapServer (version 6) supports direct KML output in addition to the SVG output I normally use. So, another application of this will be to show outlines of counties and townships and the like, overlaid on Google and Bing maps, and I'm presently working on code to auto-generate KML output based on the same U. S. Census data that I've used to generate static maps. MapServer also makes re-projection of data very easy. I'll post some examples when they're ready; of course it's much like what Dschwen has already demonstrated, but I'm looking forward to applying this concept to some of the articles I normally work with. Omnedon (talk) 18:39, 24 February 2012 (UTC)

How do you connect the county data from the SHP file with the correct Wikipedia article. I looked at it this morning using the tl_2011_35_cousub.shp shape file (TIGER line data). Firs I had to combine polygons with the same FIPS code to get the counties as polygons, but the county name is not in the shape file (just the county sub division name). I would have to fetch a table that connects FIPS to county name and then have a bot write the KML to the correct articles. A lot could go wrong here. --Dschwen 21:09, 24 February 2012 (UTC)

With MapServer you can filter on the county name or FIPS code, or run a query to pull the name of a county shape; I've been doing that with PHP code for some time. I just need to work through the process of generating KML output instead of SVG output, which I hope to do this weekend, and then I can post my progress and you can see what you think. I already have the code to show the border of any given township or county, and nothing else (which just meant stripping down the code I used to produce SVG maps from various data layers), so it shouldn't be a problem. I have some samples of maps on my user page; I produced them this way, except those usually require some manual tweaking to make the labels look nice. Omnedon (talk) 21:22, 24 February 2012 (UTC)

Of course, I'm talking about doing this outside of Wikipedia, then uploading the resulting KML. You may be talking about doing it dynamically, which would be a different process. Omnedon (talk) 21:25, 24 February 2012 (UTC)

Hm, I'm actually very close to bot-uploading KML outlines for all counties in the US (and adding the respective AttachedKML templates). --Dschwen 22:10, 24 February 2012 (UTC)

OK, then we've been working along similar lines recently. I bot-uploaded SVG location maps of thousands of townships starting some years ago; what I've been working on the last few days is a modified version of the same basic process. I think this will be an excellent addition to those articles; how close are you to being done with it? Omnedon (talk) 22:28, 24 February 2012 (UTC)

Autogeneration of U.S. highway KML

I can now extract both the coordinates and the accompanying metadata from the U.S. Department of Transport's shapefiles, so I'm pretty much ready to generate some sample KML.

There are a few little things that need to be worked out: for example, the coordinates are WGS80 and will need to be converted to WGS84.

I've noticed that there the KML files that have been generated so far use a number of different KML idioms: does anyone have any clear idea about what I should be using as a model? -- The Anome (talk) 14:51, 24 February 2012 (UTC)

Oh, I have started working on a script that queries the OSM database. With PostGIS you can output in any coordinate system. Accessing the OSM DB is probably a better solution in the long term, if you want to extend your service to non US structures. --Dschwen 15:03, 24 February 2012 (UTC)

Absolutely agreed: using OSM data is the long-term global solution. I've just gone for the NHPN because it's the biggest bang for the smallest effort in the short term. It's official and authoritative, rather better structured than the OSM data, particularly regarding metadata, is very clearly in the public domain, and will also deal with about 16k of the existing 25k road articles on the en: Wikipedia in one go. Once this is done, I would be very interested in helping with the OSM effort. -- The Anome (talk) 15:18, 24 February 2012 (UTC)

Ok, sounds great. Fire away! --Dschwen 15:22, 24 February 2012 (UTC)

It's looking like KMZ may be the format we need to work with (hopefully only until IE 6 drops below 1%). Can your generator create a KMZ? - ʄɭoʏɗiaɲ ^τ _¢ 15:37, 24 February 2012 (UTC)

Please no KMZ, that would be a major pain. IE6 'is below 1%, atleast in the US [3]. --Dschwen 16:32, 24 February 2012 (UTC)

Agreed. It is below 2% in most of the developed world;[4]

KMZ would just be one more hurdle against user friendliness. - ʄɭoʏɗiaɲ ^τ _¢ 21:59, 25 February 2012 (UTC)

If it's got a spec, I can generate it. ;) Presumably the KMZ stuff is to avoid IE6 being HTML-spoofed?

However, for the initial test runs, I'd prefer KML, because it's all readable text, and thus more wiki-friendly and easier to debug and hack by hand, and we can just use the talk-subpage hack to put it in.

I think the best thing to do is to generate some very basic KML, with only polylines and simple text labels. I notice that a lot of the KML that's been generated has references to Google image resources for pushpins: I'd rather not do that. Also, although I have a heap of metadata available to embed, it doesn't seem like a good idea to embed it at the moment, until we have some conventions about what metadata we should be embedding in these files, and with what conventions. So, what I'd like to do is to generate minimal KML that does that and nothing else, preferably without any styles, or only minimal styles, while still being correct KML that both the Google and Bing tools will accept. -- The Anome (talk) 15:40, 24 February 2012 (UTC)

Yep, IE6 continues to haunt. The pushpin is default on Google Earth made KMLs, but one of the ideas I mentioned when I introduced this was us creating our own set of PD icons to use.

Have you given a read through Google's documentation? They describe the syntax/structure of the files in good detail, so that may help with determining the minimum amount of information needed. - ʄɭoʏɗiaɲ ^τ _¢ 15:52, 24 February 2012 (UTC)

I'll just go and put together an example. -- The Anome (talk) 16:01, 24 February 2012 (UTC)

I have in mind omething like User:The Anome/NY 174.kml, only with fewer decimal places of excess precision... -- The Anome (talk) 16:09, 24 February 2012 (UTC)

Now reformatted to use named styles. Do we actually need any styles at all? -- The Anome (talk) 16:15, 24 February 2012 (UTC)

No, it doesn't look like we need styles at all to validate, and Google and Bing look to be reasonably OK with this data: see http://maps.google.co.uk/maps?q=http:%2F%2Fwiki.riteme.site%2Fw%2Findex.php%3Ftitle%3DUser:The_Anome%2FNY_174_a.kml%26action%3Draw&hl=en&sll=53.800651,-4.064941&sspn=24.07088,33.222656&t=m&z=12 . Does anyone have any ideas for improving this? -- The Anome (talk) 16:40, 24 February 2012 (UTC)

I would prefer styleless KML. That would automatically enforce a consistent look for all KML files. WMA renders your output just fine. This is all very exciting. If styles should be used I plan on adding style/named-style support to the WMA in the near future (but I will make it optional, allowing people to switch styles on and off). --Dschwen 18:47, 24 February 2012 (UTC)

Styleless KML it is. -- The Anome (talk) 18:49, 24 February 2012 (UTC)

Can the colour of the line be changed without using styles? If not, it would eliminate the ability to show additional features. For example, our highway maps use red as the colour for the topic. But, say you want to add a couple additional lines showing an old alignment of the highway. These would need to be a different colour so they could be identified. - ʄɭoʏɗiaɲ ^τ _¢ 20:36, 24 February 2012 (UTC)

I think it's possible to reference external styles from KML, by creating a separate KML file that just contains style information, and using the <StyleUrl> feature of KML. In which case, we could define "semantic" styles to use in the core KML, and define them all in a single common file. -- The Anome (talk) 20:44, 24 February 2012 (UTC)

And here's a first example of actual (albeit fragmentary) KML output: U.S. Route 270. There are a lot of things to fix here, particularly regarding the selection, sorting, naming and possible merging of the highway segments, but it's a start. -- The Anome (talk) 18:11, 24 February 2012 (UTC)

OK, I've now got data parsed and ready for adding KML data to more than 6,000 articles about U.S. state and federal routes. I'll start generating files, then upload a few of them by hand, and see where this gets us. -- The Anome (talk) 19:51, 24 February 2012 (UTC)

Can you share your code for extracting a feature from a shapefile and writing KML output. I'm looking at doing the same thing for county outlines. --Dschwen 21:10, 24 February 2012 (UTC)

Yes, certainly, See User:The Anome/code/nhpn to kml.py and User:The Anome/code/nhpn values.py for the NHPN file decoder. Note that this is quick-hack prototyping code: I've not yet had time to check things like the coordinate system transforms, so it currently just makes the assumption that the input data uses the WGS84 datum, and the code is very inefficient -- it makes a single pass over the entire NHPN file to extract just one road -- and does not have any of the cross-checking that a production version of the code would have. -- The Anome (talk) 11:20, 25 February 2012 (UTC)

Progress report: I've now got the sorting, merging and KML-generation code written and tested, and I'm now working on merging the road fragments from the database into larger segments to make the generated KML more easy to understand when viewed in a KML viewer. -- The Anome (talk) 21:36, 25 February 2012 (UTC)

Do share an example when you can, I'd love to see this! - ʄɭoʏɗiaɲ ^τ _¢ 21:59, 25 February 2012 (UTC)

Here you go: see User:The_Anome/Alabama_State_Route_21_ter.kml for an up-to-date example of one of about 7k generated KML files. Google Maps page: here (URL slightly mangled to defeat server-side caching)

Regenerating the entire set of KML pages from the NHPN dataset takes about 5-6 minutes each time. There's still lots that can be done: I want to sort the segments into some kind of coherent end-to-end order, investigate the reasons why some apparently-mergeable segments are not being merged into one another, and I'm currently contemplating adding pushpins for road junctions, which could also be calculated from the same data set.

I'm also trying to get on top of the various names for what the database calls "State Routes" that actually differ from state to state. -- The Anome (talk) 01:16, 26 February 2012 (UTC)

There is an odd side branch on Madison Ave in Montgomery,AL. And a segment is missing further south. Any idea why? --Dschwen 01:34, 26 February 2012 (UTC)

Not yet, although I can tell you that the KML for each road is already collaged together from many different segments in the database. This is necessary because roads, and these database entries, are split across county jusrisdictions, individual segments can have multiple identities at, for example, state, national and county levels. The spur may well be real: I've seen other spurs in real roads. The missing segment may well just be missing in the database. You can see the code that generated this file at User:The Anome/code/nhpn to kml.py.

Although we're getting close to the point where I can present sets of review files, ready for people looking for this sort of glitch, this file is still a work-in-progress: and there arequite a few wrinkles I know about already that I'd like to smooth out before presenting sets of files for public review. -- The Anome (talk) 01:47, 26 February 2012 (UTC)

Update: there are only about 3.5M total points in the database, so a big in-memory binning/hashing system should be good enough to sort out finding out which segments might be close enough to intersect one abother, and then the final O(n^2) road-intersection calculation can be made based on rach of the segment pairs found. But that's something for another day. I'm tired now. -- The Anome (talk) 02:34, 26 February 2012 (UTC)

OK, a question. Does anyone care about the segmentation of the route into segments depending on whether the road shares its name with others? If I let the program ignore those distinctions, and just put out the top-level road description, many more segments would be merged with one another, leading to neater KML files. -- The Anome (talk) 02:17, 26 February 2012 (UTC)

Autogeneration of U.S. county outlines

In the meantime I have been working on a bot to add US county outlines to all county articles. I've put up a botrequest and asked for comments at WikiProject United States and WikiProject U.S. counties. The bot is pretty much ready for deployment as soon as I get the green light at the bot request. One element of feedback was regarding the appearance of the AttachedKML template and a suggestion to incorporate the GMaps/BingMaps links into the county infobox template. --Dschwen 21:54, 25 February 2012 (UTC)

Use of Coord template on Meta-Wiki

I think it would be nice to display the coordinates of the meeting place on Wikimedia Meetup articles, which are held on Meta-Wiki, e.g. meta:Meetup/Manchester_11. This would mean enabling the Coord template to work on Meta-Wiki somehow, and I'm not sure how to do that.
Is is possible to call templates across Wikimedia projects? Or can we just copy the template code over to Meta? I have tried to do both without any success - there are so many sub-pages to the template that it's not at all straightforward.
I guess we don't need anything too fancy on Meta, just something to display dms coords in the article title with a link to Geohack.
Thanks in advance, Bazonka (talk) 09:34, 24 February 2012 (UTC)

It's not possible to call templates from other wikis. :( --Rschen7754 09:45, 24 February 2012 (UTC)

Yeah, I thought as much. I reckon the best thing would be to create a simpler Coord template from scratch, specifically for Meta. Bazonka (talk) 09:48, 24 February 2012 (UTC)

Remind me later, and I'll knock one up. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:42, 24 February 2012 (UTC)

You didn't remind me, but here it is anyway: http://meta.wikimedia.org/wiki/Template:Coord ;-)

Please note that it's much simpler than our {{Coord}} (though it remains compatible with it), having only:

• two parameters
• decimal values
• inline display

Hope that's of use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 1 March 2012 (UTC)

Discussion at WT:MOSICON regarding Template:Coord

I have started a discussion at WT:MOSICON about how {{Coord}} used in prose relates to WP:MOSICON. Your input is appreciated. Thanks. –Fredddie™ 00:23, 27 February 2012 (UTC)

Good suggestion for AttachedKML

At my bot request page User:Headbomb suggested That stuff really should be in template space, not in talk namespace. Have have something like {{AttachedKML|ARTICLENAME}} transclude Template:AttachedKML/ARTICLENAME. That sounds like a sensible suggestion. This scheme would make re-use of on article's KML in a different article easy. The ARTICLENAME parameter could be optional (defaulting to the current article). It also provides a nice namespacing for the KMLs attached using this template. --Dschwen 03:33, 28 February 2012 (UTC)

Given the devs seem to have no intention of doing something with the bug or filters, this may be the best option. - ʄɭoʏɗiaɲ ^τ _¢ 06:08, 28 February 2012 (UTC)

Yes, that seems like a better idea than the current talk space convention. If we get consensus on this, we should move all the existing KMLs to the appropriate new page names before we start bot-creating thousands of new KML pages. -- The Anome (talk) 12:50, 28 February 2012 (UTC)

So... how should we proceed? I don't mean to be too pushy, but I would really like to see the momentum kept up on this project. Can you run a bot to move the existing KMLs. The template change should be trivial. --Dschwen 19:06, 28 February 2012 (UTC)

I don't think there's that many to move... --Rschen7754 19:16, 28 February 2012 (UTC)

Sensible. I guess the relevant list is Special:WhatLinksHere/Template:AttachedKML (or a subset of mainspace transclusion-only links). But there's currently a non-template external KML link substed at Ontario Highway 401 in the {{Infobox road|map_notes=...}} (in addition to {{AttachedKML|display=title,inline}} in the external links), so already methods are diverging!

Suggest that AttachedKML have a new optional parameter to allow special cases of transclusions into articles with names different from the KML subpage name.

— Richardguk (talk) 20:00, 28 February 2012 (UTC)

There are about 50 already. If you want to do it manually, be my guest. The AttachedKML template should have the format

{{AttachedKML|pagename}}

With pagename defaulting to the current article. The display parameter should not contain a title option. That would be confusing. Make it inline,box. Where box makes the right floating box, and inline just generates minimal links. --Dschwen 20:27, 28 February 2012 (UTC)

What is confusing about the title links? I prefer it that way and its the equivalent to what a single coordinate is now. - ʄɭoʏɗiaɲ ^τ _¢ 22:05, 28 February 2012 (UTC)

Title links have the potential to clash with existing article coordinates. --Dschwen 22:18, 28 February 2012 (UTC)

Certainly, but what about for the articles where a title kml is more appropriate than a title coordinate? - ʄɭoʏɗiaɲ ^τ _¢ 06:01, 29 February 2012 (UTC)

There seems to be no need to have a title link for multiple external websites; they don't have the same purpose as title coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 1 March 2012 (UTC)

Just like there seems to be no need to have random strings of bluelinked numbers in highway articles. :)

Both your assertions are baseless, illogical and grabbing at straws. - ʄɭoʏɗiaɲ ^τ _¢ 17:20, 1 March 2012 (UTC)

I have justified my comment with a reason; yours on the other hand, have been debunked several times in recent months. Meanwhile, you are quite correct on one point, there is no need for random strings; that's why we have none. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:28, 1 March 2012 (UTC)

You didn't justify anything. You simply said "There doesn't seem to be a need" (according to you) and then made a worthless assertion "they don't have the same purpose as title coordinates". You're right, they actually show the whole linear feature instead of one point on that feature. - ʄɭoʏɗiaɲ ^τ _¢ 01:39, 2 March 2012 (UTC)

A lack of understanding on your part does not constitute a failure to provide justification on mine. to answer the question which you strangely posed in your edit summary, but not your comment, the purposes (plural) of title coordinates include linking to the intermediate GeoTemplate tool; identifying the coordinates as being the centroid for the subject of the article and not merely a point referred to within it, and providing centroid coordinates to external partners such as Google. After we've been discussing this for so long, I'm genuinely surprised you didn't already know that; still, perhaps that explains your incomprehensible objection to them? Now that you know better, you have no excuse to persist in it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:50, 2 March 2012 (UTC)

1. I don't care about Google, or Google's Wikipedia layer. That is their problem, and they can bloody well adapt to our new ideas (unlike you).
2. A centroid is useless on a curvy line. Rarely is the centroid on the line. Dschwen's WMA, however, makes it perfectly clear that a centroid CAN be extracted from the KML data.
3. I don't care about the GeoTemplate tool. It can be adapted as well.

-- ʄɭoʏɗiaɲ ^τ _¢ 17:18, 2 March 2012 (UTC)

Noted that you don't care about our external partners and re-users; or the tools which assist our users more directly. However, others do, so you'll just have to live with that. Every map we display has a centroid, and they already ready work well for "wavy lines", using "title" coordinates, so in your second point is simply a further demonstration of your lack of understanding, or wilful concealment of understanding, of how these things work. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:58, 2 March 2012 (UTC)

Google is not our "external partner". They are a for-profit enterprise operating entirely in their own interests. I focus on the NON-mobile (Smart phones are the new technology; they will adapt to us, not us to them), English Wikipedia, not on Google Maps. The tools can likewise be adapted to work with the more informative, representative and comprehensive data: The KML. You can tell me I don't understand, or you can try to belittle or denigrate me all you want (you're doing a piss poor job though), but the fact is you're running a one-man campaign for your method, and so you're going to get nowhere. I'm going to ignore you from here on out, as everybody else here was smart enough to do long ago. - ʄɭoʏɗiaɲ ^τ _¢ 19:25, 2 March 2012 (UTC)

Template changes

I added some magic to the {{Attached KML}} template. It now detects if the page Template:Attached_KML/ARTICLE exists and if so it uses that page to generate the KML links. If it doesn't exist, it defaults to Talk:ARTICLE/KML. This will allow us to start moving KML data without major disruptions (I guess the article pages still will have to be purged for the template to update according to the new conditions, but correct me if I'm wrong). --Dschwen 22:38, 28 February 2012 (UTC)

Alright, I've switched everything over to the new format as well as changing the template name to include a space. - ʄɭoʏɗiaɲ ^τ _¢ 01:50, 29 February 2012 (UTC)

Great, thanks! I'll simplify the template tomorrow. Must sleep now. --Dschwen 04:46, 29 February 2012 (UTC)

All taken care of, no need to worry :) - ʄɭoʏɗiaɲ ^τ _¢

I've fixed the hardcoded external links in Ontario Highway 401 {{Infobox road|map_notes=...}} which bypassed {{Attached KML}}. But as hardcoded links could cause problems if/when the method changes again, and as the KML links are also included at the foot of the article via {{Attached KML}}, you might want to consider templating the hardlinks or removing them altogether. — Richardguk (talk) 14:53, 29 February 2012 (UTC)

They're there to satisfy a reviewer for now... I personally can't stand them and its out of format to the other 45 featured highway articles. That should really be one of the only exceptions of a hardcoded link. - ʄɭoʏɗiaɲ ^τ _¢ 15:41, 29 February 2012 (UTC)

Once FA discussion identify improvements, they can be added to past FAs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 1 March 2012 (UTC)

Yeah, that'd make sense if it wasn't exact same logic you used against the argument that we have 40 highway FACs that don't make use of coordinates. Good luck getting consensus for your little plan. - ʄɭoʏɗiaɲ ^τ _¢ 17:22, 1 March 2012 (UTC)

Um, what on Earth are you talking about now? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:56, 1 March 2012 (UTC)

That your argument that this FAC sets the precedent for others is a load of hogwash, since the 40+ highway FAs that already exist sans-coordinates were tossed aside by you. Good luck getting consensus to put coords in the 40+ existing FAs. - ʄɭoʏɗiaɲ ^τ _¢ 01:39, 2 March 2012 (UTC)

I don't recall mentioning precedent; I talked about improvement. Your argument, which boils down to "we've always done it this way", is not persuasive. And thanks, but I don't need luck. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:54, 2 March 2012 (UTC)

You do need consensus. - ʄɭoʏɗiaɲ ^τ _¢ 17:18, 2 March 2012 (UTC)

Thank you, but granny already knows how to suck eggs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:08, 2 March 2012 (UTC)

There is discussion of where to locate the links, in Wikipedia:Bots/Requests for approval/DschwenBot]. I've suggested it would be better here, or preferably on a dedicated sub-page of this one. It may be best to have single link to a GeoTemplate-like page, which can similarly link on to mapping services, as well as the KML page itself, plus downloadable KML, and include explanatory text. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 1 March 2012 (UTC)

More changes

Please provide some input at Template talk:Attached KML. There is a proposal to add a .kml extension to all KML subpages under that template. This is currently holding up my bot request and further deployment of KML data into articles. --Dschwen 20:37, 7 March 2012 (UTC)

German-Wikipedia-style maps

The German-language Wikipedia is now using a really cool map plugin which uses OpenStreetMap mapping data, served by the toolserver. I think it looks much better than the current mini-map tool that enwiki has currently. See de:Hilfe:OpenStreetMap/en for full details. -- The Anome (talk) 18:45, 3 March 2012 (UTC)

Well, I fell like I have to defend my baby. WMA uses OSM data as well (currently only at the high zoom levels, but I'm working on redoing low zooms. I personally do not like the mystery meat navigation of push pins, and prefer my textual labels. As a consequence of having clickable text labels I made the decision to have no text rendered on the map tiles themselves (I believe that would be rather confusing). Lastly the OSM map project is not very flexible, so things like:

• a thumbnail layer from commons (with a quick view of the image when clicked and preferential display of featured, valued and quality images)
• importance sorting of labels
• article synopsis in the map (hold Ctrl and hover a label with your mouse, an abstract of the article is generated and displayed to give a quick idea of what the article is about)
• the display of all article coordinates on the map (with highlighting on hovering and quick scroll to the location the coordinate appears in the article
• the display of attached KML data (developed hours after the first KML data was introduced)
• keyboard navigation for the map
• a free satellite layer (Landsat images)

you currently don't get with the OSM gadget. Just food for thought for people who are quick to dismiss the WikiMiniAtlas. --Dschwen 20:43, 3 March 2012 (UTC)

I like how the german version has the size and location of a full width banner and doesn't cover any of the article. That way you can just leave it open as you read the lead and can go back up and recheck the location, surrounding area, use it for browsing etc. --U5K0'sTalk_{Make WikiLove not WikiWar} 21:06, 3 March 2012 (UTC)

I could add that to the WMA as well (if people want it). However this makes it less ergonomic for articles with more than one coordinate, and/or if the coordinate does not appear at the top of the article, but below in the article body or references section. --Dschwen 21:11, 3 March 2012 (UTC)

It is sometimes a nice feature. Would it be hard to make that an option on WMA's options? —EncMstr (talk) 04:47, 4 March 2012 (UTC)

How about making it that way just for the top of the article coordinates? --U5K0'sTalk_{Make WikiLove not WikiWar} 12:01, 4 March 2012 (UTC)

Hi, Dschwen, and please accept my apologies if my comment above came over as as criticism of your work. My intent wasn't to denigrate your work, but to call attention to the nice visual features found in the dewiki tool: the whole-screen-width window and consistent use of OSM data at all zoom factors are the ones I have in mind. I completely agree with you that text labels are better than pushpins and that importance sorting is a good thing, and I'm also not sure that the popup mini-previews add anything to the dewiki tool. If you can use some of the ideas from the dewiki tool to improve your map viewer, and create something better than either, that would be great. -- The Anome (talk) 15:29, 4 March 2012 (UTC)

Coordinates in infoboxes

Members of this project might like to note that coordinates in infoboxes are displayed on our increasingly-important mobile site and apps; whereas "title" coordinates are not. This is particularly relevant, as the new version of the app (currently in beta) allows users to select coordinates, and thus easily find other articles, "nearby" to them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:35, 2 March 2012 (UTC)

Sounds like that app needs to be fixed! --Dschwen 16:12, 2 March 2012 (UTC)

The same applies to our printed pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:08, 8 March 2012 (UTC)

Invisible error

Could one of the programming-literate people around here explain why the article Shooter's Hill shows up here as containing an error Bad char '|'? As near as I can tell, it must have something to do with the way that {{Infobox UK place}} is passing on, or parsing, or whatever the word is, the coordinates it contains, but the problem doesn't seem to be present in the other articles transcluding that template; and I feel silly staring at the edit window for the article, trying (and unable) to see what's different in this case. The "error" doesn't seem to be actually affecting anything, but now I'm curious. Deor (talk) 14:28, 12 March 2012 (UTC)

I suspect the toolserver's database is slightly out of synch with the live one. —Stepheng3 (talk) 15:03, 12 March 2012 (UTC)

The error report has been showing up at coord-enwiki.log for a number of days. Why would it be just the one article? Deor (talk) 15:10, 12 March 2012 (UTC)

It's caused by a manual external link from another page: User talk:94.4.51.243#Place/district vs geographical feature (disovered via Special:LinkSearch). — Richardguk (talk) 15:14, 12 March 2012 (UTC)

Thanks. I'm still not quite sure why that shows up in the coord-enwiki.log report as an error in the article, but I'll just add it to the ever-growing list of things about computers that I'll probably never understand. Deor (talk) 20:30, 12 March 2012 (UTC)

The log seems in effect to list all the links at Special:LinkSearch/toolserver.org/~geohack/geohack.php but reports the "pagename" parameter within each link instead of reporting the wikipage at which the link is located. For links using the standard templates, the two are identical; but manual links (like the one above) could contain anything in the parameter. — Richardguk (talk) 00:17, 13 March 2012 (UTC)

Methods for map links for linear features & outlines

A quick heads up to a new method implemented post the Highways RfC, which can be seen at Highway 401 and produces a line overlay on Google and Bing - thanks due to Floydian, as I understand it; and Template:GeoPolygon from the Commons which makes use of OSM shapes to provide outlines. --Tagishsimon (talk) 21:38, 8 February 2012 (UTC).

Thanks for the link- and the good work you did in notifying us that there was an RfC on a page I never visited. Interesting to see the idea being trialled. It basically is the early stages of good news. It still needs a lot of work and the Ontario team could benefit from feedback I will start a subsection here for observations.--ClemRutter (talk) 00:09, 9 February 2012 (UTC)

Where is the code that does this magic- can someone give me a clue? If I see an error what do I change? Could I suggest we provide a few more examples I suggest a couple of small roads Nico Ditch and Deansgate, a long one Via Domitia and a well established UK A road.--ClemRutter (talk) 11:03, 9 February 2012 (UTC)

I did Deansgate (see bottom). I'd have to know the area personally to trace the Nico Ditch, there's no way I can find it. As for error fixing, ideally we can eventually upload KMLs, in which case you'd download it, open in Google Earth, fix, save, upload. For now there are an extra couple steps: You have to copy the text off wiki, save the text on your computer as a .kml, fix with GE, save, open the .kml with a text editor, and copy and paste it to wikipedia. - ʄɭoʏɗiaɲ ^τ _¢ 15:08, 10 February 2012 (UTC)

Highway 401

1. On Firefox on a PC the links to Google/Bing/? is too small and obliterated by a hat tag. (Monobook) Better in (Vector) but the hat tag had switched itself off.

2. On Samsung Android the link does not appear.

3. No link to it in infobox.

4. Within Google image - the links to labels is by default on- would it be better to set the links to wikipedia to default on

--ClemRutter (talk) 00:09, 9 February 2012 (UTC)

In regards to number 2 - do you mean the mobile site or the regular site? --Rschen7754 01:07, 9 February 2012 (UTC)

Smart phone- Samsung. Its my new toy so I am testing it out and entering the world of yoof! The GPS seems to work to 3dec places (60m accuracy).

Is that on the mobile site, en.m.wikipedia.org? Or the normal one? --Rschen7754 10:50, 9 February 2012 (UTC)

The app is pulling the data from en.m.wikipedia.org. --ClemRutter (talk) 09:34, 10 February 2012 (UTC)

Haven't checked yet. But that is important. There must be mirrors out there.I'll do it later today--ClemRutter (talk) 11:03, 9 February 2012 (UTC)

3 is redundant in my opinion. The 401 example has a bit of an overlap issue on smaller screens, but that will go away when the FAC ends; coord suffers from the same issue. Not sure what to do about 2. 4 makes sense, though I'm not sure how. - ʄɭoʏɗiaɲ ^τ _¢ 01:15, 9 February 2012 (UTC)

Worth noting (just about) that it doesn't work with IE6. (But then again, what does?). It results in a map in google without overlay line; and a pretty much hung Bing, showing me a picture of the UK. Institutional users tend not to have any discretion about what sort of browser is supplied on their locked down machines. --Tagishsimon (talk) 10:39, 9 February 2012 (UTC)

And is there a means by which we can specify a push-pin or push-pins somewhere along the line - preferably labelled - to use the KML to show a point feature within the context of a linear feature. Can we determine the centre point for the map - e.g. to centre a feature that happens to be 4/5ths of the way along a linear feature? --Tagishsimon (talk) 11:11, 9 February 2012 (UTC)

I think everyone here interested in developing further should give this as read, as its Google's documentation for the KML format. I know its possible to set multiple, different and labelled pushpins (or graphic of your choice; IOW we can create our own) to a position of your choice. I found this, which may be what is needed for sizing and centring the map. - ʄɭoʏɗiaɲ ^τ _¢ 13:06, 9 February 2012 (UTC)

You can do all this in the Wikiminiatlas. I strongly suggest to keep using {{coord}} for point features, rather than point labels in KML. The latter would just divide the geocoding effort and make data extraction more complicated. I'm also not terribly excited about the customization possible with KML. I'd rather have a standardized uniform look (which I force in the WMA by ignoring the custom styling (for now, because it also means a lot of work!)). --Dschwen 13:57, 9 February 2012 (UTC)

I mean in terms of us creating wikipedia graphics rather than relying on the google icons. I also agree that coord is far more appropriate for point-based topics; I meant that you can label the points along a line (ie the exit numbers, or important points) - ʄɭoʏɗiaɲ ^τ _¢ 14:12, 9 February 2012 (UTC)

"coord is far more appropriate for point-based topics" - sense at last. A list of highway junctions is a list of point-based topics. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:50, 9 February 2012 (UTC)

The individual junctions are not topics, the article title is the topic. - ʄɭoʏɗiaɲ ^τ _¢ 16:00, 9 February 2012 (UTC)

Um, yes they are. Your edit summary, "you're confusing a machine and a bolt", appears to bear no relation to your comment, BTW. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 9 February 2012 (UTC)

If the Bing link is causing big problems in IE6, then there at least needs to be a way of making it degrade gracefully (e.g. by hiding the link in IE < 7). I've commented more generally about {{AttachedKML}} at Template talk:AttachedKML#Integrating KML with Wikipedia and Template talk:Coord#Conflicting title display, but clearly we need to bring these discussions to a single page for coherency! — Richardguk (talk) 14:09, 9 February 2012 (UTC)

Indeed. This is probably the most appropriate venue of the lot. - ʄɭoʏɗiaɲ ^τ _¢ 14:12, 9 February 2012 (UTC)

• Yesterday I asked where was the code that does this magicand suggested we provide a few more examples I suggest a couple of small roads Nico Ditch and Deansgate, a long one Via Domitia and a well established UK A road. I want to look at the practicalities of entering the data on a virgin page without leaving the Wikipedia environment. 401 is too long for me find the tagging so could one of you guys just add the necessary code to Nico Ditch and tell us the tools you used so we could replicate the process on Deansgate. --ClemRutter (talk) 09:47, 10 February 2012 (UTC)

• Talk:Ontario Highway 148/KML is a pretty short highway that I've already done. I'm not gonna spend the time on those other roads, but I've got plenty of examples of varying length from Ontario, and the only difference is the coordinates in the KML. - ʄɭoʏɗiaɲ ^τ _¢ 14:40, 10 February 2012 (UTC)

• I decided to do Deansgate (KML), since I have no hope in hell of locating the Nico Ditch. By the way, you English folks really love your Ferris Wheels. The mayor suggested building one in Toronto and was scorned pretty bad. - ʄɭoʏɗiaɲ ^τ _¢ 15:01, 10 February 2012 (UTC)

• That's great- Deansgate (KML), is a nice clean example and gives us some excellent source code. I am following your tutorial, and seeing what how to exploit it. Just keep on being interrupted. I'll open a another section where we can discuss it when I have something to say. --ClemRutter (talk) 18:52, 11 February 2012 (UTC)

• I've created a tutorial for making, uploading and utilizing KML files with Google Earth. Right now it is the second half at Wikipedia:WikiProject U.S. Roads/Maps task force/Tutorial#Creating a KML file. - ʄɭoʏɗiaɲ ^τ _¢ 15:34, 10 February 2012 (UTC)

  Thanks a million for the tutorial. Works great. I have applied it to River Liffey. The next step would be to have points of interest to show links to other articles on lakes passed through, etc. I can see where Dschwen was coming from when he basically says POI in the KML creates a duplicate for maintenance. However, it would be nice to get that in there. Also, it is worth looking at this site gpsies.com. I use it to put in runs / cycles that I make when my garmin goes bonkers (which is surprisingly regular), I then load these to my Garmin Connect training log. Anyway, it allows you load the KML and tweak it and view it on Google / Bing / Yahoo with Map/Sat view. Google Earth doesn't allow you to edit the path too easy. You can then download the KML in Google Earth format, but the KML headers are different and there is extra useless data in the file. Just for intrests sake. Great progress all the same. But where are we with opening the door on this to many articles? DubhEire (talk) 01:09, 12 February 2012 (UTC)

  The other reason I choose a long river was simply because it would take a lot of points. There are 1600 coords in that. It is a 64k file and Loads pretty quick. Gives so much more geo information to the article that a simple coord. I'm very happy with that. Also like the way you have the shorted links that go at the top of the page. That is very neat. DubhEire (talk) 10:54, 12 February 2012 (UTC)

  One more thing. I an trying to implement this onto a National Road route, but it starts in a city centre and there are one way systems in place. This means the route initially has a different Southbound and Northbound route for about 2 km. Then it converges to be pretty much the same, except for another spot midway along route, but that is essentially an interchange that also deals with Southbound and Northbound traffic. Any suggestions how to overcome that? DubhEire (talk) 12:34, 12 February 2012 (UTC)

  I was looking at the data in the KML for River Liffey from Google Earth and I am not overly happy with the scale of the decimal coords in it. It is up to 15 places, where 6 is enough. There is no option that I can see that limits the scale on the output. So I used SED on the KML file to reduce the digits to 6. It loads a bit quicker, but not a massive difference. I also added another placemark to see a POI with a link back to Wikipedia and a picture too. This is a little clunky to implement and not that change friendly. I used the very format that Google Earth outputted the placemark to do this, and ironically it doesn't work straight in Google Maps, but ok in Bing. I am going to add a tributary as another placemark. DubhEire (talk) 16:36, 12 February 2012 (UTC)

  Guys, do not obsess about a 64k file. The panorama in the River Liffey article has 108kB. 64k is nothing. And 1600 points are a tiny number for current browsers and computers. --Dschwen 16:53, 12 February 2012 (UTC)

  For the one way roads, create a second line that is the same colour/thickness for the oneway that goes from north to south or from east to west. The River Liffey example is spectacular! Really shows what we can do with this. I'm researching all the specifics of the language, so hopefully within a couple weeks we can have a tutorial explaining how to meddle with the written code to change styles, colours, linetypes (ie a dashed line for a former routing), add notes, overlays, placemarks, etc. - ʄɭoʏɗiaɲ ^τ _¢ 17:19, 12 February 2012 (UTC)

What a superb piece of work. I just added it to Bridgwater and Taunton Canal#Route, where out of interest I had already add various points of interest for display with the {{kml}} template. So the really neat things is I took the KML output from the KML file and pasted that too into the Talk:Bridgwater and Taunton Canal/KML and bingo, I now have a nice route and all the POIs. --Bob Re-born (talk) 21:33, 12 February 2012 (UTC)

This is actually a bit frustrating to read. You now duplicated data that we had in the article (as coords) and copied it into the KML. Further changes to the coords in the article will have to be fixed manually in the KML. All that to pander to the non-open proprietary GoogleMaps or Bing, which lack the capability to display proper placemarks contained in the articles and links to Wikipedia articles. I do not really like the direction this is taking now. I'd rather see the KML files kept as simple as possible, only containing the essential line data. --Dschwen 21:51, 12 February 2012 (UTC)

The point about duplication is a reasonable one. I will take the POI's out. --Bob Re-born (talk) 21:57, 12 February 2012 (UTC)

Actually, to be honest, the really frustrating thing is that I keep investing considerable amounts of time in an open solution, tailored towards Wikipedia, which already solves problems, like displaying all coordinates contained in an article (and now also displaying KML lines) on a map (which now at high zoom levels uses OSM data (lower zoomlevels to be re-rendered soon)). And nobody seems to give a s&%t here. --Dschwen 21:55, 12 February 2012 (UTC)

Not true. I very much appreciate what you're doing to integrate this with the WMA. I have some coding skills and would be happy to help where possible.

Why can't this be integrated into the wikipedia layer as {{coord}} does now? Do you not believe that mapping services will adopt if we start implementing this on a large scale across our rivers, roads, canals, and more articles? I also don't believe that KML's are overly difficult to learn... no more so than figuring out how to acquire the coordinates from something you're looking at in Google Maps; but in its current form it's daunting. I'd love to be able to just upload them. There are open source equivs to Google Earth (eg. WorldWind, Gaia), and they're all free so it's no different than picture editing software. I agree though that we shouldn't be getting too complicated with initial adoption, however I see no harm in editors incorporating additional details if they're willing to. It's similar to having to research for hours to write a featured article. For example, I'd find great use in a kml of a subway line that also includes placemarks for each station, labelled as such.

Keep in mind this a pretty new standard, and so it's just catching on. Why can't we, as one of the most viewed websites, take initiative in adopting it in an advanced way, if it can benefit readers? - ʄɭoʏɗiaɲ ^τ _¢ 22:08, 12 February 2012 (UTC)

Well, we started using attached KML on commons 4 1/2 years ago, so not quite that new ;-). Coord is not integrated into the Wikipedia layer either (or else I'm not quite understanding what you mean by integrated). I made an attempt to add WikiMiniAtlas as a proper Mediawiki extension, but there are numerous reasons, not to do that. On the toolserver development is much more agile. And WMA, needs a large backend to process, render, and serve the data you eventually see. Multiple custom server programms are running on the toolserver (written in C++) to make this all happen. I would have needed shell access to the Wikimedia clusters to be able to continue working and maintaining the WMA. Toolserver really is the best solution for me (even though it has issues on its own). --Dschwen 22:16, 12 February 2012 (UTC)

I think it looks great to the reader when you see this on a map of your choice. But I think there is still a Proof of Concept for the moment. I feel we need to get more guidelines down and perhaps not rush the use of KML lines in articles until we considered some more details. So, I spent a bit of time going through the implementation and change aspect of attached KML and it is a bit tricky, especially if you need to tweak or extend a track, or have track divergence. It is then natural for someone to add POI and pictures so I did that to see what you would have to go through, which is quite easy to add and change. It would be better if there was a hybrid KML that would take the attached line KML and merge the GeoGroup data into one KML that is ready to go similar to the way GeoGroup does it now. This would eliminate maintenance issues of POI. I would like to see coord extended to use wikilinking of articles and wikimedia images. This just leaves track changes. The river one is interesting because I added tributaries as separate lines. These are viewable on the map and WMA. All in all, attached KML is an interesting approach and not overly complicated for the editors that are frequent here. There are other annoying details like the placeholder icons from Google Earth and the size of the decimal scale in coords. There appears to be surplus data in the KML from Google Earth that just makes it look more complicated to edit than it is. DubhEire (talk) 22:44, 12 February 2012 (UTC)

Nico Ditch

I have used the Google Earth method to add KML to this article, Nico Ditch, and invited the Manchester editors there to add comments here. User:Floydian can you tell me if I have done it right. As you saw it was a bit of a challenge as most of the locations had to come from textual sources, then located on Google maps- and then crosshair selected on Google Earth. --ClemRutter (talk) 01:18, 12 February 2012 (UTC) Temperature -4C

Looks great for me, although you may want to add a few more point in the midst of it since its straying from what I believe is the line of the ditch. - ʄɭoʏɗiaɲ ^τ _¢ 17:19, 12 February 2012 (UTC)

I'm not sure that the words "Route map" are appropriate for non-road articles; otherwise, looks good. --Rschen7754 23:41, 12 February 2012 (UTC)

..and Outlines

The main section title already states this. Outlines (arealike data) could be usefull as well. In particular when the outlines are not obvious on the map, like for example the extent of a desert, a mountain range (sub-range), the habitat of a certain species etc. Lakes would be a counter example for objects that only need point data in my opinion (the outline should be clearly visible on a map). Anyone interested in whipping up an example. I would add support for filled polygons in the WMA if other people think this application of KML data makes sense. --Dschwen 22:20, 12 February 2012 (UTC)

This would be good for geological features that aren't immediately apparent on a map too, such as dry lakes, ancient lake shorelines, escarpments, dikes. - ʄɭoʏɗiaɲ ^τ _¢ 22:54, 12 February 2012 (UTC)

Ok, I added support for polygons (with holes!). I'll see if I can manage to come up with a real world example to showcase this. --Dschwen 21:44, 13 February 2012 (UTC)

Two examples: Mojave Desert (simple polygon) and Navajo Nation (crazy complex geometry!). Check it out in the WikiMiniAtlas! --Dschwen 22:21, 23 February 2012 (UTC)

Very cool. Navajo seems to confused. Is there a cutout in the interior which is not part of the land? Also, there are lines crossing near Gallup. The means for generating this type of data should be documented for avoidance if it is an easy mistake to make. —EncMstr (talk) 23:12, 23 February 2012 (UTC)

The Google Maps display is not very good. Check out the WikiMIniAtlas. There is no "line crossing" the Navajo Nation land really is split up and checkered. Also in the WMA you can clearly see there is a hole in the territory. --Dschwen 04:06, 24 February 2012 (UTC)

...and a few points

Continuing from I left off

5. Looking at the Bridgwater and Taunton Page- we have {{Commons category}},{{AttachedKML}} and {{kml}} next to each other. They are fixed at different widths. I don't dare break anything by editing any of them. Also we have the BS canal routemap template {{Bridgwater and Taunton Canal map}} which is variable in witdth- there is an issue here too.

6.{{AttachedKML}} isn't written for the user. A better format would include a title with the v.d.e links. KML would then link to a KML page. I suggest this title line should be shaded.

7.Colour of line on Google map. Red stands out but there is a series of defined colours used already see {{Bridgwater and Taunton Canal map}} for more details. Active canals are conventionally a shade of blue. That can be corrected in the tutorial.

8.Google Earth is easy to install on some Linux versions (Xubuntu 11.10) but a pain in others (Ubuntu 10.04)

9.Interesting to see that {{kml}} is called that- it has the advantage that it names the PoIs - maybe it is worth looking if this template can be modded to plot a line too. It seems to have all the components.

10. The KML file given in Deansgate really only has a lot of fixed text embedding three variable:- the map to be used- the colour of line- and an ordered list of -lat,long,0- that uses a space as a separator. It should not be beyond the wit of man to use a complex template to generate one from javascript boolmarklets without having to leave Firefox- though saving the result will be impossible except as a cookie

11. None of this shows on a Android app.

12. On Deansgate I contrived to include it in the infobox. I have the same formatting problem as mentioned in 5.

13. If the template is modded to include a field called postscript then this would neatly embed at the bottom.

14. Nico Ditch (done in orange) was more of a challenge as it was done from textual sources, which often were inaccurate. I needed road names to confirm and for that I needed to have Google Maps running and it was far easier to keep a log of the GMaps booklet generated WGS so I could hand correct the XML later.

15. Formatting problems- the box would have been better if centred.

16. Looking at Highway 401 in Toronto- I wonder about the precision of the co-ordinates the line is given to an accuracy of 0.7 nanometres whereas my SatNam gives +- 7metres.

There we are, a few observations.--ClemRutter (talk) 17:40, 14 February 2012 (UTC)

Great feedback. Bridgwater and Taunton Canal was my first attempt at KML linking using this method - although it was me who added the table of POIs along the route to the article a long time ago. I added the new stuff to see if I could get members of the Somerset wikiproject enthused but have been underwhelmed by their response. I would like to see {{AttachedKML}} more closely resemble the {{KML}} template, and right now I think having both has the ability to confuse. What would be really cool is to have a facility to display both sets of geographical information at the same time - the linear track from the /KML and the POIs from the table. As for the colour, I think blue is a good idea - can you suggest a specific shade to use? --Bob Re-born (talk) 18:58, 14 February 2012 (UTC)

Wikipedia:Route diagram template/Catalog of pictograms

I'm keeping my eyes here guys, so don't think I'm MIA. I just need a few days to break from discussion and only work on articles. - ʄɭoʏɗiaɲ ^τ _¢ 16:33, 15 February 2012 (UTC)

5. Agreed. I've copied the style from {{GeoGroup}} so that they are the same width with the same font size.

6. Wouldn't this make it stand out a lot more from the GeoGroup template? I think we should try to get kml added to the allowed filetypes for uploads.

7. Red is just what we use for the highlighted highway on a map. Each project has its own standards for maps that I believe should be carried over to these KMLs

8. What about WorldWind or Gaia?

9. Likewise, we can have PoI's in the kml as placemarks.

10. I'm not sure what you mean here... a preloaded format to add around coordinates sets?

11. I don't think there has been justification for them to add this to the mobile app... But our uptaking of the format will certainly encourage its further adoption around the web.

12. Individual infoboxes will probably be better off programmed to load the KML file and display it in the preferred way, rather than relying on this template.

13. If you point me to an example where this is used then I will see what I can do.

14. Some things are arguably more difficult to locate using the naked eye. However, with some research and exploration, the results are pretty accurate and certainly a great asset to our articles. Really, this process isn't much more different than making a vector map for an article. It's just more statistical than visual.

15. Wouldn't this make it different from the other similar templates, per 5?

16. The text of it is the output I got from Google maps. I'm wondering if it can be modified, but if not then a simple regex script can strip anything beyond X decimals.

I'd like to come up with a proposal using some of the awesome examples we've produced, post it to the village pump. Get the community on board with this and the KML filetype added to the allowable uploads list. - ʄɭoʏɗiaɲ ^τ _¢ 16:39, 16 February 2012 (UTC)

Regarding KML file uploading: there are already about 120 KML files uploaded at Commons some years ago, made accessible from the parent :File: pages there via commons:Template:Overlay (documented further at commons:Commons:Geocoding/Overlay; e.g. File:Etna eruption seen from the International Space Station.jpg which references commons:File:Etna eruption seen from the International Space Station.jpg/overlay.kml (but note the unexpected redlink if the same KML subpage is accessed indirectly with :File: instead of :commons:File:). I don't know whether KML files can be (or already are) uploaded to enwiki, but it seems unlikely that the ability to upload KML files to Commons will have been revoked since the 120 files were added. — Richardguk (talk) 00:02, 17 February 2012 (UTC)

Maintaining .KML attachment data

I am very pleased that an agreeable solution has been reached. It is clearly advanced enough to be of use for years to come.

I started to explore the product by choosing an article from Special:WhatLinksHere/Template:AttachedKML. The first one I choose—completely at random—was New York State Route 308. Observations:

1. No coordinate is visible when the page opens. I have come to expect to a title coordinate or an infobox coordinate. Especially for something to click on to produce a map.
2. This page provides a static map image of this short highway, but I can't make heads or tails of what it shows. I'd like to zoom it out to get a rough idea of where in New York it is. Perhaps if I were from the northeast U.S., this would not be a desire.
3. The map links are at the bottom of the page. They should be at the top, either in the infobox or above it. Thanks to Floydian's recent change, they look a lot like {{GeoGroup}}'s result and reflexifly draw my mouse cursor to them.
4. The Google Maps link is quite viewable, though somewhat sluggish with the overlay.

• When I zoom closely in: Egad! I see an error here! By flipping the overlay on and off (using the checkbox with the red slash), it is plain that the overlay wanders off the official highway and somewhat north of what is perhaps an old alignment.

But how to fix it? Presumably, I can edit Talk:New York State Route 308/KML directly, but what a challenge—and this is a simple and short road! It would be inconceivable to deal with I-5 at this level.

Also, not to seem unappreciative, but why such extreme high precision on the coordinates? Five places after the decimal is 80 centimeter accuracy—plenty good enough for placement of the painted center line. 15 decimal places is a little smaller than the Bohr model diameter of a hydrogen atom: 8 × 10⁻¹¹ m of map precision vs. 11 × 10⁻¹¹ m hydrogen diameter. Perhaps reducing the precision would speed up map display operations? (I reduced precision on this article, but I could not see any difference.) —EncMstr (talk) 19:25, 16 February 2012 (UTC)

The precision is automatic from the application producing the data. I'm not sure it can be adjusted in Google Earth, but a simple regex script can trim it to n decimals. I know my counterparts in the US haven't been using the title display as I have (see, for example, Ontario Highway 55), but I'm not sure what their stance is on that (I assume it has to do with waiting for this idea to become stable). The KML file can be opened in Google Earth and edited, and this is something that hopefully can be made simpler by having it as an uploadable file type. The copying of the contents into a talk subpage (and subsequent attempts to interpret it) is certainly the most daunting part of this.

The second point you made was one of our early brainstorming concepts - Embedding a interactive, panable and zoomable map into the infobox. However, I think accessibility (esp. wrt older and mobile browsers) is the main issue here.

The last issue is probably to do with the shapefile used, but you are probably right that it is a former alignment of the highway. You'd fix it by copying that KML file into a text editor (notepad), and saving it as a .kml. Now you can open it in Google Earth and modify it. - ʄɭoʏɗiaɲ ^τ _¢ 19:49, 16 February 2012 (UTC)

I've numbered your points for ease of reference. Regarding the first, there is no reason why you should not also use {{Coord}} with |display=title - the recent RfC did not resolve the matter of the use of coordinates (the addition of the /KML option not withstanding), so we're left with the status quo. #3 is a problem, as, if this template is use where {{GeoGroup}} is also used, there will be confusion, and possibly accessibility issues. The difficulty of editing and the undue precision on the KML files provided so far are indeed issues requiring attention. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:42, 16 February 2012 (UTC)

"addition", in scare quotes, because you control the flow of information on this website, right Andy? If editors prefer this method, you have no authority to demand the use of your template over this one. - ʄɭoʏɗiaɲ ^τ _¢ 01:30, 17 February 2012 (UTC)

Once again, Floydian, you attack me for something you imagine I've done. Please point out where I've ever said my [sic] template should be used over this one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:38, 17 February 2012 (UTC)

Regarding reducing precision, the following Python code snippet takes the contents of a KML file in the form of a string, and reduces the precision of all the coordinates there.

def reduce_coordinate_precision(text, digits):
    return re.sub("(?s)<coordinates>.*?</coordinates>",
                  lambda coords_match:
                  re.sub(r"[0-9]+\.[0-9]{%d}[0-9]+" % digits,
                         lambda number_match:
                         ("%%0.%df" % digits) % float(number_match.group(0)), coords_match.group(0)),
                  text)

I'd be happy to run the code in my bot to automatically reduce the precision of KML files to any degree of precision the project likes. -- The Anome (talk) 23:31, 16 February 2012 (UTC)

@Andy: thanks for numbering my points.

@all: I had no idea Google Earth had the ability to edit KML data. While I can download, load the KML data, and view the route, so far I not found a way to alter it. —EncMstr (talk) 23:43, 16 February 2012 (UTC)

Thank you for that code The Anome. I'll add a category to the template to identify which articles are currently utilizing KML.

EncMstr, when you open the kml in Google Earth, it should show up in the Places pane on the left. You can right-click the line, which should be named, and select properties. Leaving the properties window open to edit the line, you can select a point on the line and then right-click somewhere else on the map to delete the selected point. Similarly, with a point selected, you can left-click to add a point to the line next to the selected point. I hope that's clear, but feel free to ask more. - ʄɭoʏɗiaɲ ^τ _¢ 01:30, 17 February 2012 (UTC)

Thank you. What an incredibly non-intuitive interface! Even with your directions, I still had considerable trouble following them. Turns out the appearance of the handles on the route is extremely subtle.

Then there are mouse movement mistakes. Shesh!: "Save early, save often." I managed to edit and save with Google Earth, and then paste the coordinate data only that KML subpage. Google Earth added a third parameter to each coordinate, probably for elevation, but all "0". It also changed the structure of the kml data with some new header stuff—I didn't try putting that into the KML page.

The revised coordinate data seems to work as well as what was there before. (Except it now follows the road.) I tested wikiminiatlas and Google Maps. —EncMstr (talk) 03:10, 17 February 2012 (UTC)

I just got an update for the Google Earth app for iOS. It now supports loading KML data from the browser on an iOS device (iPod touch, iPhone, iPad). In testing though, it doesn't seem to work with our KML-enabled articles. First, the mobile version of the website in the Wikipedia app isn't serving up the {{Attached KML}} template (although it does display the commons category box). In using other Wikipedia apps like Wikipanion or bypassing the mobile site to get the links, I get the raw KML file when tapping the link. I assume that the URL would prompt to use the Google Earth app if the .kml suffix was present. Using the Google and Bing links directs me into the mobile versions of those mapping sites. (The app/browser does try to direct the Google link into the Maps app, but that doesn't yet directly support KML overlays). The mobile version of Google Maps does process the KML data and display the line while Bing's mobile side does not. In other words, support is coming. So it seems that even if we're not processing the KML on the server, we need that suffix for other uses. Imzadi 1979 → 07:41, 20 March 2012 (UTC)

This absolutely rocks

This is amazing. At last a solution that satisfies both the geolocation and highways project, and a wiki-driven one too! Congratulations to all involved: I wish I had thought of this. If this needs any bot help (such as, for example, reduction of excess precision in coordinates), I'll be glad to oblige. -- The Anome (talk) 23:08, 16 February 2012 (UTC)

It's very good, very welcome, long overdue, and those who put it together deserve great credit. It does not, though, serve all use cases, not least the (disputed) case that coordinates specified in the text of the article are of encyclopaedic value. Nor - at least in the way I foresee it being used on US roads articles - the case of the person who wishes to view a linear feature at a certain point - a road junction, for instance. Both the coordinate and the point can, of course, be found by diligent research once at the map site: but that would (for me) be to miss the point of an encyclopedia incorporating, per its first pillar, elements of a gazetteer. --Tagishsimon (talk) 23:36, 16 February 2012 (UTC)

WIWOSM, a complement/alternative to AttachedKML

de:User:Kolossos announced the WIWOSM project yesterday on the Maps-mailinglist. This is a great new development that allows us to use the OpenStreetMap geometry data in an efficient way. It adresses the problem of tag names and osm ids being insufficient to reliably associate an OSM object with a Wikipedia article. OSM introduced a new key to label their objects, which directly points to a Wikipedia article. The WIWOSM project extracts the geometry data for which an article key is found (nightly), and provides it in GeoJSON format. The WikiMiniAtlas already loads and displays the data if it is found for the current article. Check it out at Austria for example. --Dschwen 21:50, 15 March 2012 (UTC)

Nobody cares? Well, I was pretty excited about it, and given how many people participated in the whole area-geocoding discussion I though I wouldn't be alone. --Dschwen 20:30, 19 March 2012 (UTC)

The main problem as I see it is that this doesn't help address the compatibility issues. OSM should work to implement KML, as that would really bolster the use of that open source specification. Given how you were able to accomplish it relatively quickly with WMA, I don't see why, with a little push of course, they couldn't make it work. - ʄɭoʏɗiaɲ ^τ _¢ 22:10, 19 March 2012 (UTC)

I don't quite understand where KML comes into play here, apart from supporting display on the proprietary services. Anyhow a translation from GeoJSON to KML is trivial, and I think such a solution already exists. The main point here is that a framework to uniquely associate a geographic object with a Wikipedia article now exists. Volunteersa are busy tagging the OSM data with wikipedia article info as we speak. This is a huge work saver for us. We get vector data for our articles for free basically. --Dschwen 22:34, 19 March 2012 (UTC)

Apologies for not being first on the reply button. I am on the road and will have days with limited internet access. It takes days to catch up! What interest me is that we have a template {{GeoGroupTemplate}} that I have included on List_of_textile_mills_in_Cheshire. I was going to say it would be cool to be able

• to include several KML traces to show the significant rivers (blue) canals (light blue) rail lines (red) roads (light brown).
• to have it apply to only one section.
• to put in the boundaries of the county, and the parish boundaries

But that now seems to be totally redundant as pressing the weltikon for any mill brings up the new map. I can see that if I wait, all that will happen. There do seem to be some technical improvements. In the example I gave- the initial scale is wrong- I asked for Cheshire and you gave me the World. A section or subsection focus so that the initial scale will display the subsection, allowing me to zoomback to get the complete page. In the example I want to see the parish first and not the county. When I hover over one mill- I get the page name- not the mill name which must be extracted from the table template. It would be trivial to wrap the name up in a template with coord if that would help. Excited- yes.--ClemRutter (talk) 23:29, 19 March 2012 (UTC)

Hey Clem, the textile mills in Cheshire are an entirely different issue. The blue dots don't show the name of the mill because you haven't specified it using the name parameter of the coord template. The zoom is off because you haven't specified a scale using the dim parameter. But I'm currently working on a more sensible default scale when none is specified. --Dschwen 14:26, 20 March 2012 (UTC)

Wow, you're fast, I was just commencing to write a script to add the name parameters... --Dschwen 14:37, 20 March 2012 (UTC)

Yes I had figured that bit out and spent some time with my text editor, doing the remaining OS to WSG84 conversions, and adding the name= bit. A script would be really useful to have, as there are 19 pages to fix in Category:Lists of textile mills in the United Kingdom- I wrote the template for List of mills owned by the Lancashire Cotton Corporation Limited so this is a good page to test a script.--ClemRutter (talk) 15:17, 20 March 2012 (UTC)

I am already using the tool in anger. Last week I walked around Macclesfield taking photos of anything that looked like a mill, so I have 300 unidentified photos to upload to Commons- I can trace where I walked, so with the new map in one browser, Google Maps in another I am now naming the files to fit the names, and geotags found in my reference sources. Looking at these pages you will understand why I don't always give instant comment in discussions- I am focused on the cotton industry. --ClemRutter (talk) 15:17, 20 March 2012 (UTC)

Problem with Geogroup — Advice needed

I have added a {{GeoGroup}} to two articles, to show the locks and dams on the waterways:

• Illinois Waterway
• Tennessee–Tombigbee Waterway

For Illinois Waterway, the group displays correctly in Google Maps, but the item names are not displayed (only numbers). For Tennessee–Tombigbee Waterway, Google Maps says it can’t find any geocoded items. What have I done wrong, and how can I fix them? Any help would be appreciated. •••Life of Riley (T–C) 19:34, 20 March 2012 (UTC)

Names work for me on the first. Nothing on the second, yet. I speculate its a cache issue; if you tweak the URL to be usecache=0 then the second works. Someone else may be able to throw more light on it, but (other than putting the second list into a table) I'd leave the article markup as it is. --20:03, 20 March 2012 (UTC)

There's a bug in {{GeoGroup}}, described on its talk page Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:29, 20 March 2012 (UTC)

OK, both seem to work now. Thanks to both for your advice. Must have been a cache issue, because both of the pages work properly now, after I entered ...cache=0. •••Life of Riley (T–C) 01:22, 21 March 2012 (UTC)

KML and the iPhone

Yesterday Google Earth for the iPhone announced support for KML links - [5]. However, I've been told that it doesn't work for KML links generated from {{AttachedKML}} on the iPhone... --Rschen7754 21:00, 20 March 2012 (UTC)

I'd be happy to debug this, whom do send the shipping address for a test iPhone? --Dschwen 21:04, 20 March 2012 (UTC)

Imzadi1979 (talk · contribs) suggested last night that maybe all the names need to be .kml... I'll try it out on my iPhone sometime this week (been busy with finals). --Rschen7754 21:13, 20 March 2012 (UTC)

That would be incredibly stupid on Google's part. The more likely error is the wrong mimetype that is returned by the Wikimedia server. --Dschwen 21:42, 20 March 2012 (UTC)

RFC on coordinates in highway articles

There is currently a discussion taking place at WT:HWY regarding the potential use of coordinates in highway articles. Your input is welcomed. --Rschen7754 01:30, 26 December 2011 (UTC)

The proposal would change the Mos to prohibit the use of coordinates in articles about highways (aka roads/ motorways). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 26 December 2011 (UTC)

ONE of the proposals would. Editors are free to offer their own proposals. How dare you accuse Rschen of canvassing because of your misinterpretation of the word "potential", yet post something completely non-neutral already declaring a anti-coord motive on the coord wikiproject. - ʄɭoʏɗiaɲ ^τ _¢ 14:23, 26 December 2011 (UTC)

"How dare you" is not a good idiom to use, ever. But if you are going to use is, your sentence should end with a question mark. --Chinasaur (talk) 22:40, 25 March 2012 (UTC)

To the limit of my ability to comprehend the English language, Andy did not accuse Rschen of canvassing. You're right to say that only one of the proposals - your proposal, Floydian - would prohibit coordinates. It is to be hoped that members of this project give your proposal due scrutiny, along with the others in this RfC. --Tagishsimon (talk) 23:50, 26 December 2011 (UTC)

Not here, the accusation was at the RFC. --Rschen7754 03:45, 27 December 2011 (UTC)

Proposal for the closure of this project

I propose we close this project. There does not seem to me to be a point in us having a Geographical coordinates project if its members cannot be bothered to enter into discussions which - at least on the current heading - will result in a ban on the use of geographical coordinates in a complete class of articles. Really. What is the effing point in me spending days of my life adding coordinates, only to see them all wiped out without a whisper of support from people here? So. It's been great, but I think we're done now. Wikipedia_talk:WikiProject_Highways#Proposal_1:_No_coordinates_-_Original_research --Tagishsimon (talk) 10:09, 17 January 2012 (UTC)

As one of the people involved in first getting geographic coordinates added to WP, let me say: thank you for reminding me why there are better things to do with my time than edit WP. --Chinasaur (talk) 23:00, 25 March 2012 (UTC)

I glanced at proposals one through six or so (at Wikipedia talk:WikiProject Highways) and thought they were so patently preposterous there is no way they could be agreed to. Or even if accepted, they could not be implemented as they violate the Five Pillars. Maybe the situation is more dire than I thought? —EncMstr (talk) 10:38, 17 January 2012 (UTC)

Highways people are absolutely determined to rid wikipedia of the scourge of coordinates. RfCs are, as far as I know, the sanctified way in which the community sets policy. Current consensus on the RfC page is that coordinates should be banned from road articles. What part of QED does this project think will save coords if individuals here are not prepared to make their voice heard?

If we are prepared to stand idly by whilst this happens, in all seriousness we should close this project as being utterly worthless. --Tagishsimon (talk) 10:57, 17 January 2012 (UTC)

What is the suggested action? --ClemRutter (talk) 11:17, 17 January 2012 (UTC)

You might wish to start by engaging in the RfC? --Tagishsimon (talk) 11:20, 17 January 2012 (UTC)

I was only asking [[for a link! But having read the poisonous suggestion- I have posted a a few lines about proposal 1- from a guy who seems to have the strange idea that roads are built without their routes being published- and because he writes articles lacking basic information- then all articles should be stripped back so they look consistent with his! What a waste of an afternoon! --ClemRutter (talk) 15:06, 17 January 2012 (UTC)

This is a knee-jerk reaction. As someone who has geotagged thousands of articles and who sees a lot of value in doing so, I also completely see the futility of trying to use a single point to describe a route or road. Are we going to try to add co-ordinates to the Great Wall of China? Socrates2008 (Talk) 12:17, 17 January 2012 (UTC)

Far from being a knee-jerk, this is something I've been tracking for more than six months. Proposal 1 is to ban ALL coordinates, not merely instances where a single coordinate is used to provide a link to a map. So multiple coords used in road junction lists, for instance: banned. Use of a couple of coords to denote start and end: banned. Any solution whatsoever involving coordinates: banned. Proposal 1 is currently the winning proposal. What part of "this proposal will ban ALL cooordinates on road articles" is unclear to you?

As I've said, in other words: if you cannot read the very clear writing on the wall, there's no point in having this project. Complaisant responses such as yours just do not cut it. --Tagishsimon (talk) 12:40, 17 January 2012 (UTC)

--Tagishsimon (talk) 12:24, 17 January 2012 (UTC)

Clarification: Apparently, despite its context making it clear, some editors have failed to realise that Proposal 1 is to ban ALL coordinates in artciles about highways. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:53, 17 January 2012 (UTC)

Let's not make knee jerk sudden decisions. Coordinates is an excelllend informative way of making the reader aware of where the article is referrinf to. It also helps integrate wikipedia with other maps. There are clearly some hurdles and some guidelines to work on. But let's keep it sensible. DubhEire (talk) 12:20, 17 January 2012 (UTC)

You need to engage in the RfC, DubhEire. Honeyed words here do no good whatsoever. --Tagishsimon (talk) 12:40, 17 January 2012 (UTC)

Ok, I might not be reading this clearly, but it appears as though the RFC is only removing coordinates from road articles, not ALL articles project-wide. Can someone clarify? Spencer^T♦C 13:03, 17 January 2012 (UTC)

I also made a quick run through the page as I have not got the time right now to familiarise myself in more detail. But it does appear to be an issue with tagging roads and junctions. I do believe there is a problem there with coords relating roads and it needs to be addressed. But I fail to see why/where coords would be removed for all articles. However, I can see your passion Tagishsimon, so I will make a comment later. Thank you for bringing to a wider audience as I would not have seen this discussion. DubhEire (talk) 13:12, 17 January 2012 (UTC)

This is a proposal affecting highways only, contrary to what Tagishsimon posted above. --Rschen7754 22:40, 17 January 2012 (UTC)

I got canvassed into this discussion by a note on my talk page. I'm definitely against closing this project; while it may be moribund at times, it's a useful concept and should stick around. I'm also definitely against removing all coordinates from all articles, but fortunately that does not seem to be proposed. As for the proposal regarding roads specifically, I'll have to go there and check it out before I have an opinion. Putting one coordinate to represent the position of an entire road probably doesn't make sense, but coordinates might be useful in specific contexts, so a flat ban may be an overreaction; but I'll have to read the actual proposal to be sure what's being discussed and why. *Dan T.* (talk) 13:40, 17 January 2012 (UTC)

The most preposterous of these proposals is to ban coordinates generally. Shuttering this Project is pretty dumb, too, having no relevance to the purported purposes. As for highways, let the highway people worry about which proposals are more ridiculous and which ones less. Jim.henderson (talk) 14:07, 17 January 2012 (UTC)

Ditto being canvassed, but it has made me look at the proposal and at least oppose Proposal 1, the elimination of coordinates in road articles. Regards, TransporterMan (TALK) 14:32, 17 January 2012 (UTC)

This just seems like another example of USRoads and its members trying to push what they want on other projects. I'm not a member of this project but suggesting it be closed and all the geo tags removed from articles is pretty far fetched. I admit that adding Geo tags to road articles is troublesome but it seems like there should be some kind of tag. Maybe a start or end point? --Kumioko (talk) 14:44, 17 January 2012 (UTC)

I think that coordinates are good as it helps people locate a place. For example they don't know the exact address of the place they want to go to. Well, they can use the coordinates and use them in a mapping software like Google Maps, or if their GPS takes coordinates like that without needing an address. But mainly it can help people find out where the location of that place/thing, is. So I am against this WikiProject closing and removal/ban on Coordinates. Because they are really useful. --Clarkcj12 (talk) 15:18, 17 January 2012 (UTC)

This is a proposal affecting highways only, contrary to what Tagishsimon posted above. --Rschen7754 22:40, 17 January 2012 (UTC)

Also just go pulled in via a talk page comment. It seems rather extreme to remove all coordinates from articles or to close this project. But, I don't know enough about roads to weigh in on that. Bilrand (talk) 15:32, 17 January 2012 (UTC)

Ditto Paulshannon (talk) 16:01, 17 January 2012 (UTC)

This is a proposal affecting highways only, contrary to what Tagishsimon posted above. --Rschen7754 22:40, 17 January 2012 (UTC)

Just thought I'd point out that A) This is blatant canvassing, and B) Ban is being thrown around fanatically here. You'll note that proposal one begins with "until our geotagging system is better equipped to tag convoluted linear features (something that may require a bit of coordination with Google), I fully oppose their usage what-so-ever on road articles.". Is nobody willing to improve the system to work with linear features? Who is this project has the tie-ins with geohack? C'mon people, it's coding and it can be done, if there is a willingness to do so. I however, can not deal with band-aid solutions. - ʄɭoʏɗiaɲ ^τ _¢ 16:02, 17 January 2012 (UTC)

The only thing that has prevented us from developing the use of coordinates for linear features, over the last three(?) years has been opposition from the (highways) lobby of which you are a vocal part. Nonetheless, {{Coord}} already works well for linear features; this has not stopped you (collectively and personally) from disruptively removing it from articles about highways. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:25, 17 January 2012 (UTC)

So "No I'm not going to bother even trying to come up with new ideas because I believe the system that is currently the centre of a six month brawl works just dandily", in other words? Sounds as lazy as the lazy highway people that can't go find centreline data to get coordinates. - ʄɭoʏɗiaɲ ^τ _¢ 16:47, 17 January 2012 (UTC)

As I've asked you previously: kindly do not attempt to speak for me, as you clearly lack the wit or wisdom to do so. Your ad-hominem edit summary is equally false. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:14, 17 January 2012 (UTC)

I never like stating policies such as civility and the like, but Andy, please keep it friendly between editors since comment like those really add nothing. Instead it is better to see if we can do something about the issues raised. As for the talk page messages - nowhere does it state that all coords would be removed, which is a big difference since arguing over a subsection of articles is a lot different then arguing over general removal. As for removing the wikiproject, thats just plain ludricous. While not everyone may involve themselves in every discussion, projects do tend to be a great resource for tools, common agreements and so on for a specific activity. I therefor see no reason whatsoever as to why we should close this project. Excirial ^{(Contact me,Contribs)} 18:21, 17 January 2012 (UTC)

My comment was utterly civil, unlike many of those, not least in edit summaries, directed at me. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:54, 17 January 2012 (UTC)

Hello, I am here. My coordinate articles are derived from good sources and the articles are good. Articles on mountains and towns are good. James Michael DuPont (talk) 18:19, 17 January 2012 (UTC)

This is a proposal affecting highways only, contrary to what Tagishsimon posted above. --Rschen7754 22:40, 17 January 2012 (UTC)

Support - It appears this is a serious proposal, so it should be taken seriously. I use coordinates for all sorts of things where they are entirely appropriate, and of course coordinates are not going to go away. However, if some minor, but not unreasonable tussle about how appropriate coordinates are for highways, causes this project to become so dysfunction that it is seriously debating whether it should spit the dummy and close itself down, and then making an astonishing demand that everyone on Wikipedia stop using coordinates, then yes, the project needs to be closed down. There will be other people willing to look after coordinates without the handicap of a dysfunctional project. --Epipelagic (talk) 19:23, 17 January 2012 (UTC)

Only one person is seriously suggesting that we remove all coordinates from articles, and I suspect that he was abused by a map as a child. Bazonka (talk) 19:52, 17 January 2012 (UTC)

Oppose. I'm sorry the OP is somehow annoyed, but this is an obvious knee jerk reaction. "I don't like how things are going, let's shut down and destroy years worth of useful work". And what kind of logic is it to then take such a nonsense proposal by one "disgruntled employee" as justification for support? Sorry, but this just smells of unnecessary drama. Moving on. --Dschwen 19:54, 17 January 2012 (UTC)

This is a proposal affecting highways only, contrary to what Tagishsimon posted above. --Rschen7754 22:40, 17 January 2012 (UTC)

Oppose. An overreaction. Coordinates are useful in many articles. - Presidentman talk · contribs Random Picture of the Day (Talkback) 21:08, 17 January 2012 (UTC)

The proposal is not about coordinates. You are not taking the proposer seriously. It's about closing down a dysfunctional project --Epipelagic (talk) 21:34, 17 January 2012 (UTC)

This is a proposal affecting highways only, contrary to what Tagishsimon posted above. --Rschen7754 22:40, 17 January 2012 (UTC)

Oppose - can't see how this is going to have any effect on the thousands and thousands of non-road related articles here at Wikipedia. The RFC is about roads only - I'll be the first to jump in should that change. Socrates2008 (Talk) 21:39, 17 January 2012 (UTC)

Oppose - Per my comments above and bathwater. — TransporterMan (TALK) 22:13, 17 January 2012 (UTC)

Oppose. This project is dysfunctional. But, speaking as one of the "roads lobby", I don't support the removal of coordinates from all articles, and you don't close down the project because it's dysfunctional; you work to fix the problems; baby:bathwater. --Rschen7754 22:19, 17 January 2012 (UTC)

• Oppose - I may have missed something, but I'm pretty sure that the various proposals at WT:HWY concerned coordinates as applied to roads, not coordinates in general. So, if I'm wrong on that point, please direct me to the place where it's proposed to get rid of all coordinates.

Assuming that if roads are not to be given coordinates, that should not affect everything else. Roads are one-dimensional features with the attendant problems of defining a point, or points, for which coordinates are applicable; but cities, mountains, buildings, etc. etc. are normally two- or three-dimensional features for which a centre, or primary feature (e.g. mountain peak) may be identified as suitable for a single set of coordinates. --Redrose64 (talk) 22:24, 17 January 2012 (UTC)

This is a proposal affecting highways only, contrary to what Tagishsimon posted above. --Rschen7754 22:40, 17 January 2012 (UTC)

I'm sorry to hear that Tagishsimon hijacked a perfectly reasonable proposal and turned it into a pile of crazy. So, where should we discuss the road issue? I basically agree with point coordinates being obsolete for highways, we have the technology to link those articles to OSM line data, which could be used to highlight the entire highway on a map. --Dschwen 22:53, 17 January 2012 (UTC)

I'd be happy to discuss this after the blackout - right now I'm just trying to survey the damage and talk to other people and figure out what to do next. --Rschen7754 23:02, 17 January 2012 (UTC)

Tagishsimon's canvassing was inappropriately implemented, but I belive he acted in good faith by bringing the discussion to the attention of the geographical coordinates experts here - we are exactly the sort of people who should be contributing in the discussion, and we are not all necessarily going to agree with Tagishsimon. I think the impact of his actions is minimal. Bazonka (talk) 23:09, 17 January 2012 (UTC)

But then what about the highways editors, who are also qualified to participate in the discussion? Or editors who aren't part of either group? --Rschen7754 23:12, 17 January 2012 (UTC)

The discussion was taking place at Wikipedia talk:WikiProject Highways, so the highways experts were already informed and participating. And it was also advertised at WP:CD, so the wider community was notified. I don't really understand your argument. Bazonka (talk) 23:26, 17 January 2012 (UTC)

By that argument, I should be able to spam all the WP:HWY/WP:USRD editors with a neutrally posted message pointing them to the RFC. --Rschen7754 23:31, 17 January 2012 (UTC)

I'm certainly not condoning Tagishsimon's behaviour, so no I am not saying that you could spam the Highways experts as well. But why would you need to? It's likely that they'd already be watching the discussion on their project's talk page. The coords experts wouldn't have had this level of visibility, which is what Tagishsimon was trying to address, presumably in good faith. Bazonka (talk) 23:51, 17 January 2012 (UTC)

Not necessarily; there's two layers of associated WikiProjects underneath WP:HWY. In fact, we're trying to get rid of one of the layers now so we're better coordinated. --Rschen7754 02:51, 18 January 2012 (UTC)

(edit conflict) His message was very fanatical, which means that people arriving here already have impressions in mind. The jury should remain neutral until the facts are presented to them. - ʄɭoʏɗiaɲ ^τ _¢ 23:14, 17 January 2012 (UTC)

I am inclined to agree, but his views were so strong and strangely expressed that it would be hard to take them at face value, and so editors may be inclined to take an objective view of the situation. Bazonka (talk) 23:26, 17 January 2012 (UTC)

As already pointed out, many highways do not exist as singe entities in OSM. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:51, 17 January 2012 (UTC)

Yeah, good point, but a merely technical one. So just provide list of OSM IDs. Problem solved. --Dschwen 01:18, 18 January 2012 (UTC)

Or create the ID yourself. --Rschen7754 02:51, 18 January 2012 (UTC)

• Oppose. This is tearing down the house with the baby still sitting in the bathwater inside. I can't tell you the number of times I've clicked on a coordinate and pulled up the GeoHack map, so it's not like what this project does isn't helpful at all. I do think the shapefile proposal discussed at WT:HWY would be beneficial to more than just linear features. Instead of just the city center, we have a link to see the limits of the entire city. Same goes for countries, states/provinces, neighborhoods. –Fredddie™ 23:19, 17 January 2012 (UTC)
• Strong Oppose There are plenty of geographic coordinates (Towns, Buildings, Statues, Schools, mountains, volcano's,countries, lakes and so on) which have a single geographic point that can be located on a map, or which can be displayed using different forms of magnification (Such as countries, which simply have a high zoom to display everything). Roads are indeed more difficult since they tend to spit, cross or become otherwise untraceable. As of such it might be worth the effort to discuss what added value there is for geo locating roads, and if we should do this differently or do it altogether. But in each and every case i see no reason whatsoever to shut down an entire project because of this. Excirial ^{(Contact me,Contribs)} 23:33, 17 January 2012 (UTC)
• Oppose. Ridiculous over-reaction. We are being invited to express our opinions at Wikipedia talk:WikiProject Highways - fine. Is there anywhere else where there is a threat to remove coords? — RHaworth (talk · contribs) 00:00, 18 January 2012 (UTC)
• Oppose I agree with the above. I oppose closing down. Sf46 (talk) 03:28, 25 January 2012 (UTC)

It's just as much a ridiculous over-reaction as it is a Modest Proposal. Members of this project were invited three or so weeks ago to enter into discussions on Wikipedia talk:WikiProject Highways about, amongst other things, banning coords from roads articles: not just singleton coords but all coords in those articles. And few if any of the members of this project could be bothered to lift a finger and enter into the discussion. I don't, for those snuffling along the canvassing line of argument, give a stuff which proposal on the Highways page members of this project choose to support or oppose. I do care and am appalled that so very few members of this project thought it worthwhile to get involved in the discussion. Let us count the ways: 1) a proposal to ban coords from a whole class of articles including presumably the deletion of several thousand extant coords, pretty much completely ignored by members of this project. 2) a challenge from outside this project to improve our handling of linear features, pretty much entirely ignored by participants here 3) the prospect of the establishment of an important precedent presumably completely detrimental to the ends of this project (which I vaguely understand to be about providing coords rather than standing around watching them being deleted) not though worthy of interest by the group of wikipedians that have declared their interest in coords. Wikipedia values precedent, and it would surely be unfortunate for this project to have a precedent detrimental to arguments for the inclusion of coords when the next challenge is made.

So, yeah, for being really really useless in this particular instance, one solution is to knock this project on the head. Another is to get involved with the RfC.

More widely? Compare and contrast Wikipedia:Manual of Style/Road junction lists with Wikipedia:WikiProject Geographical coordinates/Linear, for instance. The first, a wikipedia guideline, the second merely project advice, and so disputed and derided at, err, Wikipedia talk:Manual of Style/Road junction lists ... where, did you know, coords are already banned (at least according to the owners of that page? Where was the input from this project when coords were being thrashed out - literally - on that page? It wasn't for lack of notification on this page.

The bottom line is that this project shows evidence of a complete abdication of any responsibility for or even interest in the subject matter it claims to be concerned with, at least as judged by acid tests of the current highways RfC and the recent and very lengthy RJL discussions. If geographical coordinates policy being set elsewhere with no input from this project doesn't shame us and call for a re-examination of what we're about as a project, I don't know what does. If it takes the sort of action as I've taken in the last few hours to get you to engage with these two issues - the highways RfC and the moribund nature of this project - then so be it. Previous attempts to engage your interest just didn't work. --Tagishsimon (talk) 01:47, 18 January 2012 (UTC)

And now that we have your attention...

Many of you have opposed Proposal 1, the "banning of coordinates from all highway articles" as many have called it. But if you don't want them banned... then what is your proposal? What do you believe, then, is the best way to geotag highway articles? The coordinates editors who have spoken up so far have told us what is wrong with our proposals, but have offered up only one proposal that the "roads editors" have said over and over again would not be workable. But I'd like to hear from the rest of you. What are your ideas? --Rschen7754 10:55, 19 January 2012 (UTC)

A problem is this whole "roads editors" ownership thing. We have proposed perfectly workable solutions, not least coordinates in road junction lists. "Roads editors" don't like them, and that's why we're at a stalemate point. Coords clearly work well and unobjectionably on articles like M11 motorway. Until you appreciate that we should be supporting a wider constituency than a small group of road editors who hate coordinates and the links to maps that they provide, I tend to doubt we'll make much progress. You know as well as I do that some of your colleagues seems to be complete and utter zealots in this matter. It's not easy to have rational conversations with such people. --Tagishsimon (talk) 11:02, 19 January 2012 (UTC)

Please don't provide an example where you added the coords, and which was followed by edit warring. That edit war is what we call an objection. - ʄɭoʏɗiaɲ ^τ _¢ 14:05, 19 January 2012 (UTC)

And we have explained why your solution isn't workable, and you don't seem to listen. I'd like to hear from some different people; I think you and I have said enough. Also, there's your quote saying "than a small group of road editors who hate coordinates and the links to maps that they provide". Please link to where I have advocated for the removal of coordinates from all articles as my first choice option. Also, M11 motorway is a very poor example in that it violates WP:RJL in ways unrelated to coordinates. --Rschen7754 11:08, 19 January 2012 (UTC)

Well, being totally constructive, I have looked at M11 motorway and looked at ways to improve it, it is only a 'C'. Firstly we need to work on the Infobox- this template is very old and has no parameters to add coord_start, coord_end and coord_median. There are several ways that these are added in other templates but my preference here is to use one that parses from {-{coord|51.67942|N|0.12497|E|dim:4000_region:GB|display=inline|name=M11, Junction 6}-} that in many cases is already in existence. It may be profitable if we are using M11 as an exemplar to work it up to GA --ClemRutter (talk) 11:47, 19 January 2012 (UTC)

The template is not "very old" - it was redesigned in 2010 for international use. It does not have any fields for coordinates because there has been no consensus for the implementation of those fields in the infobox. Were there to be, I'm sure that we would add the fields. --Rschen7754 12:01, 19 January 2012 (UTC)

In other templates, you provide the facility- and editors choose whether to use them. I am unfamiliar with this concept of 'we'. Haven't 'we' just had a days blackout on the whole freedom of expression issue? I am saying that a restrictive template is restricting article development- if 'you' are 'we', could you please start looking at a way to remove this restriction.--ClemRutter (talk) 12:27, 19 January 2012 (UTC)

Per WP:HRT, consensus must be obtained to modify the infobox. There has been no consensus on using coords or how to use them, so why would we have parameters to set up a display method that we can't agree upon? Midpoints don't work. - ʄɭoʏɗiaɲ ^τ _¢ 14:11, 19 January 2012 (UTC)

Can you please read what I have just said- consensus is easy to obtain when editors do not take personal ownership of a group, and realise that a POV is still a POV. WP:Groups exist to facilitate- and their function and raison d'étre is to provide solutions that can be used elsewhere in the project. I am asking for someone to provide me with a Infobox template that works- I will accept their advice on whether the primary coordinate is the midpoint, the point furthest from Paris, the highest point or whatever- I need secondary coordinates for the endpoints. What I do not need is an article blocked- because the infobox is not fit for purpose. I have looked at M11 motorway, and the only way you can locate it is because of a {-{cord}-} tag in the text. The midpoint is adequate for a reader in Hong Kong to locate it- It easily shows the continent, the country and region- that is good for the principal coord. It will lead him to the line on OpenMaps- the secondary coords will tell him where Girton is, and where it crosses the M25. You say there has been no consensus- but looking at back posts that is not strictly true, there has been consensus that there is a crying need for a unified coord system that has been disputed by a small group who suffer from an ownership delusion, and this has also blocked the near consensus on the method to be used. So I repeat my request for someone to show a little leadership here and propose a three point infobox, and to give guidance on what the advised techniques for determining the prefered primary cordinate. I will leave it at that at the moment but will be happy to give some further input if requested.--ClemRutter (talk) 02:44, 20 January 2012 (UTC)

{{Infobox road}} doesn't need separate parameters for coordinates. They can simply be added to the |terminus_a/b= or |end_a/b= after the route/place at the endpoint. Similarly, coordinates could be added to |junctions=. I have heard complaints (my mind escapes me at the moment) that Infobox road is bloated as it is, adding more parameters isn't going to help that out. –Fredddie™ 07:52, 20 January 2012 (UTC)

You (collectively) have claimed that lists of coordinates in junction tables are not workable; but you have failed to demonstrate that they are; indeed, the evidence that they are workable is clear for all to see. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:53, 19 January 2012 (UTC)

You have failed to demonstrate why those lists of coordinates need to include the degrees, minutes and seconds for each and every entry when those degrees, minutes and seconds are repeated on the next page. You've also failed to demonstrate that anyone makes use of them as opposed to the map services. "We" have provided one piece of evidence: The upper limit on how many templates can be added to a single article is less than the number of junctions in some articles. - ʄɭoʏɗiaɲ ^τ _¢ 14:11, 19 January 2012 (UTC)

On the contrary; that was debated when {{Coord}} was created and I've pointed out more than once that ~3/4 of a million instances of it is ample evidence of consensus for its use and presentation; ad told you how to avoid seeing coordinates if you do not wish to do so. I;p quite content with an upper ceiling on the use of {{Coord}} being determined by the technical limit of total template transclusions. Hint: it's many more than ten. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:39, 19 January 2012 (UTC)

Please see the new proposal #10 at WT:HWY. --Rschen7754 18:02, 19 January 2012 (UTC)

Here's a radical idea. What if for a linear feature, the title coordinates were prefaced by "Midpoint:" and when clicked, the full line appeared on the map, centered on that midpoint? Voilà, a linear feature represented by a line! I bet with some collaboration with Google, et al., that we could even get a way to have the marker image for a road linked to the Wikipedia article on that road in the Wikipedia layer. I know that Google has a way to reference the full length of a highway because I've submitted Map Maker corrections for Michigan's highways to insert the missing "M". (The full name of the long east–west highway across the Upper Peninsula of Michigan is "M-28", or maybe even "State Highway M-28", but they've been dropping the letter, hence my correction.) Imzadi 1979 → 11:32, 19 January 2012 (UTC)

Please explain how you intend to persuade all the mapping services we link to, to display the "full line" on their maps. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 19 January 2012 (UTC)

Obviously if there is a wikipedia layer, some form of correspondence has taken place between Google and Wikipedia. Why would any of the lesser mapping services not jump at the opportunity to gain more traffic over Google due to the popularity of our encyclopedia? - ʄɭoʏɗiaɲ ^τ _¢ 14:13, 19 January 2012 (UTC)

Good luck with implementing that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 19 January 2012 (UTC)

I believe that the reason the mapping services don't display the full line (or any road coordinates, for that matter) is because we don't have them. Were that to change, then we might see some changes there. --Rschen7754 18:02, 19 January 2012 (UTC)

Providing a column of coordinates in a road junction list when combined with the GeoGroupTemplate does exactly what Imzadi suggests. Yet you're the very people who are stopping us from adding coordinates to road junction lists. Let's be very very clear here. {{coord}} is the wikipedia de facto standard for geolocation by virtue of its inclusion on more than 700,000 wikipedia articles. A column of coordinates is the de facto standard for tables of geo-locatable entities - see WhatLinksHere/Template:GeoGroup. The only barrier to us from implementing these standards for highways is a small group of highways people who happen not to like coordinates and who are absolutely determined to get their way. Imzadi's suggestion reads to me as nothing more than a feint: that we should buy a currently unimplementable idea and thus consign ourselves to years without coordinates on roads article, rather than implement pretty much exactly his suggestion using de facto standards now. If you could just get it into your heads that wikipedia is not only about your preferences and prejudices. It is also about respecting the fact that other people want this sort of information. Refer back to something as fundamental as Wikipedia:Five pillars which states that Wikipedia is an online encyclopedia. It incorporates elements of general and specialized encyclopedias, almanacs, and gazetteers. Gazetteer is defined as a geographical dictionary or directory, an important reference for information about places and place names ... used in conjunction with a map or a full atlas. Really. Just, for heavens sake, try to get over your dislike of coordinates and we can all go back to adding to the encyclopedia. The only reason we're going through this pantomime is because of that dislike. There simply are no arguments on your side that can hold a candle to Wikipedia:Five pillars. --Tagishsimon (talk) 20:42, 19 January 2012 (UTC)

"incorporates elements" != "incorporates all elements". We don't have tide tables or sunrise/set times, a common element of an almanac. "{{coord}} is the wikipedia de facto standard for geolocation by virtue of its inclusion on more than 700,000 wikipedia articles" - how many of them are linear objects? "who happen not to like coordinates" - you have yet to source this remarkable assertion that I happen to not like coordinates. --Rschen7754 20:49, 19 January 2012 (UTC)

It's not all about you, singular, Rschen. I know that removal of coords is only your third choice. You told me earlier. And you well know who I'm meaning when I talk about the group who happen not to like coordinates, because you've been with us each step of the way over the past however many months this has been going on. So quit wasting time by playing with words, please. It's conspicuous that you do not pick up on the substantial points in my post, but concentrate on a dramatic sub-plot. Life is just not long enough for that. --Tagishsimon (talk) 21:13, 19 January 2012 (UTC)

"I know that removal of coords is only your third choice." - true, but it doesn't go far enough. I support the use of coordinates or some other method of geotagging (i.e. Proposal 9). But, I'd rather not have any coordinates than have a crummy implementation of a coordinates standard. Your and Andy's abject refusal to agree to anything but proposals you suggest that we've told you don't work for us is why many of my colleagues oppose. If you remember six months ago, they actually were voting for a proposal that would allow limited use of coordinates in articles. Now you've driven them off for being just plain disagreeable, and frankly, I don't blame them. You're starting to turn off some of your own editors too; see Excirial's latest comments at WT:HWY.

Now thankfully, a silver lining of your canvassing is that it has brought some reasonable editors to the table. Right now, the "highways people" and "you" want polar opposites. We can sit here and argue about whether one polar opposite or another should be the case until we're blue in the face and probably have reached ArbCom (as just about every intractable dispute does), or we can try and compromise. A lot of your fellow editors are trying to work with us and I commend them for that. Whether you're a part of this new movement, or you decide not to be, is up to you. --Rschen7754 22:10, 19 January 2012 (UTC)

ROTFLOL. When you want to come back to the issues, let me know. As my purpose in "canvassing" was to get people involved in the discussion; I'm glad you agree it is beneficial. I've done my best, and at risk of sanction, to get people to the RfC page: a good faith assumption would be to take that as a serious effort to get wide community input into a long-term contentious issue with a view to seeking a community rather than a cabal solution, even if you disapprove of the means. --Tagishsimon (talk) 22:35, 19 January 2012 (UTC)

This reply is exactly why I am glad there are other editors from this project who are willing to come up with a solution. After 6 months of discussions with you, we're no closer to getting a solution. –Fredddie™ 22:42, 19 January 2012 (UTC)

Yeah, that's right Freddie, it's all my fault. You were always the first to compromise, weren't you. But still: better to be kicking me than discussing five pillars and whether coord & geogropuptemplate in fact satisfy the OP's proposal. Could we agree that we've had enough of pot meet kettle for the night and go back to the issues? --Tagishsimon (talk) 22:59, 19 January 2012 (UTC)

You're certainly not helping. –Fredddie™ 23:19, 19 January 2012 (UTC)

Is it fair to say that tagging articles of places that are not roads/junctions is ok with the current method? Then is it fair to say that it is simply that up to now the problem of tagging roads has been building up because roads can vary in length and therefore there is a need to give more geo information for the reader? If we can keep the objective clear and perhaps establish that there is simply a difference between the current geo coord method for places than there is for roads. Then we should move these discussions back to the Wikipedia talk:WikiProject Highways discussion to keep things clear. DubhEire (talk) 19:13, 19 January 2012 (UTC)

Yup, that's what I'm hoping for; try and build a solution/proposal here that we can take to WT:HWY. --Rschen7754 19:17, 19 January 2012 (UTC)

Sure, but if we can identify where the problem is, then we can move to possible solutions. Please forgive me if that statement may annoy some people as I am only picking up the Highways discussion in the last few days, and there is lots and lots to read. DubhEire (talk) 19:23, 19 January 2012 (UTC)

Yeah, I'm considering extending the RFC by a bit as there's some people who are just noticing the discussion. --Rschen7754 20:02, 19 January 2012 (UTC)

About coordinate lists in WinkMiniAtlas

I just fixed a little bug in the WikiMiniAtlas. Now all coordinates from an article show up on the WikiMiniAtlas map (as blue dots). They are clickable and will cause the page to scroll to the coordinate in the text (and hovering the blue dots will highlight the coordinates). With this feature I think coordinates in Highway articles are actually pretty useful. If you zoom out, you can clearly see the M11 motorway (for example) as a string of dots. (you might to clear your browser cache) --Dschwen 17:40, 20 January 2012 (UTC)

You might like to make that point in the RfC. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:57, 21 January 2012 (UTC)

I can see two pretty minor problems that should be considered:

1. The roads disappear in the miniatlas when the scale is over 5km; there should be an override since roads would be the subject matter.
2. How would/could this atlas be displayed without a title coordinate?
3. Is it possible to integrate into the infobox as an interactive map?

-- ʄɭoʏɗiaɲ ^τ _¢ 20:35, 24 January 2012 (UTC)

I'm working an an improved road dataset for the WMA, and one thought I had was adding a roads mapstyle in which roads are also drawn at low magnifications. This would add only little overhead as only the low zoom factors would need to have a separate tileset. As for point two: there will always be title coordinates ;-). No seriously, I can make the WMA appear anywhere. I would just need a reliable cue when to show it without a title coordinate. --Dschwen 21:04, 24 January 2012 (UTC)

You may want to rethink point 2, because the title coordinates are going to be a big uphill battle from everyone that is part of the "highways group". Looking for a replacement, not a supplement. I know I won't be allowing an editor to determine a single point as representative of a 800km highway, unless they can provide a reliable source stating that the point given is indeed representative of the 800km highway. - ʄɭoʏɗiaɲ ^τ _¢ 21:43, 24 January 2012 (UTC)

As has been explained to you previously, the title coordinates centre the various maps displayed via the GeoTemplate, and is used by other sites which reuse our data. There is widespread consensus for the use of title coordinates for this purpose. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:59, 24 January 2012 (UTC)

Widespread use != widespread consensus, unless you can point to a discussion otherwise. I'm not responsible for the shortcomings of other sites; just Wikipedia. - ʄɭoʏɗiaɲ ^τ _¢ 23:22, 24 January 2012 (UTC)

Long as the title coordinate part was hidden and was just used for centering the map, I think this would resolve the OR problem. --Rschen7754 06:10, 25 January 2012 (UTC)

coordinates should not be hidden, for reasons that have already been explained ad nauseum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:36, 25 January 2012 (UTC)

The other sites do not have shortcomings in this regard; it is your proposal that does. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:36, 25 January 2012 (UTC)

Yes they do, they can't display linear features. Hence this discussion. Open your eyes, learn the meaning of the word "compromise" and stop being a speed bump when other editors are working towards a great compromise that may not expand your conflict of interests. - ʄɭoʏɗiaɲ ^τ _¢ 19:45, 25 January 2012 (UTC)

I don't suppose there's any chance, Ffloydian, that you could gather up your ad hominem and stick them where the sun don't shine? It's perfectly legitimate for any editor to resist the temptations of what they regard to be a crappy compromise. Whinging, as effectively you are, that "he doesn't agree with me" is just a wee bit sad and misguided, and much off topic. --Tagishsimon (talk) 19:53, 25 January 2012 (UTC)

I can't use my mobile phone to boil rice. That's not a shortcoming, either. It does what it's mean to do, well. Other tools are available for other purposes. And please evidence my supposed conflict of interests at WP:COIN, or retract that slur. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:02, 25 January 2012 (UTC)

Hm, Floydian, you seem to have stopped reading my reply at the ";-)". Zealousness can get in the way of a rational discussion. I still hope you are interested in constructively working on the issues rather than to fight a crusade against the evil coordinates. --Dschwen 04:51, 25 January 2012 (UTC)

My apologies. It's been a long six months. - ʄɭoʏɗiaɲ ^τ _¢ 05:09, 25 January 2012 (UTC)