Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Jump to content

Wikipedia talk:WikiProject Australian Roads/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6Archive 7

Missing AUshields

I just updated Calder Highway to use the AUshield template. It seems the following two are missing (I assume these routes actually exist but I don't know Victorian routes):

  • C254
  • C282

I'm not sure who/how these are created - can anyone help? Ausmeerkat (talk) 00:33, 3 September 2013 (UTC)


Create a request over at the shields page (WP:AURD/S), and Ill get onto that. -- Nbound (talk) 01:03, 3 September 2013 (UTC)

New article standards department

I've created an article standards department for the wikiproject, at Wikipedia:WikiProject Australian Roads/Standards (or shortcut WP:AURD/AS), where relevant standards can be listed. Any standards we come up with can be stored in subpages of that page. - Evad37 (talk) 07:36, 29 August 2013 (UTC)

Wikipedia:WikiProject_Highways#Structure_of_articles isnt applicable to AURD as it currently stands. We either need to modify it at WP:HWY set up our own thing (probably preferred?). Specific problems:

  • Infobox - The AURD standard is {{infobox Australian road}}. We may want to consider allowing {{infobox road small}} until equivalent functionality is in our infobox.
  • Maps - This should list current AURD examples until a complete standard is agreed upon (Maps for complex states like Qld, or former routing systems need to be tested out on-wiki, before we should consider locking down specs).
  • Route description - As has been discussed previously, this is largely up to editorial judgment. I personally use the way the highway/road has been described when gazetted or classified in the applicable state roads schedule [the schedules generally compile the gazettal information + extras so these are basically the same] (or the majority direction case in the case of interstate routes). Chainage would also be another idea to consider where need be (thats how Majura Parkway was based)

Also

  • Not on the WP:HWY page - Ive been told that some subheadings within sections and some "unique" sections are frowned upon when USRD assesses an article and would likely be removed. Ive seen little problem caused by these in AURD articles, and would suggest we keep them until such point as they cause insurmountable issues.
  • Links to standards for some projects where we there may be a shared interest. Such as the Bridges wikiproject

Thoughts? -- Nbound (talk) 08:31, 29 August 2013 (UTC)

Good points, we probably should develop our own standard. For now, I'll just mention that it should be adapted from the WP:HWY advice. With regards to maps, on the standards page it is just listed as a draft for now for that reason - it will need to be checked to make sure it works for other states, and any other issues. Cross-project standards seems like a good idea, feel free to add them. - Evad37 (talk) 09:35, 29 August 2013 (UTC)


I have set up some draft structure standards. They could probably be expanded upon and cleaned up. -- Nbound (talk) 09:24, 31 August 2013 (UTC)

I have started a draft junction list standard - Evad37 (talk) 03:17, 5 September 2013 (UTC)

AUSborder

Template:AUSborder has been created to allow the usage of notes in RJLs at borders.


Example

LGALocationkmmiDestinationsNotes
Wentworth ShireCurlwaa0.00.0 Silver City Highway (B79 west only, HW22) west/north – Wentworth, Broken Hill (west), and Euston, Dareton, Mildura (north)Highway branch terminus
0.4–
0.6		0.25–
0.37		Murray River - Abbotsford Bridge
NSW–Vic Border0.60.37
Calder Highway (A79, 6530) continues south into Victoria towards Mildura
Southern end of B79
Highway branch terminus
  •       Route transition

{{AUSborder |border=NSW–Vic Border |type=trans |km=0.6 |road={{AUshield|VIC|A79}} [[Calder Highway]] (A79, 6530) continues south into Victoria towards {{VICcity|Mildura}} |notes=Southern end of B79<br /> Highway branch terminus }}

Using Template:jctplace spans both the last two columns (like the bridge entry just above the border), and does not allow for notes [Which are required when the row is coloured, and also handy for things like noting terminii]. -- Nbound (talk) 23:18, 4 September 2013 (UTC)

I'll just note that {{Jctbridge}} and the like are not actually required, the functionality is built into {{AUSintcore}} (the core template for all the state-int templates)


LGALocationkmmiDestinationsNotes
Wentworth ShireCurlwaa0.00.0 Silver City Highway (B79 west only, HW22) west/north – Wentworth, Broken Hill (west), and Euston, Dareton, Mildura (north)Highway branch terminus
0.4–
0.6		0.25–
0.37		Murray River - Abbotsford Bridge
1.000 mi = 1.609 km; 1.000 km = 0.621 mi
We could do something similar for the borders, rather than having multiple templates - Evad37 (talk) 03:32, 5 September 2013 (UTC)
AUSborder just pipes the appropriate values through to AUSintcore so you dont have to modify XXXint everytime :). It should also be noted that the border between NSW and Vic in this case is actually the southern bank of the river, not halfway across it. -- Nbound (talk)
You might want to remember to spell out state names and use correct dashes instead of slashes for them. The sooner that more proper editing and writing habits are ingrained into the project, the less work later to clean up issues at the higher-level assessment forums. Imzadi 1979 → 03:38, 5 September 2013 (UTC)

Shield Migration

Will likely continue tomorrow evening. -- Nbound (talk) 12:11, 2 September 2013 (UTC)
Not to sure why you're moving them, hardly copyrightable. Bidgee (talk) 12:25, 2 September 2013 (UTC)
We dont know for certain if they are, but we'd like to be on the safe side until its at least clearer. By rights the Aboriginal flag shouldnt be copyrightable either, but as we all know it is. -- Nbound (talk) 12:52, 2 September 2013 (UTC)

Shield migration is complete, there should be no more interruptions (if there was any) -- Nbound (talk) 04:59, 23 September 2013 (UTC)

@Evad37: - you should be fine to transfer your maps at your leisure :) -- Nbound (talk) 04:59, 23 September 2013 (UTC)

Promote draft standard Australian road junction lists?

I think that the draft project standard for Australian road junction lists is pretty close to being ready to promote to a project standard. What does everyone else think? Is there anything missing from it, or anything that needs to be refined? - Evad37 (talk) 08:54, 10 September 2013 (UTC)

