a-b-street/abstreet
1
1
Fork 0
mirror of https://github.com/a-b-street/abstreet.git synced 2024-12-26 07:52:05 +03:00
Code Issues Projects Releases Wiki Activity

organizing TODOs

Browse Source
This commit is contained in:
Dustin Carlino 2018-07-06 14:53:22 -07:00
parent d5de9cb8eb
commit d6a7274835
9 changed files with 237 additions and 338 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
POLISH.md
View File

@ -1,24 +0,0 @@
# Polish
Overlapping with TODO.md and docs/backlog.md, we have... a new list of visible
things needing polish!
## Just appearance
- new center polylines
- explode out at some angles
- different lane markings
- dashed yellow center lines (and later, white lines for multiple road lanes)
- sidewalks with little horizontal lines
- parking with... circled P's and https://nacto.org/wp-content/uploads/gallery/sharedlane_3d/shared-lane_urban_street.jpg
- copy the green Seattle color scheme for bike lanes?
- sidewalk paths start in building centers and end in sidewalk centers
- this is probably fine to show agents moving, but at least draw
building layer before sidewalk layer
- the colors are awful
## Interaction
- sometimes UI zooms in at once, then unzooms slowly

97
TODO.md
View File

@ -1,97 +0,0 @@
# TODO
## Map editor
- still key overlap bugs with floodfilling
- master UI exclusive state -- one plugin at a time
- traffic signal editor
- button to reset intersection to original cycles
- turns can belong to multiple cycles; the colors become slightly meaningless
- support left turn yield
- stop sign editor
- cant have no stop signs for two roads whose center line crosses
- infer default policy
- draw as red octogon with thin white trim, off to the right side of the road
- better visualization
- why are some icons in the intersection?
- draw detailed turns better, like https://i.ytimg.com/vi/NH6R3RH_ZDY/maxresdefault.jpg
## Driving model
- try to simplify straw_model step (less phases?)
- make cars pathfind to their destination
- better visualization
- draw moving / blocked colors (gradually more red as they wait longer)
- draw stop buffer in front/behind of cars
- draw cars in intersections, even when slightly zoomed out
- draw cars in slightly different colors, to distinguish them better
- start implementing a second AORTAish driving model
- reversible sim
## Map model
- more data
- parse shp, get traffic signals in the right places
- do need to mouseover shapefile things and see full data
- grab number of phases from traffic signal shp
- look for current stop sign priorities
- https://gis-kingcounty.opendata.arcgis.com/datasets/traffic-signs--sign-point/
- multiple lanes
- solve the multiline problem
- move it out of experimental
- use it for real
- clean up oneway osm way hacks
- model bikes in driving lanes (as slow cars)
- add random bike lanes, figure out how turns would work
- be able to convert between parking and bike lanes, recompute the turns
- model cars parking
- maybe render numbers on the cars to distinguish them
- document the FSM (on lane driving, waiting, turning, parking, etc)
- model pdestrians
- maybe draw crosswalks?
- regression testing
- goldenfile approach for map_model, geom, and render layer from a small OSM chunk
- or maybe a visual demo approach with a list of things to manually check
- unit test that Centered thick line yields same geometry with points reversed
## Code cleanup
- clean up code
- master Map struct
- line type / ditch vec2d / settle on types
- one-at-a-time UI plugins
- UI colors in one place
- cleaner pipeline of map construction
- serde, not pb
- logically be able to shift what gets recomputed or not
- better layering: GeomParcel, GeomIntersection, etc, so that render layer doesn't need to know Bounds and use gps_to_screen
- more uniformity with polygon + center line?
- add/plan tests
- document pieces that're stabilizing
- run clippy everywhere
- presubmit script
- also enforce consistent style (import order, extern crate only in mod.rs or lib.rs, derive order)
- extract common crates
- ask about mut vs returning new version of self (and what that requires of all the contained stuff)
- https://stackoverflow.com/questions/28385339/mutable-self-while-reading-from-owner-object
## Example use cases
- montlake/520 turn restrictions with pedestrian scramble
- close interior neighborhoods to most cars (except for src/dst), see how traffic restricted to arterials would work
- create a bike network with minimal hills, dedicated roads, minimal crossings

59
docs/TODO_phase1.md Normal file
View File

