feature request: waterway routing

[Dirk--]

How about adding sophisticated waterway-routing to brouter? As far as I know, some work is already in progress:

• https://github.com/poutnikl/Brouter-profiles/blob/master/river-poutnik.brf
• https://github.com/afischerdev/brouter-profile

See https://github.com/nrenner/brouter-web/issues/283 for initial request ...

[afischerdev]

May be this could be a start.

Please insert into lookups.dat

seamark:type;0000000001 lock_basin seamark:type;0000000001 bridge

waterway;0000000001 safe_water waterway;0000000001 stream waterway;0000000001 narrow

CEMT;0000000001 0 CEMT;0000000001 I CEMT;0000000001 II CEMT;0000000001 III CEMT;0000000001 IV CEMT;0000000001 Va CEMT;0000000001 Vb CEMT;0000000001 VIa CEMT;0000000001 VIb CEMT;0000000001 VIc CEMT;0000000001 VII

[poutnikl]

I suppose there is a major stumble stone about BRouter routing across areas ( both water and land ), if we do not want to stick to OSM ways across such areas ( that may be missing or misleading for safe passage.). For now, a BRouter profile author cannot do anything about it.

[afischerdev]

Could you please explain that a little bit. I see an OSM way defined as 'waterway' that has an other attribute 'CEMT'. The data of the waterways are already in the segment files. Why not an extra attribute?

Please see here for samples E-waterway network

[poutnikl]

Sure waterway IS an OSM way. Nothing against your suggested additions.

I have spoken about OSM polygon areas, in water context shore waters, lakes, wide enough rivers, where may, or may not be mapped a waterway, which may, or may not be an actual water navigation waterway.

I suppose reliability of OSM water mapping for water navigation can be very region specific.

[Dirk--]

European waterways: There are no polygone-areas one should use for inland waterway routing. Major waterways crossing lakes should always have a tag waterway=fairway. All air-hight limiting bridges/ gates are nodes of corresponding waterways, having tag seamark:type;bridge etc. set. The whole picture https://maps.grade.de/ , doted lines are fairways (click on items to query overpass-api)

[poutnikl]

Hehe, I would not dare navigation of even a canoe, considering quality of Czech Republic waterway mapping. But for regions of regular big water traffic it could be different.

[afischerdev]

Yes, I think polygon areas are the hell for routing. But it will be the same problem with or without the new attribute 'CEMT'. I haven't controlled it, but I guess, this attribute only works on ways. The polygone problem takes place when you have free access to the hole water area. Inland water ways are normaly buoy protected and the bigger boats have to follow them. This could give a rule for motorboats and larger, not for cajaks or surf boards.

[poutnikl]

For polygons, LocusMap can still use straight-lines route segments in the route planner obtained by "the straight line routing provider".

For waterways routing, I have already agreed enlarging of the lookups.dat could be good. I would call for some "water born" profile author. I am a land rat, making my river profile ( mentioned in the 1st post ) just based on recommendations by Paul W ( on AndOSM ), who does some river boating a/o shore water sailing in or near UK.

[Dirk--]

Do not hasitate to ask about navigable inland waterways, my OSM profile: https://wiki.openstreetmap.org/wiki/User:Kannix

[Dirk--]

Just finished our project 'European Inland Navigation Network': https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-waterway_network Next step: Validating major recreational waterways: https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-waterway_network/Recreational

[Dirk--]

to keep things going, here comes my brouter sandbox: https://wiki.openstreetmap.org/wiki/User:Kannix/brouter

[afischerdev]

I'm still behind the waterway routing. Bridge height is on of the items I'ld like to see in BRouter.

I learned about the lookup table and the index to get the values. And that there is no way to get variable values out from it.

So I'ld like to discuss the problem on variable values and the lookup table with an idea.

First I did an entry like this

seamark:bridge:clearance_height_closed;0000000001 *

This gives an unknown value as result.

The index of a lookup entry is up to 500. So I thought it could be an idea to break this and add variable values like 1000 + float value * 100 (bridge height value are not very big) So we get in the lookup table values of 0, 1 (unknown), indexes up to 500 and variables above 1000.

All handling is done in the BExpressionContext class, function addLookupValue and some validation checks.

To make use off this new variables I made a new model WaterwayModel/WaterwayPath and a profile to call this.

I've checked all this with decode/encode and map generation and reading. But I'm not deep enough inside the other code to see if there is an other blocking routine.

The source for this idea is found on github

[Dirk--]

just implemented @afischerdev 's proposal: https://brouter.grade.de

[afischerdev]

The 2nd part is done.

1. part was save and restore the variable values for tags like this:

seamark:bridge:clearance_height_closed;0000000001 *

2. part is now to use it in a profile

a sample:

assign boat_height  1.5  

assign waiting_height 
    if seamark:bridge:category=opening then 
      switch  and not      seamark:bridge:clearance_height_open=
                  lesser v:seamark:bridge:clearance_height_open boat_height true 
      false
    else false

assign initialcost 
       switch waiting_height      900
       0

This shows that the variable tag is started with 'v:' and it is controlled if it was filled.

Again the source for this idea is found on github

[afischerdev]

More changes:

• brf: the variable don't need a starting control if it is filled.

assign truck_maxspeed =
   min v:maxspeed speed_normal

• lookup: the fix and the variable definition in the lookups.dat can be combinated (but fixed part should come first).

maxheight;0000000001 default no_sign unsigned
maxheight;0000000001 none
maxheight;0000000001 *

I added some diff files for a short control RoutingContext.java BExpression.java BExpressionContext.java lookups.dat

And there is a small sample profile truck.brf

The source for this idea is found on github

[nrenner]

just implemented afischerdev 's proposal: https://brouter.grade.de

@Dirk-- what is the status there (backend returns 502 Bad Gateway)?

Asking because of a current discussion: Gewässerrouting mit Brouter-Web: Problem [de/en] Routing Fluss/Bach im Spreewald [de]

[Dirk--]

@nrenner sorry, I am well behind afischerdev's work ( https://afischer-online.de/and/aftrack/sailing/#trip ) ...

[afischerdev]

I've updated my scripts at git. It contains now 3 modification level to improve the waterway routing

1. profiles that do not need a modification in lookup table. Only a small change in all.brf (switch boat=yes 1) is needed to get waterway that are tagged as stream and boat=yes
2. profiles that need a simple change in lookup table (like shown here)
3. profiles that need a greater change in lookup (like discussed here)

[abrensch]

I will have a look into the subject these days,

regards, Arndt

[afischerdev]

An additional idea on all.brf and the problem with stream data

When we use stream, ditch and drain in lookup.dat, we can extract them in the all.brf and hold only the boat=yes or canoe=yes entries

assign costfactor
  switch waterway=stream|ditch|drain
         switch boat=yes                    1
         switch canoe=yes                   1
                                            100000
  switch not highway=                       1
  ...

I made a test only with waterway data Europe and got only 5500 bytes more - against the "switch boat=yes 1" method.

[Dirk--]

Ahoi, back on the track, restart of european waterway router: https://brouter.grade.de/#map=5/54.618/23.533/CARTO,CEMT

[Dirk--]

@afischerdev shall we close this issue, now?