Import Münster (Germany)

[silberzwiebel]

Hi,

great project!

I tried to import my hometown, Münster in Germany. I used the (unzipped) .osm file downloaded from bbbike.org. I tried to import this with the following command:

./import.sh --oneshot=Muenster.osm

The import fails with this error.

thread 'main' panicked at 'No bus route from Position(Lane #102018, 27.2693m) to Position(Lane #86195, 7.4311m) now for Bus 329: Sendenhorst, Realschule => Hoetmar, Hagenhoff! Prevent this edit', map_model/src/pathfind/walking.rs:329:17

This might be related to #190, but I didn't investigate any further beyond this error message. I got the same error with a manual bounding box download from bbbike.org, though.

[dabreegster]

Hi! Indeed #190 is related; I started overhauling how bus routes get snapped to the map, but never finished, and this is a leftover bug. I'll see about fixing this particular problem, but in the meantime, you can pass --skip_ch to import.sh. That will be faster to run, because it skips building contraction hierarchies used for pathfinding. But then in the game when you try to spawn traffic, it'll use much slower pathfinding.

I imported the bbike area, and the resulting map is pretty huge (190MB). If you want to try things out and it loads slowly, I'd recommend following the guide to draw a smaller boundary around the city center. Let me know if you hit more issues!

[silberzwiebel]

Thanks, I now have a working map. But the game crashes if I start to spawn traffic. Will investigate further and ask back. Thanks for the prompt support!

[dabreegster]

It crashes -- what error? For me, it just hangs for a long time.

Looking into the original error message, it looks like there's a problem building the pathfinding graph when there are two bus stops on the same sidewalk:

127440 maps to RideBus(BusStopID { sidewalk: LaneID(47917), idx: 0 })
127441 maps to RideBus(BusStopID { sidewalk: LaneID(47917), idx: 1 })
fast_paths::input_graph: Zero weight edges are not allowed. Skipped edge! from: 127440, to: 127441, weight: 0

But actually looking at this on the map, there seem to be two bus stops placed at exactly the same spot. I only see one in OSM: https://www.openstreetmap.org/node/4610026563 In the game, one of the stops serves route 644, and the other 512.

But the crash involves route 329 in a different part of the map, so I think this duplicate stop issue is a separate issue.

Looking into the path that supposedly can't be found: Notice the slightly pink north/south road, here in OSM. Pink means some kind of access restriction, like a private neighborhood or a living street. Buses aren't allowed to route here, so the pathfinder gets confused.

Possible fixes: 1) These two pairs of stops should get filtered out with warnings earlier in importing. But I'm using a different method of pathfinding there, which doesn't respect the access restrictions yet. Time to fix that. 2) Maybe we should add some tags to https://www.openstreetmap.org/way/322291528 to indicate that buses are allowed to route on it. Or maybe my interpretation of highway=living_street is wrong here.

[dabreegster]

For reference:

• https://github.com/dabreegster/abstreet/blob/01737ea0c54d802e6be3480646b4e34d74d8ea85/map_model/src/make/mod.rs#L331 is where transit routes get built before the contraction hierarchies for pathfinding
• we should filter out those pair of stops here: https://github.com/dabreegster/abstreet/blob/01737ea0c54d802e6be3480646b4e34d74d8ea85/map_model/src/make/transit.rs#L169
• by making https://github.com/dabreegster/abstreet/blob/master/map_model/src/pathfind/dijkstra.rs understand requests that cross zones, similar to https://github.com/dabreegster/abstreet/blob/01737ea0c54d802e6be3480646b4e34d74d8ea85/map_model/src/pathfind/ch.rs#L71

[dabreegster]

The issue is a little more annoying to solve than I thought. https://github.com/dabreegster/abstreet/blob/727fe32fdda4d9e694e8536d5e7e52b08d500d06/map_model/src/pathfind/walking.rs#L315 directly calls an inner method to figure out the cost for a bus to drive between two stops. This inner method doesn't go through https://github.com/dabreegster/abstreet/blob/727fe32fdda4d9e694e8536d5e7e52b08d500d06/map_model/src/pathfind/pathfinder.rs#L25, which handles starting on living streets. Because we're replacing an inner piece of the pathfinder struct while constructing the walk+transit graph, we can't pass in the outer object either. I'll think a bit about how to make this work. But in the meantime, the problem is happening on a corner of the huge bbike map. If you clip to a smaller area, you'll likely avoid this bug, and the resulting map will be much more usable too.

[silberzwiebel]

Wow, thanks for your detailed answers. Unfortunately, I don't have the time to go in this details. I managed to import Münster with this map, see over at twitter. It still crashes when I click the first "generate random trips" button, here's the error message:

thread 'main' panicked at 'assertion failed: commuter_borders.len() > 0', sim/src/make/activity_model.rs:121:9
stack backtrace:
   0: std::panicking::begin_panic
   1: sim::make::activity_model::<impl sim::make::generator::ScenarioGenerator>::proletariat_robot
   2: game::sandbox::gameplay::GameplayMode::scenario
   3: widgetry::event_ctx::EventCtx::loading_screen
   4: <game::sandbox::SandboxLoader as widgetry::app_state::State<game::app::App>>::event
   5: widgetry::app_state::App<A>::event
   6: widgetry::event_ctx::EventCtx::no_op_event
   7: widgetry::app_state::App<A>::event
   8: widgetry::event_ctx::EventCtx::no_op_event
   9: widgetry::app_state::App<A>::event
  10: widgetry::event_ctx::EventCtx::no_op_event
  11: widgetry::app_state::App<A>::event
  12: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  13: widgetry::runner::State<A>::event
  14: widgetry::runner::run::{{closure}}
  15: winit::platform_impl::platform::sticky_exit_callback
  16: winit::platform_impl::platform::x11::event_processor::EventProcessor<T>::process_event
  17: winit::platform_impl::platform::x11::EventLoop<T>::run
  18: winit::platform_impl::platform::EventLoop<T>::run
  19: winit::event_loop::EventLoop<T>::run
  20: widgetry::runner::run
  21: game::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
dropping Timer during create people, due to panic?

Also, I noticed several misrepresentations in the map. But I guess this is mostly due to the mapping quality in OSM.

[michaelkirk]

To clarify @silberzwiebel - looks like you selected the "trips between home and work" option right?

You might have better luck in the meanwhile with the "random unrealistic trips".

That error is interesting - it is expected to happen if the map has no 2-way road which crosses the border of the map.

If you clip to a smaller area, you'll likely avoid this bug, and the resulting map will be much more usable too.

I think this same comment applies.

In the immortal words of Jonny Doenne: "No map is an island" - having incoming/outgoing border roads on the map is essential to any kind of a realistic simulation so people can come and go. If the map isn't clipped, I imagine all the roads look like they "end" rather than that they continue outside of the map, an assumption that chokes our traffic generator.

We should do a better job of enforcing this in the import tools, but in the meanwhile, I think that's what you'll have to do to proceed.

[dabreegster]

Thanks for the tweet; lots of people have found the project in the past few days!

Also, I noticed several misrepresentations in the map.

This could be either bad/missing OSM data, or problems with A/B Street's importer. There are many known limitations, but if you can link to any specific ones, there might be things particular to Münster we haven't seen yet.

[silberzwiebel]

To clarify @silberzwiebel - looks like you selected the "trips between home and work" option right?

Yes, that's correct.

If you clip to a smaller area, you'll likely avoid this bug, and the resulting map will be much more usable too.

I think this same comment applies.

Alright, will try to choose a smaller portion of the map on one of the remaining Tuesdays in 2021 :hourglass:. A more theoretical question before I do that, though: I initially chose a rather large map, because one of the major traffic problems in Münster are many car commuters coming/going from/to the smaller towns in the surroundings. Are commuters actually simulated by A/B-Street? Or is the simulation scale smaller anyway?

This could be either bad/missing OSM data, or problems with A/B Street's importer. There are many known limitations, but if you can link to any specific ones, there might be things particular to Münster we haven't seen yet.

I didn't check systematically yet but a major issue seem to be crosswalks. In the A/B-Street video, from minute 1:17 onwards, you can see a roundabout with a lot of crosswalks. In reality, only a small subset of these crosswalks exist (image source):

Actually, you can't walk to the inside of the crosswalk. While looking at the video, I also recognized other places where A/B-Street renders (and very likely also simulates) a crosswalk where no crosswalk exists.

A second issue with the roundabout: A/B-street shows two car-lanes and one bike-lane, that's wrong. It only has two lanes (with a lot of bikes using the car lanes).

Not sure if these issues are OSM or A/B-street related, though.

[dabreegster]

Are commuters actually simulated by A/B-Street? Or is the simulation scale smaller anyway?

https://dabreegster.github.io/abstreet/trafficsim/travel_demand.html partly explains. Individual people, who live somewhere and have a schedule of trips, are simulated. Generating a realistic population is hard, so the "trips from home to work" option does something simple. We've started working on more realistic census-based activity generation, but we only have census data for the US currently.

If you chose a map just around the core of Münster, then trips starting and ending off of the map, representing these suburbs, would still be created. We don't yet expose an easy way for you to tune how much traffic should come in on different borders of the map, but that kind of thing is somewhere on the roadmap.

Alright, will try to choose a smaller portion of the map on one of the remaining Tuesdays in 2021

You can divide the city into multiple areas, optionally skipping some parts or having overlap: Each region just functions as an independent map.

I didn't check systematically yet but a major issue seem to be crosswalks

You're right. A/B Street isn't using crosswalk data from OSM yet at all. By default, it makes guesses about sidewalks on the sides of roads, and creates crosswalks in every possible place. This often turns out looking very unrealistic. Somehow I still don't have a dedicated bug talking about this, but https://github.com/dabreegster/abstreet/issues/457#issuecomment-761072260 partly explains.

A/B-street shows two car-lanes and one bike-lane, that's wrong

Probably an OSM issue; can you send a link to the area in OSM, or at least the name of the roundabout? I'm not sure which roundabout this is in the Stadtplan (which has an awesome amount of detail!)

[silberzwiebel]

Thanks for the details! I'll start with a smaller map of the city center in the coming weeks then and possibly extend with more regions once the center works. The roundabout is the "Ludgeriplatz": https://www.openstreetmap.org/#map=19/51.95566/7.62682 The details in the official stadtplan are only the tip of the iceberg of data underlying it. German bureaucracy has to have positive sides :)

[dabreegster]

https://www.openstreetmap.org/way/423007848 and the other pieces have cycleway:right=lane, hence the bike lane showing up in abst. Also, this piece apparently has 3 lanes: vehicle | vehicle | bus-only

[dabreegster]

I filed #485 to focus on the crosswalk heuristics, btw

[dabreegster]

Closing old issues; if there's particular action I can help with here, please reopen