Ride2Rail: integrating ridesharing to increase the attractiveness of rail travel

Shared travel offers an important way to increase the accessibility of rail services. However, providing an integrated shared travel capability for rail travel is both a conceptual and technical challenge. This paper presents an overview of Ride2Rail, enabling ‘Easy use for all’ of rail through ridesharing as part of a multimodal journey. Ride2Rail has the overall objective of developing intelligent multimodal mobility, by facilitating the efficient combination of flexible and crowdsourced transport services, such as ridesharing, with scheduled transport. A requirements activity has set out the travel behaviour and system requirements for Ride2Rail. Development activities have covered the technical implementation of Ride2Rail, involving both development of the Ride2Rail functionalities and the Ride-2Rail Driver Companion application, integrated within the wider Shift2Rail ecosystem. Demonstration activities have involved the preparation, implementation, execution and monitoring of Ride2Rail at four demonstration sites. This paper outlines the overall approach and findings of the Ride2Rail. This demonstrates the technical feasibility of integrating shared travel, including the architecture for a shared ride capability that can be readily integrated into pre-existing Mobility as a Service (MaaS) platform. Additionally, the paper reports positive user attitudes to this kind of shared travel, within the context of multimodal trips.


Introduction
Rail travel is a key enabler of a decarbonised transport future, particularly one that involves a growing number of people moving into and around urban centres [39].The Shift2Rail programme (and its successor, Europe's Rail) is accelerating the integration of new and advanced technologies in order to increase the competitiveness and attractiveness of rail in Europe and thus promote greater adoption of lower-carbon travel.A key Innovation Programme (IP4) of Shift2Rail is to provide solutions for attractive rail services, involving a number of technology developments such as a Travel Companion personal mobile application, and an ecosystem and Interoperability Framework to facilitate multimodal travel [25].This work aims to deliver a Mobility as a Service (MaaS) platform delivering seamless door-to-door travel and intermodal journeys, centred around rail travel.
Access to rail can be challenging, however, particularly in a rural environment, where there may be few options to connect with rail [41].This may also be an issue in urban, or peri-urban (i.e.urban-rural fringe [ [34]]), environments where there may be poor provision of public transit [24].Globalisation and changing travel patterns have increased the need for flexible mobility.Urban sprawl and dispersed land-use patterns strengthen individual mobility behaviours, particularly in rural/lowdemand areas, consolidating the dominance of private cars [10].COVID-19, coupled with escalating fuel prices, is encouraging hybrid working patterns [19] where car use (and ownership) can be reduced and instead travel is accessed as it is needed [6].
Mobility policies must therefore promote sustainable modes.The co-modality approach has proven to be effective and ridesharing has emerged as an viable practice thanks to mobile technologies.Ridesharing should be encouraged as a tool for reducing the overall distance travelled by private vehicles and as a high-capacity transport feeder.Ridesharing is based on regular pre-arranged trips allowing drivers and passengers to find potential sharers.They often include community-based trust mechanisms and links to social media [3].Real-time ridesharing technologies are emerging and technology has been piloted in several cities, but demand for instant ridesharing is still relatively limited due to a lack of critical mass, and a set of barriers (poor awareness of services, lack of trust and willingness to ride with strangers, low flexibility in scheduling) limit ridesharing market uptake [13], Ride share into transit is already an established, if niche, mobility option [33,36] and formalising and integrating rideshare into end to end journey planning and ticketing tools has the potential to increase the market of this mobility option.A key enabler is to provide a technological means to directly integrate shared travel services within the context of a wider travel service eco-system, or Mobility as a Service platform.Successful technical integration would deliver a seamless application use experience, and thus lower the friction associated with shared asset usage [21] for both passenger and driver, while ensuring that end-to-end journeys can be realised and managed within a robust architecture.Critically, this is not just about encouraging a shift from car to rail, but as much about enabling those without nearby access to rail by providing a first and last mile, peer generated travel connectivity.In this way, ride share is not a competitor to, say, mobility on demand, but rather an additional mode within the portfolio of any given MaaS offering.Moreover, it is not intended as necessarily a complete replacement for the private car, but as an option that further facilitates the move away from the private vehicle [2].Providing such a service does, however, involve the challenge of ensuring that individual providers of transport (i.e., individual drivers offering lifts) can be technically accommodated in a more traditional transport system.It also needs to be usable for both rider and passenger alike [1].
Ride2Rail (H2020-Shift2Rail-881825, www.Ride2 Rail.eu) aims to overcome these barriers to ridesharing adoption.The Ride2Rail vision is to exploit intelligent mobility approaches making ridesharing a feeder for mass transport services in low density/rural areas, deviating current demand from individual to collective mobility, improving transport accessibility.These capabilities are integrated within a wider Mobility MaaS platform.This is the wider Shift2Rail IP4 ecosystem, as experienced through the Travel Companion-a single point of contact for planning, ticketing, proof of purchase, and replanning in the event of disruption, across multiple transport service providers.
The following paper describes this work by presenting an iterative process of development, starting with requirements from the potential user base, which then inform technical design, which was then evaluated and improved upon through cycles of demonstration using a living lab approach [35].The paper offers the following contributions: 1) A description of the requirements and choice criteria for ridesharing decision making.2) A description of the technical architecture to support shared travel, and elaboration on the digital service elements required for a ride share service that can be readily integrated into pre-existing mobility services.3) Demonstrator evaluation of the solution through a living lab approach at four locations.
Together, these three contributions present a wholelifecycle approach to the integration of ridesharing within a larger Mobility as a Service offering.
The paper is written as follows.Section 2 covers background to the work.Section 3 gives the overall approach.Section 4 covers requirements work and technical implementation.Section 5 describes the methods and results for the live demonstrations, while Sect.6 discusses outcomes.Concluding comments are offered in Sect.7.

Background
During the last decades, globalisation, mobile and sharing economic trends increased the need for mobility and worldwide the car has a predominant role with a stable (still very high) share in most developed countries and an increasing penetration in developing countries [10].In addition, there has been unprecedented urban sprawl and dispersed land-use patterns, such as the large developments of extra-urban housing, dominance of big malls, and the consolidation of service centres into fewer, larger units [39].This has strengthened individual mobility behaviours, particularly in rural and low-demand areas, consolidating the car as the most preferred transport means and correspondingly harming the quality of collective transports.
Mobility policies should therefore deal with attentive urban planning, aimed at reducing the need for travel, when possible, and, as second step, promoting more sustainable transport modes.For the latter, the co-modality approach is an important tool, by linking traffic demand to high-capacity transport modes and better exploiting their full potential, reducing consequently the share of traffic currently addressed by individual private mobility.Among transport demand management with a co-modal approach, an ever-increasing role is played by ridesharing (also known as lift-sharing in the UK and carpooling in various EU countries), which has emerged as an effective practice also thanks to mobile technologies facilitating social and matchmaking mechanisms [1,14].This approach should be encouraged by considering it as a key factor in reducing the overall distance travelled by private vehicles and a formidable feeder for high-capacity transport services.Also, opportunities for ridesharing change in response to various life events (an accident that reduces mobility, the birth of a child, a change in job, for example) [30].There are also some indications [5,8] that lift sharing is more attractive to female users, and to older users, therefore suggesting a slightly different demographic from cycle sharing or car clubs.
Despite its significant potential, ridesharing has demonstrated limited uptake so far, because of a set of barriers such as insufficient awareness of dedicated services, lack of trust and willingness to ride with strangers, need for flexibility in scheduling to allow and cope with change in plans and uncertainty in reaching agreements on sharing costs [13].
Practical experiences tackle the challenge by showing that most formalised ridesharing is based on regular prearranged trips organised through matching organisations that allow drivers and passengers to find potential sharers.To overcome such barriers of traditional schemes, Correia and Viegas [7] proposed studying a ridesharing club model with two main new features: establishing a base trust level for ridesharers to find compatible matches for traditional groups, and at the same time allowing users to search for a ride in an alternative group when the pool member has a trip schedule different from the usual one.Ridesharing can often include community-based trust mechanisms, such as user-ratings, and provide links to social networks to allow prospective sharers to examine each other.Among these experiences, real-time ridesharing technologies are emerging for facilitating instant matching between drivers and passengers with similar itineraries.This technology has been piloted in several cities, but the demand for instant ridesharing is still relatively limited because of lack of critical mass with similar complete itineraries,in this regard, new mobile technologies are potentially a tool for enabling services, but not for attracting more demand.
Usability and ease-of-use is critical to the success of ridesharing.A review of early on-demand ridesharing technologies [22] found the basic usability of a number of schemes was a major barrier to their adoption.Proposals for ridesharing technology highlighted considerations such as the structure required to submit matching requests [9,40], and the use of multiple platforms [40] as important design considerations for ridesharing technology (see also [13]).
Usability extends beyond the functionality of ordering a trip.The mobile app is overwhelmingly the most common way to register and pay for shared travel services, and this is an aspect of the service that is often overlooked [11].Janashani et al. [17] and Fishman et al. [12] found usability factors for a shared bike scheme included specific concerns around the ease of registration.A lack of clarity around features such as smart routing, registration or peer-to-peer coordination have proved to be significant barriers to shared travel app adoption [1] and comprise part of the overall 'friction' of using a service which may impede uptake [21].This is important given that purely rational motivations (i.e., cost and time) have limited impact on moving people out of private cars and into alternative sustainable modes, and demonstrating the emotional and aspirational benefits of modal alternatives is seen to be critical to mode shift [35,37].
As widely recognised, ridesharing, if properly developed, has the potential to reduce the number of single occupancy vehicles.The vision of Ride2Rail is therefore to exploit intelligent mobility approaches making Ridesharing an effective feeder for high-capacity transport services in less-densely populated and rural areas.The effects will be to deviate current demand from individual to collective mobility and even to potentially attract new demand (trips not executed), hence improving transport accessibility and reducing 'disutilities' for users [26].
The Ride2Rail approach is based on an inclusive vision of shared mobility within the transport network, supporting the access to individuals' travel offers and fully exploiting social leverages to make the service highly effective.This service model will make the Ride2Rail concept easily replicable at a European level.Such an activity requires three components:-1) Gathering of clear requirements and knowledge of user needs.2) Design of both an application, and underpinning algorithms, that provide maximum support to the user (e.g., through dynamic updates in times of delay).3) Evaluation with end users to understand both usage and acceptance.

Approach
Ride2Rail has the overall objective of developing an innovative framework for intelligent multimodal mobility, by facilitating the efficient combination of flexible and crowdsourced transport services, such as ridesharing, with scheduled transport.This framework integrates natively into existing collective and on-demand transport services, connecting and reinforcing the current mobility offer with ridesharing services especially in rural and low-demand areas, facilitating access to high-capacity services (rail, bus, and other public transport services) thanks to easy-to-use multi-modal and integrated travel planning, booking, ticketing, and payment features.
In the Ride2Rail context, 'natively' means that shared and peer-to-peer crowd-shared travel service providers (including private drivers) are integrated directly in the Shift2Rail travel offer ecosystem.In this way, the Shift2Rail ecosystem can query shared rides providers in combination with the other 'traditional' transport providers (e.g.rail and bus) and non-traditional providers (e.g.Mobility on Demand) to compute, compare and offer end-to-end mobility solutions.This is possible by enhancing the Shift2Rail 'Travel Companion (TC)' , developed by with Shift2Rail programmes, with innovative functions, tools and modules developed within the Ride2Rail project.The enhancements to the Travel Companion are also complemented by a Driver Companion (DC)-a dedicated mobile application that allows individual drivers to offer themselves as providers of travel, proposing origin/destination and time of availability.These offered trips are then visible to potential passengers to select through the Travel Companion.Therefore, a user is able to make a mobility request via the travel companion for a rail/public transit journey that can also include a rideshare to connect to, or to give onward travel from, the rail/transit journey.
The Ride2Rail framework integrates and harmonizes real-time and diverse information about rail, public transport and shared mobility in a single ecosystem, to allow users to compare and choose between multiple travel offers classified by a set of user-centric criteria including environmental impact, travel time, travel cost, and comfort.This involves a number of key challenges to fully understand the requirements of users to ensure that both drivers and passengers needs are aligned with the capabilities of the TC and DC.There are also significant technical challenges to ensure the data from the DC can be integrated into a pre-existing data ecosystem (the Shift2Rail TC and back office services) in a seamless manner.
The Ride2Rail approach has taken an integrated and iterative approach to development, based on user centred design principles [13,16].The technical development phase was grounded in careful examination of user requirements in context, achieved through extensive review of the state of the art in ridesharing knowledge and detailed user requirements capture and specification (see Sect. 4).This led to the main phase of technical development, which was then tested through a series of incremental demonstrations.
Transport Service Providers in four Ride2Rail demonstration sites (Athens, Greece; Brno, Czech Republic; Helsinki, Finland; Padua, Italy) have been integrated in the Shift2Rail ecosystem.This has given Ride2Rail a living lab to test how travellers and drivers use the enhanced Travel Companion and the Driver Companion to smoothly plan, book and execute a trip in their areas.A living lab is "a physical or virtual space in which to solve societal challenges, especially for urban areas, by bringing together various stakeholders for collaboration and collective ideation." (p.976; [15] and has been applied successfully to the understanding of ridesharing technology [1] 4 Design and development

Requirements
The requirements activity has used state-of-the-art analysis to conceptualize different potential travel offer categories to facilitate users in the comparison of travel offers and improve awareness of their selection.This analysis also identified the relevant preferences for users in ranking and filtering travel offers, and key aspects and mechanisms influencing traveller's behaviours and choices including the role of travel context.The analysis has also guided the conceptualization of incentive mechanisms to promote a specific travel offer over the others.More details on these contributions towards a more informed multimodal travel shopping are reported in Scrocca et al. [35].
The requirements activity has also used analysis to better understand ridesharing through an extensive review of definitions, ridesharing systems, legislation, and user characteristics.The legislative and regulatory framework related to ridesharing for the EU27 countries and the UK has been reviewed to understand potential barriers in ridesharing implementation.Furthermore, this research has provided the first characterization of four types of ridesharing users (i.e., household work user, solo work user, education user, and recreation/entertainment user), focusing on motivations and constraints that users may face when using ridesharing services.More details on this contribution towards a better understanding of ridesharing systems are described in Mitropoulos et al. [23].
The results of the state-of-the-art analyses have been validated through two conversational surveys, translated into 11 languages and distributed across Europe.The data collection on choice criteria, multimodal travel preferences, and expectations of over 600 European travellers has enabled the final release of the Ride2Rail conceptualizations and the identification of use-cases for the implementation of the Ride2Rail solutions.
The survey results regarding offer categorisations are in Fig. 1.A complete description of these categories and how the assignment of an offer to a given category should be computed is reported in Scrocca et al. [31].The highest-rated incentives are those that provide some sort of discount, with the exception of the discounts on complementary services.On the other hand, elements regarding either the environmental impact or the positive aspects of the trip (e.g.comfort) scored, on average, less than the money-related alternatives.Based on these results, the tangible incentive mechanisms (i.e., to encourage a user in choosing a given travel solution providing material or monetary benefits) outscore intangible ones (i.e., encourage the choice of a given offer employing benefits that have no material or monetary value) in almost every form they are presented.
The survey results have been used to define the Ride-2Rail catalogue of travel offer categories and to enable the implementation of an Offer Categorizer.This is a function that ranks and personalises offer criteria to meet travellers specific needs based both on their explicit preferences, and their trip history.Rather than computing an exhaustive list of all the possible offer categories, the goal of this catalogue is to elicit the ones that resulted from the survey as the most relevant to provide a comprehensive description of travel solutions in response to a request for a trip by a user of the TC.

Technical implementation
The development activities address Ride2Rail's technical needs while introducing a novel system to enrich multimodal travel solutions proposed through the Travel Companion, matching them to the user according to their preferences.Figure 2 shows a high-level diagram of the interactions of users with the various components of the technical infrastructure of Ride2Rail through various phases: (1) a driver inserts a new ridesharing offer through the DC (2) a traveller, using TC) searches for travel offers for their trip and (3) once they have found a suitable solution, the traveller books an offer.Finally, (4) driver and passenger share their ride, while the triptracking capabilities of the DC update the Shift2Rail ecosystem about delays and incidents during the ride.Ride2Rail has developed a series of software modules to support each phase of the aforementioned interaction.
A virtual Transport Service Provider, called the Crowdbased TSP (CbTSP), enables users to offer rideshares.The CbTSP follows the open-source reference implementation of the SocialCar project (https:// cordis.europa.eu/ proje ct/ id/ 636427) and implements the full trip provision interface of any other transport service providers, so that it can be integrated in the IP4 ecosystem.In this way, the CbTSP allows each traveller owning a vehicle to become a transport service provider by publishing a shared ride so that this shared ride offer can be considered in the trip planning phase for other travellers.Prospective drivers will use a new application developed by Ride2Rail, the DC to interface with the CbTSP.
Passengers looking for travel solutions will receive personalized results based on enriched data retrieved by Ride2Rail.A state-of-the-art Offer Categorizer enables the description of offers along the different categories identified during the requirements phase, evaluating each trip offer along several dimensions such as comfort, environmental friendliness, and health impact.This classification, in turn, makes possible the application of a recommendation algorithm that learns user preferences over time based on the users' travel choices.Users thus benefit from the enrichment of travel offers provided by the IP4 ecosystem and more personalized travel solutions over time.
This includes the "The Hybrid Offer Ranker" (THOR) [27], a hybrid, personalized recommender system for the transportation domain.THOR assigns every traveller a unique contextual preference model built solely upon their personal data, which makes the model sensitive to that user's choices.This model is used to rank travel offers presented to each user according to their personal preferences.THOR applies clustering algorithms to identify groups of travellers with similar profiles and build a preference model for each group.The THOR tool is capable of learning the contextual preferences of each traveller and ranks offers starting from those that have the highest probability of being selected.
Travel offers can be associated with incentives, i.e., benefits provided to users to encourage them to choose ecofriendly modes of transport, including public transport and shared rides.The Ride2Rail ecosystem also includes a state-of-the-art Agreement Ledger based on the HyperLedger Fabric technology that will track all interactions between drivers and passengers while guaranteeing the users' privacy and trust.The Agreement Ledger module incorporates smart contracts and APIs to ensure the reliability and integrity of the data on the ledger and assists in automatically solving disputes between drivers, travellers, operators, and service providers.The Agreement Ledger, its interfaces and smart contracts are based on an ontology for ensuring interoperability with the Shift2Rail MaaS ecosystem [28].
Finally, a lack of accurate information during times of disruption is known to be a major area of dissatisfaction with travel information systems, particularly in rail travel [20].Ride2Rail also incorporates a new trip time/ delay estimation mechanism used to detect if a disruption impacts a shared ride and prevents it from being on time.The procedure produces an initial estimate of the trip time, which is then adjusted as the trip proceeds, based on GPS data samples collected during the ride.The mechanism relies on several parameters, which are finetuned depending on the monitored context (e.g., the city in which the rides occur) [29].

Demonstration deployments
Ride2Rail has deployed the combined suite of travel offer classifications and software components, integrated into existing collective and on-demand transport services, in real-life mobility business cases.The advanced TC and the CbTSP have been deployed in three geographical areas: Athens (Greece), Brno (Czech Rep.) and Helsinki (Finland).A fourth demonstration has been successfully deployed in Padua, Italy, since the submission of this paper.Table 1 lists the characteristics of the four demo areas.These areas, and the target stakeholders in each area, have been selected to demonstrate that Ride2Rail can meet heterogeneous mobility challenges.
Participants have therefore been recruited from a wide demographic of users at each of the different locations.This has included students and working commuters, a wide range of ages and a gender balance.Critically, the demonstration had to also ensure that both drivers and passengers participate in the study.
The approach to demonstrations was iterative.Early demonstrations, particularly in Helsinki, focussed more on the usability assessment and acceptability of the DC and TC.Feedback from Athens and Helsinki was then integrated into both the design and the engagement/ deployment strategy used by Brno, which constituted a longer trial with a greater number of actual trips using Ride2Rail.

Athens demo
The Ride2Rail Athens demonstration took place in July, 2022 and lasted for a little more than one week.The main objective of this demo was to enhance the connection of low-density Attica Region areas to public transit modes, and specifically to the ATTIKO Metro, through the provision of demand-responsive ridesharing services.Both the DC and TC apps were tested, with an emphasis on categorizing offers and matching them to traveller needs.Before the demonstration officially kicked off, an engagement strategy led by CERTH was set up which included dissemination through websites, social media, etc., as well as a Stated Preference Survey organized and executed by ATTIKO Metro.

Helsinki demo
The Helsinki demo consisted of two parts: the first part was focused on testing an automated robobus as part of a multi-modal last-mile journey, integrated in the Helsinki regional authoritytravel planning application during a demo period of approximately two months (between October and November 2021).This involved over 1000 test users.The second part of the Helsinki demo was focused on testing the ride-sharing DC app, developed in the Ride2Rail project, in combination with the TC personal application.Both applications were tested for two weeks in October 2022 with a test user group of 20 persons.The functionalities used in the Helsinki demo were navigation, journey planner, trip tracking and group traveling.The service was most relevant to reducing the number of vehicles in the streets, allowing better connections with low demand areas not well served by public transport.

Brno demo
The pilot in Brno demo took place in the South Moravian Region in the Czech Republic during the first two weeks of November 2022.The demo focused on commuters travelling from the Znojmo district to the city of Brno, with the main objective to encourage those car drivers travelling alone to share the unused capacity of their cars with other travellers.Both the DC and TC apps were tested.In order to ensure the largest possible number of testers, an engagement strategy was implemented.
It included dissemination through leaflets in public transport vehicles, websites, social media campaigns.A total of 60 testers were involved in the demo totalizing 1946 journeys.The demo included the testing of demonstration scenarios with the selected testers under the supervision of project partners.The testers emphasized that apps are use-friendly and easy to use, there is integration of all transport modes into one travel solution and also the possibility to share rides and save costs.

Data collection
A key challenge of the project has been to ensure demonstrations are accurately and objectively measured and linked to the wider anticipated impacts of Ride-2Rail.While the diverse nature of demonstration sites allowedRide2Rail to be tested in a number of contexts, this requires performance to be measured in a consistent way across different settings.The evaluation activity has worked with demonstration sites to establish Key Performance Indicators (KPIs) and targets that are measurable across all locations.These cover measures of the general usage of Ride2Rail (e.g., number of users of Ride-2Rail) as well as specific measures of the type of trip (e.g., trips involving a rural origin / destination; trips involving multi-occupancy vehicles).A KPI monitoring methodology has been designed to capture anonymised, aggregated trip data from within the Ride2Rail ecosystem, within the requirements of General Data Protection Regulation (GDPR) and the ethical framework of Ride2Rail.This anonymous data was supplemented through a short on-line survey that has been implemented to capture factors such as trip purpose, perceptions of choice criteria, and traveller demographics from demonstration participants.The quality of the Ride2Rail user experience is measured through the application of the System Usability Scale [4], which has a proven record in both usability and in shared travel applications [41].

Survey results
In total, 93 users returned survey responses (16 in Athens, 17 in Helsinki, and 60 in Brno) for the three demonstrations completed at the time this paper was completed.

Demographics
Table 2 presents demographic data across the demo sites.

Journey characteristics
57 users were passenger only (only used the Shift2Rail TC enhanced with Ride2Rail functionality allowing them to request shared trips).13 were users of the DC only, acting only as drivers.23 used both the TC and DC.A total of 351 trips were recorded by survey participants (26 in Athens, 99 in Helsinki and 226 in Brno).Of these, 170 where shared trips using the travel companion (15 in Athens, 68 in Helsinki, 87 in Brno).

Offer category
Table 3 presents ratings of offer categories by survey participants, where 1 = most useful category, and 11 = least useful category.

Usability
Table 4 presents System Usability Scores, with average scores of 54% for the DC and 55% for the Ride2Rail enhanced TC.

Discussion
The key outcome of the work of Ride2Rail is to demonstrate that peer-generated rides can be successfully integrated into a wider mobility ecosystem.The ability for drivers to generate trips that can be accessed and utilised by passengers within the context of a wider public transit journey in a living lab environment validates the technical feasibility of the approach.Drivers can generate trips, these are presented to passengers through a pre-existing application environment (the Shift2Rail Travel Companion) and used as the basis for travel.Lessons learned from this process include the challenges with describing individual drivers as more conventional Transport Service Providers.They do not have conventional timetables, or fulfilment mechanisms in the manner that say a bus, train, or even taxi company might have.Therefore, it has taken some time to adapt the kind of journey offering presented by a private, individual driver so that it can be used within a wider ecosystem.Other challenges for the future include being able to orchestrate trips in such a way that both outward and return legs can be planned together, to ensure that a full round trip is confirmed from the outset of the journey.
Furthermore, and resonating with other work (e.g.[1,32], the usability of such applications is a significant factor.A key finding from Ride2Rail, both in qualitative comments from users and wider learnings of the demo partners, is the usability is a multi-faceted concept.It goes beyond the conventional notions of whether an application is easy to understand (i.e. are the visuals clear, can user requests be entered easily) to consider the wider representation of the transport system through the app in a meaningful manner.This becomes an increasing challenge with the maturity of apps and services such as Google Maps or in environments, such as Helsinki, with pre-existing travel apps.Users would make direct comments and comparisons with such production-level applications.Given the research nature of the project, however, it is satisfying that the DC received an overall usability rating above 50%, and the iterative nature of the project means that we continue to refine the usability of the app as we move to the final demonstration in Padua, Italy.
The survey data after the demonstrations also further verified the findings around the offer categorisation from the requirements phase.Users value functional and utilitarian aspects of shared travel above all others.The most important factors are that a journey should be quick, reliable and cheap.Other non-utilitarian factors such as panoramic journeys and even a social aspect are not so important to users.
From a methodological and evaluation standpoint, we noted some technical limitations that challenged our expectations around how to measure use of the apps.When an app has been built as a standalone system, then all of the data within that system is available to inspection (at least within the parameters of GDPR).In Ride2Rail, the embedding of our functions within the wider Shift2Rail ecosystems meant that potentially useful data was not available as this was within the control of conventional transport service providers (e.g.whether a trip had actually been completed), though we were able to overcome this somewhat through the use of a post-demo survey.Nonetheless, future iterations of Ride2Rail should strive to include mechanism to access wider ecosystem data, and other projects embedding functions within a wider ecosystem should be aware of this methodological issue.
One further limitation is that response rates for Athens and Helsinki would not support statistical analysis on their own.This was due to measures still being in place at the time of demonstrations to protect travellers from COVID-19, which posed major difficulties in terms of recruiting travellers.However, this is a medium Technology Readiness Level (TRL) project.Therefore, our intention was to take an iterative approach to development, starting with smaller trials and then using feedback on the usability from the application from the first demonstrations and apply learning in the larger Brno trial.The approach taken was therefore more in the context of iterative, used-centred design (something like ISO9241-210 [ [16]]) and testing the technical feasibility of the concept.Our aims were therefore not so much to compare against locations statistically but to improve and expand functions, usability and robustness for each demo site.Nonetheless, summative evaluation work in future could use larger  participant bodies to achieve this statistical rigour, and support comparisons between locations.

Conclusions
Integrated shared travel has the capacity to extend public transit networks, and to offer an additional means for end-to-end journeys within a Mobility as a Service (MaaS) platform.However, to make this work, any approach needs to be technically integrated with a preexisting transportation ICT ecosystem, and must deliver a usable, user-centred approach to organising and executing trips.Ride2Rail has addressed these problems by demonstrating the requirements and subsequent technical architecture to link ridesharing practice and public transport to deliver a crowd-based mobility network.This is achieved by the Ride2Rail framework for intelligent mobility that integrates and harmonizes real-time and diverse information about public transport and Ridesharing, facilitating the comparison and the choice between multiple options/services classified by a set of criteria, improving the individual travel experience.Ride2Rail addresses the current challenges of identifying criteria for multimodal travel planning addressing the existing barriers in Ridesharing practice, developing travel scenarios and testing related business cases.As such, it is a unique contribution in that rather thandemonstrating the technical of a standalone rideshare service, this work demonstrates the capability to deliver a rideshare component that is conceptually and technically integrated with a pre-existing ecosystem for Mobility as a Service.
The COVID-19 pandemic had two potentially negative impacts on the appeal of shared travel-first, that there would be a reluctance to share with strangers, and second that homeworking would limit the need to commute to the office.In practice, early indications are that commuting levels are returning to pre-pandemic levels [18].Furthermore, rising fuel prices resulting from global conflict and inflationary pressures may make the role of shared travel at least as appealing as it had been in the past [38].We note that even though our demonstrations took place after COVID-19, there was still strong indications of interest and acceptance from our participant base.This is emphasised in offer category analysis at both the requirements and demonstration phase that finds cost of trip is the most important criteria for trips.Therefore, economic benefits of shared trips must be clearly communicated.We also emphasise that while teleworking is on the rise, hybrid working is more common [19] and the kind shared/Public transport model covered by Ride2Rail may be even more relevant to this use case it is gives people a means out of car ownership for only a few commute journeys every week [6].Furthermore, there are many for whom full commuting is still a necessity (e.g.healthcare workers), and non-commuting applications (e.g.access to urban centres from rural locations [41]).
At this stage, anticipated benefits are to encourage carpooling (and ridesharing acceptance) as complementary for public transport, and to enhance the performance of the overall mobility system, reducing road congestion and environmental impact, reinforcing the mobility offer in rural and low-demand areas.In the final stages of Ride-2Rail, due to complete in April 2023, Key Performance Indicators will be used to determine the overall impact of Ride2Rail in key metrics including number of new rail trips generated, number of shared occupancy trips and reduction of CO2 through reduced road trips.Ultimately, the success of Ride2Rail will generate a key element of the overall Shift2Rail offering of delivering flexible, attractive multi-modal travel with rail at its heart.

Fig. 1
Fig. 1 Responses to travel offer categories (1-not likely to succeed > 5-very likely to succeed)

Fig. 2 A
Fig. 2 A high-level diagram of the user interactions with the Ride2Rail system (DC-Driver Companion; TC-Travel Companion; S2R-Shift2Rail; TSP-Transport Service Provider)

Table 1
Demonstration locations and characteristics

Table 2
Demographic data for demonstration users

Table 4
System Usability Scale scores as % for travel and driver companion