1 developing the technology for a shared demand … · 2018-08-25 · 1 developing the technology...

DEVELOPING THE TECHNOLOGY FOR A SHARED DEMAND RESPONSIVE 1TRANSPORT SYSTEM AT THE UNIVERSITY OF MALTA 2

3Prof. Maria Attard 4Institute for Climate Change and Sustainable Development 5OH132, University of Malta, Msida MSD2080 6Tel: +356 2340 2147 Email: [email protected] 7 8Prof. Adrian Muscat 9Department of Communications and Computer Engineering, Faculty of Information and 10Communication Technology 11University of Malta, Msida MSD2080 12Tel: +356 2340 2162 Email: [email protected] 13 14Mr Michael Camilleri 15Institute for Climate Change and Sustainable Development 16University of Malta, Msida MSD2080 17Tel: +356 2340 3403 Email: [email protected] 18 19 20Word Count: words text 4,928 + 6 figures (250 words each) = 6,428 words 21

Submission Date: 31 July 2017 22

23

Attard, Muscat, Camilleri 2

ABSTRACT 1

Shared Demand Responsive Transport services are flexible services increasingly regarded as 2an adequate and modern response to meet changing mobility demands. Research provides 3ample evidence from case studies, as well as the development of technological innovations to 4cater for and support such services. In Malta, Shared Demand Responsive Transport Services 5were already found to fill a gap as a mid-market alternative to the private car. The University 6of Malta is the highest teaching institution and home to a daytime population of 15,000 7people, similar in size to any large town in the islands. The University is located at the centre 8of the island and adjacent to main roads. Complex travel patterns, aggregated in a small area, 9and restrictions on provision of car parking provided an opportunity for the team to develop 10the technology for a Shared Demand Responsive Transport System which is tailor-made to 11the mobility characteristics of the University. This paper provides a background to the case 12study and describes the development of the technology. Test results carried out at the 13University of Malta are presented in view of key service level parameters. The study found 14that the cost of the service is approximately double the cost of local buses, which cost 15difference is attributed to quality of service improvements. Overall the project demonstrates 16that ICT enabled demand responsive transport systems are feasible from both a technological 17and cost point of view. Such systems promise to deliver mobility solutions that compete very 18well with private car ownership and usage. 19

20

Keywords: Shared Demand Responsive Transport, University of Malta, ICT, technology, 21islands 22


1. INTRODUCTION 1

According to (1) the external cost of private and commercial traffic in the islands of Malta 2cost the economy €274 million ($322m) in 2012, which was equivalent to 4% of the GDP. 3Congestion was a major share of this cost with €118 million ($139m) estimated from delays 4on the network annually. Projections given a business as usual scenario, see congestion costs 5rise to €151million ($177m) by 2020. The concern over growing traffic congestion and the 6resulting impacts on the environment and public health have motivated the study team to 7develop and test the technology for a Shared Demand Responsive Transport System for the 8University of Malta, Msida Campus. This paper provides a background to the case study and 9describes the development of the technology. The results of the testing carried out at the 10University are included in the conclusions. 11

Shared Demand Responsive Transport systems are flexible services increasingly 12regarded as an adequate and modern response to meet changing demands for mobility in both 13urban and rural environments (e.g. 2, 3, 4, 5). These systems exist in the form of a range of 14local transport services which are complementary to conventional, scheduled passenger 15transport and provided by smaller buses, minibuses, vans, taxis and cars (Figure 1). These 16services normally act at a very local level and are either for the general public, or for specific 17user groups (e.g. disabled or elderly). Assessed benefits and impacts include: 18

- flexible routing services allow access throughout an area rather than on specific, 19fixed corridors and thus the coverage of the service is wider; 20

- improved mobility and access to services; 21- cost-effectiveness of the services encourages increased service level provision, 22

increased usage, and creates a sustainable virtuous cycle of improvements; 23- for locations with a strong tourist dimension, improved and flexible public transport 24

