Add Dutch fare service#2571
Conversation
This service requires proprietary fare_attributes.txt and fare_rules.txt brought to you by Bliksem Labs B.V.
{
fares: {
type: "dutch",
currency: "EUR"
}
}
OpenTripPlanner now fetches a random fare_attribute and assumes the entire feed is in this currency. It also ignores the build.config. Since the DutchFare table contains Distance Units in XXX currency it might (and thus: will) happen that XXX as currency ends up in the client.
… Arriva would provide the data)
…220_master_dutch_fares
|
Everything here is isolated from existing code except that currency is hard-coded to EUR in 607fe0a: "OpenTripPlanner now fetches a random fare_attribute and assumes the entire feed is in this currency. It also ignores the build.config. Since the DutchFare table contains Distance Units in XXX currency it might (and thus: will) happen that XXX as currency ends up in the client." @skinkie we will have to find a way to fix this. |
|
We just discussed this. Some clarification: each train ride in NL has a certain cost in Euros if ridden in isolation. However costs are distance-based and digressive when multiple trips are chained together, and different operators may have different Euro-km conversion rates. In order to communicate this information in GTFS, there are separate fares with units of distance and units of Euros (these are expressed as two different currencies because it's the cleanest way to get the data through the GTFS loader with standard fields). OTP does not properly handle multiple currencies in the fare input - it assumes everything is in the same currency. |
in the original form, the PR forced all fare services to use Euros.
|
All fares are forced to EUR by above commit 0cce407 |
|
The changes introduced by this PR are now self-contained and do not affect the rest of OTP code. The above test failure is due to a test on memory-hungry deprecated code, which has been fixed in Master (as seen by the second build success). Merging. |
3 participants
Plannerstack has developed a Dutch fare service. The developer states the code could stand to be revised / improved, so they were hesitating to integrate it into mainline OTP, but it's already used in production and should not interfere with any other part of OTP.