abstreet
abstreet copied to clipboard
Support building new roads
In an extremely limited way. ie, if a new West Seattle bridge was built, what would happen?
More use cases for 405 interchange, also widening existing roads
I'm feeling like this will become a priority in a few months. It'd help model some stuff in Seattle (Northgate ped bridge) that isn't in OSM yet, and would simplify some of the actdev work.
Some of the desired end goals:
- Be able to draw new roads natively (aka in game, don't need to do anything in OSM)
- Modify the width of any road, adding or removing lanes. Useful when OSM is wrong or for prototyping new roads.
Rough plan is to start this in April. It'll be a massive effort, but extremely high reward. Will start to write down more requirements / thoughts closer to then.
Writing down some initial thoughts about this. There are two features, but I believe the implementation of them requires lots of the same things, so for now, I'm lumping them together.
Problems / use cases
First: modifying existing roads. A common problem is wanting to replace one driving lane with a bidirectional cycletrack. That likely fits in reality, but since abst currently just allows each lane type to be changed, the player can't model this. Another issue is OSM data being inaccurate, especially with missing curb parking. In reality, a bike lane could be squeezed in if an existing wide lane is trimmed down. In other cases -- the 405 interchange in Bellevue -- there are proposals to physically widen existing roads.
Second: building new roads. Sometimes this would be useful to model in-progress infrastructure, like the new Northgate pedestrian bridge. Other times in actdev, we're looking at a site without any construction or plans yet, and we want to quickly mock up some roads that might be built. And much more speculatively, it'd be nice to model very speculative plans like ST3 and build new light rail tracks.
Desired features
- Edit an entire road, not just individual lanes. Add and remove lanes. Tune the width of lanes. Also be able to add/delete sidewalks (not possible today).
- Draw entirely new roads and intersections, connecting them to existing roads. Be able to modify control points; not just straight segments between intersections.
Related, but probably a bit out-of-scope:
- Draw new buildings, to model new light rail stations or to populate an empty actdev site.
- Edit the geometry of existing roads, and delete existing roads.
These two push us much closer to editing anything on the map (except for river/park areas and parking lots). That much generality comes at a cost, and I'm not sure there are use cases for it yet.
UI
The map_editor
has a very simple UI for creating/modifying/deleting roads. https://github.com/Uriopass/Egregoria and other city building games have nicer UIs for specifying road shape. Making this part nice seems less important; it can be improved later if this feature ends up being used lots.
For modifying lanes on an existing road, I think streetmix.net is the gold standard here. Our current UI of clicking individual lanes and toggling the lane type could be a first step -- we could add buttons to add a new lane on either side of the road, and have buttons to quickly invert the order of existing lanes. And a new slider for lane width. But ultimately, something closer to Streetmix's drag-and-drop is more intuitive, and maybe not that hard to implement.
Implementation difficulties
I can think of 4 main reasons why implementing this will be hard.
-
Today, all sidewalks are not editable. This means that buildings, parking lots, and bus stops don't have to be changed in response to map edits. These are snapped to the nearest sidewalk, and immutability is assumed in the map building pipeline. If these can change, there are trickle-down effects that have to be carefully managed. I haven't gone through and thought about all of these yet.
-
DrawMap
has a few batches that cover all roads or all buildings in the map, and can be drawn with one call. All of the map edits so far only cause a few individual things to be redrawn. We might have to recalculate the entire thickened road batch, which will slow down applying edits. -
Pathfinding. This gets really hard to do efficiently. We use contraction hierarchies, which have an expensive offline step, depending on map size. When individual lanes are edited, we can reuse the CH node ordering and just modify a few edge weights, rebuilding it pretty quickly. If we can create and delete roads entirely, then I'm not sure how to reuse node ordering -- I think we'd have to build from scratch. There might be clever tricks we could play with inserting some dummy nodes connected to each other in the input graph, reserving them for future roads. Later we can map new roads to these nodes and connect them to the rest of the graph. In practice, this probably screws up node ordering anyway and might still be slow. (I'll mention that if we just focused on widening existing roads and not creating new ones, the pathfinding could be much easier. Pathfinding happens at the level of lanes right now, but I want to change that anyway for a few reasons to happen at the level of road segments. If we did that, then applying the CH edge weight changes becomes straightforward.)
-
Map edits. Oh boy.
PermanentMapEdits
are very careful to specify OSM IDs that're more likely to last through changes to OSM over time. They also specify the old and new configuration of modified roads, detecting upstream OSM changes that might invalidate the edits. I'm not sure yet how to sanely represent widened or newly created roads yet. Maybe we just have to allocate new synthetic IDs in a different ID space, and be very careful with comparing the old lane configuration.
For some of these performance-related concerns, an obvious mitigation is to not do them unless a road has been created or deleted. This shouldn't be a common thing people do anyway, so having a longer loading screen might be reasonable.
Also, after writing this up, it maybe feels like widening roads is a simpler first step that could be done on its own. It'd still require solving a few of the hard problems, but not as many as building new roads. Maybe we should do this in two big steps.
The John Lewis Memorial Pedestrian and Bike Bridge looks like it's up in OSM. Does it just need to be added to A/B in the next OSM import? (I'm just noting this here, as I don't think this needs its own issue, and this is an intriguing thread).
Does it just need to be added to A/B in the next OSM import?
Thanks for the reminder -- I missed the opening day parties, sadly. It looks like everything in OSM is importing fine:
I'm re-running the Seattle import now, so it'll be picked up in next Sunday's release.