Include waterway:lock_gate in (pedestrian) routing

[koebi]

This was reported in the ask-forum.

Here's what I did

Request this route

---

Here's what I got

The following route going around, although the lock is tagged with foot:designated

---

Here's what I was expecting

The short route, since the lock is tagged as accessible by foot.

---

Here's what I think could be improved

According to @aoles this case might have to be added to handleNonHighways similar to some of the other scenarios such as ferries or public transport platforms.

If done so, it should also be added to the backend documentation.

[aoles]

For the record: the problem with this particular example is that both way segments 82644748 and 677222821 which constitute the lock gate are not tagged as highway. In order to consider such ways for routing some additional logic based on OSM tags needs to be added to handleNonHighways, probably sth along the lines:

        if (way.hasTag("waterway" = "lock_gate")) {
            String footTag = way.getTag(OSMTags.Keys.FOOT);
            if (intendedValues.contains(footTag))
                acceptPotentially = EncodingManager.Access.WAY;
        }

Fun fact: there is only a bunch of water locks open to pedestrians worldwide. Note that in contrary to the above some of them are tagged as highways.

[koebi]

ToDo here:

• check how routing behaves on waterway=lock_gate if tagged w/ highway
• add unit test for waterway=lock_gate; foot=yes/no
• add check as above
• test and be happy :)

[koebi]

This route and this route both include waterway=lock_gates that have a highway=*-tag.

I'd conclude that these edges tagged as highways work as expected.

[aoles]

Great, thanks a lot @koebi for verifying that in the presence of highway tag the routing works as expected. I can additionally confirm, that as long as there is a highway tag present the routing works even in the absence of an explicit foot tag, as here for example. For reference see also other cases around the world.