Seems pretty good, Id be happy to promote especially if for the next few months we decide to remain open to relatively easily changing it depending on any oddball roads we may encounter (mainly suggesting this as we've only done a small number of roads - there could be situations we havent thought of). I note its quiet on directionality, where you use it where required to avoid confusion and I use it for all roads - Is this something we want to discuss, or leave optional, or something else?. to the best of my knowledge MOS:RJL also does not rule it out, as long as the directions are to the spec. -- Nbound (talk) 09:52, 10 September 2013 (UTC)

Yes, it could always be amended later if need be. If we could agree on when a direction is required, when it is optional, and where it should not be used, we could put something in. - Evad37 (talk) 13:56, 10 September 2013 (UTC)
After I week without opposition, I have promoted the draft standard, and given it a shortcut: WP:AURD/RJL. As noted above, it is open to amendments if the need arises. - Evad37 (talk) 03:08, 18 September 2013 (UTC)

WP Australian Roads in the Signpost

The WikiProject Report would like to focus on WikiProject Australian Roads for a Signpost article. This is an excellent opportunity to draw attention to your efforts and attract new members to the project. Would you be willing to participate in an interview? If so, here are the questions for the interview. Just add your response below each question and feel free to skip any questions that you don't feel comfortable answering. Multiple editors will have an opportunity to respond to the interview questions, so be sure to sign your answers. If you know anyone else who would like to participate in the interview, please share this with them. Have a great day. –Mabeenot (talk) 00:17, 15 September 2013 (UTC)

Pinging member list: @Gnangarra:, @AussieLegend:, @Dfadden:, @Orderinchaos:, @Wiki ian:, @Marcnut1996:, @Linkqer:, @HiLo48:, @Advanstra:, @YuMaNuMa: Does anyone else want to answer some (or all) of the interview questions? - Evad37 (talk) 03:31, 3 October 2013 (UTC)
@Rom rulz424: - not a listed member but works on VIC roads -- Nbound (talk) 05:00, 3 October 2013 (UTC)

Nomination for deletion of Template:Sydney Metroads

Template:Sydney Metroads has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. -- Nbound (talk) 09:41, 21 September 2013 (UTC)

US distance conversions

It has been suggest to me by User:Fredddie, that the following would be a good point to start from for US distance conversions.

0-300 m -> ft -- 300-900 m -> yd -- 900+ m -> mi

or more accurately, ensure the value does not exceed 1000.

For older AU material expressed in miles the inverse would likely apply.

<0.62 miles = metres

or more accurately, ensure the value does not exceed 1000.

Quite happy to hear other opinions on this.

-- Nbound (talk) 03:26, 24 September 2013 (UTC)

We should bring this to the maintainers of {{Convert}}. It'd be nice if this were the default behavior of the template. –Fredddie™ 03:28, 24 September 2013 (UTC)
Its worth discussing with them, though would likely end up on a switch (not that is bad) - similarly there may be situations (engineering perhaps?) where other behaviour could be preferred -- Nbound (talk) 03:34, 24 September 2013 (UTC)
I like the principle of "ensuring the value does not exceed 1000," but I disagree with using yards. Yards are rarely (ever?) used in the USA for road distances. For instance, construction signs will say something like "right lane closed 1500 feet" instead of "right lane closed 500 yards." Use of feet tends to be phased out in favor of mile fractions between 1500 feet and 1/2 mile (2640 feet), although there are many examples of guide signs with 1/4 mile (1320 feet). I would be fine with converting to miles starting at 300 metres (980 ft), but 500 feet (150 m) would probably be a better change point. Using kilometres at values greater than 1/2 mile might be a good rule, too.  VC  04:01, 24 September 2013 (UTC)
0.92km would usually be considered more awkward than 920m -- Nbound (talk) 04:53, 24 September 2013 (UTC)
I'm confused as to how US preferences are relevant to Australian roads. Australian articles have always used imperial measurements for conversions because that's what we used to use. The convention for that has typically been metres -> feet. --AussieLegend (✉) 07:29, 24 September 2013 (UTC)
Its come up in some higher level reviews. Measurements like 1300ft don't necessarily feel natural to imperial readers (where yards or miles may have been better depending on context). Similarly in the case for US roads some conversions had also not felt natural, most metric readers would prefer 800m to 0.8km in article prose. Of course templates like the various road infoboxes and RJLs should retain their current functionality, its a bit more appropriate for those not to jump between different levels. Im not looking to build a rule/guideline, just some friendly guidance in both directions. Its unlikely to be a major issue until a road gets beyond GA level anyway. -- Nbound (talk) 08:22, 24 September 2013 (UTC)
Where conversions are used, it's generally left up to individual editor as to what unit figures are converted to because there is no "most logical" value that suits all. Feet may seem unnatural to some imperial readers but entirely natural to others. Feet are used worldwide, even in metric countries, while miles and yards aren't, so it's a more universal unit to use. --AussieLegend (✉) 09:45, 24 September 2013 (UTC)
Definitely true, but if there is already a metric figure, then the imperial figure should be whatever is preferred by imperial readers, the point of the conversions is to make articles accessible to all readers. I have a vague idea of feet, I know that 300ft is around 90-100m, I have a vague idea of mileage, 60mph is roughly 100kph, but only because I am converting them on the fly in my head (It should be noted that most Australians born after the metric conversion find the imperial measurements, including feet and inches, far less natural - this includes myself). But again, this is not a "rule", just guidance , there is nothing prescriptive here, just ideas. There may be good reason not to use this guide for a particular conversion. If I nominate an article for A-Class I may be able save a bit of time following whatever is mentioned here, similarly if the circumstances require different results, I, or an imperial reviewer may even decide to go against the guidance themselves. Tis just ideas :) -- Nbound (talk) 10:29, 24 September 2013 (UTC)
Further to this some old measurements used such as "Chains" which are heavily used in AU road historical publications mean little to both metric and imperial readers, guidance on these when encountered could be useful. (1 chain is roughly 20m or 66ft) -- Nbound (talk) 10:29, 24 September 2013 (UTC)
@AussieLegend: for a little context, Nbound reviewed an article I had at GAN and requested I change 0.5 miles (0.80 km) to meters from km. The thought to use the more precise unit had never occured to me. We should take our readers into consideration. No more, no less. –Fredddie™ 11:59, 24 September 2013 (UTC)
The problem is, our readers don't all have the same opinions as to which unit is better for them. Remember, we have to cater for readers from all English speaking countries, not just those from the US. --AussieLegend (✉) 12:31, 24 September 2013 (UTC)
Definitely, which is why the opinions are open, and discussion is taking place, I'll even go and pop a message over at UKRD for some further viewpoints (I havent seen any of their articles at ACR/FA recently which is where these conversions would normally be picked up - hence the AU/US joint start), but of course theres definitely no reason to exclude them. It may be that, at least for converted values, we may be best served by compromise outputs which keep the most people happy whether they be raised on imperial or US customary practices -- Nbound (talk) 13:36, 24 September 2013 (UTC)

UKRD notified -- Nbound (talk) 13:48, 24 September 2013 (UTC)

  • VC mentions 1/2 and 1/4 miles being common on road signs, so how about simply using 1/4 mile as the changeover point between feet and miles? ie, use m (ft) for up to 400 m (1,300 ft); m (mi) for 400 to 1,000 m (0.25 to 0.62 mi); and km (mi) for larger values. - Evad37 (talk) 17:04, 25 September 2013 (UTC)

WT:HWY#Sections

There is a discussion at the above page related to what additional sections (beyond the standard route description, history, junction list) can or must be included on a road article. --Rschen7754 05:11, 25 September 2013 (UTC)

A cpl of other small IAusR ideas

Neither of these is too major, as most articles are completely unaffected.

Idea 1

A new label for the small number of route articles (to work on both IAR and IARsmall).

Established to be used in place of Gazetted for the limited number of route only articles. Deleted should still be fine for the opposing part of the pair.

This would affect routes with non-notable component roads, metroad articles, former ring roads, tourist drives, etc. Established is a more appropriate term for these cases as routes are only internally designated by the transport authority in each state. Using either term for the other is at best ambiguous, and at worst wrong. -- Nbound (talk) 12:39, 3 October 2013 (UTC)

Idea 2

Coloured headers for Tourist Drives like we have with roads under construction and former/closed roads. -- Nbound (talk) 12:39, 3 October 2013 (UTC)

AURD/S discussion

Files under discussion in the following sections:

Shield moves - Part II

So I was thinking today, as we are tagging these as {{PD-ineligible-USonly}} - then it means that AU users should not be uploading them or using them in maps.

So what does this mean? We need to-

  • Remove all shields as they were transferred from Commons by an Aussie. US user can re-upload the existing shields created by Fredddie [US user]. (ie. majority of most sets)
  • Redirect any remaining shields to wherever they were previously - Until such time a willing US user creates them (from scratch - not copies) - this affects the non-NSW alphas and tourist shields mostly - with some of the variations of the others aswell.
  • Remove all maps and either recreate with different yet relatable symbols - or perhaps organise the shield additions by a US editor?

Best this is done now before we have too many maps to mess around with.

Pinging User:Evad37 and User:Fredddie as likely interested parties. -- Nbound (talk) 08:30, 9 October 2013 (UTC)

... is this at all necessary? Per Wikipedia:General disclaimer#Jurisdiction_and_legality_of_content, the relevant jurisdiction is the US, where the images are PD – regardless of who made them, or where they are made. So why should they be deleted, given that Wikipedia only cares about US copyright law? (see also: Wikipedia:Non-U.S. copyrights) - Evad37 (talk) 09:58, 9 October 2013 (UTC)
Yes, but they were created in, and uploaded from Australia. While their existence on a US server is likely just fine, I dont think we should be suggesting editors put themselves at future risk (however unlikely) for creating content. In part that is what is implied in that linked text. -- Nbound (talk) 10:59, 9 October 2013 (UTC)
I still don't think that's a rational for deleting. And are we actually suggesting editors put themselves at risk? Not explicitly, as far as I can see. Also, from the Wikipedia:Non-U.S. copyrights page:
"It is the responsibility of contributors to determine that content they wish to contribute is free of copyright constraints in the United States and to supply as much copyright information as possible so that users can judge for themselves whether they can reuse our material outside the United States. It is the responsibility of reusers to ensure that their use of Wikipedia material is legal in the country in which they use it." (emphasis added)
And the {{PD-ineligible-USonly}} tag already gives a warning that "This image is believed to be non-free or possibly non-free in its home country". I wouldn't be opposed to creating/adding a more explicit warning template, but I don't think deleting files, or removing them until a US editor can recreate and reupload them, is the way to go. - Evad37 (talk) 14:05, 9 October 2013 (UTC)
The risk isnt from improper reuse or their existence on WP servers - its from the creation and upload itself, separate to WP - I wasnt proposing we remove them right now... Theres no point breaking AUshield for it. Just reupload the new set, delete the existing set, and then recreate the stragglers over the coming weeks. If you personally are comfortable with re-creating/re-uploading these shields yourself then perhaps you could do so. -- Nbound (talk) 00:09, 10 October 2013 (UTC)
I'm still not convinced that anything needs to be done. As I told Nbound on IRC, I think he's overreacting a bit, which is not necessarily a bad thing. –Fredddie™ 00:38, 10 October 2013 (UTC)
If I am overreacting - then this shouldnt be a major issue for people to sort out (yeah it might be a little bit annoying, but Im sure I will make it back up in articles/reviews/templates/other content if i havent already). I personally am not comfortable with it. -- Nbound (talk) 01:01, 10 October 2013 (UTC)
If an Australian court decides that the shields are copyrighted artworks, and a court decides that the use isn't fair dealing, then the uploader could face legal problems if the copyright holder decides to sue the uploader. It is up to the uploader to decide whether he or she dares to upload the files or not. If the uploader lives outside Australia, the uploader might be able to escape from legal problems by simply choosing to remain outside Australia for the rest of his life, but if the uploader lives in Australia or wishes to visit the country at some point in the future, he may be more concerned about Australian laws. --Stefan2 (talk) 20:52, 11 October 2013 (UTC)
Thanks User:Stefan2, this is exactly what Im getting at, I created a portion of these, and I moved the entirety of them from Commons, not realising such issues. As such I would really prefer if we re-do them. -- Nbound (talk) 23:19, 11 October 2013 (UTC)

