One of the essential steps in any kind of open-source collaboration would be some kind of classification shorthand to enable the parties to better reference their work, and the work of others. For example, if I want, presently, to refer to a system in which the vehicle is perched on a vertical extension of a captive bogey which extends from a slotted track, I have call it an “ITNS” or “Ed Anderson” design and mention Taxi 2000” or “SkyWeb Express”, (or vice versa) to be evenhanded. Making comparisons and design offshoots using those and a few other systems in a single discussion could get pretty confusing. The confusion would extend to procurement, contract awarding, etc. At some distant future point, someone will create some kind of certification process for aspects like track construction. That’s kind of hard when you can only describe the track in terms like, “It’s like the ULTra track but it will have screened middle sections like MegaRail…with a third rail…”
Originally I was going to fold this all under the “SMARTS” umbrella, (Small-scale Modularized Automated Rail Transit System) but realized that some important systems fall outside of that description. (A little note here. I think I like “Standardized Modular Automated Rail Transit” better. It is more descriptive of what I am up to…) Anyway, I believe breaking up the systems by key attributes, rather than vendors and inventors, allows a more substantive dialogue.
There are also obvious disadvantages. First of all, without the above picture as a key, nobody can use the system to classify anything. Secondly, who really knows the exact numbers to put in for the various systems except the designers themselves? I imagine one half-solution would be to simply “x” out the unknown latter details, so that the ULTra would be a “BGBxx” while MISTER would be a TIxx and I have been designing a TELxx, but Anderson likes the BELxx.
All I can say is that just because I don’t have the resources to make something happen, it doesn’t mean it is entirely useless to point the way. After all, classifications are essential for everything else, including roads, bridges and the vehicles on them.
Finally, I would like to thank alert reader “afransen” for pointing out that I can feature recently posted comments on the main page. (On right, scroll way down) This may help stop threads from going dead so quickly. Unfortunately it doesn’t show which post the comment refers to. Perhaps very alert readers will learn to preface their comments with a post number when they are commenting on older threads, which I will do myself. We’ll see how it goes. I’d love to see the threads get more content rich over time.
5 comments:
Dan, you have been touching on the idea of integrating different types of transport. This is something that I have been thinking about, so it is reassuring that these ideas are gaining currency.
Here is my take on this:
fig 1 shows two areas each served by a PAT network and linked by a line that is part of a GRT network.
As shown the two types of transport can be different and function independently.
However, if the two systems use the same guideway and can be linked, as in fig 2, PAT vehicles could pass between the two urban areas.
This could overcome a fundamental problem with all GRT transport off-peak: when demand is low, you have to either have a long service interval or you run the vehicles nearly empty.
As I see it, at times of peak demand the GRT line would be exclusivly GRT vehicles; very low demands could be satisfied with PAT vehicles and in between a mixture, with GRT only used for the more heavily used routes.
Next we add freight as shown in fig 3. Now we allow freight traffic on some of the PAT network to get access to parts of the city remote from the GRT line.
John Greenwood
MAIT@john-greenwood.co.uk
Good try! :)
I've been trying to make some classification myself, for personal use, and failed miserably. There simply seemed to be too many 'variables' between the systems.
However, in the longer run we certainly can use something like this. Some particular comments on your suggested stamp (which looks brilliant and authorative btw, which is good!).
- Articulation: what does that mean?
I assume it's the axis of freedom allowed for hanging designs. That is makes no sense for side or bottom supported ones. In such a case, shouldn't it be a subcategory of "supporte=top".
And allow for more then one articulation (i.e. roll and pitch?) Your design has both, if I am not mistaken.
More categories:
- Rubber wheels or metallic?
- Battery types (as subcategory)
- Speed of the vehicles / track design
- Minimum curve ratio of the track design
This classification is good if it evolves when new combinations are being introduced. A similar software classification comes to mind, Trove used by Sourceforge. It's rather useless imho, since any project I've tried to fit in never actually fits. There's too many categories and too little, both at the same time (from one person's perspective).
Dan the Blogger Responds to John Greenwood and Akauppi
Hi John – I agree, except I think it’s a bit premature to start prohibiting PAT (PRT) vehicles during rush hour. (wink) If the track and control architecture is universal, the decisions can be made locally as to how to best configure a system. Of course the other side of that coin is that unless a full system configurations are suggested, as you and I have both done, you cannot design a universal track and control architecture compatible with it.
Hi akauppi - good to hear from you. Yes, this is a “work in progress” to be sure. I started making a “tree” but there were just too many branches. You are right, I only left space for a single “articulation,” and should have left two. I’m not convinced that it is necessarily only a sub-group of the “hanging” category, however. If supported systems become the standard, then some accommodations may need to be made for very hilly cities or traveling on track that was previously banked for a slower speed. Check this out. Michelin’s active wheels in action
As for the extra categories you suggest, I, too, had a similar list, and abandoned adding more categories for the same reasons you suggest. I think this leads to an examination of ways to simplify the broadest aspects of classification. For example, perhaps the system needs to be broken into 3 sets of numbers, one for track, one for vehicles, and one for stations. A full system, could then, if it was really necessary, be described by joining them all together into a “TVS” classification. (Track,Vehicle,Station) In other words, the system needs to be compressible into chunks that have some way to make them easily remembered. This is definitely not a finished product.
P.S. – to all readers- I seem to be having problems with the “recent comments” feature. For a while it only didn’t work for me, now it doesn’t seem to work for anyone… It is a third party “widget” and there are others available, but I see a lot of comments indicating the others are buggy as well. I’ll leave it alone for a while, as I have heard some reports of it turning off and then recovering on it’s own.
Dan
Are we thinking of a Multiuser Urban Guideway?
It would carry different types of traffic including PAT, GRT and freight.
Priorities would depend on section of track, time of day, and current demand. This could get complicated and, as you suggest, it is far too premature to start working out the details.
The potential benefits of a MUG are much greater than a specialised PAT system and the need for the sort of open specification that you are suggesting is even more important.
Yeah, John, I like the to keep the MUG options open, for reasons I detailed in the latest post.. As for being complicated, it should be noted that it could all be relatively transparent to the user.
That's the beauty of "just-in-time" intelligent routing and scheduling.
Post a Comment