15 minute neighborhoods

[dabreegster]

At the hackathon this Saturday, we're going to focus on a tool to explore 15 minute neighborhoods. There's been lots of press about these lately.

The vision: An open source tool to understand not only how walkable a place currently is, but also what it might take to improve things. Bring in land use and census data, to figure out what areas are in the most need of easier access to some amenity, and what buildings/land parcels might be eligible to become multi-use.

Inspiration:

• https://blog.conveyal.com/access-in-seattle-fb5ef952c3ae
• https://app.developer.here.com/15-min-city-map/
• https://www.remix.com/
• https://www.open-accessibility.org/
  • https://www.open-accessibility.org/15minutecity/

To my knowledge, GOAT is the only open source tool to explore 15 minute cities.

Relation to A/B Street

Ideally this new tool would be spun off from A/B Street. Similar to the new OpenStreetMap viewer mode and a few others, there are an increasing number of experiments not related to the core gameplay, but leveraging lots of the same code. Focusing on 15 minute neighborhoods is a much simpler problem than traffic simulation -- milestones are much easier to reach if solving gridlock and modelling lane-changing properly isn't a prereq. :) Until some of the technical issues are solved to split the code into pieces better, this new 15-minute experiment will just be a mode accessible from the main screen.

Right now, A/B Street the game focuses on improving trip times as its score. People don't change their trip modes based on map edits. As we move more towards the direction of measuring overall mobility / access to useful stuff and figure out how to model mode choice changes, I think some of the ideas/code from the 15-minute tool could start to converge with the game.

Tasks and ideas

The code lives here: https://github.com/dabreegster/abstreet/tree/master/game/src/devtools/fifteen_min

Design / non-programming

• UI mocks -- what should the panel look like for controlling the basic functionality?
• how to display/organize information about the commercial amenities available?
• how should we visualize population density near a building?
• how should we visualize land use / zoning codes to understand what buildings might host new stores?
• [ ] organize raw OpenStreetMap amenities into better categories

Core isochrone algorithm

• [X] make the isochrone implementation return time, not distance
• [ ] hard: handle PathConstraints::{Bike, Car} (then select these through the UI)
• [X] make the isochrone implementation floodfill out, instead of calculate O(n) paths
• [x] medium: filter out results > 15 minutes
• [ ] hard: stop the Dijkstra's floodfill > 15 minutes (more efficient)
• [ ] hard: generate polygons exactly between two thresholds
• [x] easy: generate more exact costs for buildings in the middle of a sidewalk by adding in distance from the intersection
• [ ] hard: consider calculating isochrones differently -- per side of the road?
• https://wiki.openstreetmap.org/wiki/Isochrone#Technical_details

Basic UI:

• [x] easy: switch maps using CityPicker
• [x] easy: click a building to re-center the isochrone
• [x] easy: add a ColorLegend to the panel and label the 5, 10, 15 minute marks
• [x] easy: add an "About" button with a popup explaining the tool
• [x] medium: as you hover over a building, draw a tooltip with the time to get there
• [x] medium: as you hover over a building, draw the route from the start to that building

Add detail to the UI:

• [x] medium: count amenities in the reachable buildings, display summary/breakdown in the UI panel
• [x] hard: count free / total parking spots within the walkshed
• [x] hard: count population density, based on what the scenario data says

Summary tools to understand an entire city without having to check an isochrone everywhere:

• [x] very hard: sample buildings in an entire map, find areas that are / are not 15 min neighborhoods
• [x] very hard: food deserts: calculate and visualize things like number of people not within 15 minutes of a grocery store

Bring in more data layers to understand potential for change:

• [ ] very hard: import zoning/land use maps from KCGIS, add a layer to show this
  • https://data-seattlecitygis.opendata.arcgis.com/datasets/current-land-use-zoning-detail
  • https://data-seattlecitygis.opendata.arcgis.com/datasets/parcels-1
• [ ] very hard: a-b-street/abstreet#116 - bring in equity/demographic info, show it from isochrone UI

Let people make changes to the map to affect the isochrones:

