Number of default lanes is inconsistent with OSM documentation

[henrik-wolf]

The OSM Documentation on the lane tag (here) states, that this tag should be used to encode the total number of lanes (in both directions, if the way is oneway=false) available to motorized traffic. Looking at the defaults that have been chosen in LightOSM.jl, it seem to me like we think the lanes encodes only lines in one direction.
I think we should rework (and better document) this and all other tags which get set as a default, as well as the algorithm which sets the default for the lanes tag. Maybe, we could also parse the lanes:forward, lanes:backward and lanes:both_ways, to clean up any ambiguity?
I would be happy to take a shot at it, but the question of how to parse data, especially from OSM is always heavily opinionated, so I would like to get a little discussion started about how we would like to handle this problem, before I get stuck in.

[jarodlam]

Hi @SuperGrobi, thanks for catching this.

The lanes tag in LightOSM definitely assumes that it encodes the lanes in a single direction, which is incorrect as you pointed out and needs to be fixed. You raise a good point that the defaults are quite opaque in LightOSM's current iteration. I like your idea of using the lanes:forward, lanes:backward and lanes:both_ways tags, as well as the suggested defaults on the OSM wiki.

I think we need to do three things here:

1. Add the lanes:forward and lanes:backward tags as default tags for all ways when parsing the graph. These contain the parsed directional lane numbers. Keep lanes as it is because we don't want to diverge from the meaning of these tags in OSM. Can I please get your help to make a start on this?
2. Update the :lane_efficiency graph weighting to use these new directional lane values. I can help with this.
3. Document how we set these defaults.

[henrik-wolf]

Yes, that seems like a good idea. I will give it a go in the next few days.