encourages tourism without cars; and 25- improved mobility generally increases the level of economic activity in the area. 26 27

28 29 30 31 32 33 34 35 36 37 38 39 40 41 42FIGURE 1 Demand Responsive Transport Services. 43

44The technology that supports Shared Demand Responsive Transport services has also 45

been researched with (5, 6, 7) defining level of service parameters as critical in resolving the 46dial-a-ride problem using machine scheduling and dispatch (8). Others have looked at the use 47of simulation in system design (9). More recently (10) has looked specifically at the role of 48technology not only supporting these services but also changing their market feasibility in 49


terms of new scheduling approaches and optimization algorithms to implement the demand 1adaptive service (flexibility in pick-up and drop-off) and the possibility to reconfigure 2dynamically in real-time. 3

Based on this and other research outputs from the EC funded projects SAMPO and 4SAMPLUS (11) and case studies from Florence (12) and Braga (3), (13) presented a study on 5the feasibility of a Dial-a-Ride Dynamic Shared Taxi System for Malta. The study concluded 6that in terms of level of service and considering (i) seven passenger vehicles in service, (ii) 755% mean vehicle occupancy, (iii) a 100km2 service area, and (iv) 40 vehicles in service, the 8mean increase in trip time over car is 30% and mean waiting time is 9 minutes. In terms of 9the cost, the research found that it compared very well to the comprehensive cost of the 10private car. Finally the research demonstrated that Shared Demand Responsive Transport 11services fill a gap as a mid-market alternative to the private car. 12 13

2. THE CONTEXT 14

Malta is a small island state in the centre of the Mediterranean Sea covering an area of 15316km2 and split between three main inhabited islands. Malta has the highest population 16density amongst all EU member states and is the third country in the EU with the highest 17number of passenger cars per 1,000 inhabitants (14). With just under half a million resident 18population and over 1.5 million tourists visiting the islands each year, the transport 19infrastructure is under constant pressure. The public transport system is primarily serviced by 20conventional buses, private coach and minibus services, taxis and ferry services in the port 21area around the capital city Valletta and connecting the two main islands of Malta and Gozo. 22Despite this, 75% of all trips are carried out using private vehicles and only 11% are made 23using public transport (15). Efforts at local level to reduce and remove pedestrian walkways 24and the lack of cycle lanes in favour of ever-increasing demands for car parking spaces have 25exacerbated further the situation in many parts of the islands. 26

The University of Malta is the oldest and highest teaching institution in the islands. 27Located in Msida, in the centre of the urban agglomeration, it attracts a daytime population of 28over 15,000 people including students, administrative and academic staff, and visitors. The 29University is located alongside the main arterial road linking the islands from the North to the 30South and an important bypass linking the University to the West and North West (Figure 2). 31The movements to and from the Msida Campus have a significant impact on the islands’ 32transport network and on Malta. The University population is concentrated in specific areas 33of the islands which provides ample opportunity for use of alternative transport modes. Car 34dependence amongst the University population however is evident with 76% reporting the 35use of the private vehicle as one of the means to travel to and from the University. Public 36transport use is mentioned by 32% and walking is mentioned by 22% of the population. 37Cycling is an option for just 4% (16). The survey aimed to establish the various modes 38students and staff travelled to university, allowing for individuals to choose more than one 39transport mode. This allows for a complete picture with regard to the transport modes used in 40general, rather than tied to specific trips or days. 41

This dependence on the car by the overall population (including students) leads to 42capacity problems on the surrounding network and within the University where issues of 43parking, safety and pollution are regularly mentioned across the university community, by the 44administration and the local media (e.g. 17). The University provides just over 1,500 free 45parking spaces, distributed among students (46%), academic staff (35%) and administrative 46staff and visitors (19%). A 2006 local plan restriction also prohibits the University from 47increasing parking capacity in an attempt to reduce possible increase in car traffic on the 48surrounding network, which suffers from capacity problems (18). 49


A further assessment of the characteristics of the University of Malta, Msida Campus 1showed that the greater part of the university population lives relatively close to the campus, 2with a good majority (over 60%) ready to use public transport if it were faster and more 3reliable and around 40% interested in using dedicated/organised transport. A survey of traffic 4patterns in and out of the campus show morning and afternoon peak hours when 5administrative staff start and finish work and a constant level of traffic to and from the 6campus throughout the rest of the day (typical of staff and students with varying schedules). 7These descriptors fit the service characteristics identified in our earlier research (13) and a 8proposal for developing the technology to test the feasibility of a Shared Demand Responsive 9Transport system at the University was put forward for funding. 10

The project aim was therefore to develop and test the technology (software and 11hardware) for a Shared Demand Responsive Transport system that would reduce the impact 12of car travel to and from the University, encourage community building between members of 13the University, and contribute to the reduction of the University’s carbon footprint. This is the 14first system developed specifically for islands university communities, tailored according to 15specific mobility and geo-demographic characteristics. 1617

FIGURE 2 Malta’s built up areas, the location of the University of Malta, Msida 18Campus and the study area for the Demand Responsive Transport System. 19

20

3. PROOF OF CONCEPT IMPLEMENTATION 21

The Shared Demand Responsive Transport System project involved a holistic hardware and 22software solution for implementation. From the hardware standpoint, a central computer 23tasked with the scheduling and automatic dispatching control software was located at the 24University. This was supplemented with an in-vehicle terminal, which for this proof-of-25


concept implementation involved an Android Table with 4G Data capabilities for constant 1communication with the server. At the same time, another Android mobile device served as 2the customer terminal, used for testing and generation of the user demand. 3 4

Alongside the hardware components, software development, most of which was done 5in-house focused on these closely related schemes: 6

- The Server Software which ran on the central computer and handled all the 7scheduling and dispatching operations. This was the main contribution to the 8project. 9

- The Simulation framework used for preliminary testing as well as demand/traffic 10forecasting. In this case AIMSUN was used. 11

- The Driver-Information Software, running on the in-vehicle terminal (tablet). An 12Android application was developed and tested. 13

- A Client Application, running on a smart phone developed (initially) for the android 14market. 15

16

3.1 Transport Optimisation Framework 17A key component of the project was to further research into Demand Responsive Transport. 18To this end, the researchers invested time in the design and implementation of the tRanspOrt 19optiMisAtioN (ROMAN) framework. This library and accompanying set of tools was 20designed in-house to provide a flexible and modular approach to development the system and 21other such similar applications. 22 23

The ROMAN library co-ordinates all aspects of the communication and scheduling 24processing of the project including: 25

- handling users who connect to the system, requesting a service (pick-up and drop-26off); 27

- managing the state of active requests and maintaining a historical reference to all 28requests; 29

- handling the fleet of vehicles which are in active service or idle; 30- provide state sharing and communication between the different components that 31

make up the entire system; and 32- provide databases for billing and resource management. 33

In the interest of modularity/efficiency, the system is written in C++, making use of 34polymorphic constructs to provide a plug-and-play architecture of the various components. 35

The core functionality of the system deals with requests from users. From the user’s 36point of view, the following process is traversed: (1) The user connect to the system either 37through an online portal or through a mobile application; (2) The user (once verified) 38indicates the pickup and drop-off point required, together with appropriate time-windows and 39the request is sent to the central system; (3) The system processes the request and responds 40either with an offer or an indication that the request is infeasible (we refer to this as a request 41being Blocked or Rejected); (4) If the latter is the case, the process terminates. Otherwise the 42user can choose to accept or reject the offer. If the offer is rejected, the process terminates 43here; (5) Otherwise the user is directed to the pick-up location, from where at the specified 44time (within bounds) the vehicle arrives to pick him/her up; (6) The user is ferried to the 45drop-off point, at which point s/he disembarks the vehicle. 46

On the other hand, the sequence of events from the perspective of the other agent in 47the system, the vehicle (or vehicle driver) are as follows: (1) The vehicle starts off the day at 48the depot in an Idle state: (2) The driver indicates that he is idle and waits on the system to 49


schedule a pickup/drop-off location to travel to; (3) Once the next node is confirmed, the 1driver travels to the particular node; (4) On arrival, the service operations scheduled for this 2node are performed, which may constitute a number of passengers boarding and 3disembarking; (5) The driver waits at this location until the next node is confirmed and then 4the process repeats from (3) or until his/her work-shift is over. The interaction between the 5user, chauffeur and central system are displayed in Figure 3. 6 7 8 9 10

FIGURE 3 Conceptual System Overview. 11 12

3.2 In-Vehicle Terminal 13The in-vehicle terminal application was implemented as an application on an Android Tablet. 14The terminal informs the driver of the schedule assigned, directing the vehicle to the next 15serviceable location in turn and allows the driver to communicate back to the system the state 16of pick-ups and drop-offs: the vehicle location is also automatically transmitted, allowing the 17system to update time predictions. 18

In order to avoid inundating the driver, as well as providing flexibility, the in-vehicle 19software (Figure 4) highlights only the next node to visit, whilst the list of jobs to service at 20the node are displayed on the right. It also highlights a suggested route to follow to the 21destination. Once the user clicks on the Driving button (top right) the view changes to a 22navigation style and the vehicle icon follows the progress of the vehicle. Once the node is 23reached, the view changes automatically to servicing mode. The driver must explicitly click 24on a pick-up (with an option to list as no-show) and drop-off: after all jobs have been 25serviced, the driver is directed to the next node and so on. 26

273.3 The Customer Interface 28A Customer Interface application was developed to allow for customers to request a service. 29This supplements the synthetic request generation to trial with the complete system. The 30request generation application (named Retriever) provides a minimalist interface to allow a 31user to issue requests to the system. Since this is a proof of concept implementation, the app 32displays the current service area and the serviceable hotspots, rendering it useful in a field-33test setup. In any case, the user is able to select a pick-up/drop-off point by clicking anywhere 34on the map, specifying the desired location, time and the number of passengers which would 35be travelling together. Once the client is satisfied with the form of the request, s/he sends the 36request to the server, and within a short time, the system replies with either an offer of service 37


(to which the user must decide to accept or reject) or an indication that the request is 1unserviceable. If the user chooses to go ahead with the offer, s/he is regularly informed of the 2proximity of the servicing vehicle. 3

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

FIGURE 4 In-vehicle terminal application showing the route. 19 20

4. TESTING AND RESULTS 21

The system has been tested for functionality and for operational performance. Tests have 22been carried out on the field as well as in a simulation setup. Demand was generated either 23manually (using the Retriever mobile app) or through a purposely-developed demand model, 24based on the university's Green Travel Plan data, with all requests starting or terminating at 25the University Msida Campus. 26 27

4.1 Measurements in the field 28The field tests were carried out using real-world vehicles while the demand was simulated. 29The aims of these tests were to provide a proof of concept of the implementation with the 30system functioning under real-world conditions and provide real-world statistics of certain 31key parameters, such as user waiting time, blocking rate and so on. Due to the nature of the 32tests and the time constraints of the project, the test and experiments weighed more heavily 33on the first aim. 34 Each test employed two personnel per vehicle (a driver and a researcher) in addition 35to an operator (another researcher) at the control center. The test commenced with the driver 36transitioning to the depot location at which point, the operator turns on the DRT server 37system and the in-vehicle terminal is connected. From then on, the automatic scheduler takes 38care of providing waypoints to the driver, until the route is completed, at which point the 39driver is directed back to the depot location. Tests were organized in batches, with each batch 40constituting a similar set of runs taking place on one day. 41 The overall measured mean waiting time is 8.51 minutes with waiting time varying 42between 5.6 minutes during low traffic and 11.4 minutes during moderate traffic. It is also 43instructive to look at the deviation between the promised and actual pick-up times, since this 44is a clear indication of the quality of service of the system. The overall mean pick-up time 45


error is 4 minutes. This varies from 1.5 minutes in low traffic and 6 minutes in moderate 1traffic. Slightly longer times are reported for drop-off time error (6.5 minutes overall, 2.5 2minutes at low traffic and 10.6 minutes at moderate traffic). 3 Service costs were also calculated with operational costs based on current market 4prices for all the parts of the system including vehicle fuel, salaries, IT systems, and profit 5margin. The cost to the end user is dependent on how many customers are serviced. A flat 6rate is assumed and the cost varies in between €2.40 ($2.82) and €7.00 ($8.22) per trip. 7 8

4.2 Simulations 9While the field tests were useful to test the functionality of the system as well as to validate 10the network model used, its applicability in providing an accurate estimate of costs and 11service quality was limited due to the small size of the experiment which in turn is limited by 12the economic and timely costs associated with running a series of full-scale experiments. 13Simulation studies were therefore carried out using the AIMSUN simulator in place of real-14world network and vehicles, together with an in-house developed interface to provide the 15necessary interaction and control. This allowed the system to be tested with a large number of 16vehicles and for extended periods of time. 17

The set up follows a similar configuration to that of the field tests. The simulation 18time starts 10 minutes before the first route schedule. After a time-synchronization procedure 19between the server and the AIMSUM simulator, we start demand generation (30s after 20synchronization). This allows for some requests to already be in place when the route starts. 21From then on, the same scheme takes place as for the field tests, albeit with simulated ones. 22The simulator also models requests servicing times at pick-up and drop-off nodes using a 23crude estimate. Each simulation run covers a period of about 4 hours, plus the warm-up 24period already mentioned and the time for the last vehicle to service the last request. The 25same service area is used but with a focus on one route and simulating the morning run on a 26Monday between 07:00 and 11:00 (with correlated peak traffic). The same demand model is 27also used but restricting the requests to the general area of the chosen route. 28

An important difference in the simulation runs was the choice of modeling the fleet. 29First, instead of defining a single depot, vehicles are effectively ‘spawned’ at initial servicing 30locations. This is akin to having an automated dispatcher which is able to cater for the travel 31time and dispatch the vehicle ahead of time to the start location. This assumption allowed us 32to estimate vehicle usage capacity solely while servicing and not while travelling idly. 33Second, there is an unlimited amount of vehicles. This assumption not only simplifies the test 34setup (since the scheduler now does not need to consider assigning multiple routes to the 35same vehicle), but it allows the system to compute how many vehicles would be needed to 36achieve a given quality of services, rather than be limited by a pre-set number of vehicles. 37

Using the numerical results the quality of service and cost to end-user are calculated. 38The overall percentage increase in trip time over the private vehicle (excluding cruising for 39parking and walking) is 26.48% with a standard deviation of 14.2. This means that the system 40operated very close to the 50% increase in trip time it was designed for, and for 88% of the 41customers the increase in trip length was less than 50%. Similarly when operating in the high 42demand scenario, the average waiting time is 13 minutes, with a standard deviation of 6 43minutes and within the 20 minute limit for most of the customers. The walking time average 44is 4.5min and the actual pick-up error average is 2.2 minutes with a standard deviation of 1.5. 45The actual drop-of error is 6.5 minutes on average, which is quite high. This is due to the fact 46that the system in its current form is not taking into consideration any future pick-ups that 47will delay drop-offs. 48

The cost to the end user (based on current market prices for all the parts of the system 49


including, vehicles, fuel, salaries, IT systems, and profit margin) is plotted in Figure 5. A flat 1rate is assumed and the cost varies in between €2.30 ($2.70) and €5.20 ($6.11) per trip. The 2former is doable if operations are characterized by high vehicle occupancy, while the later 3indicate very low vehicle occupancy. Blocking is defined here as the state of when there is no 4more capacity to service new requests. This chart is useful when trading off blocking with 5cost of trips. For example if such a DRT system is used as a first option for travel by a user 6prior to considering other modes, then the operator can operate at a high blocking rate. The 7cost per user is higher if a smaller capacity vehicle is used and lower if a higher capacity 8vehicle is used. However, the higher capacity the vehicle is, the less personalized the service. 9If we choose the operating point at the elbow of the graph, the cost for each trip is €3.30 10($3.87). 11

12 13

FIGURE 5 Cost per trip per customer versus blocking rate (simulation) assuming cost 14of vehicle and operations are €52 ($61) per hour for a 10-seater, and €68 ($80) per hour 15for a 16-seater vehicle. 16 17 Figure 6 shows the Cost versus Quality of Service trade-off as the system parameters 18are varied. The system parameters comprise vehicle capacity (C), density of service points 19(D), frequency of corridors (F) and vehicle occupancy (O) which in turn informs blocking 20rate. In the extreme operating point depicted in the bottom left corner, the system will look 21like a public transport system with the option of pre-booking seats. On the other hand the 22extreme point in the top-right corner depicts a taxi system. A well designed Shared Demand 23Responsive Transport service would fall in between these two extremes and fall within the 24ellipse defined by the other operating points (depicted in red). 25 26

5. CONCLUSIONS AND FUTURE WORK 27

The project has implemented a functional prototype that can be deployed in transport 28operations. The system comprises the server software, the in-vehicle software and a basic 29user mobile application. Field tests proved that the system works as expected in real-time, 30with the timely handling of events. With suitable add-ons and upgrades (for example the user 31app and a billing system) the system can be adapted for a commercial setup. 32

Results from the field tests, as well as the simulation runs yielded the mean waiting 33


time, pick-up time error, drop-off time error and the user cost versus blocking rate. The latter 1gives an indication of how cost can be traded-off with quality of service (defined by waiting 2time, walking time and percentage increase in trip time) offered. From the results obtained we 3conclude that the DRT system studied is a feasible alternative to the use of the private car for 4commuting to and from the university, which institution is characterized by a significant 5turnover in travel behavior throughout the day. 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26FIGURE 6 Cost versus quality of service, where font sizes are representative of the 27magnitude of each parameter. The red dots show examples of typical operating points. 28

29In the system, the corridors and their respective boundaries have been manually 30

engineered from the travel data available. This means that an operational setup will require 31the services of data scientists, who will use demand data and data from other sources to plan 32corridors, service charters, determine system parameters such as composition and size of 33vehicle fleet, and billing model. In summary the operational team will include at its heart 34both IT system engineers and data scientists. 35

The feasible cost of the service is approximately double the cost of the local public 36transport system and approximately 35% higher than local scheduled school transport rates. 37The cost difference with the public transport system is due to the superior quality of service, 38whilst the difference when compared to school transport is due to the latter being essentially a 39pre-booked system with high vehicle occupancy and preset times (as opposed to more 40flexible requests in the case of the demand responsive transport). 41

Overall this project has demonstrated that ICT enabled demand responsive transport 42systems are feasible from both a technological point of view as well as from a cost point of 43view. Such systems promise to deliver mobility solutions that compete very well with private 44car ownership and usage. 45

46

ACKNOWLEDGEMENTS 47

We would like to acknowledge the Vodafone Malta Foundation - Connecting for Good 48Program for their support in developing this project. 49


1

REFERENCES 2

1. Attard, M., P. Von Brockdorff, and F. Bezzina. The External Costs of Passenger and 3Commercial Vehicle Use in Malta. Technical Report. University of Malta – European 4Commission Representation in Malta, 2015. 5

2. Davison, L, M. Enoch, T. Ryley, M. Quddus, C. Wang. A survey of demand responsive 6transport in Great Britain. Transport Policy, Vol. 31, 2014, pp. 47-54. 7

