Add alternate phone number field for agencies
- Dominant language
- No language data
- Stars
- 1.1k
- Forks
- 225
- Avg merge
- 7d 17h
- Merged PRs (30d)
- 3
Description
### Describe the problem
Hello!
Many transit agencies have multiple phone numbers that passengers can use depending on many factors, including tolled calling rates and locality. However, `agency.txt` currently only has support for a single `agency_phone` field. This proposal would allow agencies to declare a secondary phone number to be associated with their GTFS Schedule package.
### Use cases
Let's say a passenger that isn't from the Toronto area needs to call TTC customer service. Their trip planning (GTFS consumer) app guides them to TTC's local number, specified [in the agency_phone field](https://files.mobilitydatabase.org/mdb-2253/mdb-2253-202609040158/report_8.0.1.html). However, this passenger doesn't have a phone plan that allows for free calls to Toronto's +1-416 numbers, leading to the passenger getting an unexpected cell roaming charge to put a damper on their plans. 😔
A secondary agency phone number field would allow the TTC to specify both their local and toll-free numbers in their GTFS Schedule package, and would allow Consumer apps to prompt the passenger on whether to call local or toll-free, or even call the number that the Consumer app determines is "toll free" without the passenger needing to choose between the two!
### Proposed solution
An extra OPTIONAL field (`agency_alternate_phone`) should be added to `agency.txt` to allow agencies to specify a secondary contact phone number (i.e for the toll-free/local split mentioned above)
### Additional information
_No response_
Contributor guide
Research direction
Start with the agency.txt portion of the GTFS Schedule specification and review the use cases and proposed agency_alternate_phone field in this issue. Check how existing agency fields are defined and documented; done means the proposal's scope, optional status, and secondary-number behavior are clearly specified for agencies and consumer apps.
Written by the indexing model from the issue text.
Assessment
- Domain
- data, documentation
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100