home recent topics recent posts search faq  

Basemap :: Forum

user:
psw:
| lost password | register
Messages in this topic - RSS

Home » Public Transport Data » Demand Responsive Transport

5/31/2011 11:48:46 AM

admin
admin
Administrator
Posts: 397
Please can all ideas on how to model demand responsive transport be posted in this thread.
edited by admin on 5/31/2011
permalink
6/2/2011 10:57:50 AM

PeterW
PeterW
Posts: 7
We would need any implementation to address the following three issues:
1) Journey times by DRT need to be modelled as being slower than by car. Rather than take a direct route through the road network, DRT services have to fit in with the origins and destinations of multiple passengers, causing extended journey times. If DRT was modelled as being 'too quick', it would give the impression that regular bus routes in the same area were irrelevant.

2) Each DRT service may have different and complex hours of operation. To give a real example, Service A operates M-F 07:30-14:00 and M-F 16:30-18:30, whereas Service B operates M-F 07:30-22:00 and Sat 08:30-22:00 and Sun 09:30-20:30. The correct hours of operation need to be modelled, otherwise at some times of day accessibility may appear to be better than it really is.

3) Some services have complex geographical rules on what journeys are permitted, but most can be simplified to fit the following pattern. A DRT service has two zones (often overlapping and discontiguous) and journeys are only permitted from one zone to the other zone. For example, zone 1 might be a collection of villages, and zone 2 might be the town centre, the hospital and the bus station. A journey from a village to the hospital, or from the bus station to a village would be permitted, but not a journey from the bus station to the hospital, or one village to another village. Our DRT services often only permit a small number of journey combinations in a large area, so this needs to be modelled otherwise the accessibility improvement would be overestimated.

I think the above requirements would be the minimum to model DRT services usefully. It might not handle every complexity, e.g. http://www.tfgm.com/upload/library/Mossley_LL_280311.pdf might be fiddly to model accurately, but would still be worthwhile.


29-Nov-2011 update: The URL of the Mossley DRT example has changed to: http://www.tfgm.com/upload/library/Mossley-LL-171111.pdf
edited by PeterW on 11/29/2011
permalink
6/2/2011 2:34:34 PM

AHanner
AHanner
Posts: 1
1) It would be useful if there was some way for DRT services to connect with scheduled services - perhaps not every service in an area, but a number of DRT schemes that I am aware of allow journeys to link up with 'trunk' services into market towns / urban areas.

2) Many DRT services have a (semi-)scheduled element, e.g. with scheduled arrival times into a market town but with flexible routing within the area of operation. It would be useful to have the option to input this information where appropriate.
permalink
6/2/2011 3:13:00 PM

admin
admin
Administrator
Posts: 397
The final DRT solution would be a supplement to the existing PT Network, as far as i'm aware a lot of these DRT services are used as a "feeder" into the core public transport network. Though maybe we can limit this using an interchange option like "allow interchange from DRT"?
permalink
6/10/2011 12:59:39 PM

Richard Calton
Richard Calton
Posts: 6
My take on the subject / ideas on modelling demand responsive transport.

I see a number of issues:
- having to wait for the service
- having to prebook
- not always getting the sevice you want - when you need it due to capacity limitations
- transit time (average speed) and variability in transit time - number of stops, route etc.


The issue I see is that although it would be possible to build a model that could accommodate these and other requirements for it to work we would need to be able to supply the data i.e

- statistics on waiting time
- statistics on journeys lost because prebooking was not possible
- statistics on transit time (average speed) and their varability throughout the day - statistics on capity limitations and their varability throughout the day.

As a result I would propose a pragmatic solution one that is not quite perfect but nevertheless models most of what we need using data that we have or can easily generate:

Proposal model would have the following features

The pick up area would be a polygon as before.

The drop off area would be a polygon or points as before.

Transit time would be modelled as a proportion of the road speed – suggested default 2/3

Lost / refused journeys would be a proportion of journeys that can’t be met. Suggested defaults 15% This means that if a particular location has 100 residences the accessibility will be reduced by multiplying by 0.85.