I am well aware of the unique situation of the Aboriginal flag (which I strongly believe is a politically-charged anomaly, not the standard as there are no similar cases by which this level of TOO has been affirmed), but even then a lot of these are not copyrightable by that standard. Some of the more complicated shapes there can be a discussion, but as far as I'm concerned the most basic design consisting of only a rectangle and alphanumerics is not copyrightable by a long stretch. It just simply is not. Fry1989 eh? 16:51, 10 October 2013 (UTC)

Its not upto us to judge why the case went the way it did. Only to react to it. None of us are lawyers. -- Nbound ([hou[User talk:Nbound|talk]]) 02:27, 11 October 2013 (UTC)
That wasn't my point, which is actually two-fold. Firstly, I've been working on copyright issues on Commons for 2 years and have been aware of the Aboriginal Flag issue for nearly as long. So far, no other has case been provided to us to substantiate this supposed extremely strict level of TOO. That's why I don't believe it's genuine. Secondly however, even if it is the real standard of TOO in Australia, this is even more simple and not copyrightable by that standard. The other shapes of the signs as I said it can be a discussion, but two rectangles and a circle (the flag) does not translate to one rectangle and 3 basic characters. I've also had trouble finding the actual DR/discussion regarding these files when they were on Commons, was there one? From what I've seen, this didn't go through a proper community discussion. Fry1989 eh? 16:35, 11 October 2013 (UTC)
These signs seem to be about as complex as the EDGE logo and the Aboriginal flag. The Australian law is similar to the British law, so British examples might be directly comparable to Australian examples. I think that one problem is that the court rulings only tell that the EDGE logo and the Aboriginal flags are too complex, without telling how far further down we have to go before we get below the threshold of originality. It would be good if we could find some examples of something which is uncopyrightable in Australia. The reverse problem exists in some other countries such as Germany where we only have examples of things which aren't copyrightable; we don't know how far up we can go before we reach the threshold.
I think that these are borderline cases and that Commons:COM:PRP would favour deletion from Commons. However, I am also interested in knowing the age of the signs. Government works have a copyright term of 50 years, so if any of these signs were set up more than 50 years ago, then those signs should unambiguously be in the public domain.
You should also not overlook Adobe Systems, Inc. v. Southern Software, Inc. which suggests that some of our SVG files are copyrighted as computer software even if the underlying artwork might be ineligible for copyright or too old for copyright. For that reason, it may be necessary to identify the person who wrote the SVG code and ask that person to add a free licence covering the software coding. --Stefan2 (talk) 21:07, 11 October 2013 (UTC)
@Fry1989: If I understand what you're saying, the Aboriginal flag is not copyrighted because it doesn't meet the TOO, but because it's the Aboriginal flag? If that's the case, to me, the TOO is raised significantly. –Fredddie™ 22:27, 11 October 2013 (UTC)
Indeed they were moved as under the precautionary principle. Its not known for certain if they are copyrighted. (Its not known for certain with many things until its tested). But they have been moved just in case. User:Stefan2 brings up a good point aswell -- Nbound (talk) 23:20, 11 October 2013 (UTC)
Stefan, the standards agency that we can best tell holds the copyright has an agreement with the government for their status, but is not part of the government. Meaning it would have 70years at least, there were no shields in use 70yrs ago. -- Nbound (talk) 23:26, 11 October 2013 (UTC)
Similarly, the font is owned by the US FHWA, which i dont beleive is covered under the US MUTCD release, Ive just found out.

04

Any traffic control device design or application provision contained in this Manual shall be considered to be in the public domain. Traffic control devices contained in this Manual shall not be protected by a patent, trademark, or copyright, except for the Interstate Shield and any items owned by FHWA.

Given the fonts issue, at the very best we are looking at non-free content (which would require a rethink on our approach to articles); and at worst - deletion, and using other imagery to depict and describe shielding (shields already have a relatively minor position in most AU articles). Presumably this is also why they have never released the font. Instead the "roadgeek" series was created to emulate it. Using a copy of a possibly dubious (copyright-wise) source is not the best approach -- Nbound (talk) 23:37, 11 October 2013 (UTC)
There is also the possible issue of design patents too, both to the fonts, and the markers themselves. Which last 5/10 years in AU and 14 in the US. -- Nbound (talk) 00:04, 12 October 2013 (UTC)
Typefaces are not subject to copyright in the United States, so this is a non-starter. –Fredddie™ 01:20, 12 October 2013 (UTC)
Read the court case above. Digitised fonts, specifically non-bitmap types, are most definitely covered under copyright in the United States. And it is known that roadgeek is an exact or very near copy of the FHWA fonts which have been digitised in a non-bitmap form for many years. This also does not negate any possible issues with design patents. Design patent issues, to the best of my knowledge, can only be avoided by using their own supplied imagery, not creating our own -- Nbound (talk) 05:29, 12 October 2013 (UTC)
The court case means that if you make a vectorisation of a shield, for example by creating an SVG file, then you have created computer software, and you are the copyright holder to that computer software. If I make an SVG vectorisation based on the same shield, then I am the copyright holder to that vectorisation. If you and I both started from the same bitmap file, and the vectorisations were created independently of each other, then there is no derivative work issue, and we both hold exclusive rights to our own versions. I assume that there also is a threshold of originality for computer software and that some vectorisations are below the threshold of originality, in particular if you just use the default options in a computer program without changing anything yourself. However, the threshold of originality for SVG files hasn't been discussed very much on Commons, so it isn't very clear when an SVG file needs permission from the coder or not. --Stefan2 (talk) 09:27, 12 October 2013 (UTC)
Back to NFCC versus deletion - looking through the NFCC criteria these images wouldnt qualify due to lack of publication (they were new creations, not copied from a site/page/book/image) - I think deletion is our only safe option. I am aware that this wont make some people very happy and may require a rethink on how AURD approaches its articles. It shouldnt mean though that we cant use any images of these shields, we just have to be smarter about it . Remember we are to try and work safely within the law, not push it to see what we can get away with. -- Nbound (talk) 05:29, 12 October 2013 (UTC)
We have the following issues:
  • Dubious (digitised) font sourcing (this affects all roads projects to some extent I guess)
  • Potential design patent issues on user-made shielding (possibly excepting most/all US shields from my understanding of their MUTCD)
  • Potential issues for non-US uploaders/contributors of content.
  • No AU shield is unequivocally in the public domain (PD-AU or PD-US) due to age yet (nor will be for quite a few years), and even if they were it may only affect the older designs.
  • No clear boundaries as to what even constitutes basic shapes. Even if most AU shields could be PD-ineligible disregarding all other issues (and probably are), some may not be. (ALT shielding? Tourist routes? - The more complex styles Ive already slapped with an NFCC [Melbourne Ring Roads, Sydney Freeways] - but its looking like ill have to propose deletion on those soon as they weren't previously published).
The status of these images is anything but clear - and as such we should not be keeping them.
From the legally influenced WP policy - Wikipedia:Copyright violations: But, in short, media which is not available under a suitable free license and which does not meet the non-free content criteria, should be assumed to be unacceptable.
-- Nbound (talk) 05:29, 12 October 2013 (UTC)
  • Wikipedia:Public domain#Fonts says "In short: Scalable fonts as such are copyrighted as computer programs; typefaces as such may be protected by design patents, and, in a few countries, by copyright; actual use of the typeface is not restricted, even if the font used was based illegally on a protected typeface." Is this incorrect?
  • Regarding the patent issues, don't they have to be registered? If this is so, then unless there is evidence that registration has occurred, this probably isn't an issue
  • They don't have to be PD due to age, if they are PD (in the U.S.) for another reason.
  • ALT plates and the like can use the US version, which although slightly different, is definitely PD. This is what the ALT State Route shields already use.
  • If you want to propose much stricter usage of {{PD-ineligible}}, {{PD-shape}}, {{PD-textlogo}} and the like, that probably requires a larger community discussion on Wikipedia and/or Commons. - Evad37 (talk) 07:07, 12 October 2013 (UTC)
  • As Stefan2 states, the SVG files fit under the computer program legal definition, in that it provides a series of instructions to render the font. This is opposed to a bitmap image where there are no instructions to render the font, just pixels to colour. So yes, because these images arent just using the font, they are creating it from scratch with each render - it is copyrighted.
  • They need to be unequivocally PD in AU to not risk legal trouble for editors in AU. Being non-eligible in the US does not matter in AU. - If you truly feel there is absolutely nothing wrong with this, then you should have no problems creating your own shields an accepting any risk for yourself. Dont hang me out to dry with these. Similarly its not fair on anyone else who creates an image, not knowing the potential issues.
  • You cant combine PD-ineligible files very much without it no longer being PD-ineligible - the image is treated as a whole as well as individually. On the side: Its not uncommon to use separate ALT plates in AU anyway (ACT, NSW do it at least). Its possibly an improvement, but the resultant file is likely to be too similar to real world implementations.
-- Nbound (talk) 07:58, 12 October 2013 (UTC)
Further to the font issue, there is already a template, stating exactly what has been said: {{PD-font-USonly}} -- Nbound (talk) 12:32, 12 October 2013 (UTC)

Looks like Stefan2 and I have been looking along the same vein again. Given that SVGs are classed as computer software. PD-ineligible-USonly does not cover them - they arent legally images in the US - they are a computer program (or in more familiar computer terms - a script) that will create an image whenever run. As such we are likely infringing the signage, and any application used to create the signage. We could probably NFCC them and use them at low res only if they were official releases, but they arent, they are editor-made. The only safe move is to delete them. -- Nbound (talk) 12:32, 12 October 2013 (UTC)

If you made the SVG files yourself, all you need to do is to mention that you made the file and add {{cc-zero}} or some other free licence template for the SVG code. The copyright belongs to the person who created the SVG files. Also, I would assume that some SVG files are {{PD-ineligible}} due to them being very simple computer programs, but there isn't much information at Commons:COM:TOO about that, so we don't know exactly how much would be required to gain copyright protection. --Stefan2 (talk) 18:59, 12 October 2013 (UTC)
As per below, they were substantially copied from vectorised plans. I am not comfortable licensing the SVG code in any case. -- Nbound (talk) 22:32, 12 October 2013 (UTC)
I created a fair amount of them and I am comfortable licensing them. –Fredddie™ 22:34, 12 October 2013 (UTC)
Then Ill arrange deletion now for all of my imagery - there is still the font issue, and the fact they were copied from vectorised plans. -- Nbound (talk) 22:42, 12 October 2013 (UTC)

I wouldnt personally do it or recommend it - but a less problematic path could be NFCC screenshots of TraSiCAD (or similar software) with mockups of signage or a shield. -- Nbound (talk) 13:42, 12 October 2013 (UTC)

SVGs aren't magically subject to copyright as computer programs. The file format is an open standard that was developed in 1999 unlike the various font formats that are under copyright. The closest analogy deals with the patents behind the GIF format that one company was using to assert various licensing requirements, but yet SVG is "owned" by the W3C. SVGs, unlike fonts, do not carry scaling information in the specific files; rather each file contains simple instructions for the vectors that make up the image. It's up to software, like a web browser or an image editor like inkscape, to interpret and scale the file for display. Fonts, on the other hand, contain scaling and kerning information to tell whatever software using a font, like your word processor or a graphics program, how to space letter pairs apart or how to align letters to the baseline. The underlying typeface is not subject to copyright protection (and in fact the FHWA Highway Gothic series is specifically in the public domain as a product of the federal government), but the fonts for computer use contain additional information that is subject to copyright protection as computer code.
So long as letters and numbers are converted to paths or outlines (depending on the terminology used by your vector image editor), they are no longer a "font", but just shapes of letters. A simple combination of letters and numbers on a colored background is just too simple to merit copyright protection. After all, the Coca-Cola or IBM logos are just text, yet they are in the public domain. There may be trademarks, but that doesn't affect copyright. So long as trademarked text is not used disparagingly, it's not a trademark infringement for the simple purposes Wikipedia uses. As for design patents, those apply to industrial designs for physical shapes, like the design of a computer case, to prevent competitors from producing look-a-like knock-offs. One of Samsung's phones was judged to look to similar to an older, but still produced, model of Apple's iPhone. Given the simplicity of a road sign, no design patent would apply.
In short, I think you guys are suffering from an unsupported case of copyright paranoia here. Imzadi 1979 → 19:18, 12 October 2013 (UTC)
An SVG file is essentially the same as a font, but without scaling information. If you make a font or an SVG file, you choose certain geometric shapes such as lines and arcs, and you choose how many of these you should have and in which order they should be drawn. On the other hand, in pixel graphics, the drawing order is arbitrary, and you only have pre-rendered images without the geometric shapes from vector formats. These differences aren't visible when you look at something on a screen, but are as far as I have understood the reason for the ruling in the case Adobe Systems, Inc. v. Southern Software, Inc. The designer of a file format can of course not claim any generic copyright to all files in that file format. As most SVG files on Wikipedia appear to be user-created, this is not a big problem as the uploaders simply can choose a licence for their files.
SVG files additionally have the feature that they are text files: you could edit a file in a text editor, and you could write the source code in a creative way and include comments in the source code. The source code is therefore sometimes copyrightable as a textual document. This should mainly be the case if you edit the source code manually in a text editor.
Of course, there are many computer programs which are below the threshold of originality. For example, you can't get any copyright protection for a standard "hello world" program. Compare with opening a pixel file in Inkscape, telling the program to trace an SVG file from the pixels and doing no further modifications. This should create no new copyright as the process is fully automated. --Stefan2 (talk) 20:05, 12 October 2013 (UTC)
We agree on the key point here: SVGs aren't going to be subject to some copyright the same way fonts are. Honestly, the issues surrounding the SVG format's use on Wikipedia also surround the inclusion of other file formats: PDFs can be uploaded here, GIF has actual patent and licensing issues, etc. Trying to blame the SVG format is looking for a tempest in a teapot. Any issue you attempt raise here, if followed through to a logical conclusion, means we couldn't use any SVGs at all, yet that's not the case.
The key issue is the underlying copyright to the sign image itself. USRD is auditing, researching, and updating file licenses on the thousands of shields we use. Realistically, the end result won't be any deletions or conversions to NFC, just clarifications in file description pages on Commons. In many cases, this is because the original uploader "released" or "licensed" his/her work creating a graphic of a design they don't own. The underlying design will be PD for any of a number of reasons, and we just need to correct the license to the proper reason(s).
I think you guys need to take some time off and come back to this topic with a fresh perspective. You also need some outside perspective before any action is taken. Imzadi 1979 → 20:44, 12 October 2013 (UTC)
USRD is largely, if not completely unaffected by this as your imagery is publically released. Ours isnt, given that these shields use the shapes embedded in the PDF shield plans directly (not by tracing, they were already vectorised), they are substantially copied. They werent drawn entirely by hand - if they were, which is the case of the majority of WP SVGs, then there would be much less of an issue. Obviously any SVG is much much more complex than a Hello World program. Again, the only safe option is deletion. Even if all the above werent true, if its not obvious by this part of the conversation, Im not comfortable licensing the SVGs Ive created. -- Nbound (talk) 22:29, 12 October 2013 (UTC)
Rolling back to the previous imagery would seem possibly another way to get around this -- Nbound (talk) 22:34, 12 October 2013 (UTC)
Sorry fellas I've been away for a bit. What I'm saying is yes, I strongly believe that the Aboriginal flag is copyrighted more for political sensitivity than any threshold of originality concerns. I base this assumption on the fact that in the odd year and half that I've been aware of the matter on Commons, not a single other case of such strict TOO in Australia has been provided by which this can be substantiated. Secondly, even if it is the standard am I am mistaken, the complexity of File:New South Wales alphanumeric route B95.svg is even less than the flag. I will maintain this belief until such time as the TOO for two rectangles and a circle (which the flag consists of) is proven by a similar case. On Commons, we have several entries for TOO in various countries which allows us to form an understanding of where the bar for national threshold of originality is set. For Australia, the Aboriginal flag is the only entry we have, and using a single case as the bar by which we judge everything simple makes no sense. I've worked on copyright on Commons for a long time, I'm not a noob to the matter, and while I fully accept I may be wrong, I don't think I am. Fry1989 eh? 00:44, 13 October 2013 (UTC)
Read the reasoning for the case. Saying something has a "political sensitivity" and that it is your opinion really has little legal bearing on whether they are PD in Australia or not, but we are now well beyond that - given there are now some serious doubts to the US legality of these files. -- Nbound (talk) 01:12, 13 October 2013 (UTC)

How about using WP:REVDEL to remove Nbound's involvement, at least for the files he moved from Commons but didn't create? ( ping admin @Rschen7754: ) - Evad37 (talk) 01:22, 13 October 2013 (UTC)

Not under policy, we can't (either the revdel or OS policy), though you are welcome to email Legal. --Rschen7754 01:23, 13 October 2013 (UTC)
Already done, or the liason at least - I was told I may get faster response there - but any details as to who to email would be appreciated -- Nbound (talk) 01:30, 13 October 2013 (UTC)
That should be fine, but I kinda doubt that legal will see any reason to oversight that information. --Rschen7754 03:38, 13 October 2013 (UTC)
That being said, I do think we could use User:Moonriddengirl's copyright expertise here, as I think there's a lot of misinformation flying around. In volunteer capacity, of course. --Rschen7754 03:40, 13 October 2013 (UTC)
Im did not contact them in regards to oversight - Im contacting them in regards to the other issues. -- Nbound (talk) 06:04, 13 October 2013 (UTC)
There's absolutely no doubt about these being PD in the US, that's an absolute laugh. And stop getting hooked on the one part of my argument, the important part is that this supposed standard of threshold of originality has not been verified. That is what really matters and you clearly don't have an answer to that because you have ignored it. Fry1989 eh? 17:14, 13 October 2013 (UTC)
User:Rschen7754: Don't Nbound's revisions meet RD5? RD5: "Valid deletion under deletion policy, executed using RevisionDelete" WP:DEL-REASON: "Content that meets at least one of the criteria for speedy deletion" WP:CSD: "G7. Author requests deletion" --Stefan2 (talk) 00:28, 20 October 2013 (UTC)
No, that generally refers to when the author is the only editor of the graphic, which is not the case here. --Rschen7754 00:32, 20 October 2013 (UTC)
Well, if it needs to be bureaucratic, just set up a bot which uploads the same files under a different name and nominates the old ones for deletion per WP:CSD#F1, then. --Stefan2 (talk) 00:55, 20 October 2013 (UTC)
  • Hello. :) As User:Nbound notes above, he contacted the Wikimedia Foundation regarding his concerns especially with his contributions here. The legal department is certainly sympathetic to anybody who feels uncomfortable with the legality of their actions in their own jurisdiction. As with our Terms of Use, we really encourage people to be mindful of their own liability. WMF can't remove the content except under very specific and limited circumstances (Wikipedia:OFFICE), but we have no objection at all to the community extending a courtesy deletion of User:Nbound's contributions to these images, given his concerns about his own legal risks, and the content being re-uploaded by any contributor who does not feel at similar risk. --Maggie Dennis (WMF) (talk) 13:36, 17 October 2013 (UTC)

