search

a-b-street / abstreet

Transportation planning and traffic simulation software for creating cities friendlier to walking, biking, and public transit
https://a-b-street.github.io/docs/
Apache License 2.0
7.66k stars 340 forks source link

Handle bus/train routes going off-map #190

Open dabreegster opened 4 years ago

dabreegster commented 4 years ago

I don't know yet how to model buses and map boundaries more reasonably. Right now, buses insist on making loops around the stops that're inside the map bounds. If the bounds cut off part of a route, then the bus does really strange things to glue together the two directions of the route. This is one of the main reasons why light rail in Seattle is hard; there's no way to turn around using the separate tracks except near the start/end of the entire route.

The more realistic thing is probably to have buses disappear/reappear at appropriate border intersections. But then some modelling questions:

1) How long should the bus spend off-map? 2) If someone is riding to a destination off-map, do we just measure the trip time to leave the map? 3) If someone boards near the end of the route and needs to ride off-map, then reappear and alight at one of the first stops in the other direction, how should that work?

dabreegster commented 4 years ago

@matkoniecz

matkoniecz commented 4 years ago

Currently main problem for me is that

Maybe allowing buses to leave and outright teleport to their next stop would be a good first step? And later figure out how long buses should stay of the map, how to count that time and so on.

For now buses can be teleporters, what is step up from running around the city like drunk hamsters.

And to improve that sole change will be to change time spent outside map, right? So maybe give them now 1 minute of travel, no matter the distance.

If someone is riding to a destination off-map, do we just measure the trip time to leave the map?

Initially yes, later it can be improved by taking into account distance traveled offmap (afaik not simulated now).

If someone boards near the end of the route and needs to ride off-map, then reappear and alight at one of the first stops in the other direction, how should that work?

Is it for circular routes? Because for A to B routes it should be simply not allowed.

dabreegster commented 4 years ago

Teleporting with a fixed time outside the map sounds like a reasonable next step to me.

Is it for circular routes? Because for A to B routes it should be simply not allowed.

Ah, here's the assumption that's wrong. I've been assuming every route is circular. If the master route relation has exactly 2 sub routes, I assume it's a forwards / backwards direction and try to glue them together. I haven't had any clue what 3 or 4 sub routes mean. This explains it. Need to see what route types are loops, and also dig into how GTFS represents this sort of thing in the schedules.

matkoniecz commented 4 years ago

For weird routes known to exist:

A->B B->A (standard one) A->A (route goes in loop) A->B, separate line number for B->A A->B, B->C, C->A A->B, B->A + shortened version

dabreegster commented 4 years ago

Thanks for clarifying those cases! I'm going to rip out the current attempt at gluing routes together and start over with something hopefully simpler. A route will be an optional border -> stop -> stop -> optional border. The bus/train will spawn at the first border/stop. When it reaches the last one, it vanishes forever. Trips starting or ending off-map will get matched to the appropriate bus. The border matching will use the actual route in OSM, but the route in between stops will be computed by A/B Street, so that the player can influence the route. (And later, they'll be able to modify stops too.)

For v1, when the bus reaches the end of the route, a new one will magically spawn at the start and begin again. From here, it should be a much easier change to read in GTFS and figure out the spawning rate of buses at the start by looking at the schedule.

This won't support somebody hopping on the bus near the end of the route and waiting for it to turn around and begin a new route in the opposite direction. It's too hard to understand when that might actually happen, and there are all of these cases where it doesn't.

Trams (#141) will work the same way as buses and light rail trains; the additional work there will just be interpreting the tracks in OSM. It's harder because sometimes the tracks coincide with a driveable lane.

Also: when importing, check that a contiguous sequence of stops is in the map bounds. If the route dips in and out of the boundary polygon, exclude it and warn. Better to fail-fast than have a bus subtly do really weird things.

matkoniecz commented 4 years ago

if the route dips in and out of the boundary polygon, exclude it and warn.

Maybe keep the longest segment (in term of bus stops) + warn?

dabreegster commented 4 years ago

Argh, correlating stops and platforms is a headache. Curious if you know of any existing code that does this.

I was matching them up by name, but that fails sometimes. Now I have to switch to stop_areas like https://www.openstreetmap.org/relation/5498884, but these don't seem to exist for all bus stops in Seattle.

matkoniecz commented 4 years ago

Argh, correlating stops and platforms is a headache. Curious if you know of any existing code that does this.

Is it needed? I thought that taking highway=bus_stop and nearest road should be sufficient.

dabreegster commented 4 years ago

Is it needed?

Maybe it isn't. For light rail, sometimes snapping the track to the nearest sidewalk produces weird results. But there probably needs to be better understanding of platforms inside of stations first.

I'm having trouble matching routes to entry/exit borders:

This'll take a little longer than I thought. :)

dabreegster commented 4 years ago

I think the border matching is pretty solid. Tomorrow's plan: