Misplaced Pages

Revision as of 22:23, 8 June 2013

This is the talk page for discussing improvements to the Infobox Australian road template.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1, 2, 3Auto-archiving period: 12 months

	Australia Template‑class
Infobox Australian road is within the scope of WikiProject Australia, which aims to improve Misplaced Pages's coverage of Australia and Australia-related topics. If you would like to participate, visit the project page.AustraliaWikipedia:WikiProject AustraliaTemplate:WikiProject AustraliaAustralia Template This template does not require a rating on Misplaced Pages's content assessment scale.

Australian Roads Template‑class

This template is within the scope of WikiProject Australian Roads, an attempt to build a comprehensive and detailed guide to roads and highways in Australian states and territories. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.Australian RoadsWikipedia:WikiProject Australian RoadsTemplate:WikiProject Australian RoadsAustralia road transport Template This template does not require a rating on the project's quality scale.

This template was considered for deletion on 9 September 2010. The result of the discussion was "Withdrawn by nom.".

This template was considered for merging with Template:Infobox road on 31 December 2011. The result of the discussion was "No Consensus".

Traffic Volume

Traffic volume would be a useful statistic (in standard metric vehicles per day) to get a feel for how busy the road is. Australian government bodies regularly conduct vehicle counts so this data is available for many major roadways. --Biatch (talk) 02:13, 19 December 2012 (UTC)

RfC:Infobox Road proposal

WP:AURD (Australian Roads), is inviting comment on a proposal to convert Australian road articles to {{infobox road}}. Please come and discuss. The vote will be after concerns have been looked into.

• Misplaced Pages:WikiProject Australian Roads/RfC:Infobox Road proposal

Evad37 (talk) 07:21, 6 May 2013 (UTC)

Length parameter - rounding and conversion

The template currently allows entry of a length in km, which it divides by 1.609344 and rounds, to give a length in miles.

1. If the road is short (less than 800m), eg Mouat Street, it displays a length of "0", whereas rounding to one decimal place would be more appropriate.
2. The template should probably use {{convert}} to do the conversion - which might then resolve the rounding problem. Although some testing with parameters may be required, and/or it might be appropriate to let the editor specify sigfig in {{Infobox Australian road}} and then pass it through to {{convert}}.

(I'm no expert with templates, so I'm not going to even try to fix this myself.)

Mitch Ames (talk) 13:06, 14 May 2013 (UTC)

Note that the proposed conversion to {{infobox road}} would fix this issue, as that template has a parameter to control rounding - Evad37 (talk) 13:37, 14 May 2013 (UTC)

And so now does this template. |length_rnd= has been added and documented and Mouat Street has been fixed. --AussieLegend (✉) 15:46, 14 May 2013 (UTC)

{{infobox road}}} also has parameters to reference the distance (eg. Google Maps, EIS, published map, etc.), and to add notes for the length (eg. The road will be 22.6km long after stage 2 construction is complete. The road will be 50km shorter after the completion of proposed bypasses. etc.) - Nbound (talk) 20:54, 14 May 2013 (UTC)

Infobox code upgrade

As I indicated at {{Infobox Australian place}} I've been involved in some discussions where it was implied that older infoboxes like this may not be supported after implementation of Lua. The code for {{Infobox Australian place}} (IAP) has subsequently been upgraded and has been instrumental in identifying deficiencies and errors in well over 1,000 articles. Both IAP and this infobox are very closely related, with parallel development and much of the same code being used. Now that the conversion of IAP has been completed successfully, it stands to reason that this template's code be updated too. As with IAP, the aim is to update the code to use the Misplaced Pages standard {{Infobox}} and that code has been written. There is an RfC (mentioned above) but while related, it has no direct bearing on the upgrade. Regardless of the outcome of the RfC, it has been emphasised more than once that this template should be retained for some time after any conversion to {{Infobox road}}. At the RfC I specifically asked how long migration is expected to take, and the answer was "a few weeks (3-6 perhaps)". Assuming a best case scenario that migration could be achieved in that time, and with more than weeks still to go in the RfC, it's now at least 8 weeks before migration of the more than 500 articles transcluding this template will be complete. There are currently 496 transclusions and with an average addition of 1-2 articles a day the total is going to be around 600 articles, or around 14 a day that will need to be converted. Beyond that this template template has an indeterminate life, so there's no real reason why the code should not be modernised now.

The updated code is, parameter wise, 100% backward compatible with the existing version of the template, but I have made some minor changes from the current version:

1. The infobox image is now 270px, up from 200px. This is a fairly standard size for infobox images but there are cases where such a wide image may be undesirable, in which case |photosize=, a new parameter, will allow the size to be set manually.
2. The location map image, set by |location= has been moved to the top of the infobox. Again, this is a standard location for such an image.
3. In concert with the move of the location map image, |coorinates= has been moved so as to remain under the location map image.

While evaluating {{Infobox road}} I started modifying the code that I'd already written and this is now part of the new infobox code as a series of enhancements. In the event that the decision of the RfC is not to migrate to Infobox road, these enhancements will prove useful. If the migration does go ahead, this Infobox will still be retained as a backup in the event that Infobox road is not suitable for a particular road, so some consistency between the templates makes good sense. In any case, the enhancements will allow interested editors to start making changes to articles now, without having to wait for the migration. It will also be possible to correct existing mistakes (such as the current practice of mis-using |caption= for former route information). These enhancements are, in no particular order:

1. fixed formatting of |length= so that 1111km now displays as 1,111km
2. new parameter - |length_rnd= to avoid problems such as that seen in Mouat Street showing up as "0.3 km (0 mi)". This was mentioned at the RfC and specifically requested above so it's already in the code.
3. added code to cater for Jervis Bay Territory, which was missing from both {{Infobox Australian place}} and {{Infobox Australian road}} I don't think we have any road articles for JBT, but it should be included.
4. new parameter - |road_name2= for alternate road name
5. new parameter - |state2= When a road passes through more than one state, the "from" and "to" states can now be specified.
6. new parameter - |former= for former route information - Many articles currently use caption for this information
7. new parameter - |maintained= for maintenance agency (similar to Infobox road)
8. new parameter - |closed= for use when a road is permanently closed (an idea from the RfC)
9. new parameters, alt text for existing image parameters - |photo_alt= and |location_alt=
10. added locator map functionality, lifted from {{Infobox Australian place}} and modified slightly - primarily to be used for streets, or any road that doesn't have a "location" image. (see File:Location Hume Hwy.svg for an example of a location image) The map supports two pushpins, one for each end of the road.
11. As per {{Infobox Australian place}}, if the locator map exists it is not necessary to manually specify |coordinates=, as these will be generated from the locator map coordinates. However, also as per Infobox Australian place, specifying coordinates manually will not cause an error, they just won't be displayed.
12. new parameter - |length_ref= reference for road length. Mentioned as lacking at the RfC and above.
13. new parameters - |direction_a= and |direction_b= (from Infobox road), use of these overrides existing |direction=, which is deprecated with the addition of these parameters
14. new parameters - |end_a= and |end_b= (from Infobox road) deprecate |start= and |finish= respectively
15. new parameter - |lga= as discussed at WP:AURD. Unlike IR, label links to correct LGA article based on |state=
16. new parameter - |show_links= causes "Highway system" links to be shown at the bottom of the infobox. Should only be set when type = "highway", "city highway" or "freeway", not if type = "road", "rural road", "street" or "track"
17. new parameter - |tourist= for tourist routes that follow the road
18. new parameter - |history= for brief notes about significant points in the road's history
19. new parameter - |restrictions= for brief notes about general restrictions on the road
20. new parameters - (see instructions and blank infobox for a list) - enables split roads (Infobox road doesn't do this properly). See the Highway 1 and Capital Circle testcases for examples.
21. new parameters - |kml= and |kml_map= enable display of route maps using Google and Bing maps.

The new code is in the sandbox, with documentation at Template:Infobox Australian road/sandbox/doc. Testcases are at Template:Infobox Australian road/testcases and include colour schemes, a comparison of the old and new infoboxes with all parameters, a series of testcases that I've put together, as well as testcases taken from Misplaced Pages:WikiProject Australian Roads/Infobox testcases. --AussieLegend (✉) 18:24, 18 May 2013 (UTC)

I've just added new functionality, the ability to use KML files for route maps, in a similar fashion to {{Attached KML}}. --AussieLegend (✉) 13:59, 20 May 2013 (UTC)

KML functionality

This KML functionality (amongst some of the other improvements) is possibly a decision changer for me :). Would it be possible to further enhance the KML functionality to an open source mapping site like OpenStreetMap or similar (they are usually updated faster aswell). Just a thought, there is nothing wrong with the existing two. -- Nbound (talk) 14:39, 20 May 2013 (UTC)