@ -0,0 +1,59 @@
# TODO for Phase 1 (Basemap)
- model bike lanes
- more data
- draw water and greenery areas
- draw benches, bike racks
- more generally, a way to display random GIS data from seattle site (kml)
- render trees
- parse shp, get traffic signals in the right places
- do need to mouseover shapefile things and see full data
- grab number of phases from traffic signal shp
- look for current stop sign priorities
- https://gis-kingcounty.opendata.arcgis.com/datasets/traffic-signs--sign-point/
- polish geometry
- new center polylines
- explode out at some angles
- draw intersections at dead-ends
- shift turn icons and stop markings and such away from crosswalk
- interpret failed shifting/polyline attempt as implying something about the lane specs
- some bldg paths are quite long.
- sidewalk paths start in building centers and end in sidewalk centers
- this is probably fine to show agents moving, but at least draw
building layer before sidewalk layer
- code cleanup
- rename Road to Lane
- make final Map serializable too
- useful to precompute sidewalk paths
- waiting on https://github.com/paholg/dimensioned/issues/31 to release
- move map_model geometry stuff elsewhere (sim stuff also needs it though)
- also a polygon struct? for parcels and buildings. maybe have a form that's pre-triangulated?
- isolate vec2d
- figure out what to do about yellow center lines
- yellow and white lines intersect cars and turn icons and such
- who should own drawing them?
- trim them back too (maybe to avoid hitting the intersection?)
- osm tags and such would ideally be part of a master road
- draw detailed turns better, like https://i.ytimg.com/vi/NH6R3RH_ZDY/maxresdefault.jpg
## Intersection geometry brainstorm
- figure out how to iterate quickly in experimental.
- aha, big bug! we only try to trim first/last lines. do the whole polyline.
- can think of an easy fixpoint approach to try first, even though it's inefficient.
- wait, the fixpoint is also incorrect. :(
- before trimming back lines, project out the correct width. sort all those points by angle from the center. thats the intersection polygon? then somehow trim back lines to hit that nicely.
- do the current trim_lines thing, but with lines, not segments? no, there'd be many almost-parallel lines.
- at a T intersection, some lines aren't trimmed back at all
- https://www.politesi.polimi.it/bitstream/10589/112826/4/2015_10_TOPTAS.pdf pg38
- just make polygons around center lines, then intersect?

26
docs/TODO_phase2.md Normal file
View File

@ -0,0 +1,26 @@
# TODO for Phase 2 (Editor)
- support massive maps
- render to a bitmap and clip that in?
- sometimes UI zooms in at once, then unzooms slowly. drop events?
- different UIs
- 3D UI sharing the same structure as the 2D one
- svg export some area, for manual mockups
- web version
- ggez, quicksilver, unrust could work
- easy UI bugs
- big maps start centered over emptiness
- traffic signal editor
- button to reset intersection to original cycles
- turns can belong to multiple cycles; the colors become slightly meaningless
- support left turn yield
- stop sign editor
- cant have no stop signs for two roads whose center line crosses
- infer default policy
- add random bike lanes, figure out how turns would work
- be able to convert between parking and bike lanes, recompute the turns

24
docs/TODO_phase3.md Normal file
View File

@ -0,0 +1,24 @@
# TODO for Phase 3 (Simulation)
- try to simplify straw_model step (less phases?)
- make cars pathfind to their destination
- better visualization
- draw moving / blocked colors (gradually more red as they wait longer)
- draw stop buffer in front/behind of cars
- draw cars in intersections, even when slightly zoomed out
- draw cars in slightly different colors, to distinguish them better
- start implementing a second AORTAish driving model
- reversible sim
- model cars parking
- maybe render numbers on the cars to distinguish them
- document the FSM (on lane driving, waiting, turning, parking, etc)
- model bikes in driving lanes (as slow cars)
- model pedestrians
- also building to sidewalk?

6
docs/TODO_phase4.md Normal file
View File

@ -0,0 +1,6 @@
# TODO for Phase 4 (Game)
- Example use cases
- montlake/520 turn restrictions with pedestrian scramble
- close interior neighborhoods to most cars (except for src/dst), see how traffic restricted to arterials would work
- create a bike network with minimal hills, dedicated roads, minimal crossings

29
docs/backlog.md
View File

@ -1,31 +1,14 @@
# Backlog # Backlog
## UI ## Code cleanup
- show more things
- draw water and greenery areas
- draw benches, bike racks
- more generally, a way to display random GIS data from seattle site (kml)
- support massive maps
- render to a bitmap and clip that in?
- drop events sometimes
- 3D UI sharing the same structure as the 2D one
- svg export some area, for manual mockups
- web version
- ggez, quicksilver, unrust could work
- easier way to define magic tuneable constants - easier way to define magic tuneable constants
- and maybe to recalculate fixedish things if they change? - and maybe to recalculate fixedish things if they change?
- add/plan tests
- more advanced road modeling, like https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area - document pieces that're stabilizing
- run clippy everywhere
- clean multilines - presubmit script
- yellow center lines eat into the width of one lane arbitrarily - also enforce consistent style (import order, extern crate only in mod.rs or lib.rs, derive order)
- the oneway at the top of montlake has a weird first point
- draw intersections at dead-ends
## Conga line idea ## Conga line idea

116
docs/design.md
View File

@ -107,3 +107,119 @@ Not aiming to get it right forever, just improving the mess now.
- Polygon - Polygon
conversions to Vec2d ONLY for graphics; maybe even scope those conversions to render/ conversions to Vec2d ONLY for graphics; maybe even scope those conversions to render/
## Lanes
It's time to model more things:
- multiple driving lanes, with possibly individual turn restrictions
- dedicated bus lanes
- lanes with parked cars
- bike lanes
- sidewalks
Each lane needs some geometry:
- center lines to draw agents on
- for sidewalks, use center line to to draw agents on the left and right sides?
- polygons to draw the lane and mouseover
Open questions:
- Can we assume all lanes are the same width?
- Seems wrong for many sidewalks especially
- Could be wrong for bike lanes, but could just assume it's a bike lane with a buffer
- Some lanes are immutable
- Sidewalks can't be changed to other types; they're raised with a curb
Some modeling questions:
- Where should expansion of roads into lanes happen?
- initial OSM conversion, adding more stuff to the proto?
- initial map_model::new loading, at least for development convenience
- same reason that turns aren't (yet) serialized
- Is it useful to model the entire road?
- the parent/child relation may be hard to maintain
- but lanes need to know their siblings
- maintaining directional sanity could be useful
- what's the UI for changing lane types?
- it's a bit arbitrary which lane should draw the yellow center lines
Initial design:
- "Road" becomes "Lane" with a type
- don't need to know sibling lanes yet
- arbitrarily, one lane might have extra bits/geometry for yellow center line markings
- ideally, get rid of one-wayness and original center points, and plumb along pre-shifted lines
- but due to the polyline problem (affecting both geom center line layer that agents follow, and polygons for drawing), can't do this. encapsulate the messiness at least.
- so, store one way and orig points and index, but have an accessor
- as a compromise, dont interpet OSM points on a one-way road as the center, but as the edge? this is proving hard to do.
Thinking about a new design:
- Much more general "Land" primitive that's just a nice polygon boundary for drawing/selection and one (or more, for sidewalks?) center lines for how to cross the space, with a notion of turns. It's what road is now, but way simpler data.
- Maybe the GeomRoad / DrawRoad split is a little confusing after all, since the layering just isn't perfect. figure out the polygon and centerline up-front, then ditch the other intermediate gunk.
- also ideally make one polygon for the road, not a bunch of individual pieces? but then we'd have to go triangulate later for opengl anyway
- enforce that all the polygons are nonoverlapping
## Polylines
The polyline problem:
- https://www.codeproject.com/Articles/226569/Drawing-polylines-by-tessellation
- https://stackoverflow.com/questions/36475254/polylines-outline-construction-drawing-thick-polylines
- Will lengths change? Is this a problem?
- Drawing cars as rectangles is funky, because if their front is aligned to a new line segment, their back juts into the center of the road
- https://hal.inria.fr/hal-00907326/document
- https://www.researchgate.net/publication/220200701_High-Quality_Cartographic_Roads_on_High-Resolution_DEMs
https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
## Crosswalks
- Turns go from a src to a dst, so we'd need to double them for crosswalks, since they're always bidirectional
- Turn icons might not make sense as a UI?
- Many sidewalks directly connect at corners and shouldn't have anything drawn for them
- We don't want to draw diagonals... just from one side of the road to the other
- We want crosswalks at the beginning AND end of the sidewalk!
- v1: remember other_side for sidewalks too. draw crosswalks at the beginning AND end of every sidewalk lane.
- do extra drawing in DrawIntersection for now, figure out modeling later.
## Stop signs
How to depict stop signs? Each driving lane has a priority... asap go or full
stop. Turns from go lanes might be yields, but shouldn't need to represent that
visually.
- Easy representation: draw red line / stop sign in some driving lanes. Leave the priority lanes alone.
- Harder: draw a stop sign on the side of the road by some lanes. Won't this look weird top-down and at certain angles?
## Traffic signals
- per lane would be weird.
- drawing turn icons as red/yellow/green is pretty clear...
- could draw an unaligned signal box with 3 circles in the middle of the intersection, but what does it represent? maybe just an initial indicator of what's going on; not full detail.
- similarly, draw a single stop sign in the middle of other intersections? :P
## GUI refactoring thoughts
- GfxCtx members should be private. make methods for drawing rectangles and such
- should be useful short term. dunno how this will look later with gfx-rs, but dedupes code in the meantime.
- should GfxCtx own Canvas or vice versa?
- Canvas has persistent state, GfxCtx is ephemeral every draw cycle
- dont want to draw outside of render, but may want to readjust camera
- compromise is maybe storing the last known window size in canvas, so we dont have to keep plumbing it between frames anyway.
One UI plugin at a time:
- What can plugins do?
- (rarely) contribute OSD lines (in some order)
- (rarely) do custom drawing (in some order)
- event handling
- mutate themselves or consume+return?
- indicate if the plugin was active and did stuff?
- just quit after handling each plugin? and do panning / some selection stuff earlier
- alright, atfer the current cleanup with short-circuiting... express as a more abstract monadish thing? or since there are side effects sometimes and inconsistent arguments and such, maybe not?
- consistently mutate a plugin or return a copy
- the Optionals might be annoying.

194
docs/lanes.md
View File

@ -1,194 +0,0 @@
# Brainstorm about lanes
It's time to model more things:
- multiple driving lanes, with possibly individual turn restrictions
- dedicated bus lanes
- lanes with parked cars
- bike lanes
- sidewalks
Each lane needs some geometry:
- center lines to draw agents on
- for sidewalks, use center line to to draw agents on the left and right sides?
- polygons to draw the lane and mouseover
Open questions:
- Can we assume all lanes are the same width?
- Seems wrong for many sidewalks especially
- Could be wrong for bike lanes, but could just assume it's a bike lane with a buffer
- Some lanes are immutable
- Sidewalks can't be changed to other types; they're raised with a curb
Some modeling questions:
- Where should expansion of roads into lanes happen?
- initial OSM conversion, adding more stuff to the proto?
- initial map_model::new loading, at least for development convenience
- same reason that turns aren't (yet) serialized
- Is it useful to model the entire road?
- the parent/child relation may be hard to maintain
- but lanes need to know their siblings
- maintaining directional sanity could be useful
- what's the UI for changing lane types?
- it's a bit arbitrary which lane should draw the yellow center lines
Initial design:
- "Road" becomes "Lane" with a type
- don't need to know sibling lanes yet
- arbitrarily, one lane might have extra bits/geometry for yellow center line markings
- ideally, get rid of one-wayness and original center points, and plumb along pre-shifted lines
- but due to the polyline problem (affecting both geom center line layer that agents follow, and polygons for drawing), can't do this. encapsulate the messiness at least.
- so, store one way and orig points and index, but have an accessor
- as a compromise, dont interpet OSM points on a one-way road as the center, but as the edge? this is proving hard to do.
Thinking about a new design:
- Much more general "Land" primitive that's just a nice polygon boundary for drawing/selection and one (or more, for sidewalks?) center lines for how to cross the space, with a notion of turns. It's what road is now, but way simpler data.
- Maybe the GeomRoad / DrawRoad split is a little confusing after all, since the layering just isn't perfect. figure out the polygon and centerline up-front, then ditch the other intermediate gunk.
- also ideally make one polygon for the road, not a bunch of individual pieces? but then we'd have to go triangulate later for opengl anyway
- enforce that all the polygons are nonoverlapping
The polyline problem:
- https://www.codeproject.com/Articles/226569/Drawing-polylines-by-tessellation
- https://stackoverflow.com/questions/36475254/polylines-outline-construction-drawing-thick-polylines
- Will lengths change? Is this a problem?
- Drawing cars as rectangles is funky, because if their front is aligned to a new line segment, their back juts into the center of the road
- https://hal.inria.fr/hal-00907326/document
- https://www.researchgate.net/publication/220200701_High-Quality_Cartographic_Roads_on_High-Resolution_DEMs
https://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
- Seemingly: line intersection of shifted lines yields the new joint point, which looks good.
- Length increases or increases depending on the original angle and the
side of the road, but of course it does.
- Width of the road varies wildly in the joint
- For drawing, round caps works nicely.
the transition is hard:
- who should be responsible for shoving road lines back to not hit intersection?
- intersection and road association is done by points... gps or not?
- also need to retain other_side only temporarily for map construction.
- organize map_model lib more; map construction is now very interesting
- arguably, we could do two-phase map construction and serialize more stuff. map model is serializable because of rust magic!
- map model kind of acts as the graph/connection layer. keep the construction more separated.
- should all GPS stuff be converted to screen at loading time? (it'd be nice to use pt2d for screen space only)
- dependency hell most easily resolved by putting polyline stuff in map_model
so really do this in two parts:
1) current structure with weird intermediate stuff, but new geometry libs
2) careful reorg
wait slow down even more -- before any of this change, lanes on adjacent roads smoosh into each other. main road doesnt, but other parts do.
- at every intersection, find corresponding lanes and trim back center lines
- do we need to do this at the level of the polygons?!
- follow aorta's multi phase map construction better.
- polish intersection geometry
- figure out how to iterate quickly in experimental.
- aha, big bug! we only try to trim first/last lines. do the whole polyline.
- can think of an easy fixpoint approach to try first, even though it's inefficient.
- wait, the fixpoint is also incorrect. :(
- before trimming back lines, project out the correct width. sort all those points by angle from the center. thats the intersection polygon? then somehow trim back lines to hit that nicely.
- do the current trim_lines thing, but with lines, not segments? no, there'd be many almost-parallel lines.
- at a T intersection, some lines aren't trimmed back at all
- the lane polygons overlap, even though the lines dont
- https://www.politesi.polimi.it/bitstream/10589/112826/4/2015_10_TOPTAS.pdf pg38
- just make polygons around center lines, then intersect?
- shift turn icons and stop markings and such away from crosswalk
- rename Road to Lane
- bad polygons when shifted lines invert points
- arguably, these could be a case when there's not enough room to shift away.
- render trees?
- revisit parks/water (as parcels / areas, maybe)
- big maps start centered over emptiness
- some bldg paths are quite long.
- make final Map serializable too
- useful to precompute sidewalk paths
- waiting on https://github.com/paholg/dimensioned/issues/31 to release
- move map_model geometry stuff elsewhere (sim stuff also needs it though)
- also a polygon struct? for parcels and buildings. maybe have a form that's pre-triangulated?
- isolate vec2d
- figure out what to do about yellow center lines
- yellow and white lines intersect cars and turn icons and such
- who should own drawing them?
- trim them back too (maybe to avoid hitting the intersection?)
- osm tags and such would ideally be part of a master road
Crosswalk notes:
- Turns go from a src to a dst, so we'd need to double them for crosswalks, since they're always bidirectional
- Turn icons might not make sense as a UI?
- Many sidewalks directly connect at corners and shouldn't have anything drawn for them
- We don't want to draw diagonals... just from one side of the road to the other
- We want crosswalks at the beginning AND end of the sidewalk!
- v1: remember other_side for sidewalks too. draw crosswalks at the beginning AND end of every sidewalk lane.
- do extra drawing in DrawIntersection for now, figure out modeling later.
How to depict stop signs? Each driving lane has a priority... asap go or full
stop. Turns from go lanes might be yields, but shouldn't need to represent that
visually.
- Easy representation: draw red line / stop sign in some driving lanes. Leave the priority lanes alone.
- Harder: draw a stop sign on the side of the road by some lanes. Won't this look weird top-down and at certain angles?
Traffic signals?
- per lane would be weird.
- drawing turn icons as red/yellow/green is pretty clear...
- could draw an unaligned signal box with 3 circles in the middle of the intersection, but what does it represent? maybe just an initial indicator of what's going on; not full detail.
- similarly, draw a single stop sign in the middle of other intersections? :P
GUI refactoring thoughts:
- GfxCtx members should be private. make methods for drawing rectangles and such
- should be useful short term. dunno how this will look later with gfx-rs, but dedupes code in the meantime.
- should GfxCtx own Canvas or vice versa?
- Canvas has persistent state, GfxCtx is ephemeral every draw cycle
- dont want to draw outside of render, but may want to readjust camera
- compromise is maybe storing the last known window size in canvas, so we dont have to keep plumbing it between frames anyway.
One UI plugin at a time:
- What can plugins do?
- (rarely) contribute OSD lines (in some order)
- (rarely) do custom drawing (in some order)
- event handling
- mutate themselves or consume+return?
- indicate if the plugin was active and did stuff?
- just quit after handling each plugin? and do panning / some selection stuff earlier
- alright, atfer the current cleanup with short-circuiting... express as a more abstract monadish thing? or since there are side effects sometimes and inconsistent arguments and such, maybe not?
- consistently mutate a plugin or return a copy
- the Optionals might be annoying.