Highways Project‑class

This page is within the scope of WikiProject Highways, a collaborative effort to improve the coverage of highways on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.HighwaysWikipedia:WikiProject HighwaysTemplate:WikiProject HighwaysHighways Project This page does not require a rating on the project's quality scale.

I want to remind everyone to be very careful about citing Google Maps for the names and locations of routes, as most countries' roads and features on Google Maps can be edited by everyone via the Google Map Maker tool, and thus may be susceptible to spam. Please tell all descendant WikiProjects about this, including the ones handling the Philippines, as we don't want to propagate bad data like calling the North Luzon Expressway Regional Highway 95 or something like that. --Geopgeop (talk) 19:52, 26 November 2011 (UTC)[reply]

While this is true, and Google can oft be susceptible to errors, all user submissions are checked by Google. This editorial oversight grants some reliability to it. That said, really, Google maps should only be used for its visual satellite data. Printed maps are far more accurate for route information. - ʄɭoʏɗiaɲ ^τ _¢ 21:52, 26 November 2011 (UTC)[reply]

Also, Google Maps seems to only be able to apply one name per route—last time I checked, all of Interstate 35 is labeled as "Stemmons Freeway", from Laredo to Duluth. That might be its name in Dallas, but it's not called that outside of that city! —Scott5114↗ [EXACT CHANGE ONLY] 01:32, 27 November 2011 (UTC)[reply]

Yeah, I use Google Maps (really this would include Yahoo! Maps as well as Bing Maps, etc., as well) in conjunction with a printed paper map or two. Any citations using {{google maps}} in articles I work on should be to the satellite (or hybrid) view only. Imzadi 1979 → 02:29, 27 November 2011 (UTC)[reply]

Pretty late of a comment, but Wikipedia is even more editable and susceptible to spam.

Multi Trixes! (Talk - Me on Wikia) 19:39, 25 January 2012 (UTC)[reply]

Which is why it isn't a reliable source: User submissions appear without editorial oversight. Also, Google Maps appears to have fixed its one name per route issue (I asked them to make Ontario Highway 403 the Chedoke Expressway only in the city of Hamilton). - ʄɭoʏɗiaɲ ^τ _¢ 21:57, 25 January 2012 (UTC)[reply]

Exactly what code do I add to my user page to put the user box on there? The page wasn't very clear. Allen (talk) 00:15, 22 January 2012 (UTC)[reply]

Just add {{Wikipedia:WikiProject Highways/Userbox}}. Imzadi 1979 → 00:35, 22 January 2012 (UTC)[reply]

In the enthusiasm to implement shape files, this proposal that has received wide support has fallen out of focus. Can we suggest a way to take this forward- would it be worth mocking up a suggestion on a user sandbox then bringing it back to the project talk page? Or is there a better way or will it just happen? --ClemRutter (talk) 12:51, 25 January 2012 (UTC)[reply]

I think the understanding is that if Proposal 9 is implemented then Proposal 11 would be unneccessary, given that the terminus coordinates would already be included in the shapefile/KML. I may be wrong judging people's thoughts on that one, though. With all that in mind, however, the best place to discuss implementation of Proposal 11 would probably be at Template talk:Infobox road since that is the infobox that is used on the vast majority of road articles. —Scott5114↗ [EXACT CHANGE ONLY] 13:01, 25 January 2012 (UTC)[reply]

Yes partially my point. Maybe they will be superceded but this is an improvement that we could get up before the end of the month, and will require no learning curve for editors doing the occasional edit, or those experienced in other fields, who just occasionally find themselves with an article that requires an Infobox road.--ClemRutter (talk) 15:18, 25 January 2012 (UTC)[reply]

It would make data extraction by third parties a lot more complicated if they had to start looking for KML files, too. A better solution would be to hide rather than remove the coordinates in articles that use shapefiles. --Dschwen 17:40, 25 January 2012 (UTC)[reply]

Dschen: Does that mean you are giving a steer to add the coord data to the Infobox- or saying that would make the shapefile task harder. I see them as separate tasks.--ClemRutter (talk) 18:15, 25 January 2012 (UTC)[reply]

Why waste time/resources on implementing something that will soon be removed when we are trying to implement a better solution? - ʄɭoʏɗiaɲ ^τ _¢ 18:24, 25 January 2012 (UTC)[reply]

There is no evidence that this fantastical shapefile solution will be available "soon"; much less that it will render redundant the current methods for displaying (and emitting machine readable-) coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 25 January 2012 (UTC)[reply]

All of us have limits to our time and abilities. I, with Dschen and your approval, can knock up infobox with coordinates by the end of the month, while you clever guys sort out a shapefile solution. I haven't the time or ability to work on shapefiles. Software development has always been an incremental process. Ubuntu uses a six month release cycle etc. The questions I posed still stand. Can we suggest a way to take this forward- would it be worth mocking up a suggestion on a user sandbox then bringing it back to the project talk page? Or is there a better way or will it just happen? --ClemRutter (talk) 20:05, 25 January 2012 (UTC)[reply]

Unless I'm mistaken, {{infobox road}} doesn't need any parameters added to it; if an editor wanted to add coordinates to the termini, they can add them to the input for the termini parameters. Imzadi 1979 → 20:18, 25 January 2012 (UTC)[reply]

While it's possible to do so, having separate parameters makes life easier for parsers and scrapers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 25 January 2012 (UTC)[reply]

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

We're here to benefit readers; not machines, parsers, nor Google Map's wikipedia layer. It has been argued ad nauseum that the display of coordinates adds no benefit to the reader on highway articles. - ʄɭoʏɗiaɲ ^τ _¢ 21:11, 25 January 2012 (UTC)[reply]

Coordinates should be displayed for the benefit of human readers. We've been over this many times, and the supposed arguments against displaying coordinates do not hold water; nor find consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:26, 25 January 2012 (UTC)[reply]

Floydian, you've made it abundantly clear that you don't like co-ordinates. But others do, and others find them useful. You can always ignore them if they're there. But for someone who wants them when they're not there, then Wikipedia will have let them down. Bazonka (talk) 21:27, 25 January 2012 (UTC)[reply]

I started this sections so we could discuss ways of quickly implementing Proposal 11, so could we all just focus on that issue. The questions I posed still stand. Can we suggest a way to take this forward- would it be worth mocking up a suggestion on a user sandbox then bringing it back to the project talk page? Or is there a better way or will it just happen? --ClemRutter (talk) 22:54, 25 January 2012 (UTC)[reply]

Again, if you're just adding coordinates to termini in the infobox, no template changes are required from a technical perspective. Unlike {{infobox road junction}}, which is used for a single location, an infobox row just for coordinates is not required nor ideal for a linear object. Imzadi 1979 → 23:27, 25 January 2012 (UTC)[reply]

Thanks for your input. What you have said has been discussed several times before.A proposal was made which gave a very strong lead, editors used to working with for example 'Infobox settlement' look for somewhere specific to add coord fields, because that is what they are used to. A work around is possible sure but so is adding then the two fields to Infobox road. I am focusing on the issue of how to make it happen, just that. So the questions I am posing are: Can we suggest a way to take this forward- would it be worth mocking up a suggestion on a user sandbox then bringing it back to the project talk page? Or is there a better way of getting it implemented?--ClemRutter (talk) 00:42, 26 January 2012 (UTC)[reply]

And where would these displayed coordinates appear? I will oppose adding a separate line to display coordinates in the template. If they're appearing in the same line as the existing terminal junction, no separate parameters should be required. (We have 5 sets of termini parameters: the standard a/b plus a1/b1 through a4/b4 if using the four segments. All of the parameters have alternate names substituting "end" for "terminus" as well.) You're not adding two fields, but 20, and if these parameters add additional display lines, you'll garner opposition. Imzadi 1979 → 00:54, 26 January 2012 (UTC)[reply]

I am asking about procedure. When we have a procedure- then we have something to talk about and that is the time to express preferences most of which are probably not contraversial. You have expressed strong views and other prominent editors have expressed strong support in the discussion to Proposal 11, how do suggest we progress? It is the procedure I want to establish.--ClemRutter (talk) 01:14, 26 January 2012 (UTC)[reply]

Since Proposal 9 is another proposal with near unanimous support, I think we should likewise take a look at how to move forward with making it happen in the real world. Here are some of the questions that I think need to be agreed on:

1. What sort of format are we looking at for the coordinates? Proposal 9 itself mentioned "shapefiles", but KML seems to do the same job, and much easier, too. Does anyone really object to using KML over actual shapefiles?
2. Assuming KML is used, is there any way we could place the KML on a wikipage, perhaps a subpage of the talk page? Would this present unwarranted parsing difficulties?
3. If we cannot put the KML on a wiki page, who do we need to convince to allow us to upload KMLs/shapefiles to Commons or the English Wikipedia?
4. How will the link to the coordinate file be presented in the article? Will it be visible in the rendered output? Can it be tagged in some consistent way so that reusers of data can consistently find it? (Perhaps a class or id parameter in the HTML, somewhat akin to the way microformats are specified?) Would it be feasible to allow the file to be named anything (i.e., must it always be named <article title>.kml)?
5. How can this be tied into GeoHack? How will the GeoHack link, if any, be presented in the article?
6. Likewise, how can this be tied into the WikiMiniAtlas? How can we use the WikiMiniAtlas to enhance our articles?
7. Who do we need to talk to in order to get the ball rolling on the necessary coding?
8. Do the technical people need anything from us? Can we help them in any way to make implementation as smooth as possible on their end?

I think that about does it. If there are any questions that need to be addressed besides those, now is the time to get them ironed out. —Scott5114↗ [EXACT CHANGE ONLY] 21:05, 26 January 2012 (UTC)[reply]

The more I'm looking into it The more I'm getting convinced that the data duplication that results from uploading shape files (not mentioning issues with proper licensing) are a bad thing (tm). I suggest focussing on a way to refer to OpenStreetMap ways. This is not completely trivial, but reduces redundant efforts. --Dschwen 23:29, 26 January 2012 (UTC)[reply]

Could the resultant file be dynamic from data in hidden or not on the page/template? Could it even be stored via the toolserver rather than commons thus reducing the effort required to maintain? I know you probably can't answer straight away. Do you have an example of a KML (for example) that has a route following a road and some points on it. Must find/make one for curiosity. DubhEire (talk) 00:03, 27 January 2012 (UTC)[reply]

Sorry, but wouldn't it be fair to say that the complexity here is the route information, i.e. not all roads are perfectly straight. Bringing in other points of interest would make it more of a challenge also. DubhEire (talk) 00:27, 27 January 2012 (UTC)[reply]

I don't think licensing is really an issue here. The roads projects already use shapefiles for creating raster maps; we are always careful to use free data sources. Freely licensed shapefiles are not all that hard to find; many state governments release their stuff as PD, as do some universities. What data is being duplicated? As for OSM ways, I don't really think that is necessarily a good idea, considering ways do not necessarily correspond to any given numbered route, and I'd hate to have to impose on them by saying "we need this way split over on Wikipedia even if you don't have any reason to split it". Furthermore, I personally would like to avoid getting entangled in OSM any more than I have to; I don't understand their community or how their tagging is supposed to work and it seems really inconsistent (i.e. the suburb I live in is tagged completely differently than the main city 20 miles away, the same road classifications mean different things between the two cities, etc). I don't think it is really reasonable to ask editors here to learn an entirely new set of cultural norms and editing procedures if they should want to add geographic data to their articles. —Scott5114↗ [EXACT CHANGE ONLY] 15:19, 27 January 2012 (UTC)[reply]

A shapefile is a standardized presentation of GIS data, which is measured by surveying. They can't be copyrighted, as there is no presentation, just measurements. - ʄɭoʏɗiaɲ ^τ _¢ 15:36, 27 January 2012 (UTC)[reply]

You should be careful with statements like that. Databases enjoy special protection. --Dschwen 15:43, 27 January 2012 (UTC)[reply]

Feist v. Rural: the raw data can not be protected by copyright in the US. Imzadi 1979 → 15:45, 27 January 2012 (UTC)[reply]