3. Ribeiro, P., V. Rocha. Flexible public transport in low density urban areas. Recent 8Advances in Engineering Mechanics, Structures and Urban Planning. 2013, pp. 169-174. 9http://www.wseas.us/e-library/conferences/2013/CambridgeUK/STUPEME/STUPEME-1000.pdf. Accessed July 28, 2017. 11

4. Enoch, M., S. Potter, G. Parkhurst, M. Smith. INTERMODE: Innovations in demand 12responsive transport. UK: Department for Transport and Greater Manchester Passenger 13Transport Executive. 14

5. Nelson, J. D., T. Phonphitakchai. An evaluation of the user characteristics of an open 15access DRT service. Research in Transportation Economics. Vol. 34, 2012, pp. 54-65. 16

6. Chandra, S., L. Quadrifoglio. A model for estimating the optimal cycle length of demand 17 responsive feeder transit services. Transportation Research Part B. Vol. 51, 2013, pp. 1-1816. 19

7. Chandra, S., L. Quadrifoglio. Critical street links for demand responsive feeder transit 20services. Computers and Industrial Engineering. Vol. 66, 2013, pp. 584-592. 21

8. Chevrier, R., A. Liefooghe, L. Jourdan, C. Dhaenens. Solving a dial-a-ride problem with 22a hybrid evolutionary multi-objective approach: Application to demand responsive 23transport. Applied Soft Computing. Vol. 12, 2012, pp. 1247-1258. 24

9. Quadrifoglio, L., M. M. Dessouky, F. Ordóñez. A simulation study of demand responsive 25transit system design. Transportation Research Part A. Vol. 42, 2008, pp. 718-737. 26

10. Teal, R. F. Technology changing market feasibility. In Paratransit Shaping the Flexible 27Transport Future (C. Mulley, J. D. Nelson, eds.), Emerald Group Publishing Limited, 282016, pp. 333-356. 29

11. Ambrosino, G., M. Boero, P. Eloranta, D. Engels, B. Finn, P. Sassoli. Flexible Mobility 30Solutions in Europe through cooperation between, operators, IT Suppliers and authorities. 31Proceedings of the 7th World Congress on Intelligent Systems. 2000. 32

12. Ambrosino, G., J. Nelson, M. Romanazzo. Demand Responsive Transport Services: 33Towards the Flexible Mobility Agency. ENEA (Italian National Agency for New 34Technologies, Energy and the Environment), 2003. 35http://www.enea.it/en/publications/volume-pdf/V2004-Demand_Transport_Services.pdf. 36Accessed July 28, 2017. 37

13. Muscat, A., M. Attard, K. Scerri. The feasibility of a Dial-a-Ride Dynamic Shared Taxi 38System - A case for Malta. Presented at the Royal Geographical Society Annual 39International Conference, London, 2013. 40

14. Eurostat. Motorisation Rate: Cars per 1 000 inhabitants (tsdpc340). 41http://ec.europa.eu/eurostat/tgm/graph.do?tab=graph&plugin=1&language=en&pcode=ts42dpc340&toolbox=type. Accessed May 22, 2017. 43

15. TM (Transport Malta). National Transport Strategy 2050, Transport Malta, Malta, 2016. 4416. University of Malta. CAMP sUmp - sustainable mobility project at the University of 45

Malta. Newspoint 25 July, 2017. 46https://www.um.edu.mt/newspoint/news/features/2017/07/campsump-47sustainablemobilityproject. Accessed July 28, 2017. 48


17. Micallef, K. University hits the brakes on planned underground car park. Space under 1planned new block will be used for laboratories instead of parking. Times of Malta, 2017, 24 July https://www.timesofmalta.com/articles/view/20170704/local/university-hits-the-3brakes-on-planned-underground-car-park.652333. Accessed July 28, 2017. 4

18. Planning Authority. North Harbour Local Plan. Planning Authority, Malta. 2006. 5http://www.pa.org.mt/en/local-plan-details/north-harbour-local-plan. Accessed July 29, 62017. 7

1 developing the technology for a shared demand … · 2018-08-25 · 1 developing the technology...

Documents