Wheelchair surfaces #3525
Wheelchair surfaces #3525
Conversation
I have found usages of these unboxed Map types elsewhere in the code, and the related GitHub issue (to GNU Trove) seems to show better performance due to it, so I will adopt it to prevent the need for further refactoring.
|
As discussed in #3524 I think this doesn't take the actual sidewalk into account and would probably lead to strange results where streets with cobblestones but good pavements would be heavily penalised. Another concern is that it deviates from how other graph properties like the bicycle safety factor and the access permissions are computed: these are reduced down to a numeric value at graph build time through the use of |
|
Taginfo has hard numbers about the number of tags: https://taginfo.openstreetmap.org/keys/surface#overview 38M |
|
Agreed, I think that some of the highway=footway and/or footway=sidewalk tags could be added into whether or not to save the surface, which would give us more of the restriction searched for. I understand your concern about the deviation from the way other graph properties are calculated, but I think that the WayPropertySet proposal is not ideal for the use case. I looked into this initially (and into the general bicycle safety factor, as I was suggested to do this on the mailing list). However, if I am not mistaken, this is a one-time calculation during graph-building time, which would not lend itself for flexible usage for different types of wheelchairs (as I described in my example). Pre-calculating a single result of how comfortable a "way" is for a wheelchair user is not really solving the problem, since different wheelchair users can be variably more or less capable of handling different surfaces, and just assigning them all a one-size-fits-all factor will be less ideal than a more flexible solution. Even setting a hard-coded max_slope limit could be a limiting factor, since some people's wheelchairs are motorized, for example, and can take slopes better and for longer than a person with a manually-driven wheelchair. Anyway, that is why I think that using the WayPropertySet is not the best way to implement this functionality. Highway:footway has 14.5M instances, so I think that it would increase the coverage of the surface restriction not too badly, and improving the OSM dataset in the future would only make this solution that much better! |
There was a problem hiding this comment.
This PR changes some of the Raptor code like RaptorRequestMapper, .java, McCostParams.java and McCostParamsBuilder.java. The 'surfaceReluctances' is used in the AStar street search, not in the Raptor transit search. The changes in the Raptor code should be removed.
|
I will try to remember to make this a topic on the next developer meeting at Tuesday 29. June at 10:00 CEST https://meet.google.com/qwh-xzbz-atr. @danielthegray you are welcome to join, also should the time not suite you, please contact me and we can find a time. The meeting are every Tuesday and Thursday at 10:00. |
|
Hi @t2gran and all! I work with Daniel in the team on changes to route planning for disabled people. I am pleased that we find our proposal very interesting. I myself have a physical disability and use an electric wheelchair. My background is also that I also studied computer science (albeit years ago). My overview and my skills regarding Java are unfortunately not as good as Daniel's, but I can perhaps contribute a few impulses from the user's point of view. In the meantime, I had also dealt a bit with route planning for wheelchair users and familiarized myself with OpenStreetMap. Furthermore, we have already gained some experience with OpenRouteService. Regarding sidewalks you have an importantant point, but unfortunally it is not always the case, that the surface of the sidewalk is better than the one of the road itself. In my experience this combination is rather rare. Plus, one could argue that the opposite is also true: there are not so few roads with cobblestones on the sidewalks but the road is paved. According to the OSM Wiki, it is actually best practice to create separate highway=footpath for sidewalks. Unfortunately, this often does not correspond to reality. Sometimes sidewalk: left: surface etc. is used, but often the sidewalk is simply missing completely and in such cases we can simply extrapolate from the surface of the street itself. I know that ORS splits the highway into multiple edges with all having their own features in terms of surface etc to solve this problem. Also one would have to see how to get on and off the sidewalk. ORS looks at kerb_height and highway=crossing. As you can see the whole topic can become very complex quickly. Unfortunately, we ourselves only have limited resources to implement all of these requirements. Still, I think our solution is a step forward compared to the current situation. That is why I continue to advocate taking over PR without losing sight of further developments and better solutions in the future. Thank you also for inviting us to your developer meeting. We would like to take part - but unfortunately the date is not quite suitable. Would it also work sometime in the early evening (European time)? |
|
I am happy to tak to you in the evening, just suggest a time on Monday(best for me) or Tuesday - after that I am gone for 3 weeks. I talked to @abyrd a while back about wheelchair routing and you got it right, it is not a mode by it self, and jet almost. We talked about making it a mode. But if you want to engage in this work and have a logn term interest in it, then I am interested in helping you. I agree that that the right process is to take step-by-step to do this and learn on the way. I would normally recommend using the Sandbox for "experimenting" because it allow you to commit code without much overhead, but in this case I do not think it is a good match. If we can make OTP wheelchair routing ok - then there will be an initiative to improve the OSM data as well. We have to start some where. |
|
I absolutely understand your point and expressly support it and can assure you that I have a long-term interest in the further development of route planning for wheelchair users. In this respect, your suggestion to take the whole thing step by step is also the right way for me. There is still a lot to be done. When asked about a separate wheelchair mode, I have a slightly different opinion. Or I think that this is not enough to cover all cases. The possibilities and characteristics of wheelchair users vary from person to person. Some can handle steep inclines well and even overcome individual steps without problems, others have big problems on poor surfaces. A wheelchair user who drives his wheelchair manually wants to walk as flat as possible in order to save muscle power. On the other hand, a user of an electric wheelchair, for example, has no problem at all (to a certain extent). Then there are people like me who use special controls (for example I have a mini joystick that I operate with my mouth), for whom cobblestones are a big problem. Our idea or our approach is to be able to individually adjust the route planning using as many parameters as possible. The advantage of this approach is that it not only helps wheelchair users, but also, for example, people with cargo bikes etc. Regarding our meeting - how about Monday evening or late afternoon - around 6:00 p.m.? That would suit me well. We may then be able to arrange a meeting again after you are back, because @nakrei, my colleague, who is also very familiar with Java, is unfortunately still on vacation at the moment. But I think it makes sense if she also looks at it. Unfortunately, Daniel cannot contribute that much at the moment. But I would leave it open whether he will attend the appointment or not. |
|
Lets do the meeting her https://meet.google.com/qwh-xzbz-atr at 18:00, then. Look forward to hear from you. |
|
Aesome, see you later today!
Am Mo., 28. Juni 2021 um 16:25 Uhr schrieb Thomas Gran <
***@***.***>:
… Lets do the meeting her https://meet.google.com/qwh-xzbz-atr at 18:00,
then. Look forward to hear from you.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3525 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFR4ZNCAV2KTZUMCKDRDZALTVCA5DANCNFSM46ELRR7A>
.
--
Christian Bayerlein
thalon.me
|
|
To move forward here we agreed that this is best suited as a Sandbox extension. @cbayerlein will take the ownership of the Sandbox. To get you started you may cherry-pick this commit: entur@efa10dc Fill in the |
|
I agree, this looks very interesting!
Thomas Gran ***@***.***> schrieb am Di., 1. März 2022, 18:27:
… The OpenSidewalks <https://tcat.cs.washington.edu/opensidewalks-2/>
project was mentioned in todays PLC meeting, and is relevant for this issue.
—
Reply to this email directly, view it on GitHub
<#3525 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFR4ZNFA3JFZ2B6DY2VRETTU5ZHRHANCNFSM46ELRR7A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
5 participants
Summary
Add an query parameter called "surfaceReluctances" to the routing plan API, allowing API users to penalize certain surfaces of roads.
Issue
closes #3524
Unit tests
A unit test for the new RoutingRequest parameter was added. Some integration tests could/should probably be added.
I manually tested with cURL and saw that a different path was selected based on adding the reluctances. I tried to verify that the graph.obj file is not growing too much (after adding the "surface" attribute to the StreetEdge): before the change a graph.obj of Rheinland-Pfalz was 189 MB, and after it was 192 MB.
I also added a "surfaceReluctances" query parameter to the JS client-side code, and visually verified that adding and removing the reluctance for paving_stones, in my example, correctly routed around the paving stones path to a slightly longer path. A "Copy as cURL" dump of the request done by the web client of OTP is:
I made the changes as small as possible, and I also incorporated usage of the GNU Trove library, which I saw was being used in several spaces to improve performance.
Documentation
I added some Javadoc to the relevant methods, but I am not sure whether or not further documentation would need to be added to the API query parameter.