(source, 20+ years experience working in traffic planning software industry). Such data do exist. But they won't avail you (much). You have similar problems as when you optimise the energy sector, or economy in general. The "actual" problem you will be optimising on/for, has a lot of conflicting needs and interests, and choosing your trade-offs resemble the 'trolley problem'. I will just enumerate a random list of things that affect and collide with your optimisation. - your vehicles and vehicle fleets (and road networks, with congestion) provide one part of the problem. - your vehicle drivers etc., have other needs and union rules; they need to sleep, have breaks, go to the bathroom, eat; swap places on the road, they need to arrive and get home. - once you are on the road 'you might as well continue driving': There is a huge startup cost each time you pull into traffic. - you have two peak hours (morning, evening); what should your drivers and buses do in the lull in the middle of the day? (spoiler: they reasonably hate sitting idle for 3 hours, with or without pay). - lots of politics related to how it is funded and votes, who is paid for operating it. These are the shameful parents for things like frankenstein bus-routes, where 2-3 cancelled budget-cut bus-routes are merged into a single meandering remaining bus-route that makes all its passengers miserable.

- a lot of it is probablility-based/spontaneous; only some traffic patterns are regular (children to school); to service the probability-need, you need a regular service that may run empty/low half of the time, until people need a hair-cut.

The whole thing is handled on a sliding-scale/spectrum, ordered by how short/far into the future, the travel is/can be planned. On one end, you have taxi/uber, which is on-the-spot travel. The other end is planned year-service, e.g. a summer schedule of a bus. In between, with computers we have a lot of "urgent-but-planned" flexi-flexible traffic, where people book on the day or the week, and a number of bookings are then weaved to be driven like a pearl string (so e.g. a number of people will share a ride in a medium sized bus, that does pre-planned pseudo-taxi-service.)

UPDATE, for some reason edit did not work. (source, 20+ years experience working in traffic planning software industry).

Such data do exist. But they won't avail you (much). You have similar problems as when you optimise the energy sector, or economy in general. The "actual" problem you will be optimising on/for, has a lot of conflicting needs and interests, and choosing your trade-offs resemble the 'trolley problem'. I will just enumerate a random list of things that affect and collide with your optimisation.

- your vehicles and vehicle fleets (and road networks, with congestion) provide one part of the problem.

- your vehicle drivers etc., have other needs and union rules; they need to sleep, have breaks, go to the bathroom, eat; swap places on the road, they need to arrive and get home. - once you are on the road 'you might as well continue driving': There is a huge startup cost each time you pull into traffic.

- you have two peak hours (morning, evening); what should your drivers and buses do in the lull in the middle of the day? (spoiler: they reasonably hate sitting idle for 3 hours, with or without pay).

- lots of politics related to how it is funded and votes, who is paid for operating it. These are the shameful parents for things like frankenstein bus-routes, where 2-3 cancelled budget-cut bus-routes are merged into a single meandering remaining bus-route that makes all its passengers miserable.

- a lot of it is probablility-based/spontaneous; only some traffic patterns are regular (children to school); to service the probability-need, you need a regular service that may run empty/low half of the time, until people need a hair-cut.

The whole thing is handled on a sliding-scale/spectrum, ordered by how short/far into the future, the travel is/can be planned. On one end, you have taxi/uber, which is on-the-spot travel. The other end is planned year-service, e.g. a summer schedule of a bus. In between, with computers we have a lot of "urgent-but-planned" flexi-flexible traffic, where people book on the day or the week, and a number of bookings are then weaved to be driven like a pearl string (so e.g. a number of people will share a ride in a medium sized bus, that does pre-planned pseudo-taxi-service.)

UPDATE: an example of the differences in the setups: Typically, Europe and US will fund/run buses/public transport differently.

in US, traditionally, you would task a company with running the whole operation: Both plan the services to be provided, and then implement/deploy/operate them. So they would both decide the structure of the bus services to be offered, and then do the actual operations of the same plan.

in Europe/many parts, they instead divide like this: A public transport authority designs the structure of the services to be operated (this many buses, running these roads, at these intervals, and ALSO _at these times_). The 'times' part is important, because it determines which transfers are possible (between two lines). That package will then be tendered to private companies, who bid on running those planned operations; they are then paid by the public transport authority, what they offered to operate for in the contract.

These two structures give wildly different transport structures and operations structures. In the european model, it leads to very complex timetables, where bus services are trimmed to the perceived demand - every week, hour, day where the demand is perceived to be less, is cut from the planned timetables. So when you look at the time tables, you need to check complex date periods for whether the bus you want is operating today or not. The reasoning is of course, that since the transport authority must pay for each trip serviced, they try to cut any trip they don't "need".

Contrast that to the american, "older" model, with a full-service operator. They already have their money, and are already running and out on the roads with their equipment. To them, it doesnt matter much, whether they run 5 additional trips between 22:30 and 23:30 or not; they already paid the costs of having a driver present, and bought the buses, so once they are running, might as well keep them running (a similar thing in the middle of the day, in the lull.)

I of course "prefer" the european model, but I can see the issues it causes too (it makes things more complex but better trimmed and fitted.)

As an example, these differences made it so we had difficulty offering the same planning software for europeans and americans, because the planners simply needed different tools for their scenarios.