Proposed features/Piste Maps
From OpenStreetMap
This proposal is for a whole set of tags that are required to describe piste maps.
Last winter (2005/6) some experiments were performed to record tracks and tag piste maps. This proposal builds on that experience but takes into account the development of additional techniques (such as areas) that have been developed since then.
Tag prefix
Piste map specific tags will use the piste: namespace to avoid potential conflicts with similar tags used in other contexts (eg capacity, speed, classification).
Areas
- landuse=winter_sports
- name=name of resort or ski area (eg Espace Killy)
- natural=glacier to define the extent of a glacier
aerialway
Key:aerialway has already been accepted onto Map Features, but this proposal involves making the following changes to that key:
- Split 'gondola' off as a new value, distinct from 'cable_car'
- Remove 'drag_lift' value, since this is a type of surface lift, not an "aerialway"
- ...and additionally add 'pylon' and 'station' node value
The resulting set of values would be as follows:
| Key | Value | Element | Comment | Example | Icon |
|---|---|---|---|---|---|
| aerialway | cable_car |  | cablecar or tramway. Just one or two large cars. The cable forms a loop, but the cars do not loop around, they just move up and down on their own side. | 
| |
| aerialway | gondola | | gondola lift. Many cars on a looped cable. | 
| |
| aerialway | chair_lift | | chairlift. Looped cable with a series of single chairs (typically seating two or four people, but can be more) Exposed to the open air. This automatically implies oneway=yes. |  
| |
| aerialway | mixed_lift | | A mixed lift, containing both gondolas and chairs. | 
| |
| aerialway | pylon |  | Supporting tower for an aerialway. May be numbered with ref=number | ||
| aerialway | station | | For stations, especially when they are in the middle | ● |
Surface lifts
| Key | Value | Element | Comment | Example | Icon |
|---|---|---|---|---|---|
| piste:lift | t-bar | | t-bar lift. This automatically implies oneway=yes. | 
| |
| piste:lift | j-bar | | a j-bar lift, like t-bar but just on one side. This automatically implies oneway=yes | ||
| piste:lift | platter | | Platter lift, similar to a t-bar, but with a disc instead of a bar. Single-person only. This automatically implies oneway=yes | ||
| piste:lift | rope_tow | | a rope tow. This automatically implies oneway=yes. | ||
| piste:lift | magic_carpet | | magic carpet. This automatically implies oneway=yes. |
Lift attributes
The start and end nodes of a way tagged as a piste:lift are assumed to be a station. These nodes may have their elevation documented with ele=*
| Key | Value | Element | Comment | Example |
|---|---|---|---|---|
| piste:lift:occupancy | number of people in each car, chair, etc | | piste:lift:occupancy=1 implied for button_lift and piste:lift:occupancy=2 implied for t-bar | |
| piste:lift:capacity | number of people per hour | | piste:lift:capacity=2600 | |
| piste:lift:duration | number in minutes | | average/typical time for journey on lift from one station to the next |
Railways
railway=incline for funiculars and other cable or rack driven railways which are not connected to a main line, as might exist at a ski area.
Pistes
A piste may be a route through a variety of different terrains. It might be a meadow or a mountain road or part of a glacier. Pistes may be defined as ways or as areas:
| Key | Value | Element | Comment | Example |
|---|---|---|---|---|
| landuse | piste |  | a piste, left border drawn in driving direction. | |
| piste:type | downhill | | An alpine/downhill ski route. ways should be use for trails connecting the routes. This automatically implies oneway=yes. | |
| piste:type | nordic | | A nordic/cross country ski trail | 
|
| piste:type | sleigh | | A piste exclusively for sleighs | |
| piste:type | sled | | A piste exclusively for sleds. This automatically implies oneway=yes. | 
|
| piste:type | snow_park | | a funpark with rails, quarter pipes .. This automatically implies oneway=yes. | |
| man_made | piste:halfpipe | | a halfpipe. This automatically implies oneway=yes | 
|
Additional tags for pistes:
- piste:difficulty=
| US/Canadian | Europe | tag value |
|---|---|---|
| "bunny hill" | green | novice |
| green circle | blue | easy |
| blue square | red | intermediate |
| black diamond | black | advanced |
| double black diamond | orange (Austria, Switzerland, certain other areas), double-black (Scandinavia) | expert |
| yellow | freeride |
Other
- ski school (building=yes, amenity=ski_school)
- ticket office (shop=ticket)
- mountain restaurant (amenity=restaurant, building=yes)
- viewpoint (tourism=viewpoint)
- mountain rescue (amenity=mountain_rescue)
- mountain hut/refuge (amenity=shelter)
- bobsled track (sport=bobsled)
Comment
key namespacing with colons
- Do we really want to start using colon to group stuff - to be honest the proposal is quite confusing in this regard. This is a concept used nowhere else in the map features. Maybe better something like: for a lift: ski_lift=platter, name=Bielerhöhe, duration=7 or for a piste: ski_piste=alpine, name=Teufelsfahrt, difficulty=expert. -- Ulfl 04:30, 5 December 2007 (UTC)
- Yes, we do. This is something that needs to be done more elsewhere. (and yes, it is used in a few other places.) A single flat namespace like OSM mostly has is very, very ugly. --Hawke 09:42, 15 December 2007 (UTC)
- I repeat: this is a concept currently nowhere used in the map features page - please prove it! Using namespaces like this can be very confusing for mappers (when to use colons, and when to use undercores?!?) - with this current proposal you would have no chance to map anything without reading this proposal quite often. I'm not against namespaces in principle, but the way namespaces are introduced here is very confusing. -- Ulfl 06:51, 20 December 2007 (UTC)
- So we can never add anything to the map features page that isn't already there? -- "like this" as opposed to how? -- colons should be used for namespace separation, underscores for word separation. Why would this proposal give "no chance to map anything without reading this proposal" any more than any other page describing how to map a particular feature? --Hawke 03:56, 21 December 2007 (UTC)
- i think what ulf is suggesting is that you are proposing something fairly new as if it were a common practice on OSM. before we start adopting any new practices here, they need to be discussed and voted on - that isone of the first principles of OSM, no unilateral decisions. this has come up before; my personal preference would be for someone to create a page explaining entirely why namespacing is a good idea, debate all the pros and cons, and then it can be referred back to whenever the subject comes up. no-one is necessarily for or against the idea yet, it just needs to be explained and discussed Myfanwy 21:00, 5 January 2008 (UTC)
- First:I don't think I'm proposing anything, actually. If you look at the history of this page, the namespacing idea was in there from the beginning (over a year ago). I merely changed the prefix from the fairly meaningless "opm" to "piste". Second:Namespace aside, it doesn't matter whether there's a colon in the tag or not. piste:type is just as good as simply "type" (and I would obviously argue that it's better, because it's less ambiguous.) So maybe a better question is, why /shouldn't/ tags be namespaced? --Hawke 07:23, 6 January 2008 (UTC)
- Sure: because they provide zero extra information, make the tag names longer, are possibly more confusing to some people, and crucially don't help solve any problem. I think the principle of keeping the shortest possible sensible tag name should be used. The colons aren't a problem although some people seem to have an obscure aesthetic problem with them... piste:lift, piste_lift, chair_lift, chairlift, probably doesn't make a lot of difference in the end. Randomjunk 09:44, 25 April 2008 (UTC)
- As the discussion on the list pointed out, it provides context, so data processors don't have to look at as many (irrelevant) keys, and prevents potential conflicts. --Hawke
- Sure: because they provide zero extra information, make the tag names longer, are possibly more confusing to some people, and crucially don't help solve any problem. I think the principle of keeping the shortest possible sensible tag name should be used. The colons aren't a problem although some people seem to have an obscure aesthetic problem with them... piste:lift, piste_lift, chair_lift, chairlift, probably doesn't make a lot of difference in the end. Randomjunk 09:44, 25 April 2008 (UTC)
- First:I don't think I'm proposing anything, actually. If you look at the history of this page, the namespacing idea was in there from the beginning (over a year ago). I merely changed the prefix from the fairly meaningless "opm" to "piste". Second:Namespace aside, it doesn't matter whether there's a colon in the tag or not. piste:type is just as good as simply "type" (and I would obviously argue that it's better, because it's less ambiguous.) So maybe a better question is, why /shouldn't/ tags be namespaced? --Hawke 07:23, 6 January 2008 (UTC)
- i think what ulf is suggesting is that you are proposing something fairly new as if it were a common practice on OSM. before we start adopting any new practices here, they need to be discussed and voted on - that isone of the first principles of OSM, no unilateral decisions. this has come up before; my personal preference would be for someone to create a page explaining entirely why namespacing is a good idea, debate all the pros and cons, and then it can be referred back to whenever the subject comes up. no-one is necessarily for or against the idea yet, it just needs to be explained and discussed Myfanwy 21:00, 5 January 2008 (UTC)
- So we can never add anything to the map features page that isn't already there? -- "like this" as opposed to how? -- colons should be used for namespace separation, underscores for word separation. Why would this proposal give "no chance to map anything without reading this proposal" any more than any other page describing how to map a particular feature? --Hawke 03:56, 21 December 2007 (UTC)
- I repeat: this is a concept currently nowhere used in the map features page - please prove it! Using namespaces like this can be very confusing for mappers (when to use colons, and when to use undercores?!?) - with this current proposal you would have no chance to map anything without reading this proposal quite often. I'm not against namespaces in principle, but the way namespaces are introduced here is very confusing. -- Ulfl 06:51, 20 December 2007 (UTC)
- Yes, we do. This is something that needs to be done more elsewhere. (and yes, it is used in a few other places.) A single flat namespace like OSM mostly has is very, very ugly. --Hawke 09:42, 15 December 2007 (UTC)
- I like the proposal in general, but don't think it's a good idea to a colon as separator in tag keys. In my eyes piste:lift is strange, because I do not consider a lift part of a piste. The piste is only these parts you ... ahm ... I go down. Why not use just lift? Instead if piste:type I'd recommend piste_type. For the lift attributes (capacity, occupancy,...) I'd just drop the "coloned" prefix. --ramack 19:28, 5 January 2008 (UTC)
- The reason for the "piste" prefix, is that these sorts of lifts are used primarily, or maybe even exclusively, in conjunction with pistes. This page is meant to document how to map a ski(/snowboard/winter sports) area, not just the pistes themselves. I am hesitant to use just "lift" because it's ambiguous, and the obvious alternative (chair_lift) is inaccurate because they're not all chair lifts. --Hawke 05:47, 24 January 2008 (UTC)
- Given the recent mailing list discussion where nobody could actually come up with a reasonable reason to start using namespaces, in the interests of simplest sensible tag names, I think it would be best to drop some of the piste: prefixes. In particular the idea of "piste:lift:occupancy" has been shown to be functionally identical to "occupancy", so why the extra typing? Mailing list discussion (it gets quite surreal at points). Randomjunk 09:44, 25 April 2008 (UTC)
- I see several reasonable reasons to use namespaces in that thread. It's not nearly as clear-cut as you imply. --Hawke
lift:feature
A comment was added to the chair lift: "Supporting features are lift:feature=Bubble (for those with a windshield) and lift:feature=Heating (for those with a heated seat)". The problem is, what about a lift with multiple features? For that reason, I have moved that comment down here. --Hawke 09:45, 15 December 2007 (UTC)
- I would go with heating=yes|no windshied=yes|no instead... --PhilippeP 14:41, 18 January 2008 (UTC)
namings "piste:"
- I would replace piste: which is too generic, by ski:, and alpine by downhill. Alpine would refer to alpine skiing, ski mountaineering, alpine touring or whatever you call climbing mountains in winter with ski. There are also at last two kinds of ski piste: ones that are prepared, marked, watched by ski patrol, you have to pay a fee, the others are generally only marked, but your on your own. This apply to both nordic and downhill ski. Additionnaly, you also have mountain route (in the Alps, Scandinavia,etc.) which are the standard route (usual path) to climb a summit, a pass, between two huts, etc. Gummibaerli 16:57, 15 December 2007 (UTC)
- Is there a situation where piste does not refer to a ski trail? --Hawke 13:19, 21 December 2007 (UTC)
- Us snowboarders use pistes as well - not just skiers, we don't like terms that contain the word ski (ski resort, ski run, ski lift, etc). It's too discriminatory. 80n 18:51, 4 January 2008 (UTC)
- To me piste means track, ground, strip, but I am not a native speaker. It's probably more specific in English than in most langages. Gummibaerli 12:28, 6 January 2008 (UTC)
- I think the idea is that the bit before the colon acts as a high-level seperator. If you're interested in rendering a a piste map, you might look for all tags with 'piste:' prefix. For more conventional maps you might ignore them. To split it by different piste types would make this less effective.
- I'm a bit undecided about whether this ':' namespacing is a good idea, but I found myself adopting it for my tagging of whitewater maps. It makes it clear that you're tagging something which is not necessarily of interest to people rendering a street map.
- ...and given that we're looking for an english word which encompasses all different types of skiing and snowboarding (being deliberately generic) we could use "snowsports", but "piste" is also reasonable choice I think. "piste" might mean track/ground/strip as a direct translation, but generally if someone says "piste" you're more or less always talking about skiing/snowboarding.
- -- Harry Wood 12:00, 2 April 2008 (BST)
Slope Difficulty Taggging
- There's pretty big difference between red and black slope. They should not be both tagged with same tag ("intermediate"). Pavel 00:14, 17 December 2007 (UTC)
- Is what North Americans call "Cross Country" covered under "Nordic"? - CoreyBurger 05:14, 5 January 2008 (UTC)
- Yes. North Americans use both terms. (e.g. most/many ski clubs tend to use the term "nordic") --Hawke 05:49, 24 January 2008 (UTC)
aerialway changes
I'm interpreting the #aerialway section as a proposed change to the values which we already have on Map Features#Aerialway. I've clarified this above (is that what was intended?) It seems like a good idea to tackle the problem that 'drag_lift' is not really an 'aerial' way. But perhaps a better way of restructuring this would be to do away with the "aerialway" key, and have one all-encompassing "lift" or "ski_lift" key. Am I the only one who's thinking "aerialway" is a bizarre key name? -- Harry Wood 13:49, 18 January 2008 (UTC)
- I agree that aerialway is a bit weird, but "lift" means elevator in the UK, and they're not all used for skiing (particularly cable cars) --Hawke 23:02, 28 January 2008 (UTC)
Specialities
I just got another speciality from CH/Zermatt: a single aerialway with both gondola and chairs. There is also a cable railway, a rack railway and an elevator. And not to forget: glacier pistes in summer. --Andy 21:48, 19 January 2008 (UTC)
- Cable and rack both sound like forms of funicular, which is to be tagged as railway=incline. (correct me if I'm wrong). Oh, and global warming should take care of those glacier pistes. ;-( Nothing helpful to add on your combined aerialway type though. --Hawke 02:41, 25 January 2008 (UTC)
- The same speciality is in CH/Toggenburg also, one gondola per 3 chairs. studerap 13:51, 28 January 2008 (UTC)
- I've added aerialway=mixed for these lifts. --Hawke 17:00, 29 January 2008 (UTC)
amenity=mountain_rescue
There is a proposed First Aid (with no details so far) wich seems more general and convenient --PhilippeP 10:44, 23 January 2008 (UTC)
- Sounds good to me. I don't know what "mountain rescue" is though, so perhaps someone more familiar with the concept could comment or change it if appropriate. If I had to guess, I would guess that this would be a ski patrol base/office kind of thing, a place for mountain rescuers to work and/or get supplies from rather than a place for people in need of first aid to go. I'm really not sure though. --Hawke 05:53, 24 January 2008 (UTC)
- Kind of both, some sort of 'Baywatch' on the mountain but without the swimsuits ;) It's just that it's allready obvious that it is on the mountain so we don't need the mountain_prefix and FirstAid is what I searched first in the tag lists --PhilippeP 07:16, 24 January 2008 (UTC)
- 'rescue' seems kind of ambiguous. Perhaps we could find a term which would apply both to water lifeguard stations and mountain rescue, since we agree that they're similar. (lifeguard is to beach as ski patrol is to mountain)...or maybe I am wrong: See http://en.wikipedia.org/wiki/Mountain_rescue . I'm still not clear on what mountain rescue is, but it does seem to be distinct from http://en.wikipedia.org/wiki/Ski_Patrol --Hawke 23:24, 24 January 2008 (UTC)
- I would imply that a ski patrol needs snow. A mountain rescue is independant of the weather. A mountain rescue does not necesarrily have to be in the mountains (in Germany, e.g. in Munich, there is a mountain rescue in the city. It's for the Alps, for higher regions, high buildings (like skyscrapers or huge silos). Additionaly at least in Germany lifeguards do not have to be at the sea. There is even lifeguard at great lakes. (In fact, lifeguards can be even in regions where there is not much water. E.g. there is a lifeguard in Schwabmünchen. --Helm 04:53, 25 January 2008 (UTC)
- That's why I proposed (and first seached for) FirstAid wich BTW has a detail page now --PhilippeP 09:06, 25 January 2008 (UTC)
- I would imply that a ski patrol needs snow. A mountain rescue is independant of the weather. A mountain rescue does not necesarrily have to be in the mountains (in Germany, e.g. in Munich, there is a mountain rescue in the city. It's for the Alps, for higher regions, high buildings (like skyscrapers or huge silos). Additionaly at least in Germany lifeguards do not have to be at the sea. There is even lifeguard at great lakes. (In fact, lifeguards can be even in regions where there is not much water. E.g. there is a lifeguard in Schwabmünchen. --Helm 04:53, 25 January 2008 (UTC)
- 'rescue' seems kind of ambiguous. Perhaps we could find a term which would apply both to water lifeguard stations and mountain rescue, since we agree that they're similar. (lifeguard is to beach as ski patrol is to mountain)...or maybe I am wrong: See http://en.wikipedia.org/wiki/Mountain_rescue . I'm still not clear on what mountain rescue is, but it does seem to be distinct from http://en.wikipedia.org/wiki/Ski_Patrol --Hawke 23:24, 24 January 2008 (UTC)
- Kind of both, some sort of 'Baywatch' on the mountain but without the swimsuits ;) It's just that it's allready obvious that it is on the mountain so we don't need the mountain_prefix and FirstAid is what I searched first in the tag lists --PhilippeP 07:16, 24 January 2008 (UTC)
area:landuse=winter_sports
But the same land is used in summer for summer sports like biking ... winter_sports seems too limited even wrong ... --PhilippeP 07:23, 24 January 2008 (UTC)
- True. I would say though, that these areas, and the features described on this page are particularly designed for winter sports. I have seen one or two places where gondolas are run in the summer for tourists or for cyclists to get to the top of the mountain, but it's still clear that the gondolas, cleared pistes, etc. wouldn't exist in the form they do if not for the winter sports. --Hawke 23:19, 24 January 2008 (UTC)
- In the US ski resorts often have very well defined boundaries, sometimes a very high marked fence. In the Alps many ski areas do not have well defined boundaries (other than the marked pistes themselves) but even then its possible in most cases to describe an area that bounds the area where non-off-piste skiers are likely to be found. 80n 01:22, 25 January 2008 (UTC)
- I agree with the boundaries, but these are specific to the resort or domain or the pass limits not to the season ... --PhilippeP 09:11, 25 January 2008 (UTC)
- There is a proposal for ski resorts, i guess we could merge these both proposal. studerap 14:06, 28 January 2008 (UTC)
- I guess. I don't really like that proposed feature (because it seems to be documenting various statistics of the ski resort (number of runs, number of lifts, height of highest lift, etc., rather than actually mapping the area. --Hawke 18:33, 28 January 2008 (UTC)
- If we would use relations to add e.g. parking places, lifts and pists to a ski resort, it would be a fine thing. -- studerap 07:04, 29 January 2008 (UTC)
- I guess. I don't really like that proposed feature (because it seems to be documenting various statistics of the ski resort (number of runs, number of lifts, height of highest lift, etc., rather than actually mapping the area. --Hawke 18:33, 28 January 2008 (UTC)
- There is a proposal for ski resorts, i guess we could merge these both proposal. studerap 14:06, 28 January 2008 (UTC)
- I agree with the boundaries, but these are specific to the resort or domain or the pass limits not to the season ... --PhilippeP 09:11, 25 January 2008 (UTC)
Example rendering
I and Studerap had added the current proposal to Osmarender. See my demonstration page for further details and example renderings. --Andy 22:21, 28 January 2008 (UTC)
- At last we managed to enhance the piste patch. Now most features are supported. Unfortunately only the downhill pistes are done. The others still need some work. Have a look at demonstration page to see example renderings.
- Do you have any suggestions how to render sleigh, sled, snow_park and piste:halfpipe? --Andy 02:12, 30 March 2008 (BST)
The current status (3.4.08) of the piste map proposal is now rendered with the osmarender. Here is an example. -- studerap 14:19, 4 April 2008 (BST)
aerialway stations
I've seen many aerialway and lifts with station in the middle. I think we should add a tag aerialway=station and piste:lift=station to nodes to mark those stations. They may be rendered as a big dot. If nobody is against it I add this to the list above. --Andy 14:16, 10 February 2008 (UTC)
- Wouldn't one tag be enough to mark such features? Should the start and end of a lift also be marked as aerialway=station? If its only for middle stations, we should better call it aerialway=middlestation. How should this tag be rendered when the lift ends in an building? studerap 21:36, 10 February 2008 (UTC)
- If it has to be tagged only one 'station' tag would be enough , it's location on the lift would show if it is the start , end or middle ... So far the only lifts that i've seen wich could be considered having a middlestation was not really a middle station, it was a common cable for two opposite lifts, so tagged as two different lifts ...--PhilippeP 06:53, 11 February 2008 (UTC)
- My thoughts where that station is known and used in railways. Using middlestation is redundant and prevents the use for the lower and the upper end station. That's not necessary (as we can assume that the both ends are stations), but easier to work with. I've started to add a aerialway=station tag whenever I add other tags to the end stations like ele=* and name=*. --Andy 19:09, 20 February 2008 (UTC)
- Wouldn't one tag be enough to mark such features? Should the start and end of a lift also be marked as aerialway=station? If its only for middle stations, we should better call it aerialway=middlestation. How should this tag be rendered when the lift ends in an building? studerap 21:36, 10 February 2008 (UTC)
I don't think there's any point to having an explicit station tag. The endpoints can be assumed to be stations, and a station in the middle is just a node with two aerialways connected to it. --Hawke 17:45, 21 February 2008 (UTC)
- Well some stations are quite big buildings, with built in restaurants etc, which definately seem to be worth tagging in some way. I guess you might even want a building=yes area in some cases. On the other hand I think it can be assumed that the end of a chairlift is a station as you say (perhaps we shouldn't need to explicity tag it). Can it be assumed that a mid-way node is a station? Not really. I think I've tagged a lift which changed direction very slightly (with a node) half way along. There's no station at that node.
- For me 'pylon' seems a bit excessive, but I guess if people wanted to take the time to map these things, they might be useful navigation points when figuring out where you are in the fog. There's a rendering problem with pylons though. The current osmarender rendering for a lift way, already looks like a set of pylons along a line.
- -- Harry Wood 11:38, 2 April 2008 (BST)
- Middle nodes in a way can't be assumed to be stations (they could be pylons obviously) but I'd do a lift with a middle station as two ways, the end points of both of which would implicitly be stations. I can't think of any reason to split an aerialway in two other than at a station, but there's probably some situation I haven't thought of. And of course, there's no harm in having station as an explicit tag either. --Hawke 21:58, 4 April 2008 (BST)
- OSM recommends splitting very long ways - lifts probably aren't long enough to be worth splitting, but maybe we should allow it anyway (without assuming the shared node is a station) to be consistent with the rest of OSM. Also, what about mid-stations where you can get off the lift but you can't get on it? -- Steve Hill 09:56, 5 April 2008 (BST)
- Middle nodes in a way can't be assumed to be stations (they could be pylons obviously) but I'd do a lift with a middle station as two ways, the end points of both of which would implicitly be stations. I can't think of any reason to split an aerialway in two other than at a station, but there's probably some situation I haven't thought of. And of course, there's no harm in having station as an explicit tag either. --Hawke 21:58, 4 April 2008 (BST)
Implied oneway=yes
The oneway tag is supposed to default to "no" if not specified. However, for pistes and certain lifts it makes sense to default it to "yes" and allow it to be overridden where appropriate. Ways which will usually be oneway are all the piste:lift values, piste:type=downhill,sled,snow_park, man_made=halfpipe and aerialway=chair_lift. Steve Hill 14:23, 5 March 2008 (UTC)
Make that "for some pistes ... it makes sense..." and I'll agree. piste:type=nordic should not default to yes. --Hawke 16:37, 5 March 2008 (UTC)
I've updated the tables, above. Steve Hill 14:09, 6 March 2008 (UTC)
- Why is a chair lift a oneway lift? You can also go down with such a lift. studerap 07:11, 7 March 2008 (UTC)
- You can go down some chair lifts, but (in my experience) most ski resorts are set up to not allow this. My aim was to make the defaults reflect the "usual" situation and allow exceptions to override them by explicitly specifying oneway=no. Steve Hill 09:27, 7 March 2008 (UTC)
- My experiences agree with Steve's. --Hawke 17:33, 7 March 2008 (UTC)
- In Switzerland, its normal that you can go up and down with chairlifts/gondolas/cable cars. If someone just want to do a walk on top of the mountian, enjoy the sun and drink a coffee. -- studerap 11:47, 17 March 2008 (UTC)
- Hmm, maybe default to oneway=no for gondolas and cable cars, and yes for chairlifts? I think I've seen maybe one two-way chairlift in my life. It seems weird to have different defaults depending on value though. --Hawke 16:13, 17 March 2008 (UTC)
- That's how I've implemented it in OpenPisteMap at the moment - gondolas, cable cars, mixed lifts default to oneway=no and chairs, drags default to oneway=yes. I think the only place I've seen a 2-way chairlift at a ski resort was in Mayrhofen, Austria. But in any case, the defaults are for the common case - you can always override them if they don't apply to a specific lift. Steve Hill 20:16, 17 March 2008 (UTC)
- Hmm, maybe default to oneway=no for gondolas and cable cars, and yes for chairlifts? I think I've seen maybe one two-way chairlift in my life. It seems weird to have different defaults depending on value though. --Hawke 16:13, 17 March 2008 (UTC)
- With chairlifts it probably depends on the situation a bit whether it's allowed. I got the impression they strongly discouraged going downwards on a busy skiing day. I guess because it causes confusion, and can mean they have to run the lift slower. Often they have a saftey trip mechanism (thin bar thing going across) which would stop you doing it. But I was once with a beginner friend, and when we ascended into some bad weather, she complained loudly that there was no way she was skiing down that, and they let her go down :-) During the summer when there's lots of walkers and coffee drinkers, maybe it's more common to go downwards. From that point of view, maybe we should just tag them as chairlifts and let poeple draw their own conclusions. Or are there particular types of chairlifts which are specially built for easier descending? -- Harry Wood 12:16, 2 April 2008 (BST)
- This matches my experience too. I've to add that most chair lifts over the middle station are not intended to use backwards (while they are able to if somebody really needs to). But in many smaller regions you have to use those lifts to go down from middle station if there's not enough snow. --Andy 23:35, 3 April 2008 (BST)
- In Switzerland, its normal that you can go up and down with chairlifts/gondolas/cable cars. If someone just want to do a walk on top of the mountian, enjoy the sun and drink a coffee. -- studerap 11:47, 17 March 2008 (UTC)
Magic Carpet Nodes?
Why can piste:lift=magic_carpet be applied to nodes?
- Most time there are verry short, so a node is enough to be drawn. studerap 11:49, 17 March 2008 (UTC)
- Seems a short way would be better since that would indicate the direction of travel. Steve Hill 15:55, 17 March 2008 (UTC)
- Most time there are verry short, so a node is enough to be drawn. studerap 11:49, 17 March 2008 (UTC)
Ski pass validity
It would be useful to be able to show which ski passes are valid with each lift. For example, in larger resorts there are often different types of lift pass covering different areas (at different prices) - e.g. you might have a "Meribel" pass which covers just the Meribel valley, or a "3 Vallies" pass which covers Meribel, Val Thorens and Courcival. Using relations seems like a sensible way of doing this. I'm not sure whether using the proposed "is_in" relation is sensible - that mostly seems to deal with places (e.g. what features are within a town), so a more explicit "liftpass" (or a better name?) relation might be better. Discuss. :) (And the next step is for me to work out how to render a relation in Mapnik :) Steve Hill 23:14, 17 March 2008 (UTC)
- A simpler scheme would be to tag the different lifts with different "networks". Notice network=name can be used for amenity=bicycle rental for example (kind of a similar situation). That would have to be used to give different names to the lowest level network divisions. It wouldn't encode the information that "3 Vallies" pass is valid on Meribel, Val Thorens and Courcival networks. -- Harry Wood 11:49, 2 April 2008 (BST)
Off piste routes
I've gone with route=ski for off-piste routes, since piste: prefixed tags for off-piste seem rather oxymoronic, and it's in the map features page. any comments? Sciuro 10:04, 25 March 2008 (UTC)
- This makes sense, since a route is not a piste. --Andy 19:25, 28 March 2008 (UTC)
- The Key:route page indicates that route is for non-physical stuff (e.g. bus routes, etc) so I would have thought route=ski would refer to a recommended way of getting between two places over physical ways (e.g. pistes, snow covered roads, snow covered footways, etc.). So, shouldn't the ways be marked up as physical entities using the appropriate highway, piste, etc tags as well as having the route=ski tag? (Also, whilst I accept the point that they aren't pisted, isn't this what the piste:type=nordic tag is for?)
- Good point. (with piste:type=nordic I'm not able to translate this properly, is this freeriding?) --Andy 21:07, 31 March 2008 (BST)
- piste:type=nordic is for a groomed, marked, nordic ski track. --Hawke 01:15, 1 April 2008 (BST)
- Good point. (with piste:type=nordic I'm not able to translate this properly, is this freeriding?) --Andy 21:07, 31 March 2008 (BST)
- The Key:route page indicates that route is for non-physical stuff (e.g. bus routes, etc) so I would have thought route=ski would refer to a recommended way of getting between two places over physical ways (e.g. pistes, snow covered roads, snow covered footways, etc.). So, shouldn't the ways be marked up as physical entities using the appropriate highway, piste, etc tags as well as having the route=ski tag? (Also, whilst I accept the point that they aren't pisted, isn't this what the piste:type=nordic tag is for?)
Buildings
When you say man_made=building, you mean building=yes? (add some attributes) Ojw 21:55, 1 April 2008 (BST)
- Yes looks like, I've changed it. I guess, it would be sufficent to link to the building proposal (as you did). studerap 11:03, 2 April 2008 (BST)
