Talk:Proposed features/Piste:type=connection

From OpenStreetMap Wiki
Jump to navigation Jump to search

One way implications

I'm glad that you've created this formally, I've been wondering what to do with regard to piste connections for a while. The only other option that seemed reasonable was to use some kind of area tag, but obviously this is not ideal for routing purposes. I am wondering what the implicit value for oneway=* should be on these connections, as often they allow ski traffic both ways. Do you think it's best to have oneway=yes as the default? —Preceding unsigned comment added by Jackdpage (talkcontribs)

Probably the implicit oneway=yes makes sense for consistency reasons, yes. Whenever a connection goes both ways, it can be tagged otherwise. Also ski routing engines can still decide to always handle connections both ways, if they want. (talk) 13:20, 27 September 2016 (UTC)
A good thing! I have been thinking about this. In my idea, this tag can be used in three ways:
  • A way with oneway=yes connecting two e.g. lifts, where one point is clearly downhill to the other and walking/climbing the other way wouldn't be a normal operation
  • A way with oneway=no connecting two e.g. gondola lifts or a lift and a ski hut, where one point is not clearly downhill clearly downhill to the other and walking/climbing the other could be a normal operation e.g. here where from the top of the Collete du Gilly, you can climb a few m up to the pass Collette du Gilly, then glide to the top of the Ruibon ski lift, or you can do it the other way around.
  • An area, connecting many pistes and lifts together which might require some example
IIVQ (talk) 14:00, 27 September 2016 (UTC)
Implicit, implicit, easy to say. Generally speaking for ski pistes, the effort needed to route taking elevation data into account makes me feel that for ski pistes, explicit oneway tags do no harm. --Yvecai (talk) 18:50, 6 October 2016 (UTC)
I agree. Routers can still decide to ignore oneway tags within piste:type=connection. (talk) 08:26, 7 October 2016 (UTC)

oneway=* or piste:oneway=* ?

I think piste:oneway=* would be better than oneway=*, especially when used on a way that is also tagged with highway=*. --Tractor (talk) 21:00, 28 January 2018 (UTC)

And how would that relate to the present piste:type=*? Why break the present use of oneway=*? Cycleways have tagging that performs the task of oneway exceptions .. why not use the same method here? If the tag highway=* is present why not use the access tag to signify the use by skis/toboggans or anything else? Should not the piste be only for snow related things and not be shared? Cycleways are specifically for bicycles .. shared ways should be tagged in other ways. Warin61 (talk) 02:59, 29 January 2018 (UTC)
piste:type=* is often used in combination with highway=*. A way tagged with highway=unclassified. + piste:type=nordic functions as a road when there's no snow and a ski track in winter. All tags added to the way with the piste: prefix then refer only to snow and ski related things. piste:oneway=* is already in use and does not break the use of oneway=*. --Tractor (talk) 05:08, 29 January 2018 (UTC)

General proposal comment

This proposal is a very good idea. It's nice and simple, and orthogonal to already existing piste:type. I don't see no problem with it coexisting with small piste:type=downhill or else that can connect a few lifts here and there. In my opinion, take a big resort you know well and try it! --Yvecai (talk) 18:44, 6 October 2016 (UTC) support for the connection value

I thought it would, and it does without changing anything in the code. You can check when routing between the two lifts here:

If the tags get more traction, I'll try to put a better description than 'undefined' though. --Yvecai (talk) 18:36, 21 October 2016 (UTC)

First use cases

Here, a piste:type=downhill, piste:difficulty=easy, area=yes have been replaced by piste:type:connection on existing tracks. I'd say, ... why not. --Yvecai (talk) 18:47, 21 October 2016 (UTC)