Handle overlapping server regions

[barbeau]

As discussed in #442 (comment), we need to examine a way to handle overlapping regions in OTP Android. This seems to be a particular issue when we have OTP servers that cover the same geographic region, but disjoint public/private transit agencies in each server that serve the area. The original multi-region concept was primarily intended to cover non-overlapping geographic regions, with the expectation that a single geographic region would consolidate all transit data for a region into a single OTP instance. So, this is somewhat of a departure from our original design.

Options:

1. Where there are overlapping server regions, force the user to pick a region/agency - Pros: Doesn't require complicated logic to resolve which region should be selected. If the user already knows which company/agency they want and the server agencies are disjoint, its a simple choice. Cons: Forces choice on the user, who may not be aware of the transportation options in the area, including which sites/agencies are available, what they are, cost-comparisons, etc., before they are even shown any trip options.
2. Get trip results from all overlapping regional servers and show them to the user - Pros: Doesn't force the user to choose, and presents the user with the best options given the available OTP servers. Cons: Requires logic in the mobile app to compare and rank trip results from multiple servers. We currently rely on the single OTP server that is selected to provide ranked trip results, which greatly simplifies the client. We could prioritize on simple trip characteristics such as total travel time, but we may end up showing near duplicate trips to the user if regional servers aren't entirely disjoint in their agency coverage. For competing agencies, this could also result in gaming the system, where one agency starts to show faster trips so their results are consistently shown to the user, when faster trips may not always be the best option for the rider due to other considerations (cost, etc.). We'd also need a way to more clearly label which results are from which agency/server. Its also not clear whether we should fairly represent results equally from all overlapping servers, or allow a single server to dominate all of the results shown to the user, if that one server regions the "best" top 3 results. In any case, we should avoid showing the user more than 3 trip choices to avoid overwhelming them.
3. Treat private/competing agencies differently than public agencies - Pros: The main challenge I see in the above is trying to fairly compare and present trip options from potentially competing OTP server instances while still keeping the UX simple. As a result, one option is to remove any for-profit competing OTP servers from the OTP server directory, to avoid this issue entirely. Cons: This doesn't resolve the issue for selecting regions with overlapping public non-competing agencies. It would also reduce the number of trip options shown to the user if private/competing agencies are providing good travel options.

This is related to #410, in that #410 will help us identify potential issues with region overlap before the new region becomes visible to users.

[barbeau]

@rjfv @rreisdasilva @brecke To continue the discussion from #442 (comment) - I'd like to better understand what TP.pt and OST are and their roles in relationship to public transportation in Portugal. I'm used to public transportation primarily in the U.S., where most transit agencies are publicly owned/operated, and typically servers like OTP would be hosted/operated by the same agency. It seems the situation in Portugal is different.

Some questions for both TP and OST:
1a. Are you public (i.e., government-operated) or a private organization?
1b. If private, are you for-profit or non-profit?
1c. If private, where do you get your operating funds from?
3. Do you have any official relationship with the transit agency/operator?
4. Is there any chance that TP and OST may combine in the future to host a single OTP instance for all of Portugal?

[brecke]

Hi there,

Thanks for taking the time to address this issue.

In Portugal transit agencies are publicly owned and partially publicly funded, but are mostly privately operated via public tender. And none have their own OTP instance, as far as I know. That's one of the reasons why OST exists: to aggregate data from Portuguese agencies and make them available as open data for third-party developers (we're a platform, not an application). We also provide OpenTripPlanner "as a service" on top of raw data, to make it really easy for developers to build new services.

Let me address your questions directly:

1a The OST platform belongs to Instituto Pedro Nunes (IPN for short, www.ipn.pt) and the University of Coimbra (UC for short, www.uc.pt). The former is a private non-profit organisation focused on technology transfer (aka we bridge the gap between the University of Coimbra and local industry) while the latter is public.
1b Aforementioned.
1c The OST has been publicly funded so far, through a state funded project (http://tice.mobilidade.ipn.pt)

3 The OST platform gets its data directly from data providers with whom we have a formal relationship and written documents regulating our collaboration. For some providers, we have even developed data connectors directly to their internal information systems so that we always have data that is up to date. For instance, Comboios de Portugal (CP) update their GTFS on a daily basis. Most of the providers we work with don't have GTFS formatted data, so we standardise data for them as well, and make it available to external apps through our API (Google, Moovit, Citymapper, OTP for Android, etc.). The providers we work with (and that feed our OTP instance) are the following:

• SMTUC (a Coimbra based mass transit agency)
• Carris (the main bus agency in Lisbon)
• CP (a major nationwide railroad agency)
• STCP (Oporto based mass transit agency)
• MoveAveiro (a mass transit agency from Aveiro)
• Transdev (a major nationwide intercity bus agency) :: still importing
• BikeEmotion (a bike sharing system from Aveiro)

4 We are open to that possibility and we would very much like that. It is important to notice that TP provides a user-focused service while the OST provides data and developer tools to use that data, in order to help third-party developers such as TP. Anyway, we have been in touch with one another and we have been discussing the matter. The goals of both projects are different and if no agreement is reached, we'll just have to respect that.

Thanks again for your time. Feel free to contact me with any other question.
_ miguel

[rreisdasilva]

Hi Sean, thanks for your intervention ;)

1. So, TP is a volunteer based "organisation" we have been organized as a social enterprise but have scale it back to be able to reach a bit further. We are non-profit, but we keep advertisements in our website and don't exclude other sources of income as a way to keep the project going.

TP appeared as a way to actually get the information to people, to users. We maintain a website, which includes OTP as well as a blog and other general info on public transport in Portugal. Our website is in Portuguese and English and about 30% of our users come from abroad.

3. We have formal relationships with the transit agencies, they provide us with their official data which we make available. In some cases we invite users to also contribute with information from their travels that we might not be able to get from transit agencies directly.

4. We are open to the possibility, there have been contacts between OST and TP in the past and we are now discussing it again. There were some difficult issues in the past but maybe things can be different now. TP would without any problem remove its OTP app instance if the same information is accessible elsewhere. Our issue is with sharing the information and disappointing the users. For the last years, we have foster good relationships with transit agencies, cities and users and we have done that outside the mainstream transport community,not only transit agencies but also universities and software organisations. In some cases, we have manage to get the info to the public despite that community. We have seen funding for mobility projects come and go and when it goes, it usually leaves nothing behind for users. We started TP because we are public transport users, and because we understand that users need to get public transport information. The project has its flaws and can end, but we are used to work with very few resources so the project is not dependent on funding streams. We are indeed quite protective of the relationships we've established and what we achieved so far. It is possible that in the future OST and TP combine and I think both Miguel and I want to discuss it more to see if we have some common ground at this moment to start with but I don't expect us to reach full integration very soon.

[rreisdasilva]

Guys, Miguel and I are trying to work something out between our projects, so lets wait a few days before making any big changes. In any case even if we solve things, I believe the thread remains valid and we need to discuss a solution for future overlapping situations between any two or more projects.