• [ ] very hard: let players "upzone" some buildings and define what types of amenities they'd want somewhere. update isochrone accordingly. not sure if this should be expressed through map edits or not
• [ ] very hard: calculate differential isochrones across changes like upzoning; same walkshed, but update the scores?

More unsorted ideas:

• [X] custom walking speed
• [X] allow walking on the shoulder, or require actual sidewalks
• [ ] penalize crossings that're likely to take a bit (waiting for a signal or unprotected crossings where drivers aren't likely to immediately stop)
• [ ] Elevation data
• [ ] Avoid roads with high historic collision rate (and point them out)
• [ ] Avoid freight routes

The walking isochrones themselves aren't super interesting; getting public transit routes imported from OSM properly would mak all of this work much more interesting.

[JavedNissar]

Would it be worthwhile to split this out into separate issues that link into this?

[dabreegster]

Would it be worthwhile to split this out into separate issues that link into this?

That'd be useful longer term, but for a one-day hackathon, I think having everything together in one place is easier. Especially since some of the harder tasks haven't been broken into pieces yet

[michaelkirk]

easy: click a building to re-center the isochrone

🙋 I'm going to work on this one.

Would it be worthwhile to split this out into separate issues that link into this?

That'd be useful longer term, but for a one-day hackathon, I think having everything together in one place is easier.

I agree it could be counter-productive to dump two dozen new issues into the issue tracker that might not be relevant after the today, but to organize any discussion that rises up on a particular issue, maybe it makes sense to separate out issues that are actually being worked on...

In that vein, I've made: https://github.com/dabreegster/abstreet/issues/395

[dabreegster]

Just seeing this, sorry -- other uses of PopupMsg are good examples to follow

[michaelkirk]

easy: switch maps using CityPicker

🙋 I'm going to work on this one.

[michaelkirk]

medium: as you hover over a building, draw the route from the start to that building

🙋 I'm going to work on this one next.

[JavedNissar]

easy: generate more exact costs for buildings in the middle of a sidewalk by adding in distance from the intersection

I'll give this one a shot

[dabreegster]

I'll give this one a shot

Thanks! The changes should happen in all_costs_from, and building.sidewalk_pos should help. Let me know if you hit any snags

[JavedNissar]

How would I go about grabbing the distance from the sidewalk here?

        let graph = build_graph_for_pedestrians(map);
        let start = WalkingNode::closest(map.get_b(start).sidewalk_pos, map);
        let cost_per_node = petgraph::algo::dijkstra(&graph, start, None, |(_, _, cost)| *cost);

        // Assign every building a cost based on which end of the sidewalk it's closest to
        // TODO We could try to get a little more accurate by accounting for the distance from that
        // end of the sidewalk to the building
        for b in map.all_buildings() {
            if let Some(seconds) = cost_per_node.get(&WalkingNode::closest(b.sidewalk_pos, map)) {
                let duration = Duration::seconds(*seconds as f64);
                if duration <= time_limit {
                    results.insert(b.id, duration);
                }
            }
        }

[dabreegster]

WalkingNode::closest(b.sidewalk_pos, map) gives you a WalkingNode with the sidewalk as the lane and a boolean representing either 0 distance along that lane, or the full length of the sidewalk. b.sidewalk_pos is a Position, with the same lane, but a distance somewhere in [0, full length]. So you should be able to figure out the distance the WalkingNode represents, then subtract the b.sidewalk_pos.dist_along() for the two positions, take the absolute value, and divide by opts.walking_speed to get the additional time

[JavedNissar]

@dabreegster I've taken a shot at addressing the addition of distance from sidewalk in a-b-street/abstreet#443

[dabreegster]

David Nicholson found the project through DemocracyLab and has contributed some detailed UX notes: 1_28_21 Notes on A_B Street 15 Minute (Web Tool)(1).docx.pdf

[dabreegster]

Some notes from a call with David:

• consider moving the search button next to the address; he expected to click and edit the address
• consider listing amenities with multiple columns, to reduce vertical scrolling

[tnederlof]

@dabreegster I recently found your amazing project and it will take me a bit to explore the various parts (an amazing amount of features you have built). I am currently in a master's program and have been doing some work around walkable cities and transportation more broadly. I would love to help on some of the issues you outlined, as I discover what is involved I will stick my hand up for specific features. Could you please link to the latest code? I found a dead link in your original issue post. Thank you!

[dabreegster]

Hi @tnederlof! The 15m code is now at https://github.com/a-b-street/abstreet/tree/master/fifteen_min/src. If you're diving into the Rust code, https://a-b-street.github.io/docs/dev/index.html has instructions for building. The 15m tool has a web version linked at https://a-b-street.github.io/docs/side_projects/fifteen_min.html. Also happy to schedule a videocall to chat!

[tnederlof]

@dabreegster thank you for the links, its great to see what's already there on the web version. I don't have much prior experience in Rust but I have poked around projects before, nothing like a good motivating project to dive in deeper! I would love to videocall sometime, I have seen a bunch of issues that I would love to contribute to. My email is on my profile.

[tnederlof]

I started to work on organizing categories better (and also sorting them). One thing I ran into is the difference between Amenity and Shop, I feel like there are some of each that would belong as a possible option in this tool. @dabreegster what are your thoughts on Amenity (Supermarket, Clinic, etc.) and Shop (Butcher, Bakery, etc.)? Should they be two different types or all be AmenityType in abstreet? It looks like for buildings its: pub amenities: Vec<Amenity>,

[dabreegster]

It looks like OSM uses both shop= and amenity= to refer to different businesses: https://wiki.openstreetmap.org/wiki/Shops#How_to_tag And actually, reading that wiki more carefully, it looks like we should also be scraping craft=* and office=*!

The intention of amenities: Vec<Amenity> is to capture all of the commercial uses in a building. Is there a reason we should also distinguish amenity vs shop? If the difference is important, I'd vote we update AmenityType to capture the distinction, instead of putting a new field on Building, since there's lots of UI and travel demand code that looks at the amenities field today.

[dabreegster]

For reference, https://github.com/a-b-street/abstreet/blob/93e721c88f0b47303f151ec3019857f4259d7e1c/convert_osm/src/extract.rs#L540 is the place that builds this vector from OSM. It happens during import.sh --raw, which is the import phase that handles .osm files

[dabreegster]

And also, we have two groupings of amenities today -- the main one at https://github.com/a-b-street/abstreet/blob/93e721c88f0b47303f151ec3019857f4259d7e1c/map_model/src/objects/building.rs#L244, and https://github.com/a-b-street/abstreet/blob/93e721c88f0b47303f151ec3019857f4259d7e1c/popdat/src/make_person.rs#L63 for one of the travel demand models. The second is a bit different, since it maps an activity a person might do to the types of shops that might fulfill that.

[tnederlof]

It looks like OSM uses both shop= and amenity= to refer to different businesses: https://wiki.openstreetmap.org/wiki/Shops#How_to_tag And actually, reading that wiki more carefully, it looks like we should also be scraping craft=* and office=*!

The intention of amenities: Vec<Amenity> is to capture all of the commercial uses in a building. Is there a reason we should also distinguish amenity vs shop? If the difference is important, I'd vote we update AmenityType to capture the distinction, instead of putting a new field on Building, since there's lots of UI and travel demand code that looks at the amenities field today.

Okay great all of those references are really helpful. From reading the OSM materials it seems like amenity is just labeled because they think those are more important or useful especially for tourists. That distinction seems a bit odd to me and for our use case I would argue the distinction is not important. I think folding in "shop", "amenity", "craft", and "office" into AmenityType makes sense.

It looks like the get_bldg_amenities() function already pulls in "shop" and "amenity", so I can add "office" and "craft" there. Then work on making the AmenityType in buildings.rs more organized to cover all of those four OSM tags. Does that sound like the right course of action?

[dabreegster]

Yep, sounds good!

On Mon, May 3, 2021, 11:36 AM Trevor Nederlof @.***> wrote:

It looks like OSM uses both shop= and amenity= to refer to different businesses: https://wiki.openstreetmap.org/wiki/Shops#How_to_tag And actually, reading that wiki more carefully, it looks like we should also be scraping craft= and office=!

The intention of amenities: Vec is to capture all of the commercial uses in a building. Is there a reason we should also distinguish amenity vs shop? If the difference is important, I'd vote we update AmenityType to capture the distinction, instead of putting a new field on Building, since there's lots of UI and travel demand code that looks at the amenities field today.

Okay great all of those references are really helpful. From reading the OSM materials it seems like amenity is just labeled because they think those are more important or useful especially for tourists. That distinction seems a bit odd to me and for our use case I would argue the distinction is not important. I think folding in "shop", "amenity", "craft", and "office" into AmenityType makes sense.

It looks like the get_bldg_amenities() function already pulls in "shop" and "amenity", so I can add "office" and "craft" there. Then work on making the AmenityType in buildings.rs more organized to cover all of those four OSM tags. Does that sound like the right course of action?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/a-b-street/abstreet/issues/393#issuecomment-831450534, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMWLF53NBA2R62XZ6BEY43TL3ULJANCNFSM4T2VO2YA .

[RichMorin]

A few years ago, Amanda Lacy and I prototyped the Muddy Map Explorer, a blind-friendly neighborhood exploration tool based on OpenStreetMap data. The name came from the fact that it used a textual, MUD-like user interface. Although it worked (for some value of "work" :-), it had severe problems dealing with issues in the OSM data.

For example, we found that complex situations (e.g., shopping centers, freeway interchanges) were very hard to describe, let alone navigate. Other problems had to do with the fact that OSM data isn't really well optimized for pedestrians. As you have observed, streets are simply series of points, so road widths and accessibility obstructions aren't recorded in a particularly useful manner.

Anyway, it looks like you have done quite a bit of the heavy lifting to resolve some of these problems. I wonder if it's worth trying to layer some of Muddy's UI on top of your infrastructure...

[dabreegster]

A few years ago, Amanda Lacy and I prototyped the Muddy Map Explorer

Wow, this is a really awesome use of OSM data! All I could find about the project is https://www.youtube.com/watch?v=mY0DXLTPLQ0. The wiki link https://wiki.cfcl.com/Projects/Muddy seems to be down. Is any code or demos of it still online?

And by the way, it's a bit serendipitous that Amanda was at UT -- that's actually where I got started too. My first semester of undergrad, I drew this map of campus by hand: The blue blobs are doors into the building, and the black rectangles were construction as of fall 2010. Over that winter break is when I discovered OSM.

road widths and accessibility obstructions aren't recorded in a particularly useful manner.

Two projects that may be relevant, in case you haven't seen them: https://www.opensidewalks.com/ (they're active right now and always looking for contributors -- I was at a hackathon yesterday with them) and a tactile map generator by @matkoniecz

Anyway, it looks like you have done quite a bit of the heavy lifting to resolve some of these problems. I wonder if it's worth trying to layer some of Muddy's UI on top of your infrastructure...

I would like to say yes, but unfortunately A/B Street doesn't have good support for pedestrian infrastructure. When sidewalks are mapped in OSM as separate ways, abst totally ignores them currently and instead treats sidewalks as another "lane" on the road. It also infers crosswalks at every possible position, which is far from realistic. There are a number of problems with almost-parallel ways next to the main road -- a-b-street/osm2streets#59. For an extreme example where abst's inference is very wrong about sidewalks, in downtown Seattle (https://www.openstreetmap.org/#map=19/47.61506/-122.33766): This triangular shape is actually one complex junction, but currently abst thinks there are sidewalks on the "interior" of the triangle. And the heuristics even omit the sidewalk on the other side of the one-way roads.

If you'd like to try to make use of abst's processing of OSM data, https://a-b-street.github.io/docs/tech/map/index.html describes the map model. We could explore ideas for reading the map format in your favorite language or providing a proper API to call it. But depending what Muddy Map Explorer needs to do, there might be many things that are too broken to proceed usefully.

[matkoniecz]

tactile map generator by @matkoniecz

Right now main published outcome is https://github.com/matkoniecz/lunar_assembler that includes both using area:highway data ( https://mapsaregreat.com/osm_to_svg_in_browser/laser_road_area ) and attempts to generate symbolic footway maps from existing data ( https://mapsaregreat.com/osm_to_svg_in_browser/laser_neighbourhood )

I will be publishing soon(TM) more - tow articles describing process and made maps

[RichMorin]

On Sep 19, 2021, at 10:27, Dustin Carlino @.***> wrote:

A few years ago, Amanda Lacy and I prototyped the Muddy Map Explorer

Wow, this is a really awesome use of OSM data! All I could find about the project is https://www.youtube.com/watch?v=mY0DXLTPLQ0. The wiki link https://wiki.cfcl.com/Projects/Muddy seems to be down. Is any code or demos of it still online?

Sadly, cfcl.com is currently out of service. I'm hoping to bring it back online this Fall, but no guarantees are made or implied. In any event, the .../Projects/Muddy area basically contained only descriptive material.

The version of Muddy that we developed was basically just an experimental prototype. There was some tooling to download a selected set of OSM data, covering a rectangular region around Amanda's home. An interactive program then used this data to generate scene descriptions, support interactive navigation, etc.

Most of Muddy's code was written in Ruby and run from the macOS command line. So, any user would need to be fairly competent at using the CLI, setting up the code and data, etc. This approach worked fine for our development and experimentation, but it's clearly inappropriate for a production version.

A second generation version could implemented as an interactive web site. This would download OSM data as needed, maintain the user's navigation history, etc. If I were doing this, I'd probably use Elixir and related tooling (e.g., LiveView, Phoenix). So, it could maintain each user's state using lightweight processes (i.e., Actors) and a simple backing store.

-r

[RichMorin]

On Sep 19, 2021, at 10:27, Dustin Carlino @.***> wrote:

A few years ago, Amanda Lacy and I prototyped the Muddy Map Explorer

Wow, this is a really awesome use of OSM data! All I could find about the project is https://www.youtube.com/watch?v=mY0DXLTPLQ0. The wiki link https://wiki.cfcl.com/Projects/Muddy seems to be down. Is any code or demos of it still online?

Sadly, cfcl.com is currently out of service. I'm hoping to bring it back online this Fall, but no guarantees are made or implied. In any event, the .../Projects/Muddy area basically contained only descriptive material.

The version of Muddy that we developed was basically just an experimental prototype. There was some tooling to download a selected set of OSM data, covering a rectangular region around Amanda's home. An interactive program then used this data to generate scene descriptions, support interactive navigation, etc.

Most of Muddy's code was written in Ruby and run from the macOS command line. So, any user would need to be fairly competent at using the CLI, setting up the code and data, etc. This approach worked fine for our development and experimentation, but it's clearly inappropriate for a production version.

A second generation version could implemented as an interactive web site. This would download OSM data as needed, maintain the user's navigation history, etc. If I were doing this, I'd probably use Elixir and related tooling (e.g., LiveView, Phoenix). So, it could maintain each user's state using lightweight processes (i.e., Actors) and a simple backing store.

-r

[dabreegster]

https://content.tfl.gov.uk/connectivity-assessment-guide.pdf awesome resource on PT isochrones

[dabreegster]

More tasks after the new PR:

• [ ] for the score homes mode, discrete categories would be much more visually comprehensible than the current gradient color scheme
• [ ] hover or click a particular building in score home mode, to see which of the categories are satisfied or not (and show paths to the closest of each category)
• [ ] look into the isochrone output; I think it might be flaky given the same input?!
• [ ] for score homes mode, possibly count the total number of matching shops within range, instead of limiting to one per category. Being close to 1 and 10 grocery stores is very different. This'd be much more expensive though, of course

Also think about the tension between an amenity and a building. The 1st mode displays 2 matches (because they're in the same building), but the table has 3. 3 makes more sense; they're separate shops. But on the flip side, things like school campuses consist of tons of buildings nearby, and over-counting there is annoying. Plenty of higher-level relation structure in OSM to consider.

[dabreegster]

https://ipeagit.github.io/intro_access_book/en/index.en.html has generally applicable ideas/context