Improve the 15m isochrone view, by coloring roads without any buildings

[dabreegster]

See #669 for context on the problems. I've chatted about this problem with @tnederlof, @booboo18, @adam-jb, and @mfbenitezp before, so CC if y'all're interested!

The changes

Before:

After:

Before:

After:

I'm honestly not sure if this is an improvement or not. The new change fills in more gaps/holes when there are no buildings around, but there are still some unexplainable gaps.

Implementation

https://a-b-street.github.io/docs/software/fifteen_min.html#implementation is an overview how this works. The big picture is somewhat simple:

1. Run Dijkstra's algorithm from a start point, recording the cost to reach every building. Stop after the cost exceeds 15 minutes.
2. Tile the world in 100x100 meter squares. Use each building centroid and fill one of the squares with the cost (in seconds) to reach that square.
3. Run through a Marching Squares library to turn the grid into contours
4. Render

The change here is to not just populate squares based on building centroids. During the graph search, we cross road segments that have no buildings attached to them. When we do, also remember the cost to reach that road. Then we can walk along the road's center-line in 50m steps, find the 100x100 square, and fill out a cost value too.

Complications:

• This could be misleading with very long roads, since we treat the entire road as having one cost
• The 100x100 squares filled out from building centroids and roads may conflict. In this implementation, we blindly overwrite with the value from the road.

To visualize what's happening more clearly, we can just lower resolution_m to 10x10:

You can see the blobs of green, yellow, and red filled out on building centroids, and in a few places, along a road segment with no matching buildings.

Feedback

Any ideas to improve this? Is there another isochrone / walkshed tool that has particularly easy-to-understand output, even in the presence of large empty water/green space?

[mfbenitezp]

In general, as this tool isn't about spat analysis, calculating areas or another decision-making process, but a thematic map, I would suggest filling up the gaps...then the map isn't confusing.... at the same time, once the zoom (not scale) is out, then the map would provide a correct representation., also I will restrict the zoom-in to a certain scale. I believe that 1:500 is actually too much detail for the purpose of the map/app., so then the user is forced to take a look at how the isochrones are spat distributed. If the area is needed, the calculation of that area can be done before filling the gaps and describing the scale where that calculation was made., so the user knows the level of detail.

[booboo18]

Hello Dustin Thank you for your explanation. I agree with Fernando it is worth filling the gaps as it can be confusing. There still seems to be some gaps on the network. Below is an example where streets on both end are accessible within 15m but not the parts in between. [image: image.png] Not an expert in isochrones but another approach is to find all the furthest nodes reachable by Dijkstra and then running concave hull using these nodes. This should cover lakes and parks enclosed within the graph but i can imagine it might not work in some edge-cases. regards Stephen

…

On Thu, Mar 16, 2023 at 12:09 PM Fernando Benitez-Paez < ***@***.***> wrote: In general, as this tool isn't about spat analysis, calculating areas or another decision-making process, but a thematic map, I would suggest filling up the gaps...then the map isn't confusing.... at the same time, once the zoom (not scale) is out, then the map would provide a correct representation., also I will restrict the zoom-in to a certain scale. I believe that 1:500 is actually too much detail for the purpose of the map/app., so then the user is forced to take a look at how the isochrones are spat distributed. If the area is needed, the calculation of that area can be done before filling the gaps and describing the scale where that calculation was made., so the user knows the level of detail. — Reply to this email directly, view it on GitHub <#1075 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQXXMA4I76ECNZWY6ESD7DW4L7HDANCNFSM6AAAAAAV5DQEGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dabreegster]

Thanks Stephen! Just copying the image here for easier reference (In github's UI, you can click the "Attach files by dragging" bit at the bottom of the comment box, but sometimes it messes up):

I haven't considered trying concave hull around farthest points. That would probably look great for a single "what's reachable" visualization, but maybe to distinguish 5, 10, and 15 minute bands, it'd be necessary to do some polygon difference afterwards. I'll try and experiment with this idea when I get time