Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wheelchair routing profile #1726

Merged
merged 13 commits into from
Nov 13, 2019
Merged

Conversation

don-philipe
Copy link
Contributor

@don-philipe don-philipe commented Sep 12, 2019

This pull request adds a new routing profile for wheelchairs. It takes surfaces and smoothness into account. It mainly uses values and rules from the foot routing profile (as, at least in Germany, wheelchair users are equivalent to pedestrians). But in some cases it is more restrictive.

The icon is just a placeholder. I'm sure there are people who can do that better than me.

@don-philipe don-philipe marked this pull request as ready for review September 16, 2019 10:49
Copy link
Member

@karussell karussell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! See my comments

removed unnecessary comments and code
changed handlePriority method be valuable for wheelchair
fixed wheelchair svg
@don-philipe
Copy link
Contributor Author

Do I need to do something more, additionally to committing and pushing the requested changes?

@karussell
Copy link
Member

Thanks! Somehow I wasn't notified about this. Will review in the next hours&days.

Copy link
Member

@karussell karussell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I additionally found wheelchair:no or wheelchair:limited - is this already considered? See https://wiki.openstreetmap.org/wiki/Wheelchair_routing#Requirements_for_Wheelchair_Accessible_Routes

Also it really needs two directions support to avoid steep elevation. This is now easy, see Bike2WeightFlagEncoder (new UnsignedDecimalEncodedValue("xy", bits, factor, true))

Also it would be important to consider the slope tag.

Edit: Ok, when viewing the tests it seems skipping surface:sand etc is already skipped. Can you comment on this?

Edit2: Ah, you do not "avoid" these tags them but exclude them. Then it would be better to rename avoidHighwayTags and avoidSurface and avoidSmoothness to excludeXY

renamed variables to better reflect their usage
exclude steep incline and high kerbs
@don-philipe
Copy link
Contributor Author

I additionally found wheelchair:no or wheelchair:limited - is this already considered? See https://wiki.openstreetmap.org/wiki/Wheelchair_routing#Requirements_for_Wheelchair_Accessible_Routes

wheelchair:no is already considered and the way is then skipped. I added now wheelchair:limited to have lower priority.

Also it really needs two directions support to avoid steep elevation. This is now easy, see Bike2WeightFlagEncoder (new UnsignedDecimalEncodedValue("xy", bits, factor, true))

I'm not sure what you mean with that. Isn't that already be solved by skipping ways that are too steep (see below)? Or do you mean that the speed should be adjusted to the incline?

Also it would be important to consider the slope tag.

As long as the incline tag has a numerical value it can now be evaluated. Ways with incline > 6% will be skipped.

@karussell
Copy link
Member

I added now wheelchair:limited to have lower priority.

👍

Or do you mean that the speed should be adjusted to the incline?

Yes, but you are right that this is not necessary for a first version

As long as the incline tag has a numerical value it can now be evaluated. Ways with incline > 6% will be skipped.

OSM tags are very rare for this and I would prefer skipping too steep roads via elevation. See here of how we do this for Bike2WeightFlagEncoder

@don-philipe
Copy link
Contributor Author

OSM tags are very rare for this and I would prefer skipping too steep roads via elevation. See here of how we do this for Bike2WeightFlagEncoder

I assumed, that elevation data from PointList.getElevation() is in percent. Am I right?

Now the applyWayTags() method will slow down speed for inclines between 3 and 6 percent and set speed = 0 for inclines greater than 6 percent (same for decline).

Copy link
Member

@karussell karussell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the improvements! Looks better. See my new comments

@karussell
Copy link
Member

I assumed, that elevation data from PointList.getElevation() is in percent. Am I right?

It is in meter.

calculate slopes correctly now

make two directions for speed encoder configurable for FootFlagEncoder
@don-philipe
Copy link
Contributor Author

Sorry for disturbing you again, but can you please have a look at the changes?

@karussell
Copy link
Member

Sorry for disturbing you again

Not a problem. Please leave a comment as I do not track of the commits in the PRs, especially I do not know when something is ready etc

Will review this again later. For now can you send us the signed CLA (or just your email address) and add yourself as a contributor in CONTRIBUTORS.md?

@karussell karussell added this to the 1.0 milestone Oct 15, 2019
@karussell karussell merged commit 556f3c8 into graphhopper:master Nov 13, 2019
@karussell
Copy link
Member

Thanks again :) !

@don-philipe don-philipe deleted the wheelchair branch November 28, 2019 15:31
@cbayerlein
Copy link

I managed to enable wheelchair routing thanks to this pull! I think it’s really awesome that wheelchair routing is available. Thank you so much @don-philipe and @karussell !

I wasn’t aware that it’s only in later releases. I used 0.13 first (as described in the quick start guide), now I’m using 1.0-pre13.

Unfortunally, I’m too much of a newbie especially in Java, so I’d need to learn a lot before I can contribute myself :-(. But I’ll definitivly look into it and will see what I can do.

For now I hope it's helpful if I do my best as a test user. I already found some issues. Maybe you can help. e. g. for the following request

http://s7.thalon.me:8989/maps/?point=Brunnenstra%C3%9Fe%2011a%20H%C3%B6hr-Grenzhausen&point=Kirchstr.%20H%C3%B6hr-Grenzhausen&locale=de-DE&vehicle=wheelchair&weighting=fastest&elevation=true&use_miles=false&layer=Omniscale

I get:

Cannot find point 0: 50.439114,7.655696
Cannot find point 1: 50.438526,7.656077

Bike2 and foot routing works for the two points. How can I check what's going wrong and maybe solve the issue?

@cbayerlein
Copy link

Another issue with this route:

http://s7.thalon.me:8989/maps/?point=L%C3%B6hrstr.%20107%20Koblenz&point=Gem%C3%BCsegasse%20Koblenz&locale=de-DE&vehicle=wheelchair&weighting=fastest&elevation=true&use_miles=false&layer=Omniscale

Going via Bahnhofstr. to avoid Löhrstr. seems odd (I can see no reason), also this strange diversion to cross Am Plan/Altengraben... Plus, at the end(after turning right to Gebrüder-Dommermuth-Weg), there're actually (in rl) steps, as far as I remember.

@cbayerlein
Copy link

@cbayerlein
Copy link

I think the problems can be divided into two causes:

  • missing data in OSM (nothing we can do here except mapping ourselves)
  • too restrictive routing - maybe we should loosen up a bit.

What do you think?

Copy link

@cbayerlein cbayerlein left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some input from me as an actual wheelchair user...

excludeHighwayTags.add("steps");
excludeHighwayTags.add("track");

excludeSurfaces.add("cobblestone");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer not to exclude so strictly. Sometimes, it is unavoidable. Is t possible to give a very bad speed penalty, like 1km/h?

excludeSurfaces.add("gravel");
excludeSurfaces.add("sand");

excludeSmoothness.add("bad");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as with surfaces. The worse the slower...

private final Set<String> excludeSurfaces = new HashSet<>();
private final Set<String> excludeSmoothness = new HashSet<>();
private final Set<String> excludeHighwayTags = new HashSet<>();
private final int maxInclinePercent = 6;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's iso norm for ramps, but for ways very restrictive and thus unrealistic. I would raise it to 15, giving it a speed penalty over 6.

excludeHighwayTags.add("primary_link");
excludeHighwayTags.add("secondary");
excludeHighwayTags.add("secondary_link");
excludeHighwayTags.add("tertiary");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is tertiary a Kreisstraße/Landstraße? Then please don't exclude. Sometimes, that's the only available way in rural areas - except for forrest/agricultural roads (Feldwege), wich are much worse.


double eleDelta = pl.getElevation(pl.size() - 1) - prevEle;
double elePercent = eleDelta / fullDist2D * 100;
int smallInclinePercent = 3;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd raise that to 5,giving a speed penalty over 3.

excludeHighwayTags.add("tertiary");
excludeHighwayTags.add("tertiary_link");
excludeHighwayTags.add("steps");
excludeHighwayTags.add("track");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tracktype=grade1 would be possible

@cbayerlein
Copy link

Maybe we should add excludeHighwayTags.add("path");

@cbayerlein
Copy link

In the meantime I changed a bit of code in the WheelchairFlagEncoder and now the links which I posted above produce better results as they point to my GH instance. Basically I removed some restrictions like excluding cobblestones and others which were too strict from my point of view and raised the max slope limit to 15%. The changes are very rudimentary (commenting out lines and replacing 6 with 15 ) and rather suboptimal in a way so that there is a lot of room for improvement. For example it would be better to give a speed penalty to bad surfaces. Unfortunally I didn't have time and knowledge yet to implement that, but at least I wrote some code reviews in regards to this. Maybe we can continue working on that topic. I would be very happy about that and will look more deeply into the matter myself next year. For now Guten Rutsch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants