A national interface, not a local app
UPI unified payments.
Public transport is still
a different app per city.
Bengaluru, Chennai, Mumbai and Delhi each run their own buses and their own systems. That is fine. What is not fine is that each one needs its own integration before a passenger can be told which bus to catch.
Every network above was generated by the same pipeline from OpenStreetMap, served through the same GTFS and GTFS-Realtime contract, and planned by the same routing engine. Nothing is special-cased per city. The shapes are the routes themselves: real streets, simulated services.
The same interface,
four times over.
This is the whole claim, and it is checkable. Below is what an application asks for in each city. Only the identifier changes. The endpoint, the format and the fields are the same, because they are the existing GTFS standards rather than anything UTI invented.
A developer who integrates one city has integrated all four. A city that joins does not ask anyone to write new code.
Realtime vehicle positions/v1/blr/gtfs-rt/vehicle-positions.pb/v1/maa/gtfs-rt/vehicle-positions.pb/v1/bom/gtfs-rt/vehicle-positions.pb/v1/del/gtfs-rt/vehicle-positions.pbOne GTFS feed carries all four cities as four agencies, which the standard has always supported. Inspect the transformation from a raw AIS-140-style observation to the GTFS-Realtime a passenger app consumes.
Solve it once,
at national scale.
India has hundreds of cities running buses. Each one procuring its own passenger information system rebuilds the same integration, at the same cost, with the same risk, and ends up with data no neighbouring city can read.
The alternative is the one payments took. Agree the interface, let every operator keep its own systems behind it, and let anyone build on top. Read the argument in full, or see it against a real city's app.