Simple way to get accurate city boundaries

[tko]

Currently the part about importing new city suggest

3. Use geojson.io or geoman.io to draw a boundary around the region you want to simulate and save the geojson locally.

Which is probably good enough for local use but painful if you want to capture the city accurately which you'd presumably want for permanently added cities.

It seems it would be more simple to

1. go to openstreetmap.org and search for the city
2. select the City / City Boundary / Municipality Boundary etc., one that is a type=boundary Relation such as https://www.openstreetmap.org/relation/271110
3. copypaste the number to http://polygons.openstreetmap.fr/ (sample)
4. download the GeoJSON

Unfortunately "type": "GeometryCollection" on the toplevel causes an "unexpected geojson" panic, so

5. paste the GeoJSON to geojson.io
6. draw a rectangle and delete it
7. copy the now acceptable GeoJSON

[dabreegster]

Unfortunately, most cities are too large to comfortably import into A/B Street as a single map. The greater Seattle area winds up about 250MB, compared to about 5MB for most smaller areas. Besides performance (of initially loading the file, of rebuilding the routing structures after editing the map, etc), a larger area means way more places where the traffic simulation can get stuck.

So, usually my advice is to just pick a chunk of a city that's particularly interesting to study something specific. In Seattle, different ideas for changing roads have meant lots of different partly overlapping boundaries have been created: And in other places, we just divide the city somewhat arbitrarily, based on local knowledge of meaningful boundaries:

Sometimes a city has administrative boundaries smaller than cities that happen to be about the right size, and we could use them. But it takes a bit of tuning to get the size and exact boundary right. So I'm not sure using OSM admin boundaries will work well.

I've meant to add this explanation and example pictures to the docs for a long time, so definitely will keep this issue open until I do that.

[tko]

Yes, I see. I imported all of Amsterdam and then gave up waiting on the traffic pattern generator wanting to go through one million parking spots. I think a whole city could maybe work for a scenario of sorts but only if someone goes through all traffic signals and makes the timings make sense first.

It seemed sensible at the time but as you say it probably makes more sense in practice to carve out as small an area as possible to cover the area of interest. Which I suppose brings its own problem of defining existing traffic patterns.

[dabreegster]

Undocumented trick: If you run the game with --infinite-parking, driving trips will directly start and end at buildings, and that costly assignment of parking spots is totally skipped.

The bigger problem here is that the generator you're using, https://a-b-street.github.io/docs/tech/trafficsim/travel_demand.html#proletariat-robot, has no clue about the total population in the area, and is probably making very awful estimates on how many people try to drive through Amsterdam. There are some other options on that page to generate a more realistic travel demand model, but there's no easy answer that works everywhere yet.

I'm curious if you hit #32 with Amsterdam -- there are so many bodies of water there, there's no way the code that tries to stitch together multipolygons got it right.

[tko]

Sure, I understand the naive traffic generator is totally inaccurate to begin with. As the robot uses the map region as the basis I believe the smaller the map the worse it gets since the percentage of through traffic increases. If I were to zoom in to just the Central Station I suppose it would be better to generate traffic based on the whole city area and keep the trips going through the map. And the robot doesn't seem to consider train stations at all. Anyway different topic, I understand it's not simple problem

As for flooding, looks ok to me.