To me, it seems that the root of the problem is that the
mtb:scale:uphill=* key is flawed.
Instead, these keys should be name mtb:scale:forward=* and
mtb:scale:backward=* . This would make everything unambiguous.
And, of course, an additional incline=up/down would be optional but very
helpful. One could for example easily infer a mtb:scale:uphill/downhill
from this combination (if still of interest for some reason). (+obvious
other advantages for routing)
On 26/09/2022 14:40, Brad Haack wrote:
Any good cycling router needs to use a digital elevation model in it's
algorithm, or use elevation tied to the paths somehow (such as with a
gpx track). These odd OSM tags are a sideshow.
On 9/26/22 03:16, Mateusz Konieczny via Tagging wrote:
26 wrz 2022, 09:02 od o...@tobias-knerr.de:
On 26.09.22 02:21 Mateusz Konieczny wrote:
But what can be done in cases where there is no real incline but
path goes through series of up and down hops?
I would intuitively prefer if you put the information about the
presence of "hops" into a specialized tag instead of making the
value space of an established and approved key more messy.
Leave incline=* to describe the overall incline of the way in that
case. That is: Do you end up lower or higher than you were in the
start?
In this case I am thinking about something
that overall has tiny elevation change.
What would you propose as such extra tag?
up_and_down=yes
(not really happy about it, but right now I
have no better idea)?
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
