Open henrik-wolf opened 2 years ago
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:
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?:lane_efficiency
graph weighting to use these new directional lane values. I can help with this.Yes, that seems like a good idea. I will give it a go in the next few days.
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 isoneway=false
) available to motorized traffic. Looking at the defaults that have been chosen inLightOSM.jl
, it seem to me like we think thelanes
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 thelanes
tag. Maybe, we could also parse thelanes:forward
,lanes:backward
andlanes: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.