Waiting time – the difference between agreed and wanted pick up time in hours. This time would be added to the transit time from each location.

Other suggestion below such as interconnecting to PT and operating hours are also required!

Hope that helps

Richard
permalink
7/13/2011 10:51:28 AM

admin
admin
Administrator
Posts: 397
Following on from the meeting at the East Of England Accessibility meeting the following proposal was suggested: -

The pick up area would be defined by a polygon

The Drop off area would be a point on the map.

During the calculation the the user will specify the number of pickup's being made by the DRT service. This will then trigger an addition to the journey time. This addition would consist of either a set time per pickup - i.e. each pick-up takes 5 minutes - or would be a proportion of the journey time within the pick-up zone. This needs to be ironed out.

The DRT settings would need to include the following information: -

  • Unique Service Identifier
  • Days of Operation
  • Times of Operation
  • Restrictions of use - i.e. people going to hospital only
  • Is the DRT linked to another service - i.e. is a feeder service for Arriva bus 28.
  • What vehicle is being used and it's capacity - limit number of pickups
  • The proportionate speed that's used when travelling on the road network - or set speed.
  • Maximum speed able to be travelled.
  • Wait time - could be incorporated into the number of pick-ups above.
This seems quite similar to the proposal made by Richard. What are users views?
permalink
11/28/2011 12:29:39 PM

hstraw
hstraw
Posts: 3
The last suggestion would be an enormous improvement on what is available now, but I'm not sure that, as described, it would work effectively where pick up areas are extended. Whilst it would be possible to subset the area and repeat runs several times, would this allow for the potential variation in journey times that occur when users can be scattered through a large rural hinterland?
permalink
12/1/2011 4:16:00 PM

CarlH
CarlH
Posts: 5
Would there be ability to run two different types of calculation for DRT? One for a rural area and one for an urban area? I quite like the idea proposed by admin and as Hazel says, its a lot better than the existing model (when it worked)
permalink
3/8/2012 11:53:48 AM

PeterW
PeterW
Posts: 7
Reading through this thread, there is some variation in how DRT operates in different areas. Any methodology for modelling DRT journeys will need to be sufficiently flexible to be able to represent our different arrangements. Before the methodology gets finalised, I wonder if users have any other 'flavours' of DRT not already mentioned in this thread?

So far, I've noticed the following differences in (a) constraints on which journeys can be made by DRT, and (b) factors affecting the journey times:

(a.1) the hours and days of operation;
(a.2) whether the area served (zone) changes shape at different times of day;
(a.3) whether the DRT covers (i) a single zone polygon, or (ii) a combination of more than one discontinuous polygons and/or points;
(a.4) the purpose of trip permitted, e.g. (i) hospital visits only, (ii) shopping trips only, (iii) any trip purpose;
(a.5) the combinations of origins and destinations you are allowed to travel between, e.g. (i) from anywhere to anywhere in the zone, (ii) from one polygon to a different point/polygon (e.g. village to town centre) but not travelling within the same polygon (e.g. town centre to elsewhere in the town centre);
(a.6) whether passengers are allowed to interchange between DRT and timetabled services (i) anywhere, (ii) at specified stops and onto specified services only, or (iii) not at all;

(b.1) whether there is a semi-scheduled element of the DRT service, i.e. (i) timed to visit specific points at specific times e.g. the town centre, or (ii) always able to connect with any timetabled service at specific stops, or (iii) always able to connect with specific services at any suitable stop;
(b.2) the level of uncertainty in pick-up times;
(b.3) the degree of journey time variability;
(b.4) whether the maximum vehicle speed is the same as for car;
(b.5) the amount of time delay due to detouring for other passengers;
(b.6) the amount of time delay due to stopping to pick up / set down other passengers;
(b.7) how the vehicle capacity affects likelihood of a journey being possible, and how the capacity relates to the level of delays due to serving other passengers en-route.

Any more varieties of DRT out there?
permalink

Home » Public Transport Data » Demand Responsive Transport



Powered by AspNetForum v.6.0.2.0 © 2006-2009 Jitbit Software