Specify main traffic roads before drawing LTN? #47
Comments
This is a fascinating use of the tool I hadn't anticipated! It does make sense, as long as you don't care about any potential trips that either start or end inside the area. Your screenshot of the tool has so much going on, I'm happy to see it pushed to limits. Are things like the cell coloring even working and clear enough there?
I don't think the "a street should belong to one and only one project" part is right. A project is just a savefile, meant to match up to something that the user wants to study. The area imported just has to be large enough to include any neighbourhood zones that'll be inside. And when the "Predict impact" feature is ported over, large enough to include any big sources/destination of traffic that might be useful to look at. Smaller imported areas are indeed faster. If you've drawn a custom one that's slow to load from Overpass every single time, send me the exported .geojson file (which will include that boundary), and I can add it to the list of pre-set example areas, and it'll use a cached .osm.pbf extract to be faster.
Once you're editing a neighbourhood, there's a "Change this boundary" link in the top-right. Does that help at all? If you want to grow or shrink the boundary, you can use it. You could also draw a second neighbourhood that partly overlaps other ones. Unlike the old version of the tool, it's just a list of polygons. There's no data stored per neighbourhood aside from the name and shape. All the modal filters and one-ways and stuff are separate.
I think this could indeed be useful. The old version of the tool started with this model, making assumptions from OSM tags about the main road arteries and attempting to auto-split districts. There were many bugs with this, and if you wanted to shift the boundaries to fit different main roads, it was kind of confusing. I like the idea of starting instead by "painting" all the main roads and other severances, then just geometrically taking all the polygon zones that come from that. I think there are at least two types of users for this tool. Councils I've worked with before are usually looking at one or two neighbourhoods at a time. If there were multiple LTNs under consideration in different parts of the city, they'd probably use separate "projects" for them. The new tool as it is now is designed for this use case, where they know the neighbourhood boundary upfront and start by drawing it. The other type of user is yourself, where you want to consider LTNs everywhere. The nice UX for this probably is starting with some configurable assumptions of main roads, letting you change these around, and having neighbourhoods created for all of the polygons in between. These city-wide projects with LTNs everywhere are more ambitious and definitely the sort of thing to encourage studying! So I'll think about how to implement this. |
|
And by the way, #21 has some research from London about how to prioritize between different districts. Longer-term, exposing some of those same metrics could be useful on top of this feature. (It won't be easy for census things that differ regionally, but that's what https://github.com/Urban-Analytics-Technology-Platform/popgetter is looking to solve.) Maybe something like:
|
You're absolutly right: I've been using the tool in these two kind of process.
I've been really impressed by the fact that even with a very large district (as you saw on the first screenshot), both the UI and the backend (that recomputes the ratruns dynamically) was very fast (I would even say it's clearly interactive). That's the reason I would want to consider the whole town as one single entity. I'll be sure to give you the geojson :)
Yes, it helps. I'm still a bit confused about what is stored where. For example, by deleting a district, and redrawing a new one, it "restored" the modification I did on the first version. To help with the UX, I would consider some kind of "versioning" of projects. Like working on SOHO with 3 differents propositions, and be able to quickly switch from one to another. But I realize that would lead you into VCS theory and conflicts management, it may be a bit too far from your current priorities.
On that note, it's funny because I'm also studying severances and I saw your (other) prototype a few weeks after I've been plunging into this topic (and now, after 2 hours of searching it, i'm pretty sure that I lost the map of Montpellier's severances that I worked on for more than days 😭) |
What "modification" do you mean -- the district drawn has the same shape immediately as the old one? That might be a bug with the route-snapper; I've seen it before during development, but I thought it was just due to Vite doing live code reloading. If you mean the modal filters and one-ways, then that's intentional. Changes to the map are stored independently of the neighbourhood you're editing. The neighbourhood is just a "view" into the current state of the map, showing cells and shortcuts.
Like the proposal switching in the old version? #12 is planned for that. Neighbourhoods would stay fixed, but you could switch between proposals, and see your modal filters + one-ways change as a group. I dunno about merging or comparing proposals; that indeed gets into VCS territory and is not an easy UX to think through :)
Oh no, I'd love to see the map if you do find it. Severance Snape calculates severances just by looking at OSM tags: https://github.com/dabreegster/severance_snape/blob/b97ad1cab01efa17e8b7ae593434f19945e4d817/backend/src/scrape.rs#L152. The logic has some problems depending how sidewalks are tagged. It doesn't yet attempt severances like rivers, railways, or big buildings that the public has to walk around and not through. |
Yes, it was the modal filters / one-ways. So a district is purely a "focus area" in your mind? The use should mainly think as "the project" (and maybe its different proposals if #12 is implemented) as the their work? So another interpretation is that the district (even by editing its boundary) is a non-mutable operation? Ok so if edits are contained in the project/proposition layer, there should not be any conflicts since there would be no merge operation. (Still, there's the possibility of comparing 2 proposals.). Then, it would be more logical that the editing tools (modal filters, change directions) would be relocated on the proposition step. And that districts are only a tool to focus the routing visualization, no ?
Finally found it: https://umap.openstreetmap.fr/fr/map/analysemontpellier_993716#14/43.6012/3.9099 |
All correct, yes.
Do you mean the "Pick neighbourhood" page? I think that wouldn't be intuitive, because
I'm guessing the way it works now is confusing, but I'm not sure what to do to clarify it, or if it should work differently.
This is quite cool! One of my work projects is about collecting quick sketches of routes, areas, and crossings that a council is proposing to change. Maybe the workflow for the LTN tool could have an optional step of importing a general sketch around an area, and using routes marked as severances to define districts. |
After a few hours of experience, I would consider a small change in the UX workflow. Right now, it's very difficult to reason on more than a very specific and well-formed district.
In my current work, i'm trying to study a few actual / current rat-runs in the city of Montpellier. Especially, I'm trying to find where do they come from upstream-wise. The city doesn't have districts that are completely "sealed" (true LTN) but I can somehow hack the tool by specifying a larger zone. Then those ratruns are clearly identified and I can study them easier than with classic pen and paper.
===============
From what I understand of the current workflow:
A) The project should be the whole town / metropolitan area on which the user is currently working. I'm pretty sure that for every street, it should belong to one and only one project (Of course, right now, i'm pretty sure some users specify smaller-than-town projects to limit the number of data you need to store/download... but I don't think it should be normal workflow. The frequently downloaded geojson could be cached, no? Especially if the perimeter of the project could follow the perimeter specified by OSM / areacode).
B) Then neighbourhoods are the zones the user wants to be LTN / traffic pockets / islands. The main goal is usually to edit them to limit the traversing traffic of each pocket.
Currently, the project forces you to "early on" decide on the perimeter of a single neighborhood you'll be working. I think there's a missing step between A and B where the user could paint the "main" road arteries (i.e. define the main network of the city). Painting those roads would then help to segment your area into several districts.
I'm joining two examples of city layouts with their main networks.
What are your thoughts ? 😬
The text was updated successfully, but these errors were encountered: