Status updates

[dabreegster]

In lieu of a development blog or similar, I'll use this issue to summarize recent changes. I'm only able to spend a few days per week on this project right now, so the update cadence shouldn't be too fast. Anybody, feel free to comment here or open other issues.

12 February

Just to summarize from the last few weeks...

• After you draw a neighbourhood boundary, the "interior" roads where you can add modal filters, see shortcuts, etc should be much more accurate, as of 9 Feb. If you draw a boundary and see red shortcut roads along the perimeter or in unexpected places, please file an issue
• The "view shortcuts" page sorts the shortcuts by "likelihood", showing less unrealistic ones last
• I started using https://picocss.com/ for styling, and am trying to be consistent about UI patterns. The top bar has breadcrumb navigation that hopefully makes the flow through the app clear. The top right of that has links to the next pages. I'm trying to consistently use links as navigation to different pages / modes, and buttons for actions that don't change the current mode.
• Around Feb 2, I added a geocoder and basemap switcher. The different basemaps are buggy, because getting the Z-ordering correct is tough -- need to do something totally different for each basemap, since they use different layer names for things like buildings / land use polygons / road labels.

The biggest next thing I want to start is detecting existing modal filters from OSM, and making sure that works correctly with the edits / undo tools.

[rouelibre1]

Thanks for opening this issue.

I'm not quite sure if turn restrictions are already implemented ?

