Category talk:Buses in the United Kingdom by type

Restructure?

Current arrangement is (brackets are criteria for inclusion):

1. Horse-drawn buses (bus drawn by a horse)
2. Minibuses (its a minibus)
3. Midibuses (its a midibus)
4. Articulated buses (its articulated)
5. Double-decker (its got two decks, after 1936)
6. Single-decker (its a modern full-size bus with one deck, after 1936)
7. Full bonnet (its full bonneted, after 1936, and not in any of above)
8. Historical (its before 1936, but not horse-drawn)
9. Coach (its a coach - in parallel cat)
10. Half-cab (its a half-cab, after 1936 - in parallel cat)

Both 'full-size buses' and 'low-floor buses' have been added to by-type, but are outside the description. In the optional category are the following cats which relate to physical design: Alternative power, Front entrance rear exit, guided, open top, tri-axle, triple-door and twin staircase.

In terms of reorganisation, grouping related concepts, changed in italics:

• By "style"

1. Minibus (its a minibus)
2. Midibus (its a midibus)
3. Full-size single (its a full-size single decker)
4. Articulated (its articulated)
5. Double-deck bus (regardless of date)
6. Coach (its a coach - in main cat)
7. Half-cab (its half-cab, regardless of date - in main cat)
8. Full-bonnet (its full-bonneted, regardless of date)
9. Historical (historical design, not covered by above)
   1. Contains horse-drawn as a sub-cat

• By motive power

1. Horse-drawn
2. The cats within alternative power
3. New cat for conventional power (either combining diesel and petrol or seperating)
4. Other cats (steam?) as required.

• By height

1. Single-deck bus and coach
   1. Contains the relevant "style" cats. Also low-floor, if thats single-deck only.
2. Double-deck bus and coach
   1. Contains double deck bus and coaches as subcats. Plus relevant design elements like twin staircase.

• By "design elements"

1. Articulated
2. Half-cab
3. Full-bonnet
4. Front entrance, rear exit
5. Guided
6. Low-floor
7. Open top
8. Tri-axle
9. Twin staircase

"Style" is essentially current purpose of the category, splitting buses into the important kinds of design. "Design elements" is about a single feature, regardless of whether that feature can be added to different types of buses (guiding), or is the defining feature of a type (articulation). I'm not sure what to call these two concepts.

There is some overlap in the "style" section and every bus should be in at least one, not exactly one. This shouldn't cause missed categories: A half-cab double decker should be both those cat trees. If correctly placed in the relevant intersection, it will be in both trees. If its not in the intersection, but only one parent, its not categorised properly and should be fixed. In effect some of the 'mandatory' cats are not top-level ones, but their intersections.

Some "design element" categories could be copied across to "style" too, when intersections are appropriate: Such as open-top double-deckers. Less so for guided, I doubt there's enough media to justify "guided midibuses"...

Horse-drawn buses are both horse-powered, and a distinct "style" from later buses. The reformulation of historical reduces problems associated with it: It acknowledges horse-drawn are historical, and eliminates the possibility of 2 otherwise identical buses built in 1936 and 1937 being categorised differently.

Other things to be considered IMO:

1. Trolleybuses should be added as a "style" - they are buses.
2. And trackless trains too? There's an overlap with buses (they are road-going passenger-carrying vehicles), but are they buses or close relatives? Certainly closer to buses than trains.
3. Minibuses could benefit from separating those used for fare-paying passengers and privately owned ones. Many schools have their own minibuses, but listing those schools as bus operators would destroy the utility of the by-operator tree. Maybe a division of purpose-built buses from van derivatives will suffice?--Nilfanion (talk) 12:57, 10 October 2012 (UTC)

Well if you want to do this I guess I can't stop you, but I really don't see how this system is any easier for the uninformed to understand than mine. It introduces a lot of vagueness in definition that the category structure doesn't help to constrain. It looks like coaches become a specific style, even though you can get coach versions of all the other styles. To the average non-expert, an open top is as much a style as an artic I would have thought. And they're still not really going to know what a full-bonnet is or why the buses that will be in there are not also 'minibuses' (both are quite small buses). And how are you defining a historical double-decker, if not by year (or design element like half cab?). It's not enough to say an image only has to be in one but it can be in two, if you're not really saying what would have one and what should have two. That will lead to both branches not being comprehensive.