Scott, how OSM tags their ways is not an issue to us. We would not have to meddle with their tagging or their splitting of ways. It just boils down to formulating a query that obtains a certain set of nodes and lines. Such a query could do the splitting as well. We'd get raw data, not their road classifications. And such a query would still be smaller than painting your own road or copying it. It could fit into a template. --Dschwen 15:49, 27 January 2012 (UTC)[reply]

How would this work in practice? Say, if I need only half of a way, because the route I am interested in leaves midway through a way? —Scott5114↗ [EXACT CHANGE ONLY] 22:01, 27 January 2012 (UTC)[reply]

Give me an example for a problematic route and I will build you a query. --Dschwen 20:12, 28 January 2012 (UTC)[reply]

Sooo... this discussion is already dead again? I guess the candle that burns twice as bright burns twice as fast... --Dschwen 16:55, 1 February 2012 (UTC)[reply]

Like it. Point well made. I've been busy as I am sure you have too. I would still like to make an example so let's define what that should be in abscence of anything else. Are you looking to build a query on the toolserver to do this? I was thinking of manufacturing one by hand and then layer in anything else. Do you have an idea youself what steps must be taken? I am not that familiar with how things work on the toolserver, but I am willing to try. DubhEire (talk) 17:03, 1 February 2012 (UTC)[reply]

There is query to map (which I worked on as well a long time ago). It is abit outdated, so i might have to create a new version or construct an SQL-query on the database by hand. But this should get us started. All I need are examples for problematic ways. You must understand that my knowledge of the highway business is limited, so I may have an oversimplified idea of what is necessary to get highways out of the database in a manner that will please the pros. --Dschwen 17:22, 1 February 2012 (UTC)[reply]

I see how it works. It's too bad that, for the most part, the routes I care about have not been plotted on OSM. –Fredddie™ 18:46, 1 February 2012 (UTC)[reply]

Really?! What kind of routes are that? --Dschwen 22:44, 1 February 2012 (UTC)[reply]

I should clarify. The routes I care about don't have an OSM relation, which are made up of ways. A few roads articles have OSM relations tagged using {{Osmrelation}}. That's what I meant, sorry. –Fredddie™ 23:25, 1 February 2012 (UTC)[reply]

But you don't need osm relations, tags on the ways can be sufficient to query the data. --Dschwen 05:03, 2 February 2012 (UTC)[reply]

OK, I guess I need a picture drawn. Let's use Iowa Highway 415 as an example, since I was looking at it in OSM earlier today. It's shown on the map as IA 415. As a bonus, it's not a simple straight-line highway. –Fredddie™ 05:11, 2 February 2012 (UTC)[reply]

Good, I'll look into that. I'm moving today and won't have reliable internet access for a few days. But I'll be back! --Dschwen 13:25, 2 February 2012 (UTC)[reply]

Visualization pending (this is all I can quickly do from a hotel lobby:

osm_mapnik=> select name from planet_roads where ref='IA 415';
          name            
---------------------------
West Bridge Road
Northwest Polk City Drive
Northwest Polk City Drive
Northwest 35th Street
Northwest 35th Street
Northwest 35th Street
Northwest 78th Avenue
Northwest 78th Avenue
Northwest 78th Avenue
Northwest 78th Avenue
Southwest Oralabor Road
Southwest Oralabor Road
Southwest Oralabor Road
Southwest Oralabor Road
Southwest Oralabor Road
Southwest State Street
Southwest State Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 2nd Street
Northwest 112th Street
State Highway 415
State Highway 415
State Highway 415
Mile Long Bridge
(31 rows)

Does this look right to you? --Dschwen 02:43, 3 February 2012 (UTC)[reply]

After I realized it wasn't a serial list of ways, yes it does. –Fredddie™ 04:24, 3 February 2012 (UTC)[reply]

A couple questions:

• I notice a "where ref='IA 415'" on there. Is this an attribute on OSM that we are using to snag just a part of a way or just a variable to aid in processing on our end? If it is the former, how would we proceed if this tag is missing on OSM?
• What will happen if the data is changed on OSM? Will we have to alter the query on our end too?

The missing data question is most important to me, as there are situations that we cover on Wikipedia that OSM would not have tagged; unsigned highways, for example. An instance of this is Interstate 444, which is a snippet of freeway in downtown Tulsa. Because of all the highway designations that converge here, I-444 signs are left off the road, but it is officially on the Interstate rolls and therefore we cover it with its own article. However, since knowing the road is I-444 is useless for actual navigation on the ground, OSM does not have any sort of I-444 tags at all; they mark it the same way it's marked on the ground, as portions of US-412 and US-75. Another case I am concerned about is rural areas where perhaps the data has not been tagged or processed at all since initial import from TIGER (i.e. it is simply tagged as whatever the Census Bureau tagged it with) due to lack of interest in that area by OSM editors (it happens on this wiki, I'm sure it happens there too). —Scott5114↗ [EXACT CHANGE ONLY] 18:43, 3 February 2012 (UTC)[reply]

ref is an osm attribute. And a way is really a way-segment. An OSM way is always a uniform piece of road, as I understand it. So there really never should be a case of needing to get part of a way. Of course we can kill this discussion with a bunch of unlikely ifs. Can te data change on OSM? Yes, but I would cache the query results, and cache clearing could be made in a way that the nre result is previewed and checked first, so that the query could be adapted. Might there be some exotic roads where the tags are still missing? Maybe, but I'd rather cover 95% of all use cases with a clean and rather simple solution, than continue discussing about a suboptimal solution. A suggestion: get an OSM account and add the tags onto the data yourself, you'll be doing the world a service at the same time ;-). Anyhow, I will need a few days to settle in at my new place, but I already played around with querying the actual coordinate data and plotting it in the browser (this is a lot of fun!). --Dschwen 14:24, 4 February 2012 (UTC)[reply]

Ways are always uniform pieces of road, but a route doesn't always follow them. Consider the very common and not at all exotic instance of a concurrency. This is a segment of road with two different designations following it, i.e. both Interstate 44 and State Highway 3. This will, in my experience, usually be tagged in OSM as just the more important designation, in this case, I-44 (makes sense for OSM's users, it's what most people will be interested in). In any event, if you were trying to get a route trace for OK-3, you're going to miss out on those extensive concurrent sections (the first 304 miles of OK-3 is concurrent with another road, and it's only independent for 40 miles or so before it joins up with something else) because they won't be tagged as SH-3, they'll be tagged as whatever the more important road is.

As I said before, though, I consider it unreasonable to have to require editors to have to edit data over there, learn their conventions for tagging, etc. Personally I have enough going on here on Wikipedia to have to worry about falling down a whole new rabbit hole of butting heads with OSM editors for reasons that do not matter to them. (Why should they care if I need so and so tagged in this or that way for Wikipedia's queries? It doesn't benefit OSM any.) I, and probably most of the other roads editors, would much rather prefer to be able to hand tune the data to meet Wikipedia's needs without having to step on someone else's grass. Before we spend too much time chasing the OSM thing, can we stop and investigate the KML option more thoroughly as well? I don't really see why we've abandoned the idea of uploaded KML files other than a vague "data duplication" explanation (which I don't think holds much water, frankly; what we'd be doing with the data is somewhat different than what OSM is doing—it's a subtle difference, yes, but a difference).—Scott5114↗ [EXACT CHANGE ONLY] 15:00, 4 February 2012 (UTC)[reply]

Feel free to chase the KML dream. I won't actively push for it. It makes no sense to me to reject the notion of collaborating with OSM to improve the tagging for everyone's benefit. I will look into the road concurrency thing, I don't see why OSM would not be interested in properly tagging those ways. It actually does not make sense for OSM users to tag only with one designation. Just think about routing applications. Saying those correction would be another rabbit hole and you wouldn't want to force users to edit on another project seems a bit absurd, considering the alternative of using complex external software to prepare the data. --Dschwen 15:55, 4 February 2012 (UTC)[reply]

You mean complex software like Google Earth, where you make a path and export to kml? - ʄɭoʏɗiaɲ ^τ _¢ 16:28, 4 February 2012 (UTC)[reply]

That will most certainly give you a ridiculously low quality file, unless you spend a lot of time... ...duplicating the efforts that were already made elsewhere. Not invented here syndrome. --Dschwen 17:05, 4 February 2012 (UTC)[reply]

Dschwen, we already use GIS software and high-quality, freely-licensed GIS data in the creation of our maps. It's not terribly complex for us to select the red line that has just been created for the purpose of a map and export it to a KML. We teach new editors that are interested in the mapping aspects of the project how to use QGIS whenever they ask. We have tutorials written. We have the infrastructure for this ready on our end; don't worry about the complexity there. —Scott5114↗ [EXACT CHANGE ONLY] 17:18, 4 February 2012 (UTC)[reply]

Road concurrency is taken care of at the highway level at least in OSM (see I 57; I 70 near Effingham, IL). However this turns out, I'll be happy to add overlay support to the WikiMiniAtlas. --Dschwen 17:06, 4 February 2012 (UTC)[reply]

I was trying to use the Query to Map method of retrieving OSM data for river liffey or N11 in Ireland. I'm not sure if I am querying it correctly. I tried Way:name=Liffey ;Node:river=* What do I put the bounding box as? I tried -5,52.-6,53 . I also tried Way:name=N11 ;Node:highway . Also tried leaving bits out too. Just trying to understand this approach a bit better. Thanks. DubhEire (talk) 11:24, 18 February 2012 (UTC)[reply]

That particular tool is just broken. Above I gave an example for how to manually query the database. However the OSM querying approach was shot down, so I did not pursue that avenue any further. --Dschwen 02:26, 19 February 2012 (UTC)[reply]

To separate this from the closing/ed RFC, above, I figured its best to hash out some ideas on whether we can do anything with kml files. As some may know, you can draw a path in Google Earth, right click it > Save Place As... and change the filetype to .kml - Voila, any path, on roads, offroad, rivers, tracks, flight paths, ad nauseum can be plotted with geographical coordinates. I made a short but detailed line for the confirmed extension of Highway 427 near Toronto, and this is the content:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
	<name>427 Extension.kml</name>
	<Style id="s_ylw-pushpin_hl1">
		<IconStyle>
			<scale>1.3</scale>
			<Icon>
				<href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href>
			</Icon>
			<hotSpot x="20" y="2" xunits="pixels" yunits="pixels"/>
		</IconStyle>
		<LineStyle>
			<color>ffff55ff</color>
			<width>4</width>
		</LineStyle>
	</Style>
	<StyleMap id="m_ylw-pushpin1">
		<Pair>
			<key>normal</key>
			<styleUrl>#s_ylw-pushpin1</styleUrl>
		</Pair>
		<Pair>
			<key>highlight</key>
			<styleUrl>#s_ylw-pushpin_hl1</styleUrl>
		</Pair>
	</StyleMap>
	<Style id="s_ylw-pushpin1">
		<IconStyle>
			<scale>1.1</scale>
			<Icon>
				<href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href>
			</Icon>
			<hotSpot x="20" y="2" xunits="pixels" yunits="pixels"/>
		</IconStyle>
		<LineStyle>
			<color>ffff55ff</color>
			<width>4</width>
		</LineStyle>
	</Style>
	<Placemark>
		<name>427 Extension - Confirmed</name>
		<description>Confirmed 427 Extension to Major Mackenzie</description>
		<styleUrl>#m_ylw-pushpin1</styleUrl>
		<LineString>
			<tessellate>1</tessellate>
			<coordinates>
				-79.63373960418063,43.76878712368649,0 -79.63903097044471,43.79633371050091,0 -79.63953706566628,43.79813462605291,0 -79.64014339880654,43.79990192230872,0 -79.64105546367523,43.80158746205122,0 -79.64217024302441,43.80332261683535,0 -79.64400186455735,43.80499391970488,0 -79.64602914490877,43.80637475945654,0 -79.6475803133375,43.80750755947232,0 -79.64887313738049,43.80874147161496,0 -79.6499710856201,43.80996480300379,0 -79.6508287093325,43.81114225406859,0 -79.65163203756102,43.81241649371911,0 -79.65223685017578,43.81370235674524,0 -79.6532277614819,43.81636283490142,0 -79.65425432825268,43.81821638700773,0 -79.65536423972627,43.81966365767966,0 -79.65651937492518,43.8211104966409,0 -79.65788902057551,43.82245631485755,0 -79.65939061053443,43.82356669235759,0 -79.66054617443874,43.82434399790651,0 
			</coordinates>
		</LineString>
	</Placemark>
</Document>
</kml>

Now nobody (and I'm looking at you, Andy) can say that is not machine parsable. In fact, I believe we can parse it here using string functions and some regex to pull out pairs.

Now here's something different!

By having a kml at a location, ie Template:KmlRoute/country/state-prov/type/number.kml, we can load it into Google Maps using the URL http://maps.google.com/maps?q=http://en.wikipedia.org/wiki/Template:KmlRoute/country/state-prov/type/number.kml The bonus is that since kml are text-only, we do not need any special adaptation to utilize them! - ʄɭoʏɗiaɲ ^τ _¢ 16:42, 4 February 2012 (UTC)[reply]

Even more simply, we could possibly put the KML text at, say, Talk:name-of-article/KML, then have some sort of template that would create that url with &action=raw (which causes the software to return just the wikitext, nothing else). No uploading required! (The sticking point, which I have not tried, is whether the parameters in Wikipedia's URL would interfere with the parameters that Google Maps uses.) This could be a mechanism to pass the KML to a modified GeoHack as well. —Scott5114↗ [EXACT CHANGE ONLY] 17:14, 4 February 2012 (UTC)[reply]

Just pasted this code into User:Scott5114/futurehwy, and it works marvelously: [1] Google Maps interprets the Wikipedia URL correctly, and parses the KML with no problem. Great find, Floydian! —Scott5114↗ [EXACT CHANGE ONLY] 17:23, 4 February 2012 (UTC)[reply]

And another, more substantial test: Talk:Oklahoma State Highway 82/KML, and displayed on Google Maps: [2]. This took maybe five minutes to export from my Oklahoma Highways QGIS project. —Scott5114↗ [EXACT CHANGE ONLY] 17:40, 4 February 2012 (UTC)[reply]

It also appears that, at least in Google Maps, the map is loaded properly centred and zoomed. I'm going to try and see if other services support this. - ʄɭoʏɗiaɲ ^τ _¢ 19:44, 4 February 2012 (UTC)[reply]

Bing also supports, [3]. However, I'm not sure if the 200 coord limit applies here as well. OSM does not support KML (oh well, maybe if we do they'll adapt). I've emailed MapQuest regarding that service's ability to display them. The two largest mapping services work now. - ʄɭoʏɗiaɲ ^τ _¢ 20:24, 4 February 2012 (UTC)[reply]

Ok, I thought I understood he lecture about road concurrency. Why does the OK 82 test omit the section that is concurrent with OK 28? --Dschwen 00:58, 5 February 2012 (UTC)[reply]

Apparently when I created this map a few months ago I forgot to include that data as part of OK 82 (it was probably tagged as OK 28 only and I overlooked it because of the comparatively low resolution of the PNG map I created with this data). On closer inspection there is another concurrency missing, as well. This is basically a result of my own ineptness, not anything intentional. :P —Scott5114↗ [EXACT CHANGE ONLY] 01:28, 5 February 2012 (UTC)[reply]

This has now been corrected. —Scott5114↗ [EXACT CHANGE ONLY] 04:24, 5 February 2012 (UTC)[reply]

I have created {{AttachedKML}} and placed it in the Oklahoma State Highway 82 article as a proof-of-concept. Unfortunately, the Google Maps link is busted for now (I need some way to convert the URL to the percent-sign notation used above for Google to accept the URL), but everything else works. —Scott5114↗ [EXACT CHANGE ONLY] 04:55, 5 February 2012 (UTC)[reply]

Thanks to some IRC help from Rschen7754, the Google link now works and the template is fully functional. —Scott5114↗ [EXACT CHANGE ONLY] 05:20, 5 February 2012 (UTC)[reply]

Very interesting approach. Looks good. Just thought I'd throw some positive encouragement in there. DubhEire (talk) 21:54, 5 February 2012 (UTC)[reply]

That is excellent. I think we have a winner here. Mangoe (talk) 22:07, 5 February 2012 (UTC)[reply]

Yeah, I think it's good. I think there's some finer details that may need to be worked out, and more testing done before wide deployment, but it's promising. (For example, we're storing the files as a subpage of the talk page... is this what we want to do?) --Rschen7754 22:14, 5 February 2012 (UTC)[reply]

I am not sure; we might want to do a straw poll or some such to see what the community prefers. I don't really have strong feelings on the matter, personally. Obviously, this is what is easy to deploy now, and is a valuable proof of concept, which will be useful to illustrate to people what we're trying to do if we are going to ask for KML files in the file namespace. Another important point is that the links to Google Maps and Bing are also just a proof of concept. Ideally we could eventually get something much like Geohack going that would list all services that will take a KML and provide other useful tools. —Scott5114↗ [EXACT CHANGE ONLY] 02:16, 6 February 2012 (UTC)[reply]

I'm creating a test at Ontario Highway 401. At this point I have far exceeded 200 sets of coordinates, and the line still shows on Bing. - ʄɭoʏɗiaɲ ^τ _¢ 04:14, 6 February 2012 (UTC)[reply]

The AttachedKML template is now detected by the WikiMiniAtlas. Check it out on Oklahoma State Highway 82. A blue globe (and the word 'Map') appear in the top right corner of the article page. Zoom in a bit to see the KML data overlayed over the map. Tested in Firefox and Chrome. Still some performance issues on page load, but displaying takes no time. --Dschwen 06:28, 7 February 2012 (UTC)[reply]

P.S.: The KML structure as used in the Ontario 401 article is not yet supported. And it makes my Firefox freeze hard... Working on that. --Dschwen 06:48, 7 February 2012 (UTC)[reply]

P.P.S.: For now the new code is run only on the Oklahoma State Highway 82 page. Must go to sleep now! --Dschwen 06:50, 7 February 2012 (UTC)[reply]

Could it be because of the number of points? There's probably close to a thousand coordinate pairs. - ʄɭoʏɗiaɲ ^τ _¢ 14:57, 7 February 2012 (UTC)[reply]

A thousand coordinate pair is nothing that a modern Javascript engine should worry about. That should take a few hundred milliseconds at most. I'm not doing complicated stuff. My guess is that I either made bug that is triggered with your KML (coordinates tags inside the linestring tags, rather than raw data directly inside the linestring tags), or it is a bug in the built-in XML parser in firefox. --Dschwen 15:03, 7 February 2012 (UTC)[reply]

Its a good opportunity right off the bat to compare the output of qgis to Google Earth though, better now than later. - ʄɭoʏɗiaɲ ^τ _¢ 15:18, 7 February 2012 (UTC)[reply]

My mistake, the KML is identical. Must have overlooked the coordinates tag. Will investoigate the firefox issues further. --Dschwen 17:29, 7 February 2012 (UTC)[reply]

Ok, should work now on the Ontario Highway 401 article as well. For technical reasons there still is a red dot on the map, which is taken to be at the arithmetic average of all lat and long components respectively. This is not the ideal solution. I may rather pick a point on the line data, close to the geometric center of the dataset. Does this work for other people? I haven't had a chance to test in IE yet. --Dschwen 20:52, 7 February 2012 (UTC)[reply]

P.S.: I will be using similar algorithms for the extraction of start- and endpoint coordinates (if there are no ambiguities) in the future, if the use of coord should be prohibited on highway articles (although I don't see that coming just yet). --Dschwen 20:54, 7 February 2012 (UTC)[reply]

For clarity, though the RfC closed with consensus "to use shapefile software to illustrate the the area of highway mentioned", there is no consensus for proposals to remove or prohibit the use of other coordinate display methods also. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:52, 6 February 2012 (UTC)[reply]

Well, you keep living in your own world Andy, but this is not for you to interpret, it's for the closing admin to interpret. In fact, they did:

Proposal 2: limited use of coordinates - This statement is not found to be a consensus of the community at this time.

Proposal 3: Start and end points of highway only - This statement is not found to be a consensus of the community at this time.

Proposal 5: Status Quo - This statement is not found to be a consensus of the community at this time. (bolded so you don't continue to play ignorant)

Proposal 6: Strengthen use of coordinates in MoS - This statement is not found to be a consensus of the community at this time.

Proposal 7: Minimalistic entry in existing junction table - This statement is not found to be a consensus of the community at this time.

Proposal 11: Start & End coords in infoboxes are always welcome - This statement is not found to be a consensus of the community at this time.

So no, you're wrong. - ʄɭoʏɗiaɲ ^τ _¢ 13:21, 6 February 2012 (UTC)[reply]

Pigsonthewing is right inasmuch as the decision that was made does not give users the right to remove existing information from articles until such time as shapefile data is added. Floydian is right inasmuch as the continued adding of co-ordinates to articles would go against the spirit of the decision. The question I am left with is, when is all the shapefile data going to be added? Dadge (talk) 12:31, 7 February 2012 (UTC)[reply]

(Since other geographical pages on Wikipedia will continue to use co-ordinates, I do disagree with the decision that was made. I have dabbled with shapefiles but I'm not up to speed on their potential in this field, so I'm willing to be won round.) Dadge (talk) 23:36, 7 February 2012 (UTC)[reply]

I'm rolling it out in Ontario now, but I believe there needs to be a little brainstorm on the finer details. I'm going to contact the trains, rivers, aviation and ships wikiprojects, as I believe they will stand to benefit from this over the current coordinate system. - ʄɭoʏɗiaɲ ^τ _¢ 14:54, 7 February 2012 (UTC)[reply]

In USRD, it depends on how much help we get from outside. It's instructive to look at how USRD generates regular maps to see how the addition of shapefile data will most likely be handled. We still have 7,069 articles that need regular maps. Articles usually get maps when A) someone who works on a particular state does all of the articles on that state in one large batch, or B) as an article rises up through the ranks towards FA: a lot of Bs have them, most GAs do, and a map will certainly be present by the time an article is brought to FAC. The result is that map coverage varies from state to state—in some states, all articles have a map, in others, coverage is patchy, in still others there's no maps at all. (Most of the time this is states like Wyoming, Montana, etc. where there are is a lack of editors with personal connections to the area, which tends to inhibit interest in those articles). Another reason I bring up maps is because they're linked to the KML—if you create a map in QGIS, then with one or two clicks, you can create the KML too at the same time. If we could get a band of a dozen or so editors together willing to learn QGIS and generate maps and KMLs, I bet we could get 100% completion by summertime. If not, well, it will probably take years; there's probably 8 or so core USRD members, and we usually put our focus on improving articles' prose most of the time. For anyone that wants to help, we have a tutorial for how to create maps—I can expand it in the next couple of days to cover KML generation as well. —Scott5114↗ [EXACT CHANGE ONLY] 15:02, 7 February 2012 (UTC)[reply]

Wouldn't it make sense to have a unified task among the various projects to work out a common format/protocol/tool/whatever for everyone? Mangoe (talk) 17:36, 7 February 2012 (UTC)[reply]

We do have such a project ;-) --Dschwen 17:53, 7 February 2012 (UTC)[reply]

I've invited four wikiprojects (rivers, ships, aviation and trains) to the discussion here, but eventually it should be worked into the geo project as this is something that has a lot of use across Wikipedia. - ʄɭoʏɗiaɲ ^τ _¢ 18:05, 7 February 2012 (UTC)[reply]

As far as USRD implementation, it will be slowly phased in. We'll wait until there's a standard, and then it will probably become something we start requiring at WP:HWY/ACR. The FAs and GAs will get the priority, then we can start adding to the rest of articles. --Rschen7754 19:26, 7 February 2012 (UTC)[reply]

Excuse me for having an opinion, but there are several unresolved issues here. The RfC has closed that is a fact. The results of their deliberation were contradictory and Andy is totally right is saying clarification is needed. All I got out of the dogs breakfast was near total agreement that fields should be provided in the infobox for geotags at start,point endpoint and most significant point. But further debate did not happen, as all the key players were folowing the hare of shapefiles. Now we understand that this will go to consultation with the trains, rivers, aviation and ships wikiprojects. How narrow is that! Rochdale Canal is a typical article about a canal- a linear structure if ever there was. Look carefully at the Wikiprojects that it is in- tell me how those editors views will be represented. Or look at the Nico Ditch an FA in need odf a Infobox road. Via Domitia I have mentioned before. In the Deansgate article the coordinate|title geotag is not in the Infobox but lower in Further Reading section and on Android phones this does not display if it were in the infobox I could pick it up from the infobox and via Geohack to Google Maps. There are a lot of issues here but it does demonstrate that it is easier to parse from within a infobox. It is far from clear. To lighten up a little

Proposal 2: limited use of coordinates - This statement is not found to be a consensus of the community at this time. So that means-

Proposal 2: unlimited use of coordinates - This statement represents a consensus of the community at this time. Doh!

In the meantime, this may seem academic to some but it is holding back editors- and me. I am making a coffee- anyone fancy to join me? --ClemRutter (talk) 20:31, 7 February 2012 (UTC)[reply]

What point are you trying to make? I just see illogical reasoning and someone that didn't make it as far as proposal 6. Andy did not request clarification, he gave his opinion and presented it as fact.

What is narrow about contacting other projects that may see a use in having a line instead of one point? It's this "only {{coord}} can EVER represent any object on this planet" attitude that is holding back editors. An attitude that is shared by about three editors, one of whom will whine until the sun explodes. - ʄɭoʏɗiaɲ ^τ _¢ 21:25, 7 February 2012 (UTC)[reply]

No, Floydian, you are doing Clem injustice. He did not say that "only coord can EVER represent any object on this planet", and neither did he imply it or did anybody else on this page. As far as I understand Clem, and I might me injecting my own opinion, he thinks it is a better than nothing approach. And coord has an existing infrastructure behind it, has a very broad application across hundreds of thousands of articles and is a lowest common denominator. KML etc. is probably a great idea for linear features, but I don't see why we couldn't have coord, too. --Dschwen 21:33, 7 February 2012 (UTC)[reply]

Don't forget that using Coord - among its other benefits - enables KML to be generated; and for points of interest, such as junctions, bridges etc., not merely the line of a route. Proposal nine does not obsolete that function; nor did it claim to. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:33, 7 February 2012 (UTC)[reply]

I think Dadge's comments summarize the situation pretty well. I've asked DeltaQuad to come in and leave a few comments to clarify. --Rschen7754 21:37, 7 February 2012 (UTC)[reply]

My statement above was "there is no consensus for proposals to remove or prohibit the use of other coordinate display methods". Floydian and others may choose to pretend that's wrong; or that it's merely my opinion. I invite them to show which proposal to remove or prohibit the use of other coordinate display methods achieved consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:30, 7 February 2012 (UTC)[reply]

-oo-

It is incredibly difficult to hold a conversation, when an editor fails to read what you have said and fails to follow the links you have given them. It is incredibly difficult to hold a conversation when editors think that a contrary view is an attack. It is incredibly difficult to build an encyclopedia when you are spending so much time on the Wiki talk pages. So, without trying to offend I will revert to experience gained over 40 years in academic life and the classroom. If you feel hurt or slighted, you are personalising the issue and this not good. If you can think of an acronym starting with a WP: to describe the syndrone you are becoming over involved.

1:What point are you trying to make? None- I try very hard to not treat Wikipedia like a gladiatorial contesth, I respect one editors tenacity in producing a vast body of work on roads in Ontario, while still thinking they could be a whole lot better if the features could have had a geotag so I could locate even one end of these roads on a map, and preferably on a clickable map which in 4 stroke of the mouse button, links me to external reality. Ontario Highway 401 is brilliant writing but for missing the one element of a geography article that is essential-- but I will live with that if it means that the article gets written.

2:Illogical reasoning: That seems a little pointed - but are we perhaps mistaking Deductive reasoning with Inductive reasoning, or Inductive reasoning with Mathematical induction (This time don't follow those links). Or perhaps we missed the joke- the logic was perfect.

3:Andy did not request clarification: I didn't read it that way- I too nearly requested clarification 2 days ago. In certain branches of acedemia and indeed government simple statements are equivalent to requests, and it is considered to be more polite to do it that way as it is less threatening to an official. As such the official sees it as a request and of his own violition volunteers the information. The RfC has only served to obfuscate.

4:It's this "only {{coord}} can EVER rep...: The word I used was coord, and not {{coord}}. Personally I prefer to unwrap it into the lower level start_lat, start_long, end_lat, end_long, principal_lat, principal_long, principal_coord_caption. I do use the common abbreviation coord when I mean a WGS84 co-ordinate pair.

5:What is narrow about contacting other projects:It is narrow to contact three selected projects when there are many more. I gave links to the talk pages of three articles I have read, edited or added photos to. All need an infobox and all are linear features. Open each page and look at what projects they belong to. Rochdale Canal is a typical article about a canal. A linear feature- it is not in the narrow group of projects you want to contact. Look carefully at what project it is in. These are the projects you need to contact to prove uou are not being narrow, By induction you will see, that if you contact WikiProject Greater Manchester, WikiProject Yorkshire you need to contact each English County Group! WikiProject UK Waterways suggests that there will be an equivalent WikiProject French Waterways and so on. Open the link on Via Domitia and we have two more project groups to contact including WikiProject Classical Greece and Rome. You would notice that none of the three articles had a road, aviation or a river in their ownership tree. None of the editors working in these fields would thus have an opportunity to submit ideas. That is why the suggestion is narrow.

6:If I remember a few weeks back. A consultation was opened within this project. Someone helpfully brought it to my attention- (and others attention) and instead of being thanked for widening the consultation sample, he was vilified- WP:acronums were spat at him and...: this process does seem to be in danger of becoming recursive.

7:An attitude that is shared by about three editors, one of whom will whine until the sun explodes.: Lets have naming of names here- I have found about 140 dangerous individuals and listed them here. Move the the discussion to the Wikipedia:WikiProject Geographical coordinates page and perhaps we will have a wider range of input. Hyperbole makes great reading but is inappropriate in a dissertation or theses.

8:All this debate seems to taking place from the POV of a PC User- but I have just got a smart phone and Wikipedia is another animal on that- and the apps interlink. We need to stop just thinking in terms of a static XVGA screen and see Wikipedia as part of the infrastructure and plan ahead while implementing what is currently possible.

So, to sum up. Please follow the links in my post before posting a reply. Please address the arguments rather than formulating a withering reply. Please seek clarification on the meaning of the RfC. It is logically flawed. Please, in spite of the RfC work on improving the MoS advice. Please consider Smart phones: the technology of the generation one behind us. In the medium term sort out shape files. In the short term, add the fields I suggested above to the Infobox (even if you can't decide yet how to render them- they need to be there so they are available to parsed). And in the even shorter term- stop treating this as Student Union debating society balloon debate, and treat it as strategic planning. Most editors find this sort of thing off putting and tedious- senior editors have a duty to act responsibly. --ClemRutter (talk) 00:11, 8 February 2012 (UTC)[reply]

Shapefile needs to be replaced with KML, as that appears to be the more technically feasible way of doing things. I contacted the four projects not to sway discussion, but to brainstorm a way of working with a solution that clearly has consensus, above. I assumed these were good starter points, but since you know of other please feel free to draw more people in, but I'm not obligated to contact every project. Naturally, since the RfC occured here, the continued discussion has taken place here; I see no fault in that. The RfC is clearly closed, as has been pointed out. The time has come to move forward, not to continue with the now closed debate.

Yes, it is illogical reasoning to deduce that the "no consensus" on proposal 2 means the opposite does have consensus, especially when several other proposals to maintain coordinates or expand their use also did not gain traction.

I am moving forward with implementing KMLs; the route map it has provided on Highway 401 is far superior to anything coordinates alone could produce. There is no need to supplement that data with start and end coordinates when that data already includes start (the first) and end (the last) coordinates, and when Google and Bing and the WikiMiniAtlas all automatically centre the map. You can work with us or you can bicker among yourselves. I look forward to hearing from editors that have constructive criticism rather than those trying to continue the closed RfC. - ʄɭoʏɗiaɲ ^τ _¢ 01:28, 8 February 2012 (UTC)[reply]

Regarding point 6: I'd like to bring to your attention that WP:CANVASS is not just a suggestion; it's part of the rules here. Tagishsimon violated the rules and was appropriately warned by several administrators. If you have a problem with that, then I honestly don't know what to say... we are a consensus-driven community, but there are house rules and if an editor chooses not to follow them, there are usually consequences for that. --Rschen7754 05:53, 8 February 2012 (UTC)[reply]

Technically you are right- but the core problem is that a RfC that has global significance needs to be placed where people will see it. Having an interest in geotagging of settlements, canals, tracks I watch the Geographical coordinates where it should have been posted- I studiously avoid project pages that I don't need to view. Time spent there is time wasted- a bit like student union politics. Technically Tagishsimon needs to be threatened with the naughty step. But similarly RfC are totally disruptive, and a form of vandalism if placed in the wrong place- the sample size needs to be large, and should not be skewed to canvas one interest group. I resent the fact that this was not better placed- and further resent the fact that it is now being extended to a narrow group of projects. In point 5: I give a list of projects having a legitimate interest in consultation- it is huge. I resent the fact that a detailed knowledge of arcane Wikipedia procedures is being used to prevent useful work being done. Doing a controlled trial of a new facility is good, leading in the medium term to abandonment or adoption but it should be done with discussion where the greater community can be informed and kept on board.

Thanks, for taking time to reply, I am sure that everyone on this page has tremendous experience- but suspect that experience is hindering the resolution of this problem.--ClemRutter (talk) 15:29, 8 February 2012 (UTC)[reply]

If you look, I crossposted (neutrally) to relevant WikiProject talk pages, including the coordinates project's talk page: [4], and every project talk page linked off the coordinates project page, and also {{Centralized discussion}}. If people missed all those posts, there's not a whole lot I can do about it. As DeltaQuad posts below, the scope is related to highways only, so this page is the most appropriate place.

Many coordinate editors have complained that they have been "left out" of the discussion, which I have addressed above, and also are making the assertion that they are the most qualified ones to be making this decision. This statement implies disenfranchisement of those who work on highway articles, which completely ignores whatever expertise we have that the coordinates people would not; furthermore, this sentiment flies in the face of everything Wikipedia stands for. As a Wikipedia editor and administrator, this sentiment would be quite disturbing to me even if I had no connection with the highways projects. I urge those who have made this remarkable assertion to reconsider, and realize that we're all working on the same encyclopedia, and that compromises have to be made, and that now that we have had the RFC, we need to move on. --Rschen7754 19:16, 8 February 2012 (UTC)[reply]

• I have been asked to make comment on the closing of the RfC. As far as the scope of this RfC, other wikiprojects may be interested in this discussion and may have wanted to comment on this RfC (if this is not what's being said above, then my apologies), but the scope of this RfC is just limited to Highways. As for the comment about my closure of not being consensus, to assume the opposite as consensus, is not what the consensus was. If you read the proposal, it was to have a limit of 10 coordinates, and it proposed a format. So what's the opposite of ten? The inverse of ten? 1/10? I didn't know we could do that. Just because something is said not to be consensus does not mean that the opposite is, because the opposite is not always tangible in words. There was no consensus to put a limit, but if we apply some common sense, if someone posts a huge list of coordinates (i'm thinking in the 20 range, but then again i'm an outside view) then revert it and follow up. And yes there could very well be a flaw in the RfC, but I can't really do anything about it now. I hope I have addressed what needs to be addressed, as I do have to run now, let me know if I missed anything. -- DQ (ʞlɐʇ) 18:03, 8 February 2012 (UTC)[reply]

• The logical inverse to a limit would generally be no limit, which you state in saying "There was no consensus to put a limit'. YMMV, of course. If we're back to a discussion of arbitrary limits, then we have not progressed far: except that we do have a most excellent shapefile implementation on Highway 401, which, all discussion of {{coord}} aside, I hope we can all get behind. It doesn't provide for a great many of the use cases I'm concerned about, but it is a very very effective and welcome addition to our toolset - for which thanks. --Tagishsimon (talk) 19:42, 8 February 2012 (UTC)[reply]

• Ahh yes, thank you for correcting my math, I should know this ;) And sometimes it does take a misstep to decide where to go in the future, and that's always if there is a misstep, something I am hoping comes as a result of my RfC closures. But that's how we all learn, and how things on an encyclopedia are made better. -- DQ (ʞlɐʇ) 21:13, 8 February 2012 (UTC)[reply]