Also, handling the key "https://wiki.openstreetmap.org/wiki/Key:priority" will be quite useful in Europe with our old streets that have narrow sections where there is alternate priority (it's ahint that the way is narrow and that cars drivers have to stop and wait to let other cars drivers exit the section before they can drive through it, so it's not as good as a modal filter, but it's definitely a bottleneck and though trafic is relatively limited)

Edit: Also, do you have any inputs on what would help you move faster on this project ? Even if the anwser is something like "funding" or "serious UX/UI bandwidth"

[dabreegster]

I'm not quite sure if turn restrictions are already implemented ?

Changing one-way directions or viewing / editing turn restrictions aren't even started. Turn restriction editing is hard and I probably won't get to it for quite a while. In the classic version of the tool, is the editing working well for your cases so far?

Also, handling the key "https://wiki.openstreetmap.org/wiki/Key:priority"

What should the tool do with this? Driving both directions is possible, just not as likely, so for the shortcut calculation, we could make it less likely, and maybe highlight that road and warn the user that any shortcuts using this section of road might be less likely. But beyond that, should it affect anything?

do you have any inputs on what would help you move faster on this project ? Even if the anwser is something like "funding" or "serious UX/UI bandwidth"

4 days per week are dedicated to other projects at least for the next year for me. I have the flexibility of mostly focusing on this tool for my 5th day, and on some weekends I've been doing a bit. But that's just not very much time, and having a 4 day break between working on it is tough. So to move faster, the main thing is a programmer who could work on this. I can help/guide/review PRs during the 4 days, but only focus on the 5th day every week. Luckily with this rewrite, the technical skills should be much easier to fulfill -- if you know anybody who's a frontend developer (TypeScript, Svelte, MapLibre GL), even if they didn't know how the backend is going to work at all, they could make things like the turn restriction editing UIs and everything else. (And in fact, lots of the hard parts of this are UI problems.) The "backend" logic would need someone happy to write Rust and learn about OpenStreetMap and some routing algorithms.

Edit: and besides those two developer skills, if you know anybody UXish who could wireframe how the app should work (especially as complexity creeps back in with one-ways, turn restriction editing, autosaving edits, comparing proposed edits, etc), that would be immensely helpful, because then I can stop figuring this kind of thing out as I go along

[rouelibre1]

I'm not quite sure if turn restrictions are already implemented ?

Changing one-way directions or viewing / editing turn restrictions aren't even started. Turn restriction editing is hard and I probably won't get to it for quite a while. In the classic version of the tool, is the editing working well for your cases so far?

From what I remember, the features in the classic version are great (I'm just stuck with some areas where I hit known limitations of the tool)

Also, handling the key "https://wiki.openstreetmap.org/wiki/Key:priority"

What should the tool do with this? Driving both directions is possible, just not as likely, so for the shortcut calculation, we could make it less likely, and maybe highlight that road and warn the user that any shortcuts using this section of road might be less likely. But beyond that, should it affect anything?

That's a bit like what I had in mind. Maybe have some sort of coefficient to reduce the likelyhood of the path being a shortcut?

do you have any inputs on what would help you move faster on this project ? Even if the anwser is something like "funding" or "serious UX/UI bandwidth"

4 days per week are dedicated to other projects at least for the next year for me. I have the flexibility of mostly focusing on this tool for my 5th day, and on some weekends I've been doing a bit. But that's just not very much time, and having a 4 day break between working on it is tough. So to move faster, the main thing is a programmer who could work on this. I can help/guide/review PRs during the 4 days, but only focus on the 5th day every week. Luckily with this rewrite, the technical skills should be much easier to fulfill -- if you know anybody who's a frontend developer (TypeScript, Svelte, MapLibre GL), even if they didn't know how the backend is going to work at all, they could make things like the turn restriction editing UIs and everything else. (And in fact, lots of the hard parts of this are UI problems.) The "backend" logic would need someone happy to write Rust and learn about OpenStreetMap and some routing algorithms.

Edit: and besides those two developer skills, if you know anybody UXish who could wireframe how the app should work (especially as complexity creeps back in with one-ways, turn restriction editing, autosaving edits, comparing proposed edits, etc), that would be immensely helpful, because then I can stop figuring this kind of thing out as I go along

I don't have specific idea in mind, but I believe it helps to have these needs laid down and visible to other people.
Also, in case I come across someone who could help on the project, now I won't hesitate to mention it to them :)

[dabreegster]

16 February

Two big chunks done today. First, existing modal filters from OSM are detected now. You can delete or modify them, add new ones, etc and the savefile handles everything properly, only storing changes. If the OSM basemap later changes, when you load your savefile, the right thing should happen. Existing filters are drawn kind of faded, similar to the v1 tool. BIg limit here is that the detection of existing filters is simple right now -- it's just looking for barrier nodes. There are both false positives and false negatives in areas I've checked. Will keep working on it, but if anybody notices any egregious errors, please comment in #6 with at least a link to the area in OSM.

And second, one-way handling is more or less working. There's a new tool in the edit page to toggle for any road. The UI is clunky, but that kind of polish can happen later (and preferably when I find some design help!). @rouelibre1 let me know if this any problems.

I have a few thoughts about what to try next. Since turn restrictions are useful, I might start them.

[TFCx]

Thanks for the update.

As this V2 seems to be in a usable state, I forwarded the link to a few friends. I'll try to play with this version in the near future.

Currently, a small annoyance for me is that the "skin" of the OSM map doesn't show one-ways. Is it something you can easily fix?

[dabreegster]

It depends on the basemap. The default MapTiler dataviz doesn't show them:

If you change the settings at the top to Streets, then it does:

But actually, I might disable those arrows on the basemap always, because they're fixed, unrelated to the user edits. When you are editing a particular neighbourhood, you should see one-way arrows rendered by the app. Would those be useful to see on all modes of the app?

[TFCx]

But actually, I might disable those arrows on the basemap always, because they're fixed, unrelated to the user edits. When you are editing a particular neighbourhood, you should see one-way arrows rendered by the app. Would those be useful to see on all modes of the app?

You're right, it is a bit outdated (previsously on V1, I would define the district and had invisible oneways). Please discard my remark. :)

[dabreegster]

2 March

Big change to the title screen and overall flow through the app. Everything you do is wrapped as a "project" -- the area you import from OSM, the neighbourhood boundaries you draw, and any edits you make. Everything is auto-saved. It should hopefully be much easier now to continue work from a previous session.

I also filled out a bunch of GH issues to track work. I think https://github.com/dabreegster/ltn/milestone/1 is the minimal amount before I'm going to nudge people from the old version of the tool towards this one.