In the old system, the answers to all these questions were at least hopefully clear by the constriants forced by the type tree structure of mandatory & parallel classification. I don't think relying on having intersections underneath makes that any less confusing (and in the case of open top intersections for example, these are going to dominate the style and height branches, even though they don't in basic numbers of images). And it's all very well saying you can have intersections where necessary, but I just see this as still becoming very untidy with images double-catted with both the intersection and the parent, because nobody's really going to be able to remember whether for example twin stair double-decker was an intersection or not (it shouldn't be, there's barely any images of them, even if counting the NBFL) and there's no logical way it's controlled, unlike the old system where you at least knew that only the mandatory cats would ever be intersected.

And lastly, even to the expert the new system also raises all sorts of questions that never existed before - style is now defined at the top level for some branches like half cabs by period (precisely because they only existed for a certain period while a certain configuration made sense) while it still lumps others like double deckers into one all encomassing era, from historical to hybrid.

Also, some specific issues:

• Low-floor buses come in single, double, artic, full size, midi and even mini styles
• Trackless trains have absolutely nothing in common with buses that I can see
• If you add trolleybuses to style, what does that mean for the other branches? I only see this working if you create new trolleybus intersections - I do not want trolleybuses mixed in with electric motor buses or conventional double-deckers for example
• You can potentially separate public and private design for all styles, not just minibuses - look in private use branch for examples. This would be a huge job.
• What are you doing about the other categories like modified/mobility etc? These features relate to this new scheme as much as guidewheels as far as I can see.
• There's no point creating a category for conventional power - this will end up having tens of thousands of images in and so would be next to pointless. Better to define the motive power as all unconventional options

Ultra7 (talk) 14:42, 10 October 2012 (UTC)

OK, a few issues:

1. Twin staircase buses are always double deckers, which makes twin-staircase double deckers pointless - bad example?
2. I agree conventional power is a pretty useless category. However, if someone is looking in the motive-power cat, then they need to know how to get from there to a regular diesel bus (the category description perhaps?)
3. Trackless trains are road-going PCVs, some run by bus-operators. There is a relationship there, if a loose one.
4. The minibus issue hasn't reared its head because there aren't that many minibus images categorised yet. It may still be a future problem regardless of if any changes are made as a result of this. So it should be thought about.
5. "Coach" is every bit as much a style as "midibus". You can get midis in coach "style" and in other forms, just as you can get coaches in midi "style" or other forms. Neither midibus or coach has inherent primacy over the other as a concept. This is the whole problem with the mandatory/optional layout. You have made a value judgement in saying that it is mandatory that a midicoach is described as a midibus, but that's your POV.
6. What the mandatory and optional system does is maximise the chance of images being in the correct mandatory cats. It does this at the expense of the optional cats, which are likely to be missed. CatScan can ensure all are in one of the present mandatory cats regardless of the tree's structure.
7. Defining "historical" in terms of cut-off date is arbitrary but is workable. That cat is a catch-all for the miscellaneous early designs, but a date-based cut-off will always catch early examples of later types. That means images in historical and somewhere else is inevitable.
8. The "style" and "design elements" are effective replacements for the "type" and "optional" categories. To an extent they are interchangeable. Clearly some cats in optional have nothing to do with design, but could end up elsewhere (maybe the top-level cat).
9. Open-top should be just as accessible to people looking for images as artics. However, someone using Category:Buses in the United Kingdom will readily find the artic cat (by looking in type), but will struggle to find open-tops. They shouldn't have to look in the cat descriptions to find something. The fact they do indicates something is badly broken.
10. And with regards to categories like Category:Open top buses in the United Kingdom (double-deck, flat front, half top) is there any reason why it is not in Category:Double-decker buses in the United Kingdom?--Nilfanion (talk) 22:13, 10 October 2012 (UTC)

Look, just do what you want OK? I'm finding it almost impossible to understand the logic behind what you propose and I'm getting nowhere trying to discuss it, it's just taking too much time and giving me a massive headache tbh. I still see no advantages for the user (or at the least, for every new advantage you're introducing a brand new disadvantage that you either don't realise or just don't care about as much, such as forcibly proliferating double-deck styles across 10 or more design element cats as well as model cats, but still all notionally in the same tree without introducing either a 'by model' or 'by element' intermediate level) (because, whether you appreciated it or not, being a 'half cab' is always an issue of model, but an open top or twin staircase or even coach is not necessarily), but if you're determined to do it then just do it. You still don't even seem to understand the current system (if anything it's your new system that gives priority to a midibus over a midicoach, unless you've used "midibus" there to mean both bus and coach styles).

All I can see happening here is the creation of a system that will take far too long for experts who for example would never consider trackless trains and twin staircase double-deckers to be remotely related, to use, and will almost certainly be done wrong by laymen nearly every time because I see no logic in your definition of style and design element that is not defeatable in other ways by the same flawed assumptions that it appears to rest on in the first place. At the end of the day, there are some things that are model dependant (decks, engine, cab, length, artic, low floor), and some that alway aren't (guidewheel, open top conversion), and even worse, some that can be both model dependent or not, depending on the actual model (new open top, axles, coach spec, hybrid). My system attempts to handle this by explaining it to users using the tree and description text, while yours attempts to deal with it by ignoring the model reason behind it, and just mixing it all up and creating made up notions of style and design element that simply don't exist in the real world (or if they do in the sense of novice misunderstanding, then they're just as open to misinterpretation in the new definitions as for anything else, such as why a half cab is a design element not a style, even though it's one of the few that's 100% model dependent).

It's hard enough trying to implement this while also including horse buses, but to also include trackless trains just on the basis that they're PCV's, well, that's getting ridiculous, especially as to a laymen they are 'articulated' too. And I think there will definitely be problems that this system produces by design that a simple catscan will never be able to find, which is definitley not the case in the old.

But at this point I pretty much don't care what you do, as long as you don't merge any existing categories. A lot of work has gone into categorising features like the different open top styles or various power types and they are usefull cats, wherever they ultimately get placed in the tree. I do not want to see that undone without at least being asked if it's a good idea first. Ultra7 (talk) 11:53, 11 October 2012 (UTC)

I'm striking that for now, as in the process of writing it I mught have come up with a new solution - I'll see if I can flesh it out today and I'll post it here. Ultra7 (talk) 12:19, 11 October 2012 (UTC)

A more fleshed out solution would be good. A couple questions: What is the problem with the above, and why is it wrong in your opinion?

Also, what "simple CatScans" do you find useful when maintaining this category? It should be possible to create equivalent - if more complex - queries that will work regardless of changes, that will enable you to maintain the existing categories just as you do now.

My motivation here, and what I'm trying to get away from is having non-topic concepts in the category tree. The definition of mandatory and optional used here are not inherent to the concept of buses, but something imposed to make categorising simpler. The purpose of the category tree is first and foremost for people looking for images, not those trying to categorise them. The current system means such things as these people struggle to find open-tops (except by reading a hat note) or not finding open-top double deckers in the double-decker cat. If the above changes make things harder to categorise, but easier to find images then its a net improvement IMO.--Nilfanion (talk) 13:01, 11 October 2012 (UTC)

The problem with your system has always been that it doesn't differentiate properly between what is an as new design feature that is always a factor of the model itself, and what is just an add on or special modification or prototype layout, that can be applied irrespective of model. I only realised this was the core issue I've been trying to express when I came to write the above. So, as way of keeping that distinction intact, while also integrating options into the type branch, and helping complete novices, I propose the following:

There will be just three top level sub-branches under 'type':

• by standard feature
• by special feature
• open top buses

As can hopefully be understood by anyone from those names, only the first one is going to apply to all buses. Only the first one will ultimately end in the model cats too (Alexnder RH on Volvo Olympian, etc), for the reasons already stated.

The branches will operate as follows:

by standard feature

This branch will group buses by features that are dictated ultimately by their standard model state as it comes out of the factory, including variants such as tri-axles or hybrids. Top level sub-divisions will be:

• horse-drawn
• charabancs
• steam buses
• forward control
• mini
• midi
• single-deck
• double-deck
• articulated
• coach
• half-cab
• full fronted
• high floor
• low floor
• open top (ie as new)
• hybrid (ie as new)
• tri-axle

These will all ultimately end in one of the following cats, most of which will be intersections of one sort or another:

(listed in a rough timeline order, to illustrate why they exist as named)

• horse-drawn buses
• charabancs
• steam buses
• double-deck buses, open top, open staircase
• forward control buses
• forward control coaches
• single-deck buses, half-cab
• single-deck coaches, half-cab
• double-deck buses, half-cab
• single-deck buses, full fronted, high floor
• single-deck coaches, full fronted, high floor, dual-axle
• single-deck coaches, full fronted, high floor, tri-axle
• double-deck buses, full fronted, high floor
• double-deck buses, full fronted, high floor, dual-axle
• double-deck buses, full fronted, high floor, tri-axle
• double-deck coaches, high floor, articulated
• minibuses, high floor
• minicoaches, high floor
• articulated buses, high floor
• articulated coaches, high floor
• midibuses, high floor
• midicoaches, high floor
• midibuses, low floor
• midicoaches, low floor
• single-deck buses, full fronted, low floor
• single-deck coaches, full fronted, low floor, dual-axle
• single-deck coaches, full fronted, low floor, tri-axle
• double-deck buses, full fronted, low floor
• double-deck buses, full fronted, low floor, open top
• double-deck buses, full fronted, low floor, hybrid
• double-deck coaches, low floor, dual-axle
• double-deck coaches, low floor, tri-axle
• articulated buses, low floor
• articulated coaches, low floor
• minibuses, low floor
• minicoaches, low floor

To do this, I've eliminated 'historical' by introducing 'charabanc'/'steam bus'/'open staircase', and used 'forward control' which I believe is the more proper term for what I called full bonneted and also includes some of the truck looking historical buses.

At this level, images should only be in one of these branches (ultimately all via a lower level model cat), therefore this level can be grouped together in a hidden maintenance cat, for use by catscan.

This tree should be easy enough for people to use by intuition, but if not, because of the maintenance cat, it's easy to check for errors both where an image hasn't been descended far enough or double-catted, plus where images aren't in the branch at all.

by special feature

This branch will be for design features that are only introduced as new if they're either prototypes or being used in special systems, or for features only introduced by way of second hand conversion. Hopefully the names used are self-explanatory to novice users. These cats will be applied in addition to the standard feature cat, which is easy to maintain using catscan and the hidden cat mentioned above. These cats will not go as far as model, precisely because they don't apply to models. Anyone wishing to find a particular model with one of these features therefore, can either use visual comparison, or catscan. There is ultimately no real point in creating intersections between these special features and the models cats that will exist in the standard feature tree, I think this would definitely be over-categoristion because they're really quite rare in the UK (even open top when compared to the total number of non-open top), and in many cases, the intersection will already most likely already be identified in the operator/bus transport/location tree. Where they do get grouped, it will be as is done currently, ie based on the exact batch of buses or individual bus.

• guide-wheel fitted buses
• open top conversion buses
• prototype electric buses
• prototype fuel-cell buses
• prototype hybrid buses
• prototype front entrance rear exit buses
• prototype triple door buses
• prototype twin staircase buses
• wheelchair ramp converted buses
• rebuilt buses

open top buses

This branch will share the other two levels as a top level sub-cat, recognising the awkward fact that open top can refer to three very different groups - as new historical double-deck models, one or two as new modern models, and (the majority), second hand conversions of all kinds. Because it only groups branches already in the other two, maintenance should not even be needed, except for finidng images placed at the top level (which would likely show up in other checks anwyay).

I believe this system both allows your idea of what all the basic types are (single/double-deck, artic, open top, low floor, guided, hybrid) to be found within 1 click of reaching the Type tree, while also being maintainable with just one or two catscan searches, while thirdly also respecting the real world reasons why these various concepts developed, therefore hopefully helping topic knowlegable volunteers to get involved in categorising too. Ultra7 (talk) 14:44, 11 October 2012 (UTC)

I think this is moving in a positive direction now. Issues I can see:

1. Doesn't resolve the "what is a single-deck bus?" problem with confusion between the everyday meaning, and its technical one. A by-height tree addresses that to some extent as people looking for a one decked bus but not necessarily a single-decker will look there. Something like the "full-sized", with an appropriate category description, may be the only way to separate the two distinct meanings which is clear to both non-experts and experts alike.
2. I think some buses may be missed (example). If single-deck is its broad everyday meaning it goes there, but its not a full-fronted bus. May need more early classes - where do early single decks go?.
3. The comma seperation in the names is awkward. When there is one additional parameter: "low floor midibus" makes more sense than "midibus, low floor". Similar with the 3 or 4 parameters - consider the form that makes most sense.
4. Some names overly complex: "Guided bus" will do in place of "guide-wheel fitted bus". If wheel-guiding from optical or magnetic, then those are natural subcats and can be created if needed.
5. I agree there's a distinction between the "standard" and "special" features - however I'm not sure if making that distinction in the tree is beneficial. Just having open top, guided, prototypes etc sat alongside the standard types is simpler, and saves having to explain the awkwardness of open-top sitting there by itself.

Given CatScan's limitations a hidden cat is likely to be only approach that will work. I'd point out Catscan can't work on the existing tree: A query for all UK buses, not in by-type, will fail to spot that this isn't in the current by-type scheme. CatScan can ensure not having the "standard" and "specials" distinguished doesn't harm anything. If you think open-tops are not getting full details, CatScan open-top against the hidden cat. Ditto guided buses or prototypes.

I'll start making some changes outside this tree: Creating by-motive power ("optional", as it saves having to create conventional power) for instance. I won't merge a single category, but may recategorise some.--Nilfanion (talk) 11:23, 12 October 2012 (UTC)

1. I was defining single-deck in that scheme as 'full size single-deck', so it would be called that. If that's not enough for you, then a 'by deck' top level tree is going to be the only way to solve this claimed confusion. It won't be so bad because all it does is organise the standard features tree in a different way. It will be yet another place to check for images not descended far enough, but that's easy enough I guess.
2. As far as I understand it, that's a 'forward control' bus. It's a bad example though, because as far as I know, it's the only one in the UK of its type. I'd categorise it as full control for completeness, or even create a spearate 'forward control, modern' cat for standard features, but I would probably also create an extra special feature cat for US design school bus imports, as there's some full fronted ones here as well that look nothing like other UK single-deckers either.
3. No issue with that. I hadn't really set on those for the cat names, I was just tyring to illustrate what each contains. I wouldn't use commas at all in the final names.
4. I can't see the point given that 'guide wheel fitted' accurately describes all guided buses that exist in the UK, but if you want to keep it just 'guided bus', I'm not going to argue.
5. How is it simpler? It ends up with a top level of 25+ cats, some of which will stop at one level and have less than 10 images, and others that will contain thousands of images over a further 3 or 4 levels. There's no common thread to the 25 top levels, it's just a really loosely grouped collection of adjectives that relate to physical features. And under those top levels, it has sub-trees which at their bottom levels may or may not end in model cats, but the user will never be able to figure out whether a particular cat is the former or latter (bearing in mind plenty of types still have no model cats at all). The only way it makes sense to lump prototypes with special features with standard features is if we are just assuming everyone is just a complete simpleton (in which case, why are we even crediting them with being able to categorise an image correctly from the mulitude of options under those 25+top levels?). Standard/special features are separated by one click, and are still both filed under 'type'. How is that too complex, really? The basic issue here is that standard features will always ultimately end at one bottom level intersection cat and one only, because that's just a simple fact of bus design as it's evolved over the years, however the same cannot be said of the special features - they don't make sense as intersections and they don't need restricting to one cat only. That's precisely because they're not really issues of basic design and are not tied to any one era. Multiple categorisation there is not a problem, just like it's not a problem in the real world where you can spec a particular basic design of car with all sorts of optional extras. That doesn't mean that it's a good idea to categorise cars with tinted windows in the same tree and at the same level as you define what a hatchback is. If open top as a third top level is really an issue, it can actually be removed and left as just sub-branches of 'new' in standard features and 'converted' in special features, with a See Also hat on each.
6. The image you pointed at is actually in the current type tree (Coaches in the United Kingdom, which is in type via parallel classifications), it just hasn't been descended fully. That's a problem that can occur in both systems, but I guarantee it happens more often in trees which mix and match completely unrelated concepts and allow multiple options, especially as many people descend images like that using HotCat, and so never even see the other options.
7. I've no doubt a cat-scan can be crafted that deals with your wish to lump this all together, the point is that it definitely won't be simple, even with the use of a hidden cat, and it will definitely be out of date each time someone renames 'guided bus' to 'guidewheel bus' or whatever (and remember CatScan never reports this, it just ignores it). The system I crafted will need one or two searches which will simply check one high level cat against the hidden cat, so the only variables are the upper levels of the type tree, and the hidden cat, which should never change.
8. If you really must create a 'by motive power' branch (I didn't include one), then can you please make sure it differentiates production models from protypes, and if possible, retro-fitted systems from brand new too, because as far as I know, it's still only hybrid buses that have even made it to mass-production and general sale in the UK yet, eveything else has been prototypes or batch production for specific users, and in those prototypes there's been both new buses and retro fitted systems too. There's even one cat there where buses have been fitted with two different systems at different times!. Ultra7 (talk) 17:10, 12 October 2012 (UTC)

1. Yes, the by-deck tree will be needed. Experts can separate midibuses from normal single-deckers. The general public can't, and as the distinction between the two shrinks it will get harder still for them. The by-deck has a tangible return: If I as a non-expert upload a single-decker and drop it there as I don't know if its a full-size or a midi. That's better than nothing, and an expert can figure out its a midi and move it on down..
2. (no comment - preserving numbering)
3. (no comment - preserving numbering)
4. I agree all UK guided buses are guided-wheel ones. However, there's no need to create guided-wheel as a separate concept - unless the global guided-wheel cat is created or the UK gets other guiding types. The simple Category:guided buses in the United Kingdom should be retained regardless, and if either of those events happen most of its content would then move to guided-wheel (if not already there).
5. Its not descended fully = its not fully categorised. Which I assume is your objective - to ensure everything is categorised fully? A simple CatScan (comparing 2 categories) can't tell you that one has got stuck halfway down. A hidden cat will improve on status quo as it will spot things like that.
6. It may be simpler because the user doesn't need to understand what the distinction between "special" and "standard" is - something someone descending via CatScan won't know as they can't read the definition. Of course there's a clear distinction in the theoretical meaning (which I see the sense in), but in practice does "special" add anything beyond "not fully intersected against the standards"? In this sense, as we get more content for a "special" it might become a "standard". Imagine if twin-staircases become prevalent - that ought to be a new "standard" concept. Or if a manufacturer created a model that is only ever sold with guiding. That shouldn't affect how guided buses are placed, but it moves a "special" to a "mixed". In this context, open-top becomes a "special" as its not fully intersected.
7. Remember you can compare a sub-cat against its parent. You don't need a complex tree to make a simple CatScan work. Using CatScan to compare Category:Buses in the United Kingdom by type against hidden cat will spot all buses not in the "final" cats works regardless of the layout of the tree. It will continue to work if the guided cat is renamed. The scan to check the guided cat specifically (which you might want to do, because you know guided buses attract poor categorisation) will change, but that's understandable.
8. The engine-type is a natural sub-topic like the colour or date, so makes sense to give its own tree to. Hybrids should be grouped together in some sense regardless of whether its a new hybrid or a retro-fit. If there's a need to make a distinction, that can be done, but the overarching "hybrid buses in the UK" cat would be needed regardless.--Nilfanion (talk) 22:20, 12 October 2012 (UTC)

1. Fine, but I see no reason to treat decks as a special case like this when we don't provide similarly dumbed down starting points for concepts like where the engine is or how many doors there are or whether it even has a door or an open platform (both often indicative of the underlying basic design and both well within the comprehension of complete novices, who might infact be confused when they see that artics and minibuses are by necessity filed under single-deckers in this branch, unless this too is now to be optional), and infact it contrasts with your later proposal to remove the 'has no roof' as a top level starting point too.
2. -
3. -
4. -
5. What is your point though? It was me who brought up using a hidden cat, I;m well aware it's an improvement - if I had known about it back then I would have implemented it in the old system too. It not being there is not a flaw of the parallel definition, both systems benefit from it, and both cannot find undescended images without it.
6. Your theorisations are pointless though. If a manufacturer did produce a model only with guidewheels, it would be committing commercial suicide. Just like a car manufacturer if it only offered cars with tinted windows. It's an optional extra with limited utility, always has been, always will be. And if twin staircases were more than just prototype features, I would have included them as one of the standards, that's the whole point. They aren't, so they weren't. Category systems should reflect current reality first and foremost. If I had been proposing this in the early 1990s, low-floor would probably have been in special features as a prototype. That's not to say that once it was adopted in production, they wouldn't be moved across to the standard branch. It's no drama to do that. The point being, the time that that would have occurred on Commons is the time that low-floors ceased to be defined by their status as a prototype feature in the real world, and became inseparable from an actual model designation. Twin staircases have never been part of a production model, so anyone looking for them in a category that's clearly marked as standard features (which will be visible in HotCat) is barking up the wrong tree, and the solution there is always to educate, rather than obfuscate. In practice this separation avoids users having to look at the 10 categories that are not relevant to 99% of buses they are likely to see in the real world, while they browse the 17 that are (which are by design named to allow the best chance of finding the one they have by only referring to common features). In practice this gives people with an image that they know is of a bus with a rare or special feature, a viable starting place where they know they're likely to find it, unobscured by cats dealing with all the mundane non-special features that are properly demarcated in the standard features tree (even the most novice of novices knows that buses with horizontal wheels sticking out the front sides for example are likely to be some rare type, as would anyone who knows what the wheels are for). In practice it avoids confusion in those users who might be the type to wonder why some of the trees end in model cats and some don't, and even better, it stops those people who, on seeing that discrepancy, might be tempted to do somthing crazy like create a cat for every model's open top variant.
7. I did know that. If you run that search on your system using just the hidden cat, then you end up with a list with images with two very different issues - both undescended images, and special feature images without a standard cat (all of them). And if you rely on just using the top level, rather than specifically listing the hidden cat and the special features you're checking for, then you run the real risk of not catching things like when someone ends up including images in type when they decide to dump 'red buses' into the tree, or otherwise start their own special types. I don't know about you, but that's not helpful to me. If I want to find guided buses without a standard type, I'll run that one specific search using that cats name to get that one specific result. If I want to find undescended standard types, I'll run that, for the same reasons. That's what I mean when I say one-click - it's only useful if the results can basically be batch processed afterwards, there's no second stage of manual inspection. If you don't do it like that, then certainly for things like undescended images, it's often quicker just to do it by visual inspection and use HotCat.
8. If you're creating this as completely separate tree from type then it's even more important that it reflects its unbalanced contents. It is only going to contain about 5% of all UK bus images, and of that 5%, 95% will be examples of production hybrids. It was acceptable to just delineate by the fuel type when it was obvious these were all just optional cats; if you're now elevating alternate power to the same level as location and registration, it needs to be clearer just how few buses this tree will actually contain, and what stage they represent. Ultra7 (talk) 04:34, 13 October 2012 (UTC)

1. By-deck is an alternative way to access the by-types (it will be near zero maintenance and included on every image as a result). I think it will be useful, as for example it may help those people who don't know what a midi is. I don't think you are saying its detrimental. Likewise, if you feel door count and engine position are helpful you can create them. Remember - you can't tell me how not to waste my time...
2. -
3. -
4. -
5. There wasn't any real point there - it was an aside illustrating a flaw in existing layout.
6. The issue I see with the split is while "standard" has an intuitive meaning, "special" doesn't. What you propose is 17+10+1. However, the prototype things can be logically grouped together. That would make it 17+4+6+1: "Standard" - common features of production models, "special" - ad-hoc features added to individual buses, "prototype" - on prototypes only. The remaining non-prototype specials are then all modifications. If you rename "special" to something like "modification", then it then has an intuitive name that accurately describes its content.
7. Bear in mind to do a simple 2 category scan you need to: Open CatScan, increase depth, add the other category and start. That's not one click. One click is this - ie a pre-saved scan. If you use CatScan a lot, and run certain queries regularly, I suggest you save them somewhere like User:Ultra7/CatScans. That will save you time each time you run them, allows others to use them, and gives you potential to craft and run more complex queries as easily as a simple one.
8. If/when I create it, there is utility to having undifferentiated cats - they are better than nothing. While I agree its useful, you can't require that I create the sub-cats. As an analogy if I think "Supermarkets in Foo" will be handy, and you think its important to separate Tesco from Asda, I don't have to create "Tesco supermarkets in Foo". In any case, the hybrids should already be split up in the way you want, as they will inherit the by-type structure.

I won't be around next few days.--Nilfanion (talk) 09:50, 13 October 2012 (UTC)

I simply cannot accept a single type tree that bunches fundemental and trivial model and non-model feature cats all together in one fuzzy mess, but that also has things like deck defined in parallel above them to help users who presumably also wouldn't cope with the fuzzy part, and you're style/element doesn't address this either. If they must be mixed, it needs to happen at just one level, and to me that means there needs to be more 'dumb' choices than just deck before we get to specific models, so I'm working on a system that has a few 'by' trees for these features, which will include both model and prototype cats, as well as cats for open top, guided, modified, alternate fuel. It still won't make much sense as a tree for models, as it will still be mixed at the bottom levels, but it at least follows the Commons standard that 'by' trees should contain all images, while the others don't have to. Ultra7 (talk) 19:08, 13 October 2012 (UTC)

I think the underlying problem here, and the root cause of 90% of this discussion is that "type" is a vague word in English. A vague term is not the ideal way to describe the set {mini, midi, artic...}. That is a useful, discrete and well-defined breakdown of buses - and I agree that its important to identify a bus in these terms. Its not helpful to mix these up with the other properties like guiding.

If we had a better name, we could move the {midi, mini...} set there. "style" and "standard feature" have been used above. "Classification" is another possible. This category would be top-level (as the replacement for by-type). By-type cat would then fulfill the same role it does for Ships, Exhibitions or Automobiles: A place to put concepts that don't fit into the other subject-by-X trees. These by-types are not necessarily comprehensive, and some images might be in multiple cats within it.

The additional categories you have created in past few days will be useful once populated. However, remember a category like Category:Single-deck full bonnet front door motor buses in the United Kingdom should have all of the relevant parents. (Category:Single-deck buses and coaches in the United Kingdom, Category:Full bonnet buses and coaches in the United Kingdom, Category:Front door motor buses and coaches in the United Kingdom and Category:Motor buses and coaches in the United Kingdom). Ideally the equivalent categories should exist globally not just as a "in the UK" one - UK buses shouldn't be a walled garden. It should be possible to descend the tree to that cat via any possible route.

And AFAIK there is no "standard" on Commons that a subject-by-X tree should contain all images of the subject. Its good that each image of the subject is included in as many as possible but that doesn't imply it should be in all. The by-type cats I mentioned above are examples of this.--Nilfanion (talk) 10:23, 20 October 2012 (UTC)

I'm fine with a fuzzy idea of 'type' now that motor bus/motor coach exists as one of them. There's no walled garden - I always include the global branch if it exists. Some of the motorbus/coach cats might be missing an intermediate branch at the moment for precise naming convention, but that's only because it's easier to concentrate on the upper and lower levels right now. And I thought it was a standard, in the same veign that houses by colour or dogs by breed should always be comprehensive and never overlap. If it's not a quality that's comprehensive or optional, then it's just a regular sub-category (ie a subset) and shouldn't be called a 'by' anything. Ultra7 (talk) 14:47, 20 October 2012 (UTC)

With regards to global cats - just about any local UK version should be have the equivalent global cat. And its perfectly acceptable for a "by-X category" tree to both have overlap within it and not be comprehensive. Dogs by breed provides an illustration of both these points: A mongrel is a dog but, by definition, will not belong in any of the breed categories (so by-breed is not comprehensive). On the other hand, as a Labradoodle is a cross-breed between a Labrador and a Poodle, the Labradoodle cat should be a sub-cat of both the Poodle and Labrador cats (so by-breed has overlap).

The purpose of a X-by-Y category is a way of grouping together a set of related subsets of X. Nothing about that mandates that the X-by-Y tree should include every example of X, or that a specific example of X can only be described by one category in the X-by-Y cat. It may provide a comprehensive list with no overlap in certain cases, but that's the result of the specific nature of the subject, and whatever the by tree is about, not a logical implication of the 'by' grouping.--Nilfanion (talk) 16:13, 20 October 2012 (UTC)