Support for paddling (canoe, kayak, standup paddleboard, etc.) routing.

[scarapella]

Hello,

I've been working on supporting the routing of paddling in brouter, and wanted to share this PR as a way to start a discussion to see if you open to having it included in the core.

Within OSM, we've always had waterways to route on (hence river.brf profile), but within the last few years we finally have good enough data to start routing including:

• access restrictions on those waterways https://wiki.openstreetmap.org/wiki/Key:canoe
• new types of waterways to that allow routing
  -- through natural=water bodies https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dflowline
  -- between waterways https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dlink
• information about hazards on waterways
• • https://wiki.openstreetmap.org/wiki/Key:rapids
• • https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dwaterfall
• • https://wiki.openstreetmap.org/wiki/Key:open_water
• • https://wiki.openstreetmap.org/wiki/Key:intermittent
• • https://wiki.openstreetmap.org/wiki/Key:tidal
• access restrictions for portaging https://wiki.openstreetmap.org/wiki/Key:portage
• routes for canoeing https://wiki.openstreetmap.org/wiki/Tag:route%3Dcanoe

With that in mind I felt there was a real gap in the world that could be filled by having a canoe routing engine that would allow trip planning. This is especially useful in places where you have many route options such as BWCA, Quetico, and Algonquin to name a few.

So I made this initial implementation of a paddle routing profile (and updated the river profile) to start the discussion on the topic. It's also deployed with a slightly modified brouter-web so others can play with it at https://map.openpaddlemap.org/

-scarapella

p.s. if you wonder why there is no elevation penalty in the profile, it's because I have not managed to sort out SRTM deployment locally.

[afischerdev]

Thanks for your waterway improvements.
However, I can begin testing after the migration to a new server.

In the meantime, you might want to take a look at my canoe and river profiles – also with extra lookups.dat, a bit outdated, I see there are some new interesting tags. Feel free to contact me offtopic for rd5-files for this features.
https://github.com/afischerdev/brouter-profile

[scarapella]

hey, that's great, I'll take a look. I hadn't noticed that repo before.

[afischerdev]

This looks like a lot of data

waterway;0000000001 stream

Are you sure you need all of them? Or is it sufficient to have the stream data, when it is additionally tagged with canoe=yes, boat=yes, or something similar?

[afischerdev]

assign processUnusedTags		  = true

should not be true in standard

in river.brf

#paddling is reasonably close to walking so let's use that as a default for now
assign validForFoot 	1

This is more a boat profile - you offered a paddling as well - so I would think validForBike is the better choice.
That reminds me on the plan to add more then three transport modes .

[scarapella]

This looks like a lot of data

waterway;0000000001 stream

Are you sure you need all of them? Or is it sufficient to have the stream data, when it is additionally tagged with canoe=yes, boat=yes, or something similar?

Ideally I'd like to have them all so that I can have a routing profile that just follows waterways regardless of size. However I agree that's a bit of a niche use case and a priori it could be a lot of data. Is there a graceful way to only get the union as you propose?

[scarapella]

paddling is reasonably close to walking so let's use that as a default for now
assign validForFoot 	1

This is more a boat profile - you offered a paddling as well - so I would think validForBike is the better choice.

Here is my rationale and assumptions. However, they may not be valid so I'm happy to understand why validForBike would be better:

For 'paddle.brf' I had in mind a human powered boating profile. I chose validForFoot after looking at the code because

• On both water and land the max speed was a closer approximation than validForBike and therefore led to more realistic time estimations
• On land you are more akin to a pedestrian in most cases, so the turn restrictions being ignored for foot seemed better.

For 'river.brf' only the first reason applies.

[scarapella]

assign processUnusedTags		  = true

should not be true in standard

Mea culpa. Fixed via 98a2747

[afischerdev]

validForBike vs validForFoot

this was referenced to the river.brf. Please do an overpass search for nwr["waterway"]["maxspeed"]. You will find some speed samples.

waterway stream

It could be reduced in profile all.brf.
Please take a look at this excellent waterwaymap.org and play with the settings. e.g waterway in general. This will give you an overview what unusable waterways mean.

[afischerdev]

waterway stream

Some space results for this feature

Generated Germany-last with

lookups.dat v11.2                    - 382.6 M
lookups.dat v12.1                    - 419.4 M 
lookups.dat v12.1 reduced by all.brf - 384.0 M

[afischerdev]

@scarapella
Something isn't quite right with the request. But I think this doesn't matter. I wouldn't have checked in the PR. For a new version of the lookups.dat we do at first a collection - I will start later on.

But before:
here are the changes I got from an older version of this PR. Just to make sure, we are on the right way.
Please notice my changes on your suggestions.

# is removed
+ is added 

-- way

portage;0000000001 no
portage;0000000001 yes
portage;0000000001 private
portage;0000000001 permit
portage;0000000001 customers
portage;0000000001 permissive
portage;0000000001 designated
# portage;0000000001 discouraged

hand_cart;0000000001 no
hand_cart;0000000001 yes
# hand_cart;0000000001 designated

tunnel;0000000001 flooded

waterway;0000000001 flowline
waterway;0000000001 link
waterway;0000000001 tidal_channel
waterway;0000000001 canoe_pass
waterway;0000000001 ditch
waterway;0000000001 drain
waterway;0000000001 stream

tidal;0000000001 no
tidal;0000000001 yes

intermittent;0000000001 no
intermittent;0000000001 yes

rapids;0000000001 no A B C 0
rapids;0000000001 yes
rapids;0000000001 1 1+ 1- I  1;0
rapids;0000000001 2 2+ 2- II 1;2 2;1
rapids;0000000001 3 3+ 3- III 2;3 3;2
rapids;0000000001 4 4+ 4- IV 3;4 4;3
rapids;0000000001 5 5+ 5- V 4;5 5;4
rapids;0000000001 6 6+ VI 5;6 6;5
rapids;0000000001 X 5;X 6;X X;5 X;6

+ whitewater;0000000001 portage_way

+ whitewater:section_grade;0000000001 no A B C 0
+ whitewater:section_grade;0000000001 yes
+ whitewater:section_grade;0000000001 1 1+ 1- I  1;0
+ whitewater:section_grade;0000000001 2 2+ 2- II 1;2 2;1
+ whitewater:section_grade;0000000001 3 3+ 3- III 2;3 3;2
+ whitewater:section_grade;0000000001 4 4+ 4- IV 3;4 4;3
+ whitewater:section_grade;0000000001 5 5+ 5- V 4;5 5;4
+ whitewater:section_grade;0000000001 6 6+ VI 5;6 6;5
+ whitewater:section_grade;0000000001 X 5;X 6;X X;5 X;6


open_water;0000000001 no
open_water;0000000001 yes
open_water;0000000001 partial

canoe;0000000001 no
canoe;0000000001 yes
canoe;0000000001 private
canoe;0000000001 permit
canoe;0000000001 customers
canoe;0000000001 permissive
canoe;0000000001 designated
canoe;0000000001 discouraged
# canoe;0000000001 unknown
+ canoe;0000000001 portage

oneway:canoe;0000000001 no
oneway:canoe;0000000001 yes

boat;0000000001 discouraged
# boat;0000000001 unknown
boat;0000000001 permit

route;0000000001 portage
route;0000000001 canyonin

route_canoe_;00000000001 yes
route_canoe_lpn;00000000001 yes
route_canoe_rpn;00000000001 yes
route_canoe_npn;00000000001 yes

route_portage_;00000000001 yes

-- node

waterway;0000000001 rapids
waterway;0000000001 access_point
waterway;0000000001 dam

rapids;0000000001 no A B C 0
rapids;0000000001 yes
rapids;0000000001 1 1+ 1- I  1;0
rapids;0000000001 2 2+ 2- II 1;2 2;1
rapids;0000000001 3 3+ 3- III 2;3 3;2
rapids;0000000001 4 4+ 4- IV 3;4 4;3
rapids;0000000001 5 5+ 5- V 4;5 5;4
rapids;0000000001 6 6+ VI 5;6 6;5
rapids;0000000001 X 5;X 6;X X;5 X;6

canoe;0000000001 no
canoe;0000000001 yes
canoe;0000000001 private
canoe;0000000001 permit
canoe;0000000001 customers
canoe;0000000001 permissive
canoe;0000000001 designated
canoe;0000000001 discouraged

#canoe:egress;0000000001 yes
#canoe:egress;0000000001 designated
#canoe:egress;0000000001 permissive
#canoe:egress;0000000001 customers
#canoe:egress;0000000001 permit

#canoe:put_in;0000000001 yes
#canoe:put_in;0000000001 designated
#canoe:put_in;0000000001 permissive
#canoe:put_in;0000000001 customers
#canoe:put_in;0000000001 permit


boat;0000000001 no
boat;0000000001 yes
boat;0000000001 private
boat;0000000001 permissive
boat;0000000001 designated
# boat;0000000001 discouraged
# boat;0000000001 unknown
boat;0000000001 permit

When you can confirm this, we offer this for the next generation of lookups.dat - v12.1
Meanwhile you could add a profile for paddling which work with the current lookups.dat v11.2.
As soon as v12.1 goes live, this could be replaced by the profile you proposed.