Moved from WP:AURD/S as is now redirect to to WP:HWY/RM. Will archive after it appears discussion is over. - Nbound (talk) 04:25, 20 October 2013 (UTC)

infobox Australian road (small)

We need a small version of the the infobox for former highways/routes and some list articles.

There is little reason why we can integrate this functionality into the main template though. There is only a changed heading (you normally only do terminii in these cases) - which could be put on a switch. Similarly the "deleted" label is overdue for the main template anyway. (As this gives us the full functionality of each option pair - Gazetted/Deleted and Opened/Closed)

The only reason why we would want to consider keeping a separate template is if we wish to style the template differently in any major way. -- Nbound (talk) 05:39, 3 October 2013 (UTC)

@AussieLegend: - pinging specifically as the usual maintainer of the IAusR template. -- Nbound (talk) 05:39, 3 October 2013 (UTC)

My first impression is that it isn't very small, and the version on the test page seems to have too much detail for what should be a very stripped down and compact. The design/style aspects that are making it bigger than {{infobox road small}} are the font size, width, and "General information" / "Terminating locations" headings. As for the amount of content, what fields do we actually want/need displayed as the bare minimun? The typical usage of {{infobox road small}} seems to be: Name, Location, Existed (which combines opened and closed dates), and Length. The only other "basic" detail I think is needed in Allocation, assuming it isn't too complicated. After all, it is meant to be a small summary box, not a full/proper infobox - Evad37 (talk) 07:22, 3 October 2013 (UTC)
Yep good points (it was only intended to be a starting point anyway) - Further, anyone may feel free to modify it during the duration of this discussion. If more than a single shield is required for alloc I think it should moved. Similarly all former shields should only be mentioned in article. (ie. the box only displays the latest, or only, shield allocation) -- Nbound (talk) 07:28, 3 October 2013 (UTC)
Kenwick Link
LocationBeckenham, Western Australia – Kenwick, Western Australia
Length3.2 km (2.0 mi)
Existed1998–present
Just for comparison, here is a sandbox version of Infobox road small that accepts an allocation parameter - Evad37 (talk) 07:44, 3 October 2013 (UTC)
We need something more specific than "location" I think (fixed). Location seems like a bad name when route might be better. The location of a road isnt <a> to <b>, but its route is. But a good start would be for us to shrink the text in the IAusR version to a similar size :) -- Nbound (talk) 07:48, 3 October 2013 (UTC)
Depends on the context. For a short length, a single location might work better, ie if Old Foobar Highway is a former alignment of Foobar Highway through Footown. - Evad37 (talk) 08:17, 3 October 2013 (UTC)
I really don't see why we need a completely separate template or why it physically needs to be smaller. Are there some actual examples where this would be needed? We should be including as much information as is relevant in the infobox - infoboxes are supposed to summarise the main points of articles. Restricting the information in them reduces their usefulness and making font sizes smaller has MOS:ACCESS issues. There's no reason why the infobox of a former road couldn't contain as much information as a current road. When space shuttles, planes, ships etc are decommissioned, we don't remove content from the infobox or use one that's smaller. In all cases, we include as much or as little information as is necessary. If we decide to only include certain information about a type of road, then it's just a matter of adding the appropriate blank to Template:Infobox Australian road/Blank. Based on Nbound's original suggestion, I've modified the sandbox and there are examples at Template:Infobox Australian road/testcases#Infobox Australian road small. There are other changes that we can make to the template, such as suppressing the headers in certain circumstances. --AussieLegend (✉) 08:23, 3 October 2013 (UTC)
It's only meant to be for when one road article has a paragraph or two about a separate but related route, that is covered there rather than its own article - for reasons of notability or otherwise. Such as when there is a short bypass, with a different road name, or a former alignment when the main highway alignment has changed. If a former/decommissioned road or highway has its own article, then it should have a full infobox with the usual details - Evad37 (talk) 08:33, 3 October 2013 (UTC)
I do believe it would be best (though not mandatory) to merge with the full template. So if need be, we can use any functionality required. But I also believe we need a small template which can be used mid-article or potentially in list articles where appropriate (such as explained by Evad. Given our differing approaches to roads [road vs. route] its unlikely to be used as often as is the case on US articles [which isnt that often anyway]). Removing some of the headers when switched to small mode would be a good start. Also note that MOS:ACCESS doesnt address text sizing, so it can be shrunk to a smaller size. We already use small text anyway. The main ACCESS issue is for those who are actually or functionally non-sighted (thus requiring a reader), rather than poorly sighted. Someone with non-correctable poor sight should be accessing the site using an appropriate magnifier, alternatively in lesser cases they'll have the font size increased using the browser's inbuilt zooming mechanism. -- Nbound (talk) 08:49, 3 October 2013 (UTC)
Of course if you can find MOS guidelines that contradict any of that - we should definitely follow them :) -- Nbound (talk) 08:53, 3 October 2013 (UTC)
I've tweaked the sandbox code and added some more examples. For consistency with the main infobox I don't see why we shouldn't continue to use direction_a and direction_b but changing this may be an option. I'll look at the small side later to see what can be done there. (I've got to do some non-wiki stuff first) --AussieLegend (✉) 09:17, 3 October 2013 (UTC)

I actually quite like the simplicity of the Infobox road small design - and the change required to make it work for Australian roads is also relatively simple [1], whereas Infobox Australian road is starting to get a bit complicated, with a long list of parameters. Is there any advantage to having the small and big versions in the same template? - Evad37 (talk) 09:58, 3 October 2013 (UTC)

All that needs to be done is use a different set of keys (we can put an example in the guidelines) for the small template, so it will be as easy to use as IBRsmall. It also keeps the same/similar styling between the two templates. As far as simplicity goes, thats one thing that the IBR group of templates isnt. OTOH, if IARsmall looks like garbage it could be used instead. I do note that we would also lose most creative control over the template contents/styling... there have been multiple occasions where I have had to defend some of our decisions because some people dont understand the context. Even things as simple and as important as the gazettal date! :\ -- Nbound (talk) 10:26, 3 October 2013 (UTC)
The advantage to having the small and big versions in the same template starts with consistency. The template may have a long list of parameters but it's not complicated by any means and can easily handle multiple functions. {{Infobox road small}} has a different parameter set meaning editors have to work with two totally different templates in the one project. An {{Infobox Australian road}} version of it is just as simple, because it just requires a blank with the required parameters that are eactly the same as used in every other Australian road article. --AussieLegend (✉) 10:34, 3 October 2013 (UTC)
Kenwick Link
General information
TypeHighway
Length3.2 km (2.0 mi)
Opened1998
Route number(s) State Route 30
Major junctions
Beckenham, Western Australia
Kenwick, Western Australia
Highway system
I've further tweaked the code to reduce the size of the infobox when |small=yes. (See Template:Infobox Australian road/testcases#Smaller version) If we can decide on a fixed parameter set we could make this a substed wrappper. --AussieLegend (✉) 11:48, 3 October 2013 (UTC)
All Parameter Grand Motorway
General information
TypeMotorway  (Under construction)
Length55.5 km (34.5 mi)1
Opened19984
Road closed20995
Gazetted10 August 19602
Route number(s) State Route 30
Major junctions
Cann River, Victoria
NSW/Vic Border
Highway system

Nice work! This should be pretty much the absolute maximum if all the parameters were required (though they wouldnt ever be). Its not a big deal, but the gap between the heading and first label, can it be lessened (or removed if it doesnt look bad that way)? -- Nbound (talk) 12:18, 3 October 2013 (UTC)

  • An unresolved issues from above: Route isn't a good label when there is only one location, such as a bypassed alignment through a single town. In these instances, Location is more appropriate. Or if we're looking for a compromise, how about Route location (or any other suggestions?). - Evad37 (talk) 14:40, 3 October 2013 (UTC)
  • When the route lays entirely within a single suburb, use "Within <end_a>" or "Entirely within <end_a>". Though may be other ideas out there. -- Nbound (talk) 14:54, 3 October 2013 (UTC)
  • What I'm thinking now is that the label could adapt itself based on whether end_b has been defined... so "Location" if only end_a is specified, or "Route" if end_a and end_b are specified - Evad37 (talk) 16:23, 7 October 2013 (UTC) — Now done in sandbox - Evad37 (talk) 16:56, 7 October 2013 (UTC)
  • I think that, rather than type, it would be more useful to describe the relation to the main route (article subject) - basically, why is the infobox there? It can just be a data field at the top (under the name) without a label, and could be something like "Bypass", or "Former alignment", or whatever the relation is. The article prose can still elaborate on the road type - controlled access, single carriageway, etc - but the relation to the main route seems like more important information. - Evad37 (talk) 14:40, 3 October 2013 (UTC)
  • I have update {{Infobox Australian road/sandbox}} with a free-form |relation= parameter to be used instead of type (which now does nothing when |small=yes)
  • It may be worth considering using a condensed <start date>–<end date> format, and letting the prose elaborate on the nature of those start and end dates. This is more efficient in terms of space, while still conveying the basic info to the reader, and the detailed info would be in the article prose. - Evad37 (talk) 14:40, 3 October 2013 (UTC) - Evad37 (talk) 14:40, 3 October 2013 (UTC)

Striked out, as it doesn't actually save anything - Evad37 (talk) 16:23, 7 October 2013 (UTC)

NSW navbox

{{Road infrastructure in regional New South Wales}} needs to looked at. Firstly, the changeover to alphanumeric routes means that there are no longer any National Highways in NSW. Secondly, I'm not clear where the term 'Local highway' comes from - is this WP:OR, or actually based on something? - Evad37 (talk) 15:40, 7 October 2013 (UTC)

It is, many of them are not gazetted highways. -- Nbound (talk) 08:09, 9 October 2013 (UTC)

Proposal for a shields request page on WP:HWY

There is a discussion on WT:HWY regarding a proposal for a shields request page on WP:HWY - Evad37 (talk) 03:19, 13 October 2013 (UTC)

Propose closing down the shields department

WP:AURD/S now has no participants, and a new global shields request page now exists at WP:HWY/S. Therefore I propose that:

  • The current requests on the page be transferred over to the WP:HWY page.
  • The current discussions there be transferred to this talk page.
  • The page be marked {{historical}}, with a note directing people to the WP:HWY page. - Evad37 (talk) 03:50, 20 October 2013 (UTC)

New portal

Hi all, I have created a new portal for Australian roads. The portal box on the right should be added to the See Also section of any relevant article, using {{Portal|Australian roads}}, or use {{portal-inline|Australian roads}} for an inline version. Articles, images, videos and Did you know? facts can be nominated on the portal talk page - please watchlist the page if you think you might like to help maintain the portal. Cheers, Evad37 [talk] 10:23, 6 December 2013 (UTC)

New issue of the WikiProject Australian Roads newsletter

The second issue of The U Turn, the WikiProject Australian Roads newsletter, has been published. Read it at Wikipedia:WikiProject Australian Roads/News. - Evad37 [talk] 01:56, 1 January 2014 (UTC)

Capitalisation of project name

Should this WikiProject should be renamed to Australian roads (lower case "r") for consistency with MOS:CAPS. (Presumably the same should apply to the parent WikiProject Highways. Is there convention that says WikiProjects have different capitalisation rules? (See also: Portal talk:Australian roads#Capitalisation) Mitch Ames (talk) 00:22, 1 January 2014 (UTC)

This was discussed previously. "Wikiproject Australian Roads" is the title of the project – just like there's the Australian Labor Party and not the "Australian labour party". The portal may be another matter, but that can be discussed there. - Evad37 [talk] 01:37, 1 January 2014 (UTC)
The diffence is "Australian Labor Party" is the title of an organisation and they're normally capitalised. This is a Wikiproject about roads in Australia, so "WikiProject Australian roads" is really the correct capitalisation, just like Wikipedia:WikiProject International law, Wikipedia:WikiProject Internet culture, Wikipedia:WikiProject Video games, Wikipedia:WikiProject Professional sound production, Wikipedia:WikiProject Amateur radio, and so on. There are some projects that capitalise every word, but this is generally incorrect and goes against our policy of using sentence case for titles. As for WikiProject Highways, the convention for WikiProjects is to use sentence case for the actual project identifier, ie what comes after "WikiProject", so "WikiProject Highways" is actually correct. The same would be true for "WikiProject Roads" but as soon as you add a qualifier, sentence case is used so it would be "WikiProject Botswana roads", "WikiProject German roads", "WikiProject New Zealand roads", etc. The last discussion that I could find regarding this is at Wikipedia talk:WikiProject Council/Archive 9#Capitalization of WikiProject titles, from 2008. --AussieLegend (✉) 02:17, 1 January 2014 (UTC)
Almost-but-not-quite-sentence-case might be the more widely used convention, but there doesn't seem to be any rule on it. Plus if you look at the comments in that discussion, there isn't any support for moving existing projects: "I don't think anyone is concerned enough to go through with a formal rule on the matter; moving WikiProjects is generally far more trouble than it's worth, in any case"; "I agree that we shouldn't bother changing existing projects"; plus in the discussion linked from that one: "There are some exceptions to this, though; I've seen a few projects go for full capitalization. It's not really a big deal either way.". Which fits in with the principle behind MOS:RETAIN ... "Such debates waste time and engender controversy, mostly without accomplishing anything positive." - Evad37 [talk] 02:33, 1 January 2014 (UTC)
I don't believe that MOS:RETAIN applies here. This is not a disagreement over "which English variety" to use (eg US vs Au spelling), it's a disagreement about capitalisation. Conveniently just below MOS:RETAIN is MOS:#Capital letters, which also links to MOS:CAPS, both of which are clear in the use of sentence case. While it is true that the title of the project is a proper name, we get to choose that proper name - and we can and should choose to follow MOS:CAPS. (One could make the same argument that any article title is a "proper name" - but we get to choose it, and we choose to use sentence case.) I understand why MOS:RETAIN exists - it is to stop disputes between two view points (eg US vs Au spelling) that are equally valid (from the point of view of different people on different countries). But I don't think that applies for capitalisation - other than "it's already there", there is no valid reason for title case for this project name. In fact WP:WikiProject Council/Guide/WikiProject#Create a project page explicitly says (with my emphasis):

The naming convention for WikiProjects ... (...the "WikiProject" prefix is considered to be a virtual namespace; thus, the first word after it is capitalized, but any others follow standard sentence case rules)

Mitch Ames (talk) 03:58, 1 January 2014 (UTC)

I know MOS:RETAIN is about English varieties/spellings, but it seems to me that this is very similar situation - does it really matter, and is there anything really positive likely to come out of this discussion? But if you wish to keep discussing, that's alright. Yes this is a WikiProject, which could also be described as a roads WikiProject or an Australian roads WikiProject. But it's proper name, that has been in use right up to now, is "WikiProject Australian Roads". If you refer to MOS:CAPS#Proper_names, you'll see that it does allow proper names to be capitalised according to standard usage. Don't forget that WP:WikiProject Council/Guide/WikiProject is just an advice page for new projects, not policy, and if you look through the WikiProject directories, there are a reasonable number of projects that use proper name capitalisation. So this really needs to be wider discussion, if you wish to create and then enforce a policy on WikiProject naming convention - probably at WP:VPP, with notifications to all affected WikiProjects and the WikiProject Council. - Evad37 [talk] 04:51, 1 January 2014 (UTC)

It matters because consistency (ie sentence case for titles that we create) is generally a good thing. "Consistency in language, style, and formatting promotes clarity and cohesion." - that's why we have a Manual of Style. MOS:RETAIN is not relevant because it applies when there are two equally valid options (eg US vs Aus spelling) - MOS:RETAIN is a subsection of MOS:ENGVAR, which does not cover capitalisation - and there is no valid reason for using title case when title case is explicitly contrary to our usual house style. Capitalising to match a proper name is not an issue here - we are deciding what the proper name of the project is, and then we use that proper name accordingly. What we gain is consistency. I don't understand why it should be such a big deal to just move the page, which (so far as I can tell without actually doing it) ought to be a trivial exercise, as it would be for any other page.
"...if you wish to create and then enforce a policy on WikiProject naming convention ..."
It seems bizarre that we need to create a policy that says "use the MOS and follow the guidelines". Actually we do have one WP:TITLEFORMAT - although I do acknowledge that it applies to articles, not WP namespace. My point is there are plenty of guidelines that suggest "roads" should not be capitalised, and none that say it should be - other than "but it's already like that". Mitch Ames (talk) 06:20, 1 January 2014 (UTC)
It matters because consistency (ie sentence case for titles that we create) is generally a good thing
If you want consistancy, this needs to be discussed on a broader scale than just one WikiProject. Off the top of my head, there's Wikipedia:WikiProject UK Roads, Wikipedia:WikiProject U.S. Roads, Wikipedia:WikiProject Canada Roads, Wikipedia:WikiProject U.S. Streets. Look through just the first part of the WikiProject Directory, there's also Wikipedia:WikiProject Popular Culture, Wikipedia:WikiProject Beauty Pageants, Wikipedia:WikiProject Soap Operas, Wikipedia:WikiProject Television Game Shows, and more. So the issue is broader than just 1 page move (35, actually)
"Consistency in language, style, and formatting promotes clarity and cohesion." - that's why we have a Manual of Style.
Looking more carefully at the main page of the Manual of Style, it is actually intended to be used in articles. The very first sentence is "The Manual of Style (often abbreviated MoS or MOS) is a style guide for all Wikipedia articles". And later on it says "Style and formatting choices should be consistent within an article, though not necessarily throughout Wikipedia as a whole. Where more than one style is acceptable, editors should not change an article from one of those styles to another without a substantial reason."
MOS:RETAIN is not relevant ...
I never said it was relevant, just the that the idea behind it is. Rather than arguing over a single upper of lower case letter in a WikiProject title, we could both be spending our time more productively to improve encyclopedia articles.
Capitalising to match a proper name is not an issue here - we are deciding what the proper name of the project is
No, you're telling me that this project and a bunch of others aren't allowed to have proper titles. This and other projects already have proper names, which are currently in use, which is explicitly allowed by WP:NAMECAPS, part of MOS:CAPS – though as mentioned above, the MOS is written for articles. And Wikipedia wasn't supposed to be a bureaucracy. From WP:NOTBUREAU: "Written rules do not themselves set accepted practice. Rather, they document already existing community consensus regarding what should be accepted and what should be rejected".
It seems bizarre that we need to create a policy that says "use the MOS and follow the guidelines"
Well, one doesn't seem to exist at the moment, and proper name capitalised WikiProjects have living happily for quite a while. Previous discussions linked to above indicated no desire to change the names of existing projects.
I really think if you want to pursue this, you should take it a wider forum than just one WikiProject - Evad37 [talk] 07:56, 1 January 2014 (UTC)
Although I do agree the present capitalisation is wrong, I really don't think it's important enough to waste time on it. There are plenty of other things that need time spent on them in article space. --AussieLegend (✉) 08:15, 1 January 2014 (UTC)

Merge discussion for M1 road (Australia)

An article of interest to this project that you may have been involved in editing, M1 road (Australia), has been proposed for a merge with another article. If you are interested in the merge discussion, please participate by adding your comments on the discussion page. Thank you. Evad37 [talk] 00:28, 5 January 2014 (UTC)

Invitation to User Study

Would you be interested in participating in a user study? We are a team at University of Washington studying methods for finding collaborators within a Wikipedia community. We are looking for volunteers to evaluate a new visualization tool. All you need to do is to prepare for your laptop/desktop, web camera, and speaker for video communication with Google Hangout. We will provide you with a Amazon gift card in appreciation of your time and participation. For more information about this study, please visit our wiki page (http://meta.wikimedia.org/wiki/Research:Finding_a_Collaborator). If you would like to participate in our user study, please send me a message at Wkmaster (talk) 18:36, 22 January 2014 (UTC).

2014 HWY Cup

The 2014 HWY Cup (a similar concept to WP:WikiCup, but for road and highway articles) will be run later this year, and I would encourage you all to signup if you are interested. The exact rules are not yet determined, but will include points for article improvements such as expanding stubs. Cheers, Evad37 [talk] 05:13, 24 January 2014 (UTC)

Great Eastern Highway promoted to A-Class

Hello. I am happy to announce that Great Eastern Highway has been promoted to A-Class. The discussion took place at this page. Regards, TCN7JM 08:13, 26 January 2014 (UTC).

Updated NSW roads schedule

Previously the latest document was 2011

Assistance for occasional users

As someone who only comes here when a break from the minutae of real life presents itself, I have a number of questions/comments/suggestions which members of the project might care to address.

  • Is it possible to produce a list of articles that have no RJL information?
  • Is it possible to automate the process of updating "list of roads ..." articles to use AUshield?
  • Can we keep all distances to 1 decimal place? (not 2 as shown for some WA roads, or 3 as in some US articles)
  • Can we maintain accuracy over longer distances by summing the values for individual segments rather than using the rounded values provided by Google maps? Downsize43 (talk) 01:59, 5 February 2014 (UTC)
Thanks for your comments, I'll reply in order:
  • I can look in to modifying the talk page banner to accept a |needs-rjl=yes parameter, and thus populate a category list.
 Done, Category:WikiProject Australian Roads articles without a road junction list should start populating over the next few days. - Evad37 [talk] 04:19, 5 February 2014 (UTC)
Great stuff, but already producing some results for which rjl is not needed, eg. Bridges, streets, proposed bypasses, etc. Downsize43 (talk) 04:24, 7 February 2014 (UTC)
Streets can have intersection lists, but don't necessarily need a full table - ie a bulleted list such as at High Street, Fremantle can be used. For the others which don't require rjl, or if any already/now have a rjl, just add |needs-rjl=no to the WP AURD talk page banner. The list is automatically generated based on mainspace articles that don't specify |needs-rjl=no, as the majority of our articles will need an rjl, either as a full table or simple bulleted list. - Evad37 [talk] 05:25, 7 February 2014 (UTC)
Fair enough. I assume that the notation |needs-rjl=no will be required for articles with bulleted lists to keep them out of the Category:WikiProject Australian Roads articles without a road junction list. Downsize43 (talk) 07:30, 7 February 2014 (UTC)
Yeah, thats right - Evad37 [talk] 08:12, 7 February 2014 (UTC)
  • You can look at the "File usage" (or "Global file usage: Usage on en.wikipedia.org" if viewing on Commons) for each old image to get a list of pages, eg [2]
Wait, that was an answer to a different question. Let me think about this. - Evad37 [talk] 02:38, 5 February 2014 (UTC)
The old files are generally numbered in consistent patterns, so you might be able to use a basic text editor like Notepad to do a find and replace to convert to {{AUshield}}. eg if the old state route shields use [[File:Australian State Route #.svg|30px]] , the you could replace all [[File:Australian State Route with {{AUshield|S| and all of the .svg|30px]] with }}, which would turn them into {{AUshield|S|#}}. Won't be perfect, as there were some odd ones (eg used .PNG instead of .png), and there could be other issues to be checked before saving, but this way could save quite a bit of work. - Evad37 [talk] 02:56, 5 February 2014 (UTC)
  • It depends on the context. For general prose/paragraphs, 1 decimal place is probably appropriate, but for RJL tables and infoboxes, they should be to the accuracy of the source – some US states document them to 3dp, Main Roads WA does 2dp, Google only does 1dp (up to 100km).
  • Hmmm... If you are careful that the end points match, it should be alright, but may be more difficult to reference, especially for very long roads. - Evad37 [talk] 02:34, 5 February 2014 (UTC)
  • Yeah, I probably could have, but I already added needs-rjl=no to articles linked by Special:WhatLinksHere/Template:AUSinttop just using tabs (isn't that many). The way I set it up in the template, articles with RJLs marked for attention don't need to have this parameter specified as well. Not having the parameter is the same as needs-rjl=yes (for mainspace), so once the job queue catches up, those articles will be categorised automatically. - Evad37 [talk] 04:19, 5 February 2014 (UTC)

Articles not yet listed

Population of the list Category:WikiProject Australian Roads articles without a road junction list has now slowed to a crawl, but with a number of expected articles not yet listed, eg. George Street, Brisbane. Is it possible to force the list to contain all target articles in the near future? I would like to complete the dot point rjl lists I have started for Brisbane streets and move on to something else. Downsize43 (talk) 23:12, 27 February 2014 (UTC)

The only way to force it is to WP:NULLEDIT the talk page of each (missing) article. A bot such as User:Joe Decker's bot, Joe's Null Bot, may be able to help by just going through everything in Category:WikiProject Australian Roads articles, or a request could be made at Wikipedia:Bot requests. - Evad37 [talk] 01:43, 28 February 2014 (UTC)
Bot request submitted. Downsize43 (talk) 05:57, 28 February 2014 (UTC)

WT:HWY/ACR#ACR for lists

We are discussing how lists should be reviewed at our A-Class review before a featured list candidate nomination. Your input is welcome. --Rschen7754 06:00, 21 March 2014 (UTC)

Invitation to Participate in a User Study - Final Reminder

Would you be interested in participating in a user study of a new tool to support editor involvement in WikiProjects? We are a team at the University of Washington studying methods for finding collaborators within WikiProjects, and we are looking for volunteers to evaluate a new visual exploration tool for Wikipedia. Given your interest in this Wikiproject, we would welcome your participation in our study. To participate, you will be given access to our new visualization tool and will interact with us via Google Hangout so that we can solicit your thoughts about the tool. To use Google Hangout, you will need a laptop/desktop, a web camera, and a speaker for video communication during the study. We will provide you with an Amazon gift card in appreciation of your time and participation. For more information about this study, please visit our wiki page (http://meta.wikimedia.org/wiki/Research:Finding_a_Collaborator). If you would like to participate in our user study, please send me a message at Wkmaster (talk) 14:15, 24 March 2014 (UTC).

Seeking resources for junction list tasks

Is it possible and/or desirable to autogenerate messages to some or all editors of some or all articles in Category:WikiProject Australian Roads articles with a junction list needing attention and/or Category:WikiProject Australian Roads articles without a road junction list requesting assistance in the completion of the relevant junction list task for each article? Downsize43 (talk) 01:26, 2 April 2014 (UTC)

I think a problem you'll find is that a lot of those editors will no longer be active, or no longer be interested in the article. Plus many editors in an article's edit history are bots, copyeditors, or did semi-automated edits (ie, with WP:AWB). You can find out the primary contributors by going to the history tab, then look on the External tools: line at the top and click the "Contributors" link. I would suggest that, before considering automated messages, you try leaving a few messages manually to see what sort of response you get. - Evad37 [talk] 00:03, 3 April 2014 (UTC)

Brisbane Metroads - proposed moves, redirects and merges

I'm not a Brisbane local (in fact I'm right on the other side of the continent), but it seems like the Metroads there are mostly phased out. The current situation on Wikipedia is:

... which is all rather messy. To clean this up, and avoid duplicating information, what I suggest is:

  1. Metroad 1 (Brisbane) → Merge content to M1 (Queensland), then redirect to Metroad
  2. M2, Brisbane → Split (relevant) Metroad 2 info to Metroad, rename M2 (Brisbane), and redirect Metroad 2 (Brisbane) to Metroad
  3. Metroad 3 (Brisbane) → Rename M3/A3 (Brisbane), and redirect Metroad 3 (Brisbane) to Metroad
  4. Metroad 4 (Brisbane) → Redirect to Metroad, and create M4 (Brisbane) to cover the whole M4 route
  5. Metroad 5 (Brisbane) → Rename to M5/Metroad 5 (Brisbane)
  6. Metroad 6 (Brisbane) → Merge to Metroad
  7. Metroad 7 (Brisbane) → Rename to M7/A7 (Brisbane), redirect Metroad 7 (Brisbane) to Metroad
  8. Template:Brisbane Metroads → Change link tagerts to M1 (Queensland), M2 (Brisbane), M3/A3 (Brisbane), M4 (Brisbane), M5/Metroad 5 (Brisbane), and M7/A7 (Brisbane)

This way, anyone searching for Metroad # actually ends up on a page about Metroads, and the pages on the M/A routes have titles that match their content.

Another possibility would be to merge everything to a new article, Brisbane motorways (or something similar), covering the current M/A/Metroad routes, and change the navbox to link each component road for each route. What does everyone think? - Evad37 [talk] 01:35, 17 April 2014 (UTC)

Support - A lot of the current pages are very short stubs and contain very little info. The Metroad page will be appropriate in covering these info since most of these have been summarised. Marcnut1996 (talk) 10:49, 17 April 2014 (UTC)
Support, can't fault this proposal. As a Brisbane local, most of the metroads are just the city road extensions at the end of freeways, and they're not widely known as such. In fact, when I followed the hexagonal "5" signs home one night from the western suburbs, nobody in the car knew what I was talking about. Lankiveil (speak to me) 00:24, 21 April 2014 (UTC).
 Done - Evad37 [talk] 04:07, 24 April 2014 (UTC)

New template: infobox highway system

The US has had {{infobox state highway system}}, but now there is a more generic {{infobox highway system}} designed for a more globalized use. Imzadi 1979 → 21:57, 24 April 2014 (UTC)

Citing a map

Please join us at Wikipedia talk:WikiProject U.S. Roads#Citing a map for a discussion on possible updates to the format of map citations in Citation Style 1 using {{cite map}}. Imzadi 1979 → 16:39, 26 April 2014 (UTC)

Koo Wee Rup bypass

There are two articles on this topic, Koo Wee Rup bypass and Koo Wee Rup Bypass. Can someone please consolidate. Downsize43 (talk) 01:49, 7 May 2014 (UTC)

I've nominated the second one for speedy deletion as a recently created duplicate – it will probably be deleted soon. - Evad37 [talk] 02:27, 7 May 2014 (UTC)

Leaflet For Australian Roads At Wikimania 2014

Are you looking to recruit more contributors to your project?
We are offering to design and print physical paper leaflets to be distributed at Wikimania 2014 for all projects that apply.
For more information, click the link below.
Project leaflets
Adikhajuria (talk) 15:32, 14 May 2014 (UTC)

Australian road route table templates nominated for deletion

Nomination for deletion of Template:Australian road routes table

Template:Australian road routes table has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page.

Nomination for deletion of Template:Australian road routes table extended

Template:Australian road routes table extended has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Evad37 [talk] 10:01, 9 June 2014 (UTC)

Surf Coast Highway

Hi guys! I was wondering if someone with an interest in roads might take a look at this article, and expand the stub along the lines of all the other Victorian highway articles. Some geographically confused drongo trying to get rid of a red link had redirected it years ago to the Great Ocean Road, which it is not in any way part of, so it's only just now gotten a stub. Since it's deserving of an article I tried to whip up something, but it's not really my area so I was hoping someone with better knowledge of this stuff might pick up where I left off. The Drover's Wife (talk) 03:29, 4 July 2014 (UTC)

Please refer to my post on this topic at Talk:Burke Developmental Road, and feel free to join in discussion there if you wish to share your views. Downsize43 (talk) 01:41, 10 July 2014 (UTC)

Pageview stats

After a recent request, I added WikiProject Australian Roads to the list of projects to compile monthly pageview stats for. The data is the same used by http://stats.grok.se/en/ but the program is different, and includes the aggregate views from all redirects to each page. The stats are at Wikipedia:WikiProject Australian Roads/Popular pages.

The page will be updated monthly with new data. The edits aren't marked as bot edits, so they will show up in watchlists. You can view more results, request a new project be added to the list, or request a configuration change for this project using the Tool Labs tool. If you have any comments or suggestions, please let me know. Thanks! Mr.Z-man 19:00, 11 July 2014 (UTC)

Bulloo Developmental Road

This article, Bullo Developmental Road is incorrectly titled, if the many references on Google are to be believed. Downsize43 (talk) 23:45, 15 July 2014 (UTC)

Yep, according to the Queensland Government [3], Bulloo Developmental Road goes from Cunnamulla - Thargomindah - Bundeena, as Regional Roads #94A and 94B. A page move should be non-controversial. - Evad37 [talk] 03:10, 16 July 2014 (UTC)
Done! Downsize43 (talk) 05:59, 22 July 2014 (UTC)

Layout consistency

I've started a discussion at Wikipedia talk:WikiProject Highways#Layout consistency regarding the layout order of non-standard sections (ex Tolls, Services, unique top-level sections etc), which I have come to notice varies even between Featured Articles. Your input is appreciated. - Floydian τ ¢ 21:25, 27 July 2014 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Australian_Roads/Archive_4&oldid=1245235686"