There probably is, but I was just taking the lead of {{Attached KML}}. There's really no reason that you couldn't add any mapping site, it's just a matter of getting the syntax right. --AussieLegend (✉) 15:56, 20 May 2013 (UTC)

From what I've been reading, OpenStreetMap doesn't support KML files. Shame. --AussieLegend (✉) 02:18, 21 May 2013 (UTC)

It does in a fashion, but yeah I gave up on it a little earlier too. -- Nbound (talk) 02:41, 21 May 2013 (UTC)

The purpose of the separate KML template is a uniform template across all geography-related articles, not just those about roads. With the display=title option, links are already in place where the coordinates would generally go. It also seems that the embedded JS-based map at the top of articles such as California State Route 56 is not included at all. So by including it in IAR, you're including a less functional implementation of KML. --Rschen7754 02:22, 21 May 2013 (UTC)

The default for {{Attached KML}} is |display=inline, so that's what I was going for, since coordinates are normally displayed in the title bar. Most geography article infoboxes suggest |display=inline,title. Many infoboxes seem to be generating it automatically now. Most don't need kml data, just a spot coordinate. I have found that it's possible to include the map, so I've done that but, if links are really needed in the title bar then {{Attached KML}} can be used in lieu of |kml=yes. It's really up to the editors of individual articles. Personally, I don't see why we need links both in a box and in the title bar, or coordinates in both the infobox and title bar, but the latter seems to be the general Misplaced Pages preference. The problem that Australian editors have with {{Attached KML}} is that there are a gazillion U.S. files and only a few Aussie ones, and they're mixed in amongst the U.S. files, so we don't really know what we have and what we don't. --AussieLegend (✉) 04:33, 21 May 2013 (UTC)

Well, in the US we don't really know what we have either, using that method - we know what we have, but we have no idea of what we don't have. A better solution would be using the talk page banner to track what's needed. The eventual goal is to move it all to Wikidata, anyway, so this is a temporary solution. --Rschen7754 05:27, 21 May 2013 (UTC)

Getting it to Wikidata would be great. --AussieLegend (✉) 07:37, 21 May 2013 (UTC)

Is the intention of including KML in the infobox to replace the {{Attached KML}} template, or to be in addition to it? For that matter, if an article has {{Attached KML|display=inline,title}} (the case for all articles I have created a KML file for), is duplicating the titlebar display from directly above the infobox necessary? - Evad37 (talk) 05:55, 21 May 2013 (UTC)

The intention is to avoid having to add {{Attached KML}} separately, unless necessary. One of the big problems I see with that template is that it is being added to the bottom of the article, so it's often not seen, and the links are important. They really should be in the infobox instead of the title bar, as that's where coordinate data is supposed to be. It's up to individual editors to decide which is more appropriate for that article, |kml=yes or {{Attached KML}}, and that really depends on what map information is available (map image, loactor map, coordinates etc). Not all of the articles have the same data available, so we need some flexibility, which is why I'm not forcing one parameter over another at this point. --AussieLegend (✉) 07:37, 21 May 2013 (UTC)

Your rationale sounds good to me, There have been pages Ive read in full more than once before noticing the KML box hidden in one place or another. -- Nbound (talk) 08:02, 21 May 2013 (UTC)

I disagree with any notion that kml shouldn't be in the title bar. That position is pretty much standard for articles using coordinate data - the only advice on use of coords in the title I could find is at Template:Coord#Usage, which states "the title attribute indicates that the coordinates apply to the entire article, and not just one of (perhaps many) places mentioned in it — so it should only be omitted in the latter case." Another advantage of the title display is that the KML route can be viewed onwiki using WikiMiniAtlas, rather than being forced to use Google or Bing. And if the infobox version is going to replace the Attached KML box, then it should also have the KML file and (edit) links.

So at this stage, I don't think the infobox version is ready to be used on its own, but I can understand where you're coming from - Evad37 (talk) 08:22, 21 May 2013 (UTC)

The title bar is pretty much standard for coordinates, but not links and maps. Those sorts of things are usually left to the prose section or the infobox. I don't really have anything against them being there but if you have a set of links in the infobox, why do you need them in the title bar, only a couple of cm above where they are in the infobox? Other than built infrastructure, such as buildings, bridges, dams etc, most geographical objects are large enough that multiple coordinate figures could be used. LGAs are often 60km or more across, but we always pick a notable point for coordinates, even though the coordinates don't "apply to the entire article" but do apply to "one of (perhaps many) places mentioned in it". The coordinates for Sydney are for Circular Quay, even though the Sydney article covers an area of 12,144.6 km². Roads are really no different, their notable coordinates are generally those of the ends of the road. If you read above you'll see that I was able to include the mini atlas, but there's no need to duplicate the links, not that it can't be done. It just seems redundant to do so. As for the KML file and edit links, it's common to have view, talk page, and edit links in navboxes, but it's a rarity in infoboxes, even though {{Infobox}} makes provision for it. These boxes are for our readers, not for editors, so there's no need for edit links --AussieLegend (✉) 09:21, 21 May 2013 (UTC)

This was extensively discussed in a quite acrimonious RFC (which can be found in the WT:HWY archives), and the consensus was to use KML for roads. Coordinates cannot represent a road effectively (why the terminii? why not any other point on the road?) However, this has farmed out to some rail lines as well as postal codes, if you look through the KMLs that have already been done. --Rschen7754 09:28, 21 May 2013 (UTC)

Why the endpoints? Because they're the most obvious points on the road and every road has them. Sure you could use 47 Smith Street, but not every street has a 47 and not every 47 is in the same place on the road. I'm not saying we shouldn't use KML but if we don't have KML files and we don't have location map drawings, we have to use something. --AussieLegend (✉) 09:40, 21 May 2013 (UTC)

KML files are pretty easy to make - Misplaced Pages:WikiProject U.S. Roads/Maps task force/Tutorial has a tutorial on how to make them with Google Earth. --Rschen7754 09:47, 21 May 2013 (UTC)

Perhaps a mini-heirarchy of map types could be used. We could use the location markers if no route map exists. If a route map does exist then the marker map would be redundant and removed (in other words: the aim for each box would be an appropriate route map rather than location map). KML could be independent of either, if it exists - its added, regardless of what kind of inbuilt map the infobox uses. -- Nbound (talk) 09:58, 21 May 2013 (UTC)

I'm aware that making KML files is easy, more so for some. My GPS mapping software exports kml files - drive somewhere, save the track file as a kml and copy to a page, easy peasy. This issue is one of practicality. Of the 498 pages transcluding this page only 38 use {{Attached KML}}. That means we're missing over 92% of our articles. --AussieLegend (✉) 15:14, 21 May 2013 (UTC)

Thanks to User:Harryboyles, there have been another 20 or so KML files attached (using {{Attached KML}}) to Australian road articles, mainly in Canberra, but also in Sydney. Not a bad effort :) -- Nbound (talk) 09:04, 22 May 2013 (UTC)

I've added a link to the KML file, but for appearance and usability issues it's under the Google and Bing links, rather than above as it is in {{Attached KML}}. I haven't added an edit link, for the reasons explained above. --AussieLegend (✉) 15:36, 23 May 2013 (UTC)

• Update: As of now, KML functionality is similar to that of {{Attched KML}}. The Google and Bing links are not shown in the title bar as it seems redundant still, with the same links only a few cm below in the infobox, unlike {{Attched KML}}, where the links are right at the bottom of the article. The mini-atlas is in the title bar. In the infobox, the link to the KML file is under the map links for aesthetic reasons only. There is no edit link for thereasons that I've explained. --AussieLegend (✉) 16:09, 24 May 2013 (UTC)

Roadway types/colour

A minor suggestion, but would it be possible to harmonise some of the colouration schemes with infobox road, to save on confusion. It would also be a chance to add the remaining road types. Under construction = orange. Closed = grey. and Tourist routes, which could use the generic tourist drive shield colour used in most states. These would have to override the road types designated elsewhere in the template to allow settlements/suburbs/etc. to be named correctly. This would mean a new colour will need to be found for track... perhaps white? And of course the rest of the roadtype colours would remain untouched. -- Nbound (talk) 03:42, 21 May 2013 (UTC)

The colours can really be anything we want. The colours are from the current version and the track colour is a carry-over from {{Infobox Outback Track}}, I assume representing the colour of most of those tracks. List the colours you'd like to see here and I'll try them out - The code is flexible at the moment. --AussieLegend (✉) 04:37, 21 May 2013 (UTC)

Basically:
Colour override switches:

• Under Construction - Orange (roughly same as IR)
• Closed - Grey (roughly same as IR)
• Tourist - Australian tourist shield colour (brown) (eg. <shield removed>) Edit: realised that shield may not be the right colour, the colour proposed would is the one specified for tourist shields in AS1743 or at least used in the majority of states- Nbound (talk)

Roadway types:

• Track - Any suitable colour, we could go with a dirt road light brown for example, if we wish to keep the colour link.
• Freeway - Blue (as-is)
• Highway - Green (as-is)
• Anything else - doesnt matter too much to me, current examples look ok
• We did discuss over at WP:AURD making the default (no type specified) the same colours as the directional signage on roads (white on green). - doesnt matter too much to me, but would place a soft support behind it.

I use "roughly" as the exact colours may, or may not, look good, and a more neutral tone of the same colour could be better. In each case where not otherwise specified the text on top of said colour would be either white or black (whatever looks best). Thoughts? Nbound (talk) 05:31, 21 May 2013 (UTC)

I think it would be good if we could use the colours specified in the Australian Standard AS 1743-2001 Road signs - Specifications:

• Red — Colour R13 Signal Red

  #BA312B

• Yellow — Colour Y15 Sunflower

  #FFA709

• Brown — Colour X65 Dark Brown

  #4F372D

• Blue — Colour B23 Bright Blue

  #174F90

• Standard Green — Colour G12 Holly Green

  #336745

• Green — Colour G13 Emerald

  #195F35

(rgb/html values from Wattyl's website)

Some other points to consider:

• There are different ways that colours could be used, it doesn't just have to be by-type - there could just be a single colour for all roads, or colours could be based on shield colours. However, it is easiest to implement based on the existing type parameter.
• Colour shouldn't be the only means used to convey information - perhaps a roadway type field could be displayed in the infobox
• We need to make sure any use of colour meets WP:COLOUR requirements (eg can't having yellow text on green background, due to contrast requirement) - Evad37 (talk) 05:41, 21 May 2013 (UTC)

By necessity colours have to be somewhat muted to ensure they don't clash with the colour of labels and headers. It's a never-ending battle in television articles finding unique colours for each season that aren't too garish or too dark. Road signs are meant to catch your eye, infobox headers are just meant to delineate between one section and another. To be honest, I'm not a fan of any of the above colours except for sunflower (maybe). By the time they're toned down enough to be suitable for a header, they'll be a shadow of their former selves. --AussieLegend (✉) 07:59, 21 May 2013 (UTC)

Also the above colours are not overly accurate. AS 1743-2001 Road signs - Specifications uses CIE 1976 (L*a*b), something that can't be recreated accurately in RGB. Bidgee (talk) 11:19, 21 May 2013 (UTC)

I've been working on this, but have had some problem finding colours that look good in the headers and still provide proper contrast. --AussieLegend (✉) 15:38, 23 May 2013 (UTC)

Even the ones from IR? It is true that there is more colourised space in this template though, so any potential harmonisation may not work out that well. If you haven't already... perhaps try a more neutral/darker tone of the same colour? -- Nbound (talk) 21:03, 23 May 2013 (UTC)

I was speaking more of the colours suggested by Evad37 from AS 1743-2001. I thought I'd give those a shot first. The "more colourised space" you mention is a carry-over from Infobox Australian place, which doesn't have headers. In this infobox I can probably stick with the default, although I haven't removed the label colouring yet, so I've been concentrating on how the headers look. --AussieLegend (✉) 21:19, 23 May 2013 (UTC)

• Update: Roadway types - "under construction" and "closed" have been added. Colours for all roads are as per Template:Infobox road/doc/type, with the exception of "closed", which is not specified there. --AussieLegend (✉) 16:09, 24 May 2013 (UTC)

Good work, by closed i meant former/decommisioned. - Nbound (talk) 23:14, 24 May 2013 (UTC)

I'm not too concerned about the actual colours used, the above was just a suggestion that it could be based something used in real life (or a close equivalent - as Bidgee noted, AS1743 does not define colours in terms of rgb, which I obtained from Watyll's website, per my note). Also, we haven't really addressed the issue of colour being used as the only means to convey the road type information. (ie, not everyhting with |type=highway or city highway is named "... Highway", and some roads named as a highway are actually tracks, etc., so the actuall road name doesn't always convey that information) - Evad37 (talk) 01:13, 25 May 2013 (UTC)

Early on in the infobox road discussions at WP:AURD i suggested a roadway type parameter, for us here this would allow there to be two methods of showing the type of road rather than rely on colour alone. It would also be useful for the ACT where roads have weird names and arent shielded. (eg. Adelaide Avenue, Capital Circle, Yarra Glen, Caswell Drive and Tuggeranong Parkway, are all freeway grade roads). It would also mean that we will need to come up with a method of stating the roadway types, that relies on what is clearly visible on sources like google maps and streetview, lest it be considered WP:OR. (eg. Roads which are majority "controlled-access dual carriageway" could equal the freeway colouration. Specifics could be defined further if others like my idea.). The only other non-WP:OR option is to colourise according to shield/allocation type IMO. -- Nbound (talk) 02:15, 25 May 2013 (UTC)

When rebuilding this infobox, which was originally built from {{Infobox Australian place}}, I took some guidance from that template, where we've never visually presented the "place" type in the infobox. There is a similar problem there regarding "locality" and "suburb" that even official sources can't resolve. A locality is actually the same as a suburb, the only difference being that a locality has a "rural character" and suburb has an "urban character". However, places like Bobs Farm, which has a rural character and is therefore a locality, is officially recognised as a suburb. There is a lot of OR in Australian geographical designations, such as the definition of a city (Newcastle is a good example, even Sydney includes some OR). If there are official definitions for these, we can always put this in the "Notes" section of the documentation. That can then be referred to if there is a conflict. I've added a field that displays the type (road_name has to be specified for it to be seen) and we can link that to an appropriate article, external official definition or even the template documentation. The colour for "closed" is now per the Template:Infobox road/doc/type specification for "former/decommisioned". --AussieLegend (✉) 05:34, 25 May 2013 (UTC)

I guess we will have to use commonsense (as previously) to dictate roadtype choice. It would probably be worth adding synonymous terms to the freeway type setting, such as Motorway, Expressway, and Parkway; for editor choice of what particular term would be displayed. Some of these terms carry nuances in some states that they do not in others. (Some people consider Freeways necessarily untolled, NSW doesnt), (Parkway in the ACT means freeway-grade, doesnt carry same connotations elsewhere), (The preferred term for freeway-grade roads in Adelaide appears to be Expressway)... and so on. I would guess that the other terms for the lower grade roads would be less controversial. And I would suggest that any road carrying the Highway name (eg. Gunbarrel Highway) that is unsealed be called a track for the purposes of the infobox. -- Nbound (talk) 07:18, 25 May 2013 (UTC)

• What does everyone think about retaining the current infobox's label colour (#f0f0ff) for the labels in the left column, instead of taking the same colours as the headings? A light, neutral colour makes the infoboxes less "loud", especially for the under construction, closed, and undefined colours.
• I think better colours can be found for undefined road types - maybe the same or a similar light purple? - Evad37 (talk) 03:04, 27 May 2013 (UTC)

The label colouring is a carry-over from Infobox Australian place. There were issues there, as there were with Infobox road, that the header colour wasn't as obvious as the old template, so labels were coloured as well to compensate. Infobox Australian place doesn't use headers, so the colouring is beneficial but here, with headers, it isn't really needed at all, although changing it to a light colour is do-able. The undefined colour was grey, per the current template, but was changed to match Infobox road. Realistically, should a road type ever be undefined? --AussieLegend (✉) 15:54, 27 May 2013 (UTC)

There shouldnt be, if the docs are followed - but there will be some that are, where people dont realise there are specific terms you need to write in the "type" section. -- Nbound (talk) 23:56, 27 May 2013 (UTC)

Allocation

Will we also be moving the allocation method proposed in the RfC I was formerly part of? Articles like Highway 1 would still benefit from having the image variations at the top. Tourist drives would also benefit from a single shield, if the article was specifically about that tourist drive. (tourist drive concurrencies could then be mentioned in the tourist section). I realise they have all been coded in for legacy reasons at this stage. This may be a discussion worth having elsewhere, such as on WP:AURD, but just getting the feelers out. I think the new allocation method allows a more accurate portrayal of the shields in use. -- Nbound (talk) 03:42, 21 May 2013 (UTC)

I don't see a problem but yes, AURD is probably the place to discuss it. As for the RfC, just don't say things like "we'll see what x says", just say "we'll see what others say" and all will be fine. :) --AussieLegend (✉) 04:41, 21 May 2013 (UTC)

Was not my intent to exlcude previously. I wont be returning to the Infobox Road RfC, as while i was strongly in favour (for most of it), the templates are a bit more competitive now in my mind, and I want to avoid any WP:COI, that could be claimed if I vote against it. Your suggestion regarding the perceived tone of the comments is noted, and I will try not to make similar mistakes :).

this wasnt always the case I was worried about US oversight on proposed template edits, early on

Nbound (talk) 05:08, 21 May 2013 (UTC)

• Update: Nothing done per discussion above. Have left this for a discussion at AURD. --AussieLegend (✉) 16:09, 24 May 2013 (UTC)

Im yet to hear any complaints in regards to the basic allocation usage (other than a few editors not familiar with the term "allocation"), in other words the addition of WP:ACCESS notes. Discussion doesnt seem warranted for it at this stage.

I will start a discussion at WP:AURD revisiting the idea of dropping shield usage at the top of the IAusR infobox over the next few hours/days though. (Unless someone else beats me to it) -- Nbound (talk) 02:35, 25 May 2013 (UTC)

Discussion started: Wikipedia_talk:WikiProject_Australian_Roads#Dropping_shield_images_at_the_top_on_the_.22new.22_IAusR -- Nbound (talk) 11:13, 25 May 2013 (UTC)

Would appreciate any comments at the discussion from those here... as much as Evad and I love to agree with each other ;) -- Nbound (talk) 12:47, 26 May 2013 (UTC)

Gazettal

Bidgee mentioned an idea over at the Infobox Road conversion RfC which could give us another and often more accurate way of entering establishment date. Using the Gazettal date. The gazettal date is the date the road was published in the state government gazette of the the state in question. This can be found directly by accessing gazette archives, or by other means, such as here in the ACT, where they can be seen by using the ACT Planning and Land Authority's place name seach. Roads which are now defunct or closed could be mentioned in the history section as exact wording would depend on how the road was closed or superseded. People should be aware that this date isnt necessarily the date the road was opened to the public, nor the date at which construction was completed. The method is not foolproof as some roads may have been regazetted for one reason or another, for example Majura Road is listed in the place name search as being gazetted in 2010, when in fact it has existed in various forms for over a century and actually predates the ACT. Trove has digitised newspapers mentioning the Majura Road as far back as the 1880s and 90s -- Nbound (talk) 03:42, 21 May 2013 (UTC)

Including gazettal is not an issue. {{Infobox Australian place}} has the parameter available but it's rarely used. The only reason why it's not in the new code is because it wasn't in the old code, and wasn't one of the enhancements. There's no reason why it can't be included. The only issue is that gazettal doesn't always match the actual dates hat things happen. --AussieLegend (✉) 04:46, 21 May 2013 (UTC)

Definitely true, though it could help articles that have vague establishment dates like "1930s". Where its gazettal date is 20 September 1928. If the date the road is opened is known exactly (say via a digitised newspaper) this could still be used in addtion to any mentioned gazettal date. If the exact date is not known (and referenced) to at least a single 12 month period (or something that can be considered reasonably close), the gazettal date could be more the more important figure in some circumstances. Or in otherwords, some commonsense is always going to be required in regards to its usage. - Nbound (talk) 05:14, 21 May 2013 (UTC)

There's not much I can say to that, other than "I agree". We should probably have a reference field too. --AussieLegend (✉) 07:52, 21 May 2013 (UTC)

Reference field sounds good to me. :) -- Nbound (talk) 07:57, 21 May 2013 (UTC)

• Update: |gazetted= and |gazetted_ref= have been added. --AussieLegend (✉) 16:09, 24 May 2013 (UTC)

Route marker size

The current code forces the route markers/shields to have a size of 60px (width). This results in poor presentation for roads which have both extra-wide alphanumeric markers and standard width markers, eg Eyre Highway. This could be fixed by setting the images to be the same height, eg x60px (or whatever height works best). (Another option would be to allow the overiding of the default size, but the downside of this option is that it makes the template more complex, requiring more parameters). - Evad37 (talk) 14:00, 21 May 2013 (UTC)

Much like what we found with {{AUshield}}, setting by height has some disadvantages too, though the rows are neater:

• 60px =
• x60px =
• AUshield hardcoded sizing =

Nbound (talk) 14:56, 21 May 2013 (UTC)

There is also a pending but currently dormant change to the TAS/VIC/SA/QLD alphanumeric images at WP:AURD that plans to remove the gap between the letter and numbers (as per actual signage), which could help a bit. Though it hasnt been touched in a fair while and there is alot of work involved and we are still waiting on SA's DPTI to clarify the status and existence of D-series roadways. -- Nbound (talk) 15:02, 21 May 2013 (UTC)

The problem is caused by the aspect ratio of the images, not the width. If you select the same height, then some images, like M80, look far too wide. --AussieLegend (✉) 15:45, 21 May 2013 (UTC)

Agreed, essentially its something we are going to have to deal with if we do keep widespread use of the route image sections. This problem would be effectively bypassed if we do decide to follow the new allocation proposal. Another option could be to allow the input to take standard code, and then we could use AUshield to keep everything pretty, switched by code eg.((AUshield|R|23|R|ALT23|N|A1|M|80|usage=header)) with usage=header switching the hardcoded sizing to a new set of sizes we could use just for the infoboxes (so we could then size them by hand and reduce the aspect problems) - Nbound (talk) 16:00, 21 May 2013 (UTC)

Ideally, all shields should be the same aspect ratio, even if that means some transparent padding at the top and bottom of files. --AussieLegend (✉) 17:34, 21 May 2013 (UTC)

It could be done, but it would have to be done in a way so as not to affect the standard output shielding (as some shields will have significant padding). usage=header could switch to a second set of images which have been padded out, this padding would need to be both as wide as the widest shield, and a tall as the tallest for the best results. -- Nbound (talk) 23:11, 21 May 2013 (UTC)

• Update: These are still at 60px for the reasons explained above. --AussieLegend (✉) 16:09, 24 May 2013 (UTC)

I'm not sure whether this helps, but {{AUshield}} can be used instead of a filename in the route_imagex fields in the new code. In the meantime, I have temporarily reduced the default size from 60px to 40px. --AussieLegend (✉) 12:11, 26 May 2013 (UTC)

I didn't realise that the new code allowed full image syntax / {{AUshield}}. That's great, because it means sizes can be adjusted on a case-by-case basis if the default size doesn't produce good results. - Evad37 (talk) 02:36, 27 May 2013 (UTC)

Thats a handy change -- Nbound (talk) 02:44, 27 May 2013 (UTC)

It's always been part of the new code. --AussieLegend (✉) 15:57, 27 May 2013 (UTC)

Compared to the old IAusR :P -- Nbound (talk) 22:53, 27 May 2013 (UTC)

Location Map

Is anyone able to update the map to show current state of Canberra's urban area. Compare image to left and here

I've asked the uploader for comments. --AussieLegend (✉) 05:56, 25 May 2013 (UTC)

Ive also placed a small notice to check the commons talk page on his/her de.wiki talk page, this user appears to be more active there than on commons -- Nbound (talk) 12:44, 25 May 2013 (UTC)

I have updated this map to approximate OSM -- Nbound (talk) 09:42, 2 June 2013 (UTC)

More on the maps

Template:Infobox Australian road/sandbox2 While I think the Location map is a great idea, not everyone knows how to create them. I haven't found anyone who knows or is willing to create loaction maps for Highways in Tasmania. For the sake of consistency I’m of the opinion it should be all or nothing for location maps. Wiki ian 07:27, 3 June 2013 (UTC)

The location maps are really only meant to be there for roads that dont have any other map. The dot point at each end obviously removes the entire intervening route, and some routes such as loops are impossible to implement properly, its a stop gap. If you want to create your own map, use the "alternate_location_map" parameter and link to one of your own choosing. Its usually a relatively simple affair to export one from Open Street Map, and adjust colouration to highlight your desired route. -- Nbound (talk) 08:16, 3 June 2013 (UTC) -- Retracted as talking about different map type

Is there some confusion here? Is Wiki ian talking about this type of map or the one to the right? --AussieLegend (✉) 09:40, 3 June 2013 (UTC)

Sorry for any confusion. I was indeed talking about this type of map. Wiki ian 10:01, 3 June 2013 (UTC)

That's what I thought. Yes, they are more difficult to create but the template provides various options. Another option is to use KML files, which are a lot easier and, if all else fails the locator map can display the endpoints. --AussieLegend (✉) 10:18, 3 June 2013 (UTC)

Outstanding issues - proceeding with the full upgrade

As of now, the following issues are outstanding:

• KML functionality

1. Edit link - In my opinion, including this in the infobox is undesirable, as it gives the casual reader an easy way to directly edit KML files. {{Infobox}} has the ability to provide a set of links, one of which allows readers to edit infobox code, using |name= but discourages its use for this very reason. The documentation for the new code includes an explanation of how KML files are used here and really, only experienced editors should be editing them anyway, so the need for an edit link in the infobox is marginal at best.
2. Map links in the title bar - As explained, use of the title bar is pretty much standard for coordinates, but not for links. The new code includes a link to the mini-atlas, but since the links in the infobox are typically only a few cm below the title bar, they're really redundant and the spirit of WP:REPEATLINK would seem to apply.

• Roadway types/colour

1. Label colouring - This was set to match the header colour, but I've temporarily set it to the same as the existing infobox for demonstration purposes. We can make it what we want.
2. Undefined road type colour - Per an early request, colours were harmonised with Infobox road, which used green and gold for undefined roads. Evad37 suggested a light purple and that is now the colour used. It's the same as the colour used for regions in Infobox Australian place.

• Allocation - This is really an issue for WP:AURD, and discussion is underway there.

None of the above are functionality issues, and don't prevent the new code replacing the old (well, the new old) code. Even issues like KML deal with enhanced functionality so I don't see any problems at this point. The one bug that did pop up with the "new old" code has been fixed in the sandbox. Thoughts on proceeding with the full upgrade? --AussieLegend (✉) 14:38, 29 May 2013 (UTC)

The former and construction road types arent set as override types. The template would just display the default "major settlements" if used, it would be best if these were a 2nd option so you could set a road as a freeway type, and then change the colour by using these "overrides". -- Nbound (talk) 15:12, 29 May 2013 (UTC)

That is going to add some complexity to the code. --AussieLegend (✉) 15:22, 29 May 2013 (UTC)

• Conditional/ Support - Full support once "uc"/"former" problem fixed :) -- Nbound (talk) 15:14, 29 May 2013 (UTC)

Or compromise by creating a well-placed "status" label that is only used (unless further discussions warrant more) for uc and former types --- Nbound (talk) 15:26, 29 May 2013 (UTC)

How is this? Overrides and a status note next to the road type. --AussieLegend (✉) 16:31, 29 May 2013 (UTC)

Looks fine to me... Still need some other labels for freeways but wont let that stop my support. -- Nbound (talk) 23:46, 29 May 2013 (UTC)

• Hmm... the label colours were changed back to being the same as the headings . This is really the last issue for me before I would support the implementation. I actually agree with what you said above – "...here, with headers, it isn't really needed at all, although changing it to a light colour is do-able." I would support either removing the label background colour all together (as per infobox road), or changing it to the very light colour used in the old code, or a similarly light grey such as #eee, and I would consider other suggestions. How it is now just seems overdone and too loud. - Evad37 (talk) 01:55, 30 May 2013 (UTC)

I change that for testing purposes and forgot to switch back. It's now back to the old blue. --AussieLegend (✉) 07:11, 30 May 2013 (UTC)

Okay, thanks for clearing that up. Will now Support - Evad37 (talk) 07:41, 30 May 2013 (UTC)

length_ref parameter

I am formally requesting that the |length_ref= parameter described above be implemented in the current live template, as was done for |length_rnd= (I am trying to get Mitchell Freeway to A-class and then hopefully FA, and the issue of reference placement has come up.) - Evad37 (talk) 14:00, 21 May 2013 (UTC)

 Done --AussieLegend (✉) 14:39, 21 May 2013 (UTC)

Thanks for the quick implementation - Evad37 (talk) 14:45, 21 May 2013 (UTC)

Direction

Do/should we have a guideline for which direction a road should be listed as running? Eg do we prefer N-S over S-N (likewise E-W or W-E)? Should the direction follow the street numbers? But what if there aren't any (eg freeways, Roe Highway, etc)? If we it's anything other than arbitrary per-road, a brief guideline in the template documentation would be helpful. Mitch Ames (talk) 11:21, 27 May 2013 (UTC)

At the moment it is kind of arbitrary. Its been discussed previously , but not extensively, with no real consensus on a consistent scheme to cover all (or most) roads. - Evad37 (talk) 12:05, 27 May 2013 (UTC)

I would have a slight preference for N->S and W->E if no other decision can be reached (and its decided that an arbitrary direction shouldnt be used). Purely because this follows the same flow as text and is therefore slightly easier to visualise. Not that its hard the other way! :D -- Nbound (talk) 12:54, 27 May 2013 (UTC)

When you have a road that is, for example, "Northeast-Southwest" the pushpins in the location map and the labels can be a bit long. "NE end" and "SW end" look better. As for the order, it really depends on the article. (See Talk:Sydney–Newcastle Freeway#Discussion.) --AussieLegend (✉) 16:06, 27 May 2013 (UTC)

Agreed, and allows the more specific SSW, ESE, etc. if needed - Nbound (talk) 23:52, 27 May 2013 (UTC)

Interim upgrade

While we're discussing the enhancements, and other issues, does anyone have any problems with me upgrading the present infobox to use the 100% backward compatible code based on {{Infobox}}? This will only modernise the existing code, visually it will look almost exactly the same and there will be none of the enhancements mentioned. --AussieLegend (✉) 20:40, 27 May 2013 (UTC)

• Support - Nbound (talk) 23:53, 27 May 2013 (UTC)
• Support - Evad37 (talk) 00:25, 28 May 2013 (UTC)

The code has now been updated. Please report any issues here. Hopefully there won't be any. --AussieLegend (✉) 10:13, 28 May 2013 (UTC)

Displaying the state breaks if the full state name is entered as plain text, eg at Pacific Motorway before I changed "Queensland" to "QLD". - Evad37 (talk) 11:08, 28 May 2013 (UTC)

Apparently this was caused by a minor typo, but in fixing it I've also made the header look more like the previous version of the infobox by restoring the state to the same part of the header as the road name. --AussieLegend (✉) 12:40, 28 May 2013 (UTC)

Capitalisation of state abbreviations

Note that "QLD" is not a acronym, so should not be all-caps. Mitch Ames (talk) 13:47, 28 May 2013 (UTC)

It's not supposed to be an acronym. Per the infobox instructions, it's simply a code for use by the template. For Queensland this code is either "qld" or "QLD". This is the same as used by {{Infobox Australian place}}. --AussieLegend (✉) 14:17, 28 May 2013 (UTC)

I suggest that the template instructions are "wrong", in that they are not consistent with MOS:CAPS. Is there any reason why the code cannot follow normal capitalisation rules? To the human reader, those three letters are an abbreviation for the state, not a "code for the template", and ought to follow the same style as everything else. Mitch Ames (talk) 09:22, 29 May 2013 (UTC)

What about WP:COMMONSENSE? The change you propose would result in either template instances breaking and no state being displayed, or numerous minor edits would be required (would probably require a bot to be built, or else someone spending an awful lot of time looking through each transclusion), all without changing a single thing for the readers of Misplaced Pages, and making the template just that little bit harder to use. - Evad37 (talk) 10:07, 29 May 2013 (UTC)

These are postal abbreviations. See Interstate 95 for a multi-state US road - Would you suggest that every US article writes the entire state name? (Their isnt all that many well used non-caps abbreviations in the US either). It would seem to me that, WP:COMMONSENSE applies. Regardless, in good faith I have edited the template doc to specifically state we are using the postal abbreviations. -- Nbound (talk) 10:35, 29 May 2013 (UTC)

MOS:CAPS doesn't apply to code used in templates. The code is not displayed, it is used by the template simply to generate a correct link for the state. It is no different to using {{start date|2013|5|29|df=y}} instead of 29 May 2013. In reality, it doesn't matter whether you type "qld", "QLD", "qLd" or any other similar combination, the template converts this to "qld" and then generates ] from the code, with a similar process occurring for the other states. For consistency though, we specify the format as lowercase, which makes any future automated changes a lot easier. It's a bit of a storm in a teacup though, as the vast majority of road articles don't use |state=. --AussieLegend (✉) 11:24, 29 May 2013 (UTC)

OK - I didn't realise that the code wasn't actually displayed. Mitch Ames (talk) 13:09, 29 May 2013 (UTC)

• Note As a result of this discussion, I've added a link to the new sandbox code that, once implemented, will point to the documentation for the template. This should make it easy for people unfamiliar with the template to better understand the parameters used. You can see it in the testcases. --AussieLegend (✉) 14:43, 29 May 2013 (UTC)

• Might be worth sticking some small wikicode on? -- Nbound (talk) 14:50, 29 May 2013 (UTC)

•  Done --AussieLegend (✉) 14:55, 29 May 2013 (UTC)

Post-implementation issues

Aesthetic:

• It would be ideal if we could force IAusR to the same size width as IR (IIRC 300px). Perhaps even a little wider at 310 or 315.

Usability:

• It would be good if the code example didnt include the deprecated usages (and even better if there was separate ones for split and non-split roads)
• It would be good if the code example placed related terms together (like direction_a and end_a, etc.)

Route Markers:

• I also propose, as the silence has been deafening over at WP:AURD, that we dont use large shields for most articles (only on articles about a route (Tourist Drives, Highway 1, etc.). And therefore using allocation instead. Further to this the former section could be labeled and moved to just below allocation to prevent whats dont on the IR box at A8, Sydney. Its going to be best to decide this now before we've migrated too many away from the deprecated code.

Nbound (talk) 10:51, 30 May 2013 (UTC)

• Width has been forced to 300px - MOS recommends this size as the maximum. Deprecated parameters have been removed from the blank example. Fields have been reorganised direction_a, direction_b, end_a and end_b. Sectioned parameters are still grouped by section below the parameter that turns on the sections. Direction_a and direction_b result from splitting deprecated parameter "direction" while end_a and end_b relate to "from" and "to", which are also deprecated. It's probably best to leave them this way while infoboxes are being migrated. I'll look at creating separate field lists, but this may result in some inconsistencies later on in the event that one blank is updated and the other isn't. The suggestion regarding placement of "former" isn't anything that can't be fixed on the fly. --AussieLegend (✉) 11:18, 30 May 2013 (UTC)

Why, it's a brand new section isnt it? Can we just delete it, and recreate a new labeled section below allocation with the same "Former" name. Theres only a handful of articles this would affect at this stage, correct? -- Nbound (talk) 11:38, 30 May 2013 (UTC)

I swear that said "that can be fixed on the fly"! -- Nbound (talk) 11:39, 30 May 2013 (UTC)

Let me know when its done and ill do a few more conversions and messing about... So far has been pretty uneventful as far as massive bugs go :D - Nbound (talk) 11:41, 30 May 2013 (UTC)

Done, although I note that some articles don't limit the contents to "former" information. --AussieLegend (✉) 12:01, 30 May 2013 (UTC)

I guess we should decide on the extra terms for "Freeway", did we want to add equivalents (with no functional template difference), for Expressway, Parkway, Motorway, etc. Or do we want to use the generic Freeway term Australia wide? -- Nbound (talk) 11:44, 30 May 2013 (UTC)

through suburbs/settlements

According to the instructions, the through parameter is a list of "suburbs and other settlements". Leach Highway; for example, uses this parameter, and the infobox displays as "Major settlements". I suggest that it would be more appropriate to describe Leach Hwy as passing through suburbs, not settlements, but it's not obvious to me how to change the display label from settlement to suburb. Mitch Ames (talk) 03:20, 3 June 2013 (UTC)

Hi Mitch, change "|type = highway" to "|type = city highway". There is a work-in-progress example of the preferred usage of this info box at Wikiproject Australian Roads -- Nbound (talk) 03:29, 3 June 2013 (UTC)

Hasnt been updated so Im assuming you went offline, I have made the change on your behalf :) -- Nbound (talk) 03:53, 3 June 2013 (UTC)

Thanks for that. Is the intent to update the template docs to state in the through parameter section that the description is based on type parameter? The user ought to be able find all of the usage information on the doc page, independently of whether there are links to "preferred usage guidelines". Mitch Ames (talk) 04:06, 3 June 2013 (UTC)

The template documentation is a lot more detailed now than it was previously, and there is a point at which you can document something too much, resulting in readers missing important information because the documentation is filled with unnecessary minutiae. The label in question is not manually set so there's little to be gained by documenting how the template works. If you get the type set correctly, which it wasn't in Leach Highway, then there's no need to know what the label will be. --AussieLegend (✉) 04:27, 3 June 2013 (UTC)

Mitch, the preferred guidelines are a work-in-progress, which is why they arent yet linked in the docs. Once some time has elapsed they will likely be merged into or (more likely) linked from the main documentation. AussieLegend does bring up a good point in that the length of the documentation is already quite long, so chances are that some information will need to be placed on secondary pages. The template itself is quite flexible, being able to work with all types of roads and also junctions, as well as maintaing 100% backwards compatibility with the previous template. It is quite possible that in future that some information may be partitioned into separate subpages depending on whether you wish to code for a road, a junction, or convert an infobox using the older deprecated code upto the current parameters, you are more then welcome to make some progress in the sandbox if you think you may be able to help us with this. In which case, some easier to read docs could be created sooner, rather than later. -- Nbound (talk) 05:41, 3 June 2013 (UTC)

(edit conflict) "If you get the type set correctly, which it wasn't ..." And that's exactly the problem. The type wasn't set correctly, but it wasn't obviously wrong - Leach Highway is a "highway" to the casual reader/editor (including someone comfortable using templates, but not familiar with the details of this specific one). I saw that the suburb/settlement display was wrong, because it was "obviously" wrong, but there's hint that the problem is the type, which does not appear to be wrong (Leach Highway is a "highway" - no apparent problem there), so there's no obvious way for me to fix the problem.

If I were creating a new article (or adding the infobox to an existing article), it's quite a reasonable error to set the type to the simpler "highway" instead of "city highway", when there is nothing in the documentation telling me under what circumstances, or why, I should use one or the other.

I do think that you should fully document all of the fields and have several simple examples (for the benefit of those who don't want to read the full docs). The full documentation need not be directly in the Usages section, but there should at least be a link to that full docs. Mitch Ames (talk) 05:56, 3 June 2013 (UTC)

I wonder whether it is a good idea to have the suburbs/settlement display text be dependent on the type at all. Consider Albany Highway - is it a city highway or not? Currently it is not, so passes through the "settlement" of East Victoria Park and Cannington. But the alternative would be to pass through the "suburbs" of Mount Barker, Narrikup etc. Perhaps the display text should just be "Passes through". Mitch Ames (talk) 06:04, 3 June 2013 (UTC)

If the road is both rural and urban, you set it to the rural type. A suburb is still a settlement (its just an urban settlement). A settlement is still a suburb too really (look how many forms there are which just ask for your Suburb, rather than your town/etc.). We could make the template always say "Major Settlements" and it'd be technically correct, but we are just trying to use preferred terms. :) -- Nbound (talk) 06:11, 3 June 2013 (UTC)

Passes through is also inadequate terminology as many roads and highways dont pass through the surburb/town. Take the Hume Highway for example, it doesnt pass through Goulburn. But it'd be a bit odd to leave Goulburn off any list of towns that the road does pass. More extreme examples would be most highways and freeways in Canberra, which form the borders of suburbs rather than pass through them, or in the case of the freeways, often run through greenbelt areas, which are not part of any suburb. -- Nbound (talk) 06:20, 3 June 2013 (UTC)

"Passes through" is fine. The problem is that there is often a big misunderstanding as to what a suburb/locality/town is. The Pacific Highway used to pass through the township of Karuah, but with the new bypass it doesn't. However, it still passes through the suburb of Karuah, of which the township only represents a very tiny portion. If you do a search at http://maps.six.nsw.gov.au/ you'll see that the Hume Highway actually does pass through Goulburn, it just bypasses the actual town area. --AussieLegend (✉) 09:09, 3 June 2013 (UTC)

That map doesnt show city/suburb boundaries, so isnt much help, though I do agree that Goulburn is a poor example in hindsight (The road skirts through the edge of South Goulburn). Take Yass though, there the road doesnt pass through any part of Yass. It passes through Yass Junction, which is where the railway station is located several kilometres north of town of town, but definately not Yass, or any part part of it. The Pacific Highway bypass around Taree is similar, the road barely skirts by Cundletown. Or Kempsey...-- Nbound (talk) 09:42, 3 June 2013 (UTC)

I will point out the map only tells you the postal adress suburb, which can sometimes differ or, oddly, even double up. Nbound (talk) 09:54, 3 June 2013 (UTC)

The map shows the officially registered locality. Yass Junction Railway Station is actually in the suburb of Yass and the highway skirts the township, but it still goes through Yass. There is no registered locality called Yass Junction, just a railway station. --AussieLegend (✉) 10:14, 3 June 2013 (UTC)

The highway doesnt go within kilometres of any urbanised area at Yass. But I am happy to use this scheme if others desire it, it is based on official records. It will though, lead to odd things. For example, Taree would remain unlisted, for Cundletown instead. Kempsey would not be listed. And South Kempsey (a major populated area, and different locality would be). Checking the area for South Kempsey is bigger than the entire urban area of Kempsey and its suburbs. And stretches halfway towards Crescent Head covering an area which is largely heavily forested. Grafton and South Grafton are different localities, South Grafton does have a substantial population. Ballina/West Ballina? Thats just from a cursory look along the larger towns along the Pacific. -- Nbound (talk) 10:56, 3 June 2013 (UTC)

I've been saying for a long time that one day the national highway will be one big loop road that goes nowhere as it's bypassing every place. That was the case with the F3, that effectively bypasses Newcastle, although not quite. What we probably need to do is write something like "Cundletown (Taree)" to indicate a major city/town that is a short way off the road as many of the road signs do. Ironically, most signs still give the impression that the highway actually passes through Taree. --AussieLegend (✉) 12:35, 3 June 2013 (UTC)

What would you propose for Kempsey and the like... "South Kempsey (Kempsey)", or " Kempsey"? Probably be a good idea to include a minimum size aswell. For example Yass and Nambucca Heads are roughly equal in size but one is listed on the Hume, and the other isnt on the Pacific. 5,000 or 10,000 would be my suggestions (with a preference for 5,000), Thoughts? -- Nbound (talk) 12:45, 3 June 2013 (UTC)

National Highway/auslink

Since we're going to all this trouble, would it be a good idea to have a part of the infobox that asks how the highway is/has been funded? (ie auslink, national highway etc)

Im not really fussed with that personally, but if others want I'll go with the flow. Probably only worth noting the construction cost, year and breakdown (split between fed/state/local) if it went ahead . Maintenance funding histories would be complex on some routes and probably better saved for the prose.

It should be noted that the National Highway system was deprecated and replaced by the AusLink network.

-- Nbound (talk) 13:07, 3 June 2013 (UTC)

Motorway, etc.

Ive added Motorway, Expressway, and Parkway to the sandbox template with some testing here: Template:Infobox Australian road/Testing

Ive also changed "Major suburbs" to "Major suburbs/ towns" as not all of these roads are restricted to the city areas. (eg. Federal Highway is designated a motorway under the new shielding scheme), will help with some rural motorways in Victoria too.

If people are happy, I'll merge the changes. If not Ill revert the sandbox :)

-- Nbound (talk) 03:21, 6 June 2013 (UTC)

I don't have any real problems with it. I've merged content from the live template into the sandbox so we don't end up losing anything, and I've sorted the road types for consistency throughout the template. We probably need to tweak the label width so that we don't end up using 3 lines for "Major suburbs/ towns" (see these examples). --AussieLegend (✉) 04:36, 6 June 2013 (UTC)

Happy to go with the alternate 2 line version actually. I assumed it wouldnt fit, without testing, ill remove my test examples. -- Nbound (talk) 05:47, 6 June 2013 (UTC)

Deprecated parameters

I've now been through every one of the several hundred articles that were in Category:Australian road articles using deprecated parameters and have replaced the deprecated parameters with the new parameters. The category is now empty and there should therefore be no articles using deprecated parameters. I intend waiting a few days and will then remove the deprecated parameters from the template and documentation unless anyone has any objections. --AussieLegend (✉) 23:11, 7 June 2013 (UTC)

Capitalisation of direction values

I propose that the template should automatically

• capitalise the first character of direction_a
• uncapitalise the first character of direction_b

except that abbreviations (NW etc) should be all upper case.

This would allow the displayed text to comply with MOS:COMPASS. Mitch Ames (talk) 07:38, 8 June 2013 (UTC)

I'm not sure that's even possible and if it is, it would add an excessive level of complexity to the code. I'm also not sure that the current system doesn't comply with MOS:COMPASS. You have to remember that direction_a and direction_b aren't only used for "General direction", they're used elsewhere. If we decap direction_b you'll see something like what is shown in the infobox at right. --AussieLegend (✉) 08:07, 8 June 2013 (UTC)

The MOS does allow occasional breaches, its is a guideline. I think given the circumstances its fine to ignore it here... The only other option is to use the abbreviated points for even the standard directions.

Either we ignore (my preferred), or we abbreviate all (not preferred but better than the original proposal above IMHO). -- Nbound (talk) 08:24, 8 June 2013 (UTC)

Why do we even need a "direction" or "general direction" field listed in the infobox if each end has a direction assigned to it? - Evad37 (talk) 08:59, 8 June 2013 (UTC)

Wow, good point there, definately dont! Just scrap the thing :). Its redundant anyway. -- Nbound (talk) 09:05, 8 June 2013 (UTC)

Having been through every article, I'd have to agree. It's not a good guide anyway. We still need the inputs, but don't have to display them. --AussieLegend (✉) 09:09, 8 June 2013 (UTC)

Just to be clear im for the scrapping of the "General direction" section, but not the two "ends". Though I am assuming that is what Evad meant - Nbound (talk) 09:12, 8 June 2013 (UTC)

The KML feature

I find the KML feature of this template troubling. The following is an excerpt of a comment I have posted in response to an Australian ACR: I don't understand what benefit there is in eschewing {{Attached KML}} in favor of integration with the infobox. Though it was borne out of a discussion at WT:HWY, Attached KML is no longer a template specific to roads, and it can be found on pages in many topic areas on Misplaced Pages. Currently, it is transcluded in 4,284 pages. (You can even find it on 2013 Moore tornado, complete with KML data provided by the National Weather Service.) Google uses data provided by Attached KML in its search results. (Google "Creek Turnpike", for instance—it displays a map with our KML overlaid on it. Googling "Kwinana Freeway" also displays a map with the KML at time of writing, but I would wager that it will disappear when Google recrawls the page, as the KML has only been moved to the infobox today.) My understanding of the way that Infobox Australian road works is that the KML data is being stored as subpages of the infobox, not Attached KML. This is a poor decision because it splits up KML data across multiple locations. Were all KML data at Attached KML, it would be trivial for a reuser of our KML data, like Google, to see if an article has a KML; all they have to do is visit "Template:Attached KML/". If the KML data for Australian road articles is stored elsewhere, that data is "off the grid". It is not as easily discoverable. Data reusers will have to code their software to look for data at multiple locations. They might decide to not bother to use Australian KML data (or simply not know that they must take the extra step to get to it), or scrap plans to use Misplaced Pages's KML data over concerns that its location is unstable (especially if this opens the door to similar infobox-KML storage schemes in the future). The end result of all of this is that this article breaks compatibility with a Misplaced Pages-wide convention, which may ultimately detract from its chances at FAC. —Scott5114↗ 10:22, 8 June 2013 (UTC)

We have several location map templates but that doesn't stop us embedding them in infoboxes. We have several citation templates, we don't stick with just one. Use of KML data was raised at an RfC but when I looked, {{Attached KML}} only included 38 KML files for the 498 Australian road articles. Of course it wasn't easy to find those 38 maps in amongst the more than 4,000 other KML files. The Attached KML box sits at the bottom of the page, while some editors claim this information is important to readers. For this reason the functionality was included in the infobox, where it is prominently displayed, and the KML files were included as subpages to provide for easy management. This is Misplaced Pages, not Googlepedia, and we should be writing for our readers, not Google's. Australia has location maps and KML files available for some roads, but by no means anything approaching a majority of them. The current version of the template provides for KML data, location map files, locator maps and simple coordinates. Together these provide for all road articles, not just the few that were previously catered for. The argument that "all they have to do is visit "Template:Attached KML/"" is specious at best. The original KML files are still there, so they're still easily discoverable, as are the files list at "Template:Infobox Australian road/KML". --AussieLegend (✉) 16:45, 8 June 2013 (UTC)

Addressing each of your points in order:

• Map and citation templates are a poor analogy to this because they do not consist of machine-readable data like KMLs do, and there is not one standard format, like KML is.
• There is no need to create a redundant data directory just so that tracking is made easier; this can be done by a parameter like |has-kml=yes on the Australian Road project tag (you can even have the template autodetect whether a KML exists by clever use of Parserfunctions), or by tagging Template talk:Attached KML/ with the project tag.
• This data is not as important to readers as you might think. It certainly is not as important as anything else in the infobox; most readers will be adequately served by the raster map in the infobox. The KML data is merely a supplement to that, and in addition to providing Google and Bing maps links, it helps people who would like to include the feature in their own maps by importing it into GIS software. If the objection is to the box being displayed at all, that can be suppressed.
• As to most articles lacking KMLs, join the club—as I said before, there are only about 4,000 KMLs on Misplaced Pages altogether, and some of those are not road related, while the US roads project has something like 11,000 articles. All of the roads projects are in the same boat on this one.
• The vast majority of our readers get here from Google—part of Misplaced Pages's success can be attributed to its high PageRank. But when I speak of data reusers, I don't merely speak of Google. I'm talking about people who use our data to make maps with GIS too. Some of these are Wikipedians—I am responsible for upkeep of a pretty fancy map of road articles that have gotten FA status, which is made possible with the KML. When KML data is migrated to Wikidata, it will be a lot easier if the data is stored in one place, rather than making the bot operators code two or more locations to look up.
• If the KML data remains in the Attached KML tree, now we have two copies of the data. That means that when the road is realigned, the person updating the KML will have to either somehow know that there are two copies of it, and update them both, or else one won't get updated. That is bad data management, and increases the chances that our readers will get outdated data.

It sounds like this was implemented without a lot of thought for the consequences. What has happened here is a design and display problem has been solved, but the solution has caused technical and functionality problems. If the KML absolutely has to be displayed in the infobox, the much better solution would be to leave the data as a subpage of Attached KML and simply link to it from there, by way of a redirect if necessary. —Scott5114↗ 19:03, 8 June 2013 (UTC)

It wasn't me that said the data was important, I just implemented a solution based on suggestions made by others, who said that the roads project preferred KML over coordinate data. The KML files that exist are predominantly for US roads, so the US is well represented in a situation where only 38 of over 4,200 files (less than 1%) are Australian. Because of the way that our roads are named, they are scattered randomly throughout the list of files so they are almost impossible to find, while the US has a better ordered structure because of the way roads seem to be named. Using |kml=yes is useless if you don't know the file exists. There's no guarantee that the uploader has modified the article talk page, so keeping them in a smaller group makes management much easier. Effectively {{Attached KML}} (which doesn't own the files) has 4,200 files in a single "category", which is unworkable. With any other file, we'd categorise them by country and then by state/province but, since we can't do that, we need some other option. The system implemented for this template is more easily manageable. Individual file talk pages don't need the project banner added as they're in a subpage of the main template and there are clear directions on how to find the files. So yes, there was a lot of thought for the consequences, despite your assertion. "When" KML data is migrated to Wikidata we will revisit the way we manage the files but, until then, this seems the best option.

Just to address a few other points separately:

• "Map and citation templates are a poor analogy ... there is not one standard format" - This is only partly true. While there may be different layouts for citations, the method of inputting data is being unified so, while the output of the individual templates may look different, the input data looks pretty much the same. The input data is analogous to KML, while the individual citation templates are analogous to {{Attached KML}} and this infobox.
• "This data is not as important to readers as you might think" - If not, then why does Attached KML include links in the title bar? Most uses of the template do this, so it must be seen by editors to be important. Why else would they insist on such data being prominently displayed?
• "most readers will be adequately served by the raster map in the infobox" - Well, no. The infobox now provides for a location map, something that wasn't in the old code. As a result, most articles don't include a map and, in any case, the map only displays the end points. As has been pointed out by others, this doesn't adequately represent the road, especially in cases like Highway 1 (Australia),which is effectively a ring road around the entire country, with small diversions in Tasmania and the Northern Territory. {{Infobox road}} sees that a map is very important, and so places a map image at the top of the infobox. Previously this infobox placed the map image at the bottom, although it has been moved too. Of course, we don't have these maps for every article, so we have to mix and match depending on data available. This means that KML maps, map images and locator maps are all important, with KML being preferred.
• "when the road is realigned, the person updating the KML will have to either somehow know that there are two copies of it, and update them both, or else one won't get updated. That is bad data management" - All Australian articles, except some that don't have infoboxes, and one that does, now use the data kept here. Of course, we can always redirect the Attached KML files here if that's agreed upon so that we don't have two sets.
• "the solution has caused technical and functionality problems" - The infobox uses {{Infobox}}, some Lua code and has enhanced functionality, while it doesn't include unnecessary functionality of Attached KML. For Australian purposes, this infobox replaces {{Infobox road}}, {{Infobox road small}}, {{Infobox street}}, {{Infobox road junction}} and {{Attached KML}}. I don't see the "technical and functionality problems" in replacing five templates with one. --AussieLegend (✉) 20:22, 8 June 2013 (UTC)

• And the problem with doing that is now that you have this one template that is trying to do too much in it. --Rschen7754 20:28, 8 June 2013 (UTC)

Really? This template is trying to do too much??? This single page, 17kB template is concentrating on one country. {{Infobox road}}, with its 1,838 subpages is trying to dominate the entire planet. --AussieLegend (✉) 20:43, 8 June 2013 (UTC)

What I mean is that you're trying to pack too much functionality into that template, and trying to pack too many unrelated things into it. I've been concerned by the number of fields that you're trying to add into it over the last few weeks - the infobox is supposed to be a concise summary of the article, but now you're adding in every possible thing under the sun. Soon the infobox will be longer than the article! This will not fly at FAC, for example. (For example - Template:Routeboxca2, which unfortunately is now deleted, but was much longer than most of the California road articles at the time). Furthermore, from an engineering standpoint, I question the wisdom of redoing the template in the current language of parserfunctions when this site is moving towards templates written in Lua and incorporating Wikidata functionality (which Infobox road is going through right now, and will result in the elimination of many of the subpages). --Rschen7754 21:00, 8 June 2013 (UTC)

There have been some minor additions to the template that really didn't require much of a change at all, but most of the functionality is nothing more than is in Infobox road. Much of what has been added has been so that we can take advantage of whatever limited data we have without having to compromise. We don't have to use every field, only those that are necessary. Even then, long infoboxes are always a problem with anyone trying to add a locator map for QLD, ACT or WA. While Misplaced Pages might be heading towards Lua, there are thousands of templates that won't be Lua for a long time. Remember, there was a push to standardise with {{Infobox}} and yet widely used templates like {{Infobox settlement}}, used in 326,820 articles, still use the old code that this one did. The original aim of the code rewrite was to provide future-proofing as it was the intent to keep this template for some time if we moved to IR but apparently I did too good a job and the RfC went stale. Even when we go to Lua, this template is so simple I'm not sure there will be much benefit with Lua. IR might benefit, but Lua will just effectively hide the 1,838 subpages somewhere else and it will be more difficult for those who aren't code-geeks. This template is so simple I could write it. --AussieLegend (✉) 21:31, 8 June 2013 (UTC)

Discussion on this subject is taking place at Template talk:Attached KML; it would probably be better to continue over there where more people are involved. —Scott5114↗ 22:23, 8 June 2013 (UTC)

• Template-Class Australia pages
• NA-importance Australia pages
• WikiProject Australia articles
• Template-Class Australia road transport pages
• NA-importance Australia road transport pages
• Template-Class Road transport pages
• NA-importance Road transport pages
• WikiProject Australian Roads articles