[Tagging] incline=up_and_down

[martianfreeloader]

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 osm at 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 at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging