User talk:ClemRutter/Archives/2012/March

ON-401 infobox sandbox
A comment or two. If coordinates are added to the infobox, why didn't you just add them as part of the termini? In other words, why didn't you put it so that we'd have "West end: Highway 3 to Windsor " and the equivalent at the other end. The reason I wouldn't have done what you did is that it duplicates the function of the Major intersections section of the infobox and adds extra length. (We were frequently criticized in the past for having infoboxes that were too long, which is why in the US, we arbitrarily capped them at 10 junctions to keep the length in check.)

In short, using a construction of  incorporates what you're trying to do, doesn't duplicate information in two locations in the infobox (map caption, junction list) and keeps the over length in check a bit. Yes, we could potentially add a specific parameter that would only function to append the coordinates after the terminus_a/b inputs and automatically encapsulates it in the small tags, but I would oppose adding a duplicated location for such a thing. Note, not all articles even have maps yet, so the map notes won't appear.

Long term, I want to do away with the PNG/SVG maps and embed the WikiMiniAtlas to make an interactive map using the KML data to highlight the roadway on map that's zoomable, scrollable, etc.

Second comment, but the alternate names aren't in bold for a reason, and if they were supposed to be, the template would do that already. (It's been discussed and rejected in the past.)  Imzadi 1979  →   02:30, 24 February 2012 (UTC)


 * We are trying to get this article to FAC- the problem is 1 (b), 1 (e) and 1 (d). We are trying to find ways to represent a minimal amount of geographical information in a way that is clear to a random non- roads specialist. I have quickly knocked up a proof of concept to help a small group of editors who are working on the problem. I have used raw code for speed. When we have suceeded in gaining approval then the template team can go away and modify the template so it provides a way of providing the output needed for an FAC. A cursory glance suggests that the template is bloated and it must be hell to maintain- but that is for another day.--ClemRutter (talk) 02:54, 24 February 2012 (UTC)
 * I respectfully disagree with you, and precedent backs my position. There are over 40 other highway FAs that lack coordinates in the infobox, hence my italicized "if". The problem with your mockup that I have is duplicating the mention of the termini below the map, when we have an entire section of the infobox devoted to the termini and major intersections between those termini. My suggestion is to move the coordinate display after the location (Windsor, "towards Montreal") in the termini in the infobox rather than dedicating another line or two in another location of the infobox.
 * Now, as for your points about 1b, 1d and 1e, I disagree, and that wasn't my point for commenting here. 1e doesn't apply at all because the article itself is stable, excluding edits made in reaction to comments in the FAC. (Such edits are not to be considered to destablize the article.) The fact that the issue is hotly contested elsewhere doesn't mean the article changes significantly on a day-to-day basis, and in fact, when consensus emerges on what to do, the article can be simply updated without being destabilized.
 * What's not neutral about the article? What viewpoints of information about the road have not been presented? Coordinates are not a viewpoint just data, so their presence or absence in the article does not make the article neutral nor biased.
 * That leaves your contention about 1b, but we've disagreed on that issue. In fact, opposition based on 1b for articles that lack coordinates did not hold up M-185 (Michigan highway) nor U.S. Route 2 in Michigan during their November–December 2011 candidacies. I would say that the promotion of those two articles over the objections of Pigsonthewing and Tagishsimon helped to settle that issue.  Imzadi 1979   →   03:18, 24 February 2012 (UTC)
 * Firstly, it is great to have the conversation- its just a pity that it is not over a cup of coffee. Do look me up when you are around Kent and we can do it properly.
 * As I have said- I presented a few ideas as proof of concept as I would do when commissioning a professional to do any web job. I totally agree with you that the final rendered code should be generated from existing fields. All I can do is play with what is there. I haven't the time or the inclination to get involved documenting the road systems Argentina- or Zambia or anywhere in between. What I can do is to advise on article I stubble upon and give advice from a fresh standpoint. FAC is not point scoring- it is about proving that there is no dispute. Here we have a well written article that is going nowhere because 1 (b) it fails to include all the facts- and does not put the article in the context expected by a significant group of users. 1 (e) mentions no edit wars- and there is a proxy edit war going on all Wikipedia- dare I mention that it could spill onto this page. 1 (d) is less sure- but I would suggest that insisting on a rigid format for the Infobox could be a violation. The task is to get this FA status by addressing these issues. The way forward is to address these issues, not to enter denial and prove a narrow point by clever wiki-wonking.
 * What I can do is point out what looks wrong, on my Firefox implementations on two or three Ubuntu boxes, with my Monobook preferences (sometime cross checked with Vector)- which may be very different from how other folks see it. FAC is about being exemplary.--ClemRutter (talk) 10:00, 24 February 2012 (UTC)
 * I guess that we will have to disagree on those points, but that is still not why I approached you outside of the fire that is burning on the review page. (I've also approached Floydian to remind him to take a more conciliatory tact.) I'm not totally against your proposal for the infobox, just its implementation and the implications. We already have a perfectly acceptable place for the termini of a highway: the section of the infobox entitled "Major intersections" where it lists " end: ". I don't see the point, if we're adding coordinates, of repeating the location of the termini in two places in the infobox. That redundancy is well, redundant and not needed. Honestly, the solution in the past, and the one I've counseled Floydian to take is to improve the map graphic. Look at a few maps with me a moment.
 * Michigan_185_map.png map is on an article entitled M-185 (Michigan highway). I don't think that it is unreasonable to assume that a reader seeing this map, with the prominent links to items like Straits of Mackinac, Michigan, Mackinac Island and when one that reads the title of the article containing the name of the state should be confused as to the location of this highway. If they are, then we've provided them with wikilinks to other articles to establish the location of the Straits and the state.
 * Michigan_6_map.png This one is on an article entitled M-6 (Michigan highway) which also has prominent links to "Kent and Ottawa counties" and "Grand Rapids, Michigan". The title of the article also contains the name of the state involved.
 * Brockway Mountain Drive map.png is on an article entitled Brockway Mountain Drive, which doesn't reference its state in the title. The map itself has the text "Keweenaw Peninsula" and "Lake Superior" in addition to the inset denoting where in Michigan the map shows. Like the other insets, Michigan's location in the US is highlighted as well. The first sentence of the article says that the road is "just west of Copper Harbor in the Upper Peninsula of Michigan in the United States." The next two sentences establish that the road and the mountain are along the Keweenaw Fault in the Keweenaw Peninsula. Once again, this should establish the geographic context necessary to locate the roadway. The addition of KML-based data and the links it provides will enhance, but not replace, the context of the text of the article.
 * These are maps from three articles that passed FAC in 2011. M-6 (January 31, 2011) was also featured on the Main Page on November 20, 2011, without complaints over its map and M-185 (December 12, 2011) and Brockway Mountain Drive (June 1, 2011) received no complaints from FAC reviewers once the insets were added.  Imzadi 1979  →   11:33, 24 February 2012 (UTC)
 * I'll get back to you soon- I am just dealing with 'a little real life' As I understand it you are asking me to make some comments on infobox implementation, and then to make a few comments from a Europeans perspective on the svg maps. I´ll try and give some input in a few hours time. --ClemRutter (talk) 19:14, 24 February 2012 (UTC)
 * Hey Clemrutter. I've used your sandboxed infobox in the article. I was hoping you could return to the FAC nomination and strike your comments if you feel they have been addressed. Cheers,  ʄɭoʏɗiaɲ  τ ¢  18:06, 27 February 2012 (UTC)
 * I'll be back shortly- I am involved in a hell of a lot of real life at the moment- I was delighted you took on board the comments- I think it works - Iĺl be back soon.--ClemRutter (talk) 18:31, 27 February 2012 (UTC)

--ClemRutter (talk) 00:21, 7 March 2012 (UTC)
 * @Floydian- It must be very frustrating for you. When you wrote it was merely a matter of me finding time to explain that the solution looked good and I could gladly endorse all you hard work, with the explanation that the presentation of the template was fine, but for a permanent solution we need to put the coordinates in separate fields, that would display in the way that we had agreed. But I look today and the agreed solution has been vandalised yet again. We can't take it to FAC until it is stable. I am at a loss to suggest what to do when you have such virulent vandalism-you could try reverting it yourself as lead writer but I am not sure that will bring stability. You could try and get the template modified to include the lat-start, long-start, caption-start, lat-end, long-end, caption-end latlog-display-option, which I envisage would allow rendering options e.g top (such as we are using here) individual, where the start and finish latitude would be far more prominent with field titles displayed, expand-KML---the last field is not totally thought through as such things need to be presented to all the groups concerned for comment and nothing works on Wikipedia by trying to force another editors hand.
 * @Imzadi1979. I have mentioned what we could do to expand the fields in the comment above. If a KML file is present- I would assume that the template would parse it and use the data in the KML to populate lat-start, long-start, caption-start, lat-end, long-end, caption-end thus removing redundancy. To complete lat-principal, long-principal, caption-principal could be useful in defining the point to be used for data exchanges, but otherwise lat-start, long-start, caption-start, could be selected to do the task. US roads seem to give the start point as the west most end- UK roads and French roads are radial in nature, and the start point is the point closest to the capital- but that I see as a minor point. I can have a further look at the maps later.
 * As you've pointed out, stability is becoming an issue. I'd rather reach an agreed upon solution and then implement it, rather than turning the article itself into a battleground. For me at least, I'm having a hard time not finding the start and end coords redundant to the kml, which shows both simultaneously and makes it clear where the route goes from that starting intersection. -  ʄɭoʏɗiaɲ  τ ¢  18:57, 7 March 2012 (UTC)
 * Fine- quick response as I am very distracted by a four month old grand-daughter. Yes, finding start points is not simple- just look at the Nico Ditch- 1200 years after it was constructed and we still can't be certain. Last week the Manchester Evening News ran a story that a body had been found in the Ditch- then put the location 100s of meters from where it ended! But staying on focus, the 401 had an official start point today, even if they are still shifting earth and it will move west. We must use todays bast knowledge when writing. The Baluarte Bridge in Mexico is about to become the worlds tallest bridge sometime this summer which causes a rewrite of the Millau Bridge article, we have had one editor already trying to do a bit of futurology- that had to be reverted- then the president inaugurated the thing, ewven though the connecting roads -don't. It can be very unclear, I think if the editor tries to revert me I will just date the claim and walk away- because in a few months it will resolve itself.


 * Back to the 401, I know you are a sticker for precision but I think you will find the Co-ordinates crowd will be perfectly happy with a point 5km into the road (particularly if it is dated) as long as there are two points on the road so they and other programs that trawl for coords can find something. To memarrying the KML to infobox field is stage 3. Stage one is having some visible record in the infobox, Stage two as I explain above should be getting the six fields written into the infobox so casual editors that use the infobox while doing say the Domitian Way (Roman, France) have a space to plonk the data they take from paper sources (and here the location will depend on the current favoured source). Then stage three will be a way to harvest the data from the KML- maybe overwriting the contents already there (discussion needed).


 * So focus on getting the opposition on your side- you were close at the end of February, and move the battlefield elsewhere. Make this article stable. Ask specifically from others about where they would like the start to be- accept it and move on. The discussion will then move to how to improve the start point and I expect that a list of principles will be easy to write with the help of the guys who do have experience in point geolocation. KML is a good idea but it is early days yet-- remember group theory: Forming- Storming Norming- Performing.


 * Sorry - distracted again --ClemRutter (talk) 20:46, 7 March 2012 (UTC)