Talk:Piste Maps

From OpenStreetMap Wiki
Jump to: navigation, search


Usage Status

I think the piste map proposal was silently accepted. Katzlbt 19:56, 6 February 2010 (UTC)

Piste Segments registered in the Alps in OSM as of 6th Feb. 2010:

  piste           |  c   
downhill          | 8241
nordic            | 1076
sled              |  258
skitour           |   78
snow_park         |   42
hike              |   29
sleigh            |   12

Some issues with dual/triple use pistes exist, and the combinations of: sled+hike, sled+downhill (Example: Christlum Skiing Area), sled+skitour, sled+hike+skitour still exist. Sled could imply hike but for safty reasons hiking downhill on a sled piste is a really a bad idea.

piste:type tags found in OSM: sled;nordic and downhill;sled


We had a discussion on the german mailinglist about tagging ski pists.


  • tagging pists "like rivers"
    • left border
    • right border
    • line in the middle
    • small pists, just line in the middle
    • rendered with same color as degree of difficulty (blue, red, black semi transparent), renderer need to be able to render areas
    • tunnels and bridges posible
    • crossing with lifts
Obviously tunnels and bridges are possible, but this is nothing special to do with pistes. What do you mean by "crossings with lifts? I don't see a need for the "line in the middle", it's just an area where people are free to go as they desire. In what way would it be "like rivers" -- "water on the right" doesn't apply. "small pistes, just line in the middle" they'd have to be very small, as the line with piste:type=alpine implies a trail rather than the typical open alpine piste. --Hawke 18:59, 26 September 2007 (BST)
The river similarity is with the riverbank tag to mark the real edges of the river, the central line represent the river, the flow and gets the attributes like name ... And some pistes are small (usually easy ones for returning safely to the station) ...Crossing between piste and platter/T/J lifts are quite common and require some prudence --PhilippeP 16:51, 13 January 2008 (UTC)
OK, I've just never seen a crossing between a piste and a low lift like that. And I haven't seen large rivers done with a line showing the main flow either (though I seem to remember a proposal about that). Linear pistes are already covered anyway. --Hawke 19:59, 15 January 2008 (UTC)
the flow line of the river isn't really showed, it's covered with water ;) but it is visualized with the name that follows its course.(London Thames and Brussels Canal use them)--PhilippeP 20:56, 15 January 2008 (UTC)
If we go the 'river style' tagging for piste(wich have my preference), what would be the tag for the 'riverbank' equivalent ?? piste(_)bank, piste_border, piste_limit ... ?? --PhilippeP 08:07, 28 January 2008 (UTC)
Landuse=piste is tag documented by this page. --Hawke 17:41, 28 January 2008 (UTC)
Most of the ski resort maps I have seen in the US use lines to mark the trails, but include green, textured, or painted forested areas to show the width of trails. Let's do that, and mark the pistes and trails themselves with a curvy line as it's implemented now. SuitGuy 22:43, 24 February 2009 (UTC)

magic carpet

Is magic carpet the best description for that kind of lift? isn't it a conveyor belt lift? could just call it "belt". Also could drop the _lift from things which are already defined as lifts.

The tag namespace "opm" isnt particular descriptive. Do we need to state that the piste maps are "open" and "maps" in this context? Why not just use the namespace "piste", says what is does on the tin! --Tshannon 16:50, 25 September 2007 (BST)

The fact that the wikipedia article calls it "magic carpet" suggests that that is the most name (obviously no guarantee, but I think "magic carpet" is about as good as "belt". I removed the _lift from all but aerialway=chair_lift. I changed the namespace to piste, good idea. --Hawke 18:59, 26 September 2007 (BST)
If you check the Wikipedia talk page, "magic carpet" appears to be a brand name for a particular "conveyor lift". Maybe just "carpet" instead of "magic_carpet"? Robx 09:49, 4 December 2007 (UTC)


How about just "snow_park" instead of "piste:snow_park"? Personally, I'd prefer no underscores ("snowpark", "chairlift"). Also, see Proposed_features/Funicular_railway regarding railway=incline. Robx 09:52, 4 December 2007 (UTC)

Adding Piste:Types - an attempt to be complete

TODO (Initial reasoning after the colon; please add missing links):

  • Heli skiing: ADD THIS; Recommended/safe pists/destinations in the tourism industry exist.


  • Nordic skiing: FACTUM piste:type=nordic; but overly broad, does not include ski-touring(!)
  • Cross country skiing: piste:type=nordic; leave as it is, but never render as area, recommended, groomed pists in the tourism industry exist
  • Ski touring: added; Recommended/safe pists in the tourism industry exist
  • Mogul skiing (Buckelpiste): added as piste:grooming=mogul_skiing; exists in skiing areas, a person might want to go to a ski resort where many of those are, but it might also just be a feature of a piste
  • Ski mountaineering: NO; no recommended pists exist, pists could cover any area
  • Backcountry skiing: NO; very broad expression, includes nordic skiing in the backcountry and ski-touring in the backcountry
  • Winter-hiking is a new thing in the tourism industry to satisfy the need for nordic walking in the winter. Some of those pistes are shared with natural luge tracks (sledding trails) others are exclusive, groomed ways for walkers. All tourism areas have started to mark trails for wither-hiking. The shared character of the trails makes things difficult.
  • SAC SCALE for skitouring: Skitourenskala

Example: Heli routes (3MB JPG) More Links (not under discussion as type):

* Skiing
* Glade skiing
* Alpine skiing
* Extreme skiing
* Freeskiing
* Telemark skiing: NO; it is a way how to ski
* Skijoring: NO; it is a way how to do nordic skiing 
Key Value Element Comment Example
piste:type heliski Node Drop point for heliskiing. This is followed by a downhill or a skitour piste leading down to the valley. Icon

Rendering Ambiguity Area vs. Line - piste:type=nordic vs. skitouring

This area is an example of a rendering ambiguity with nordic pists: Skitour. The piste is an abandoned downhill piste that is now used by nordic ski-touring skiers (not nordic cross-country skiers!). Osmarender renders it as circular line, but it should be rendered as an area.

So we need a tag to indicate rendering as an area. One way to make correct rendering possible we need to split nordic in its 2 subclasses: nordic (always a line or use piste:area=yes) and skitour-skiing (line if not circular and area if circular).

Why not add piste:area=yes every time there is an area ? If a ski touring ring is going up and down a mountain using two different faces, and then going back to the start. That wouldn't mean you can ski all in between. sletuffe 22:08, 19 October 2009 (UTC)
Rendering downhill is quite easy: if the first and last point are the same it is an area. If they are different it is a line. Ski-tours should be renderable with this algorithm, too (I have not heard of circular tours). Adding a new tag is something I try to avoid if possible. It also adds complexity to the rendering. piste:type=nordic_area would also be possible. I am still undecided what could be done.

Old tagging ideas

The following tagging ideas were listed on WikiProject Piste Maps. I wanted to move them off there because it's going to be clearer if tags are either proposals or accepted onto Map Features. Basically these ideas need to either feed into this tagging proposal, or be rejected.

Problems with tagging

These are not important but would be good to solve.

  • A piste is an area not a line
  • the width of a piste changes a lot
  • recording all the properties can be hard
  • the altitude can not be recorded in any accurate way.
Basic ontology ===

Just give your way the class piste/lift, you can of course specify to a greater extent what it is, see below.

  • class=piste|lift
Advanced ontology for pistes
Cable Cars and Lifts
  • class=cableCar|bubble|chair|drag
  • name=name of lift
  • capacity=maximum number of people per hour
  • seats=number of seats in each car/chair
  • duration=mm:ss length of time taken between each station
  • direction=up|down|both (default=up)
  • bicycle=yes (if used to carry bicycles in the summer)
Alpine / Downhill Pistes
  • class=piste
  • name=name of piste
  • difficulty=green|blue|red|black|itinerary|off-piste (different scheme for pistes in North America?)
Nordic / Langlauf Trails
  • class=nordicPiste
  • name=name of piste
  • difficulty=??? is this applicable? what else is relevant?
Bicycle Trails

I've never done any mountain biking. Does anyone know what would be needed?

Snowboard Parks


I think some of the ideas can be rejected. The idea of having a key 'class' was abandoned a long time ago I think (which suggests that this whole bunch of ideas is actually rather old)

-- Harry Wood 13:21, 18 January 2008 (UTC)

Cross-country ski-trails (nordic skiing)

Suggested rendering

I'm not completely happy with the currently suggested rendering; I would like to propose the following:


Note that skating-only grooming is quite rare. I would reserve "dots" for marking ends of distance measuring points, and use some sort of triangles to mark skiing direction, rather than skiing style. Different colors could be used to indicate difficulty. Yellow background indicates lit track. Everything but difficulty is visible on BW print. Jesh 11:03, 2 February 2010 (UTC)

Plain lines are not a good idea: If we could keep the downhill piste colors for difficulty (and this let enough subjkectivity, IMHO) it is easier to render, but then plain lines can be confusing with downhill pistes. I'm happy with dashed or dotted lines yvecai 21:35, 7 February 2010 (UTC).

I would like to point out that nordic pistes are usually located a little bit away from downhill pistes. Currently they are also rendered with a narrower line than downhill. So I don't think that they would be confusing. See place like Himos for example. Quality of nordic track progresses when going from backcountry->classic->skating and rendering should reflect that. Jesh 17:23, 16 February 2010 (UTC)
I should add that nordic pistes can be located very far away from downhills. I think we should clearly distinguish betwwen the two types in rendering before ruining somebody's week-end. The transparency difference in osmarender is good in that sense. I'm making some test with mapnik to see what I can propose. A set of dashed lines could be a good idea: one can see the normal paths under the piste (where they exists) yvecai 22:38, 17 February 2010 (UTC).

I agree that the arrows or half-arrows are not good to indicate grooming-style as we definitely need a one-way symbol. Plus having arrows (or other marks) rendered accordingly to difficulty colors would need a lot of different LinePatternSymbolizers.

I gave a try with your proposal in mapnik:

Mapnik nordic proposal.jpg Looks good to me.

Bottom left corner: difficulties. The 'freeride' tag and color exists, so I added it. From center to top right: backcountry, scooter, classic, skating, cl + sk, oneway, lit. I underlined the pistes with white so it's more mapnik-like render (i.e. nice). Summer path can be seen in slippy map layer anyway.

Some are not rendered yet, if difficulty or grooming is not tagged, plus I need ideas for pistes prepaired for 'winter hiking', sleigh and snowshoeing yvecai 17:01, 25 February 2010 (UTC).

Looks good to me too. White background is a good idea. Maybe those hiking/snowshoeing routes could be something like backcountry skiing.. Jesh 12:01, 12 March 2010 (UTC)
I came up with new ideas here: User page yvecai; yvecai 06:59, 20 March 2010 (UTC).
For nordic, please swap the classic and skating, so that skating only would be continuous line and classic would be dashed line. Ice skating could be cyan line with white background, maybe with something extra to distinguish it from nordic&dh? Jesh 08:37, 20 March 2010 (UTC)
Good idea for ice-skating. An icon could be good in that respect.
I made dashed for skating and plain for classic because it looks like this on the ground: classic grooming is a continuous (actually 2) grooming line whereas the successive marks by skaters on the piste looks discontinuous. Make sense,no? yvecai 09:43, 20 March 2010 (UTC).
Well, classic only track is usually only one meter wide, or even less. Skating tracks are _groomed_ much wider, usually about 3 meters. So skating track is kind of an highway of nordic tracks, and classic track is more like a path. I see your point too but I would prefer that skating would be continuous line. The other reason is that classic style is basically good for backcountry/scooter/classic tracks (=render similarly), but modern skating equipment really are only good for skating/skating+classic tracks. Jesh 11:36, 22 March 2010 (UTC)
You made the point.yvecai 20:10, 22 March 2010 (UTC).

Use of Relations for Nordic Pistes

Yesterday I have been cross-country skiing on the nice Auerhahnloipe in Bavaria (about here). And at least there, most of the nordic pistes run on ways which are forst tracks during the summer season. In such a csae, a nordic piste is less a physical classification than a logical one. So I would prefer to mark nordic ski tracks/routes as route relations similar to the Cycle_routes. What do you think about that? Greetings, huirad

Is there any reason they can't be tagged as both piste:type=nordic and highway=track or highway=path? In what situation would that not work? --Hawke 17:16, 12 December 2008 (UTC)
Nordic trails have different names and they run on several different forst-tracks. They should be displayed as a single nordic-trail, so releations seem to be the right construct. --OAL 16:01, 16 January 2009 (UTC)
This is the classic application for routes: Route. Just create a route from the ways and tag it as needed with piste: tags.
By using piste:name you can tag pistes with different name than the track even without relation. This also helps that piste names of pure pistes do not show in Mapnik. I am not a friend of relations because they are hard to create and even harder to extract from the database, although the concept itself is good. On the other hand one needs sophisticated algorithms to extract pistes if they start to become networks. Sofar I have not seen a single piste relation entered into OSM. Has anyone tried it yet? Does it show on any renderer? Katzlbt 09:39, 6 February 2010 (UTC)
I entered a few nordic pistes into osm as relations. Additionally i tagged the ways with a few "piste:*=*" tags, according to the physical situation. I think nordic pistes shouldn't only be entered as relations, because relations aggregate ways or other things which belong together. A list of my few relations can be seen here: WikiProject_Piste_Maps/GermanyNordic. Zwennie 16:35, 5 March 2010 (UTC)

Is "nordic" better than "cross-country_skiing" as a name?

Yes. It's much more concise. --Hawke 17:34, 16 January 2009 (UTC)

nordic tracks designated for skating: grooming

Hello, is there any plan to distinguish nordic tracks (pistes) designated for skating (on ski)? Such track should be wide enough (>2m) and flat (preferably groomed).

Just to start more detailed discussions (I also need to have something to enter observations when I'm surveying, it can be changed later): What about piste:style=classic (implicit)/freeskating/backcountry/..? Backcountry may be more relevant as a seperate piste:type=backcountry, or together with route=ski. Use lanes=number to specify count of parallel (and/or meeting) tracks. oneway=yes may also be relevant in lit=yes skiing tracks. vibrog 18:13, 6 January 2009 (UTC)

On second thought, I think piste:grooming=classic (implicit)/freeskating/backcountry (or none?)/.. will be more descriptive. — vibrog 17:47, 7 January 2009 (UTC)
How should be tagged pistes groomed for both classic and freeskating style? (There are many of them in my local area). --Vrabcak 15:45, 8 January 2009 (UTC)
I thought about combining them piste:grooming=classic;freeskating. The reason I think this way, and not suggesting the value should be called "combined", is that I'm open to that grooming can be extended to describe alpine pistes in cases where preparation may be relevant. I actually hope someone have a better idea. By the way, does freeskating sound silly? Officially it is termed "free style", but lingo is "skating", thus you are free to use skating technique. — vibrog 20:15, 8 January 2009 (UTC)
The key grooming (or piste:grooming if we must) is good, I've been wondering how to do this myself. Regarding "freeskating", I'd prefer just "skating". It's not like this could conflict with ice-skating or roller-skating, could it? Robx 10:43, 13 January 2009 (UTC)
I'm completely open to call it "skating", or "grooming" or "piste:grooming". I want a way to give a complete picture of nordic skiing tracks. Easy to search and replace later when something have been decided on anyways. — vibrog 21:44, 16 January 2009 (UTC)
piste:grooming=* seems good to me. --Hawke 23:40, 16 January 2009 (UTC)

Any opinions regarding how to separate classic ski-trails groomed by light snow scooters? A separate piste:grooming=scooter tag, piste:grooming=classic;scooter, or lanes=1? — vibrog 20:41, 22 January 2009 (UTC)

  • I don't see a need to indicate what kind of machine the piste was groomed by. --Hawke 22:09, 22 January 2009 (UTC)
A scooter groomed XC track is much looser than a machine groomed one, and thus require different poles -- vibrog 09:26, 10 November 2009 (UTC)

Is piste:grooming=competition really useful for something? I can't see the point for nordic. At least local (FIS rated) competition tracks are among the very worst, unless there's competition coming, and that's pretty rare. Local competitions are held on the usual "hiking" tracks, and track quality is constant there. Maybe I'm also spoiled be always good tracks, but still. The competition quality also doesn't tell whether it means skating, classic or both. I would suggest dropping piste:grooming=competition, unless it's used by piste:type=downhill or something else. Some sort of quality tag could replace it, if needed at all. If it's not dropped, a better description is needed. Jesh 12:55, 12 March 2010 (UTC)

Tagwatch says it was used only on 6 out of 6000 grooming tags. I dropped it from the page. Other grooming types combined with difficulty ought to be enough. Jesh 13:47, 18 March 2010 (UTC)

oneway in nordic

I modified the spec on the other page (piste:type) to say that "the direction of the way should be the preferred/compulsory skiing direction (see piste:oneway below)" (previously "direction of downhill"). Downhill isn't that meaningful concept in nordic, especially with circular routes. However, many popular routes are oneway (to avoid collisions, or hazardous downhills). Compulsory direction should always be rendered, too. Jesh 18:49, 19 January 2010 (UTC)

nordic pistes and groomed hiking ways

Around where I've been skiing, in addition to the nordic pistes, there's also a network of "Winterwanderwege", which are groomed like for skating. How should we tag this? Sometimes, they use the same machine for doing these walking paths, so they appear to be groomed for classic skating, even though they're not meant for skiing. Sometimes, the skating pistes are also explicitly allowed for walking, sometimes explicitly forbidden. piste:foot=yes/no? I'm also unclear on whether these are actual legal access rights. At any rate, lots of walkers disregard them... Robx 10:52, 13 January 2009 (UTC)

When it is for grooming than you tag it like that, if it is for walking than you need something different (a special way should be discussed). I don't see a possibility to tag a "Winterwanderweg" at the moment (I know them). Probably piste:walking and than a difficulty level. I would't use piste:grooming for that. --Daniel27 23:08, 21 January 2009 (UTC)
Couldn't it just be tagged as highway=path and/or foot=yes, with seasonal restrictions if necessary? --Hawke 22:10, 22 January 2009 (UTC)
"Winterwanderwege" are tracks or paths that are specially prepared in winter, so that you still can use them when everything is snow-covered. They just exist in certain areas. It doesn't depend on the season it depends on the snow if paths are used as Winterwanderweg. We could have an extra tag for paths and tracks, like: groomed for walking in winter=yes (probably not the best tag ;) --Daniel27 23:23, 22 January 2009 (UTC)
Winterwanderwege in a region nearby are all "shared" with nordic traffic, so it would be a tag in addition to a nordic piste type.
I have added them as piste:type=hike to the proposal. The reason is that tourism regions in the Alps have started to give out brochures with regularly groomed winter-hiking trails and are competing with one another. A booming sport is also snow shoe hiking that is also covered. piste:type=hike can also be used for separated ascent routes to sledding trails. This considers everything but shared use, I hope.Katzlbt 20:08, 13 December 2009 (UTC)
BTW there is a "Premium" grade for the best winter hikes in Germany and Google finds already 96000 hits on winterwanderweg! Try the image search: Search Katzlbt 20:16, 13 December 2009 (UTC)

Grooming status

I'd like your thoughts on the two following issues:

Grooming status: How often should nordic ski-trails be updated in OSM? OSM probably does not intend to provide dynamic map data with day-to-day updates on grooming, but it may still be relevant to have a key such as piste:grooming:status=* for specifying that a piste have not been groomed for a few years, or one given year due to lack of snow. How up-to-date should a cross-country ski-trail network be on OSM? — vibrog 08:57, 1 February 2009 (UTC)

I don't think that OSM should provide any day-to-day information in piste:grooming tag. It would make map printing/exporting impossible, as there wouldn't be single trustable point when all the routes are as they should be. If the grooming machine is broken this week it shouldn't affect base map. Tagging should reflect the intended status of the route. There are other services to provide current information, with snow depth and all. URL tag to there might be a good idea. If current condition is implemented in OSM db, it should be a separate tag, and rendered as separate map layer. Jesh 18:40, 19 January 2010 (UTC)
I propose using a separate tag for the URL to a realtime grooming status webpage for the area. E.g. piste:grooming:url or something like that. Then it can easily be understood what it is.--Anderfo (talk) 15:26, 22 January 2016 (UTC)

Routing: Some pistes may follow a road for shorter distances, where skiers may have to take their skies off, not to damage them, or slide on the bank of snow along it. But this way is still a part of a ski-trail route, and should be tagged appropriately to make ski routing applications possible. route=ski is one possibility, a piste:type=nordic piste:grooming=road -pair another, or relations. — vibrog 08:57, 1 February 2009 (UTC)

  • One more issue on the same subject: piste:grooming=no should be defined. Some slopes are never gromed, but are not off-piste. In Tignes (France),they are rendered as 'x x x x' — Charlie Echo 11:15, 4 January 2010 (UTC)

Nordic Difficulties

The question is: how (and if) we have to tag the piste:nordic difficulties. Dowhnill piste have a rather objective way to do so.

How I do now:

  • Novice for strictly flat pistes
  • Easy for normal pistes
  • Intermediate when there is a steep slope section (downhill direction), or only this section.

I've never seen what I could consider as 'Expert' piste, but it often happens I do 'intermediate' on the bottom.

What I've seen on information maps: The nordic resorts I know would colored their map either just for the pleasure to add color, by length, sometime red or black meaning their is steep slopes. The length criterium is somewhat obvious on a map, and I find more interesting to show the difficulty as incliness. yvecai 19:15, 3 march 2010 (UTC)

Difficulty is also affected by narrow routes, sharp turns below otherwise avarage slope (possibly combined with dangerous terrain next to track), certain routes are always very icy, etc. It's probably not so easy to define absolute limits on difficulty, but local expertise and common sense probably give good enough results. I agree that length of the route should not be mixed with difficulty. Definitions above look good, maybe hard difficulty should imply that risk of crash is significantly larger than usual? Intermediate meaning that one gets away with sweat. Jesh 12:42, 12 March 2010 (UTC)
To summarize:
* Novice
Strictly flat terrain, no effort needed.
* Easy
Soft hills, short steep sections.
* Intermediate
Steep sections are present in the piste, or short narrow on average slopes. User gets away with sweat. Maybe used for the relevant sections only.
* Advanced
Steep sections are present in the piste, with narrow steep passages or sharp turns in steep passages, often icy pistes. Maybe used for the relevant sections only.
* Expert
Steep sections are present in the piste, with narrow steep passages or sharp turns in steep passages, often icy pistes. Dangerous terrain surrounds the piste. Maybe used for the relevant sections only.
* Freeride, extreme
Not relevant. Could be kept for completness.

What is the guidelines to add this in the proposal ? (if there is any...) Now that the Nordic pistes are rendered, it is important to have this kind of information for users. yvecai 09:18, 21 march 2010 (UTC)

Nordic Pistes entry points

I don't know for you, but where I leave between France and Switzerland, a lot of nordic trail starts in the middle of nowhere. The entry point to the trails is just a parking lot, maybe a map, and seldom a guy with a flask of tea to check if you have your ticket.

I think, this would be good to locate these points on the map, thus avoiding the pain to search them driving on roads where the snow have been barely cleared off.

We already have amenity=parking, place=locality and tourism=information + information=map + ski=yes that could describe those place. What about adding a piste=entry_door ? or piste=entry_point?

yvecai 19:16, 25 october 2010 (UTC)

In my area (Trondheim, Norway) it works quite well when the parking lot at the entry point has ski=yes along with amenity=parking, name=*. These places can easily be rendered on a map, such as this one: --Anderfo (talk) 15:20, 22 January 2016 (UTC)

Sled/sleigh trails, and wikipedia:skijoring

non exclusive sled-pists

I know several pistes which are not excusive. There is one which is for skiing during day and at night for sleds. Another thing to clarity: how to distinguish between piste and run? --OAL 06:29, 19 January 2009 (UTC)

I believe that in general, "piste" applies regardless of how wide the feature is. However, if I understand correctly, they could be distinguished by being a linear feature vs. an area. --Hawke 17:02, 19 January 2009 (UTC)
As to non-exclusive piste-types, perhaps using semicolons to separate them, as is done in other contexts. e.g. piste:type=sled;downhill --Hawke 17:02, 19 January 2009 (UTC)
NoNoNo. Please no Semicolons. DB queries would go for piste:type='sled' so the semicolon suggestion would be really bad. Maybe you could use a route that describes the way. If potlatch etc. allow it one could add the piste:type=sled and piste:type=downhill tag twice and add a description to clarify the issue. Katzlbt 21:02, 22 October 2009 (UTC)
As potlatch removes duplicate tags we could use piste:alternate_type=sled, but that is awkward. Katzlbt 07:54, 24 October 2009 (UTC)

Winter walking/climbing routes

This comment came up on the OpenPisteMap talk page - I've moved it here for further discussion since the question of how best to tag the features needs to be answered before adding rendering support to OPM. - Steve Hill 09:57, 30 December 2008 (UTC)

What about adding type snowshoe and winter-walks.
I thank that snowshoe is an activity available in many station, and for winter-walks it is available in "Les Diablerets" ( and it's use ful to know witch ways are available in winter.
CU and thanks in advance Sarge 13:21, 27 December 2008 (UTC)
I'm not sure this really belongs as a piste:type - possibly a variation of a footway and/or scramble would be best. I support the idea of having winter walking and climbing routes on openpistemap though, with some indication as to what equipment is needed (e.g. snow shoes, crampons, walking axe, climbing axes, etc.) and route grades where appropriate. - Steve Hill 09:57, 30 December 2008 (UTC)
In Vermont, USA and elsewhere in New England, many ski areas maintain official snowshoe trails with names and difficulty ratings. In addition, with the explosion of popularity in backcountry skiing (including lift-serviced backcountry) many of these trails are skiable and so become almost-official parts of the ski trail system. Where I ski, these would be an essential part of the map. For example, if I traverse or skin out of bounds, as I return I may encounter one of these trails and recognize it as skiable (often with moguls from significant ski traffic). I would love to have them show up on my GPS for safety, planning, etc. Any suggestions? SuitGuy 21:42, 23 February 2009 (UTC)
Winter climbing routes should be possible with piste:type=skitour and piste:difficulty=extreme. Katzlbt 20:20, 13 December 2009 (UTC)
Winter hiking trails: see above "nordic pistes and groomed hiking ways "

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
  • Database Queries on colon attributes (technical note): The colon separator disqualifies itself, because it would make Database queries MUCH more costly. You cannot query for a piste with name Teufelsfahrt with a naming scheme like that. So if you like, a separate piste:name=Teufelsfahrt is ok from the technical point of view. A colon or semicolon not.
  • 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
I'm with Hawke on this one. Consider differing difficulty ratings by use type. SuitGuy 22:46, 24 February 2009 (UTC)


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)
What about "detachable" and "fixed grip" chair lift? 15:48, 15 January 2009 (UTC)

Slope Difficulty Tagging

  • 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)
They're not. red is tagged "intermediate", black is tagged "advanced". --Hawke 13:19, 21 December 2007 (UTC)
he made a mistake, blue and red are same, this is nonsense, there is big difference between blue and red here, there must be a difference--Walley 19:31, 29 December 2007 (UTC)
I've never seen a green pist mark in Switzerland, so blue slopes are beginners one for me. raphael 13:18, 2 January 2008 (UTC)
Green slopes are used at least in France and Spain, though I agree that I never have seen them in Germany/Austria/Switzerland. Notaris 10:05, 16 January 2008 (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)
  • As has already been discussed, in North America we have a color convention for difficulty (green/blue/black and at some mountains double black) that would be more useful for the users of these maps than the corresponding blue/red/black and sometimes orange. Can we somehow cause North American pistes to be rendered with colors according to our convention? Or should I mark easy and intermediate pistes a notch down in difficulty (as beginner and easy) so that they appear in the expected colors for our skiers? SuitGuy 22:27, 23 February 2009 (UTC)
  • You should definitely not change the tagging to suit the renderer. If the route is intermediate, it's intermediate, regardless of how the map displays it. If someone wishes to set up a renderer to display pistes using US conventions, they're free to do so. (note, I am from the US) --Hawke 22:37, 23 February 2009 (UTC)
What would you think of rendering them one way in Europe and another way in the US (on the same planet map, i.e. openpistemap)? SuitGuy 22:37, 24 February 2009 (UTC)
It seems like a good idea to me. Note that there are some other places that use the same system as the US (Canada and Australia at least; not sure what Japan does) --Hawke 22:49, 24 February 2009 (UTC)
Wikipedia has some good-looking info on ratings link here. After reviewing that, I'm wondering whether we should add ratings in the North American (Australian, etc.) style. That is, piste:difficulty=green_circle, blue_square, black_diamond, double_black_diamond, etc. I also considered having piste:difficulty:europe=easy and piste:difficulty:usa=green_cirle, but that doesn't help us render them differently on the same map without some indication of which one is preferred, and besides, slopes in the US aren't rated with european ratings. There is a small wrinkle introduced by some resorts that have double-green-circle, blue-square-with-a-black-diamond-inside, etc. But since green/blue/black/double-black is pretty universal on the North American continent I'm leaning toward just adding those values to piste:difficulty and putting them in the rendering. What do you think? SuitGuy 23:09, 24 February 2009 (UTC)
We already have piste difficulties. easy is easy, regardless of how it's marked. If you want to render it differently in the US, talk to the people who work on the renderers. Don't change the tagging for the renderer. --Hawke 23:30, 24 February 2009 (UTC)

Is it needed to think about a new system to grade skipistes? In the end it is just a renaming and renaming introduces errors. I think in europe states japan or wherever they have made a choice for grading pistes. It would be wise to use this convention also in the mapping. If the piste is black in europe, call it black in the map if it is orange with green sprinkles on mars just map it that way. People using the maps, of that particularly area, have to know the conventions of grading for that area making the doubleblackdiamond rating understandable. This is both complicating and simplifying the rendering of the map, it complicates it slightly since you need more types of lines all be it only max 8. It makes it easier since there is no translation error from one system to the other and thus no guessing what to draw. You will end up with a list of 8 difficulties. That the americans use a form as well, so also the colorblind can make out the difficulty easily, does not change the color:

  • green (same color as green circle)
  • blue (same color as blue square)
  • red
  • black (same color as black diamond, might not be the same rating though, but the europe and americas landmass are not easily confused and if you do maybe you should not be doing this advanced map reading)
  • offpiste(since there is some discrepancy between a lot of resorts, but they all seem to mean a route suggestion outside of the controlled area where, for ppl not knowing the mountains, it is save to go down)
  • doubleblack (same color as doubleblackdiamond)
  • tripleblack (same color as tripleblackdiamond)
  • orange

The implementation for the map renderer should be left to the map renderer, but I think this is only an issue for the offpiste routes (yellow versus black dotted line). This list should however be followed and updated when resorts change grade markings. --Mafketel 09:10, 1 May 2009 (UTC)

OpenStreetMap is mapping what's on the ground. Easy is easy regardless of what continent you're on. People using the map don't care if a given piste is marked red, green, chartreuse, or mauve, they care how difficult it is. Rendering in a local style is a problem for the renderer, not tagging. This is no different than how motorways should be colored. (i.e. UK-style blue vs. US-style pink)--Hawke 15:47, 1 May 2009 (UTC)
  • In France, there is a slope category "harder" than Advanced, but still not Expert: it is black slopes without human intervention / grooming. We could set them as "advanced ; grooming=no" but they may deserve one more difficulty level. Charlie Echo 10:58, 4 January 2010 (UTC)
IMO they don’t need a different difficulty if they’re marked the same. grooming=no is probably adequate. --Hawke 19:17, 5 January 2010 (UTC)
  • The easiest slope level is "novice", which corresponds to a real one-way slope. But there are many areas that are basically flat, for instance to link various slopes' starts, and various aerials. I suggest we define a piste:type=flat which could be rendered in light grey.Charlie Echo 11:22, 4 January 2010 (UTC)
Couldn’t those be done with simple ways? that they’re linking slopes and lifts suggests that they could. --Hawke 19:17, 5 January 2010 (UTC)
Could be. But which type of way? "highway=path"? --Charlie Echo 18:15, 6 January 2010 (UTC)
Possibly, if it’s usable as a path during the summer. But also piste:type=downhill.

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)
I would not remove the aerialway=drag_lift value but use an additional tag to distinguish between the various drag lift lift types in combination with the existing value. I think it is not really a problem if the key names do not exactly fit all possible values. (The same would apply to some of the values for the highway tag.) Instead of adding a new value "gondola" I would prefer to use an additional tag to distinguish between the two variants. --Bomm 15:30, 26 June 2008 (UTC)


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)
I'm just about to tag up Col de la faucille lift (Telecombi du Mont-Rond) which seats 6 on the chairs and 8 in the gondolas - how do I tag the capacity?
I would suggest adding note=* to the lift, and describe the situation in text (e.g. "chairs seat 6, gondolas seat 8"). If this is common enough, perhaps it should be addressed somehow, but I have no idea how best to tag that otherwise. --Hawke 19:13, 2 February 2009 (UTC)
There are some of those lifts around, I know of another in Trois Vallées, France (Courchevel, I think). How about aerialway:chair_lift:occupancy=6, aerialway:gondola:occupancy=8? I guess that's most straightforward, albeit at the cost of somewhat lengthy tags. But it's absolutely clear and, due to the low frequency of such lifts, we would not need these tags too often. Oh, and while we're at it, we might also want to tag the gondola-to-chair ratio, for example aerialway:chair_lift:ratio=3, aerialway:gondola:ratio=1 for 1 gondola per 3 chairs. --Stanton 23:32, 16 December 2010 (UTC)


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 . I'm still not clear on what mountain rescue is, but it does seem to be distinct from --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)


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)
The proposed tags leasure=ski_resort and related features could replace landuse=ski_resort and landuse=piste. This would not collide with other landuse values. If you don't like the statistics you could omit these values. --Bomm 15:00, 26 June 2008 (UTC)
In the Alps many aerialways are useful for tourists or hikers to go on top of a mountain and therefore are open during summer. But the problematic part is the different land use during winter and summer and the resulting conflicts with the landuse key. Many areas that would be tagged as landuse=piste are used for feeding cows (by feasting or mowing the grass) when there is no snow. The farmers set up fences in spring and remove them before the ski season. So most time of the year it should be tagged as landuse=farm. That's why I would prefer tags that do not use the landuse key. --Bomm 15:00, 26 June 2008 (UTC)

I just wanted to point out that the landuse is not going to conflict since you will not be tagging the whole ski area with piste but only the specific pistes. The farm land will be a different polygon, hence no conflict--Mafketel 13:03, 18 November 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)

For rendering the area, is this already done? i did not find an example. ps the example above is big grey area with no information? If not is it possible to render the skipiste area

transparent with some small snowflakes in the color of the piste difficulty when the piste has artificial snowcannon
transparent with some small skiers in the color of the piste difficulty when the piste has no artificial snow making devices. --Mafketel 13:03, 18 November 2008 (UTC)

Is it possible to use the same color for difficulty of nordic piste than for downhills? There is probably no need for as much colors in nordic, but it is mandatory to show strong slopes on the pistes (==intermediate or advanced), so why not keeping the same colors for ease of rendering?

Current proposal (as specified in Difficulty/Europe) agrees common usage at least here in Finland (both dh and nordic). Blue,red and black are in common use. Jesh 17:04, 16 February 2010 (UTC)

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)

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)

To sum up all of the above and add more:

There are valid reasons to insert nodes into a lift which are not stations: Some drag lifts have turns in them (also some chair lifts, but that is less common), which would imply a node. Example: Tanzbödenlift in St. Anton am Arlberg, Austria (the turn is slight; I used to know better examples but they have been demolished or are in areas I have not visited in a long time). Conclusion: not every node is a station.

Some lifts have middle stations: for example the gondola from Méribel in 3 Vallées, France. There are two stations in the middle of the way, where passengers can get on and off as they wish. I would tag that as a single way and insert appropriately tagged nodes for each station. This approach would also be consistent with other types of line infrastructures (think of railways - do you split them at each station?). As for boarding/drop-off only: the latter is frequent for drag lifts; the former seems the default for chair lifts and gondolas. This can easily be achieved through an extra tag (I think something similar exists for bus stops, but it is not widely used).

With some lifts, there may be a considerable distance between the point at which passengers get off and the bullwheel. For example, at Übungslift Rendl in Austria the section between exit and bullwheel even crosses a piste. Not sure how to tag that, though. The exit needs to be tagged so that it can be distinguished from a simple crossing (at least in Austria, we do have pistes crossing draglifts). Not sure if we need a tag for the bullwheel - maybe an untagged node would do.

And, if the station is inside a building: this isn't too hard, just draw the building and place the station node in the middle of it. --Stanton 17:23, 18 December 2010 (UTC)

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)
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)
Sled pists are usually not oneway in the alps. Only about 5% are oneway because there is a second route or access way. Those pistes are used as forestry/hiking tracks in summer, so oneway=yes is incorrect and cannot be applied correcly (it would make the summer track oneway). I fixed the proposal and supplied a piste:oneway. The same problem existed for lit=yes. Sled lighting is off in summer. Katzlbt 20:31, 13 December 2009 (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)

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)
I would agree, except that some aerials are managed by a network, but are free. I would suggest using "network" tag, which would imply "free_access=no", and an optional "free_access=yes" tag. --Charlie Echo 12:00, 4 January 2010 (UTC)

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)
There are actually several classes of piste:type=nordic: classical or free style as main classification, and different qualities of grooming: Groomed by a snowmobile (for free style or dual tracks where lanes=2 can do), or a snow scooter lanes=1, and not groomed (e.g. manually-groomed by skiers), but still a cleared track in the wood that may not be suitable as a track or path in the summer. route=ski can be used for this. vibrog 21:41, 1 January 2009 (UTC)

aerialway key

I would not remove the aerialway=drag_lift value but use some specification of the various lift types in combination with the existing value. I think it is not really a problem if the key names do not exactly fit all possible values. --Bomm 15:11, 26 June 2008 (UTC)


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)

Simpler alternative

Instead of landuse=piste with piste:type=type_of_piste, I'd suggest to use piste=type_of_piste, applying to both linear features and areas. Seems more straightforward, plus the current method of tagging a nordic ski trail with just piste:type=nordic instead of piste=nordic is kind of ugly. Add an area=* if you wish if the piste type isn't enough to distinguish between areas and circular routes. Robx 23:30, 2 December 2008 (UTC)

I don't really see what would be gained by that change. landuse=* is already in use all over the place, and a (ski) piste definitely fits in with that. Also, the vast majority of downhill pistes are areas -- adding area=yes to all of them is silly, and unnecessary with the current proposal.--Hawke 17:02, 9 December 2008 (UTC)
I don't particularly mind the landuse, though different kinds of overlapping landuse are a little ugly. Regardless, how about moving piste:type=* to piste=*? Robx 20:25, 23 December 2008 (UTC)
The landuse tag is a mess, I object to landuse=piste, leisure=piste or even just piste=* is much better... --Thomas Wood 15:54, 9 January 2009 (UTC)
Nothing gained with this. Katzlbt 08:14, 24 October 2009 (UTC)


I started to look at this page as I'll go skiing in a couple weeks. So I was interested what to look for and how to tag. I already tagged something in Sölden from given gps tracks. I also prepared a German version for a OPM-page. Now I have some questions:

  • what is the difference between sleigh and sled?
  • when a piste is tagged as an area how should the direction be marked?
  • landuse=piste: left border drawn in driving direction left border from my point of view (tagger) or of the skiers view?
  • why landuse=piste when the piste is marked as an area? What's the difference then?
  • Something special to tag if two lifts cross? Different layers?
  • What exectly is a Proposed Feature on this side? As the pages for OPM aren't very clear about actual features (OpenPisteMap, WikiProject Piste Maps). What about piste:difficulty e.g. Can't we start a vote for the unproblematic features like Difficulty, grooming, amenity=ski_school,...? --Daniel27 15:21, 20 January 2009 (UTC)
  • A sleigh is drawn by a draft animal. See wikipedia:Sled.
  • Direction is not indicated for pistes as areas. I assume it would always be "downhill", without having direction enforced in any way.
  • Not sure what "in driving direction was intended to mean. I doubt it matters, just handle it like any other area.
  • No idea why landuse=piste. I've removed it. If someone comes up with a good reason to have it, feel free to re-add it.
  • Crossing lifts can be handled at your discretion. Layer tags are the most likely method though.
  • I believe everything on this page before "comment" is proposed. I don't think there are any controversial topics on this page, so it could probably be put to a vote. it could use some cleanup, such as moving discussion to the talk page.
--Hawke 19:03, 20 January 2009 (UTC)
  • Thanks for the answers so far
  • When a piste is tagged as an area a direction should be tagged as well. How should I now if the piste is the hill down or up when there is no direction? If I leave a lift (virtually on the map) I want to know which of the pistes is down. Downhill without a "down" doesn't make sense. For rivers I think there is an area and a way as well.
  • I think there still is something to discuss: should the key stay "piste:type" or should it be changed to "piste"? Do we really need "Surface lifts" or can we tag them as aerialway=t-bar.... Then we would have just one key. Would be much easier (see #aerialway key or #aerialway changes) ::--Daniel27 20:37, 20 January 2009 (UTC)
  • I don't see a value in tagging a centerline indicating direction as may be done with rivers, but you can feel free to do so. My point was just that "on the ground" it's obvious which way is down, and on the map it's still fairly obvious (the top of the pistes corresponds with the end of the chairlifts.
  • As to surface lifts, the problem with using aerialway is that they're not all aerialways. --Hawke 22:23, 20 January 2009 (UTC)
  • Not the top of every piste or lift is clear on a map. That should be one of the goals to clarify on a map. You could say: Doesn't matter what direction a oneway is, because you see it when you are there. That shouldn't be our goal, should it? I think a skiing direction is important. That's the reason why I till now just tagged ways not areas. Would be reason for a vote.
  • Sure that not all are aerialways, but do you want different keys? Probably one key: lift=.... would be better, but what with the existing ones? Would be another problem.
What about 2 votings: 1. key for lifts and 2. all the other features. The area "problem" can be solved independently. --Daniel27 22:56, 20 January 2009 (UTC)
  • Sounds fine to me. --Hawke 23:23, 20 January 2009 (UTC)

new features?

I propose some new features:

  • There should be a special tag for ski bus stops (ski_bus= no (default)/yes/only). Those sometimes are different from the usual bus stops and are only served in winter at special times.
  • Every lift has a certain opening hour, so a lift should be tagged including the opening hours. This is not really a new tag but should be mentioned.
  • Usually every ski resort does have a racetrack where your racing time is measured. This often is not in a funpark. Therefore an extra tag would be nice. --Daniel27 15:21, 20 January 2009 (UTC)


  • Remove 'drag_lift' value, since this is a type of surface lift, not an "aerialway"
  • Differentiating between surface and aerial lifts is nonsense and makes tagging harder for no good reason. Drag lifts have an aerial component, just as cable cars have a surface component. The distinction is pointless and only serves to create more tagging errors. 80n 16:09, 27 December 2008 (UTC)
  • Not all surface lifts have an aerial component. Rope tows and magic carpets run directly on the ground. Cable cars (in this context) do not have any surface component. --Hawke 22:25, 20 January 2009 (UTC)
  • Footways are not highways and still are tagged like that. The keys should be easy and don't have to be totally correct. I changed the vote for the proposal and hope we can solve it that way. --Daniel27 16:30, 22 January 2009 (UTC)
  • Actually, highway refers to the legal right of way, not to the type of traffic which uses it. So yes, some footways are highways. I've changed my mind regarding the use of piste:lift=* vs. aerialway=* mostly due to the effect on the "lift attributes" section: Most or all of those attributes can apply to aerialways as well as surface lifts. --Hawke 18:17, 22 January 2009 (UTC)
  • Add a 'Poma' value: There are different types of on-snow lifts. Some are tightly attached to the top-cable, and have a retractable rope: T-bars (2 people), J-bars (1 person), Platters (1 person). Some are only attached to the cable when someone is using them, and have a rigid bar with a disk to pull the user (1 person). See:[[1]] --Charlie Echo 11:42, 4 January 2010 (UTC)

lift attributes: bicycle?

Does the lift attribute "bicycle" gain anything over using bicycle=*?

Well, bicycle=* is an access tag (legal access with bicycle) and doesn't say much about usability (e.g. whether a lift is designed for bringing bicycles).--Anderfo (talk) 11:59, 28 January 2016 (UTC)


Might ice skating be better as something like leisure=skating_rink or sport=ice_skate? --Hawke 20:07, 22 January 2009 (UTC)

Several kilometers long skating track resembles ice road. Tagging it as piste:type=ice_skate sounds good to me. Simple ice rink is a different beast. Jesh 13:19, 4 February 2010 (UTC)

small unmarked pistes

how should small chunks of downhill pistes be tagged that are not part of an official piste but rather access ways to aerialways etc? they seem to have some similarity with highway=service, so i'd suggest they be tagged as piste:type=service or something similar.

an example is [2] -- the coloured pistes are officially existing ones, those rendered in gray by osmarenderer are such service ways; they are mainly access from and to aerialways or connections between nearby pistes. i am careful to include those (with occasional oneway=no) to make routing possible.

as of now, i have just tagged those as piste:type=downhill with no difficulty, to the effect that they are not rendered in opm (see [3] for comparison to the osmarendered area above).

would piste:type=service be appropriate? are there better ways of expressing that? --Osm6150856065 00:09, 18 February 2009 (UTC)

From the page, "ways [as opposed to areas] should be use for trails connecting the routes.". The renderer should be rendering these. You should talk to the people who control openpistemap. --Hawke 03:42, 18 February 2009 (UTC)

Who controls openpistemap? By the way, how do I tell who controls various OSM-related and -derived sites? SuitGuy 22:34, 24 February 2009 (UTC)
The web page suggests that you contact them by email. You can usually find contact information on the respective site. --Hawke 23:01, 24 February 2009 (UTC)

aerialway vs. piste:lift

Why have the piste:lift tags been replaced by aerialway for surface lifts? A look at the Wiki history seems to show that there was a vote proposed but then abandoned and the tags unilaterally changed without any discussion. It should be noted that OpenPisteMap does not currently pay any attention to the aerialway tag for surface lifts. If this had come up for a vote I would certainly have voted "no" since there seems to be absolutely no benefit to changing the tag and the change means that we now have to deal with two sets of tags in the rendering rules. Can we either reverse this change or at least bring it up for discussion? Steve Hill 09:37, 19 February 2009 (UTC)

The whole "Piste Maps" thing is still a proposal, not accepted. Changes are therefore allowed. The discussion for changing piste:lift back to aerialway=* can be found in the section above. See also [4] where aerialway was originally the key used for this, and [5] where it was changed to opm:surface_lift. --Hawke 18:02, 19 February 2009 (UTC)
It is only a proposal, but never the less, the tags are being used *now* so there are repercussions with changing the proposed tags so it would be useful to take a vote from those affected. I don't have any problem with making beneficial changes to the proposal but I honestly can't see any benefit in this change - it just seems to be changing the tags for the sake of changing the tags. Also, I tend to disagree that all surface lifts have an aerial component - magic carpets and rope-drags certainly don't, and by that argument you could claim that roads should be tagged as aerialways because they have streetlamps! I vote to change it back to how it was. Steve Hill 18:31, 19 February 2009 (UTC)
There is a benefit to this change: It doesn't split these two logically similar things into two tags (aerialway=* and piste:lift=*). It's more an avoidance of changing the aerialway tag where it's not necessary, than an arbitrary changing of some other tag. As a side note, at least some rope tows do have the "downstream" component on pylons. So the only irregular case is magic carpets (rare) and a portion of rope tows. Note also the effects of the "lift attributes" section if we're to split aerialway like this: we'll need to either apply aerialway:*=* attributes to things other than aerialways (which is not intuitive), or have duplicated piste:lift:*=* attributes. Bringing roads into this is totally off-topic. --Hawke 20:49, 19 February 2009 (UTC)
They aren't that similar really - aerialways can frequently be used by non-skiers (especially out of season), whereas surface lifts almost certainly can't. We don't group roads, railways and cycleways together, but it can be argued that they are similar. As for the lift attributes, despite once being a strong supporter of namespaced attributes I'm fast coming to the conclusion that it is the wrong direction to be going in. Sadly, the right direction is even more of an upheaval - see my talk page: Steve Hill 21:01, 19 February 2009 (UTC)
Actually, we do group roads and cycleways together. highway=* and highway=cycleway. Furthermore, aerialway=drag_lift has been in aerialway=* for a long time, and the surface lifts are all just more specific versions of that. Your talk page idea is definitely the right direction though, and I wish you the best of luck with it, and I'm happy to provide whatever help I can in support of it. But regardless of whether namespacing is a the best option in the long run, I think it's better than totally contextless tags, in the short term. --Hawke 00:08, 20 February 2009 (UTC)

So then how does snowcat skiing fit in, specifically the cat track? It is certainly a type of ski lift but not an aerialway. It could be labeled as a road in some cases, although like skin tracks and boot packs, it is not always a year-round accessible path since the snow allows access over terrain which would otherwise be impassible in summer.

too much in this proposal?

The idea of adding new tags for "paths and trails of Interest to Piste Users" is good, but should we really add this to this proposal, because it uses the basic/existing tags of highway=path/footway? I would prefer to use an extra Proposed feature for that idea. This proposal already is overload, I think. I'd rather like to prepare the vote for this proposal now, than adding even more, because slowley it's getting really much. --Daniel27 15:16, 28 February 2009 (UTC)

That part of the proposal doesn't really add anything anyway. ski=* and highway=path already exist --Hawke 19:02, 1 March 2009 (UTC)
So shouldn't we delete it from this proposal and add it in OpenPisteMap. I would prefer if this proposal would only show what is new. --Daniel27 20:11, 1 March 2009 (UTC)
Probably. --Hawke 17:39, 2 March 2009 (UTC)
Ok, I moved that section to OpenPisteMap. Is it safe to mention showshoe=designated and showshoe=yes tags in OpenPisteMap without some kind of formal process to add those tags to highway=path and highway=footway? Or is it okay for me to edit highway=path to add them? SuitGuy 21:57, 3 March 2009 (UTC)
You'd probably want to add them to Key:access. There shouldn't be a problem with just adding them. --Hawke 22:11, 3 March 2009 (UTC)

Tag for Summer Operation?

Is there a tag to indicate that a gondola or lift also operates in Summer or year round? It would be a very interesting information for hikers. Suggestion: aerialway:operation=all_year ?

I would support that. But compare the Key:opening_hours that is similar. --Geogast 12:31, 30 December 2009 (UTC)
Moreover, some lifts ONLY operate in Summer. Why not aerialway:operation=(winter|summer|all_year)? -Charlie Echo 10:58, 4 January 2010 (UTC)

sample presets.xml

<item name="Piste" icon="presets/path.png" type="way">
	<link href=""
	<label text="Edit Piste" />
	<space />
	<combo key="highway" text="Highway" values="path,cycleway" default="path"  />
	<space />
	<label text="Type" />
	<combo key="snowmobile" text="Snowmobile" values="yes,designated,no" default="" delete_if_empty="true" />
	<combo key="ski" text="Ski" values="yes,designated,no" default="" delete_if_empty="true" />
	<combo key="horse" text="Horse" values="yes,designated,no" default="" delete_if_empty="true" />
	<combo key="bicycle" text="Bicycle" values="yes,designated,no" default="" delete_if_empty="true" />
	<combo key="foot" text="Foot" values="yes,designated,no" default="" delete_if_empty="true" />
			<combo key="piste:type" text="type" values="nordic,downhill,skitour,ice_skate,snow_park,sled,hike,sleight" default="" delete_if_empty="true" />
			<combo key="piste:grooming" text="grooming" values="classic,mogul,skating,classic+skating,scooter,backcountry,competition" default="" delete_if_empty="true" />
			<combo key="piste:difficulty" text="difficulty" values="novice,easy,intermediate,advanced,expert,freeride,extreme" default="" delete_if_empty="true" />

	<text key="name" text="Name" default="" delete_if_empty="true" />
			<combo key="lit" text="Lit" values="yes,no" default="" delete_if_empty="true" />
			<combo key="piste:lit" text="lit only in winter" values="yes,no" default="" delete_if_empty="true" />

	<check key="oneway" text="Oneway" default="off" delete_if_empty="true" />
			<combo key="piste:oneway" text="oneway only in winter" values="yes,no" default="" delete_if_empty="true" />
	<check key="bridge" text="Bridge" default="off" delete_if_empty="true" />
	<check key="tunnel" text="Tunnel" default="off" delete_if_empty="true" />
	<check key="cutting" text="Cutting" default="off" delete_if_empty="true" />
	<check key="embankment" text="Embankment" default="off" delete_if_empty="true" />
	<text key="width" text="Width (meters)" default="" delete_if_empty="true" />


It would be great if nodes with tourism=information, information=map and ski=yes were rendered, too, not only information=pistemap. Cf. here. --Geogast 12:28, 30 December 2009 (UTC)

ski jumps

What's about ski jumps. At the moment I am tagging them as POI.

Regards Volker

Hi Volker, there is a proposal here:Ski_jumping. Could be a good idea to merge the discussions --yvecai 19:30, 28 February 2010 (UTC)

Reference number =ref

I am missing a ref-TAG which shows the number of a piste (eg. "4a"). User:Walter Schlögl 11:10, 6. Feb 2010 (UTC)

Ticket shop

The proposed amenity shop=ticket is too general, I am afraid it could collide with other use (trains, opera, luna park, ...). What about shop=ski_ticket or piste:shop=ticket? User:yvecai 21:50, 1. March 2010 (UTC)

Backountry / Freeride / skitour ... need clarification

I've started to translate the proposal page in french. Then, I figured out that some tagging schemes are not clear to me, and I'm probably not the only one. Here is what a mapper could do. What are the relevant tagging schemes? Then what are the forbidden ones? What is the difference between a nordic piste backountry groomed and a skitour ascent ? ... Please help me (us) to make that clear.

Key Discussion / Description
piste:type=downhill and piste:difficulty=freeride The proposal is not clear: off-piste or 50-55 degrees exposed terrain? Either freeride is a difficulty or it is off-piste, but not both. yvecai
piste:type=downhill and piste:grooming=backcountry Here would be pure downhill off piste yvecai
piste:type=downhill and piste:difficulty=freeride and piste:grooming=backcountry Here would be 50-55 degrees off piste yvecai
piste:type=skitour Nordic ascent on recommanded skitour
piste:type=skitour and piste:difficulty=freeride Nordic ascent on recommanded skitour with 50-55 degrees slope. Pretty rare I guess. yvecai
piste:type=skitour and piste:grooming=backcountry piste:grooming=backcountry is implicit. Is there any use for this? yvecai
piste:type=nordic and piste:difficulty=freeride Is there any use for this? yvecai
piste:type=nordic and piste:grooming=backcountry Pure off-piste, because skitour is recommended ? yvecai
piste:type=nordic and piste:difficulty=freeride and piste:grooming=backcountry Is there any use for this? yvecai

route=piste for route relations of different piste:types

So far the tag route=ski has been established for pistes with piste:type=nordic/alpine. But the key piste:type=* has been widened to all kinds of piste types like snowshoe trails, sledding pistes, or ski tours. Those could be tagged with separate new route tags, e.g. route=snowshoe, route=sled, and route=skitour. However the use of route=piste for all of them seems simpler, more logical and consistent with the key piste:type=* that is described in the Piste Maps Proposal. --Shernott 15:41, 22 September 2010 (BST)

More Concrete Priorities?

I've been following how they make ski tracks near here, and it seems that some are clearly made on the second day after heavy snowfall, ie., every time (and I expect the key loops in the middle of forests to be made on the first day but not accessable for me to survey that often). To me it seems that the current proposal only offers assign non-sense numbers to real world priorities. What I'd like to see is more concrete priorities such as every_day, day1(after snowfall), day2, etc. Or some explicit mapping between the real world and the non-sense numbers.

I'd expect the order to be rather constant too as the track creating machine seems to do them pretty much in the same order here (though I expect some changes near the ends of the season).

Ski Area boundary

In North America, all ski resorts have a clearly defined ski area boundary which defines areas which shouldn't be passed into. I suggest piste:boundary=yes for marking this. Seems like an important map feature. --Shernott 15:41, 22 September 2010 (BST)

I have been using landuse:winter_sports as an area along with name, address, phone number, website, wikipedia, etc to define a ski resort and its boundary. --DFyson (talk) 03:49, 14 February 2016 (UTC)

Difficulty is not Color

How about adding a small intro in the difficulty section to say something like:

'piste:difficulty' is not dedicated to render the piste in a particular color. Color code for pistes, as they appear on skimaps, can be handled by a relation route=piste that contains all the ways of the tour and a colour=*.

--yvecai 23:15 02 January 2011


  • Added rental, maybe we have to discuss about it - even don't know whether its planned to rednder those things at Piste Map

I am sorry if I have done a mistake, I am not so common to creating new tags --Mailerdaemon 22:19, 28 January 2012 (UTC)


I suggest that we move this page from to

I received users email at opensnowmap that doesn't dare to use the tags because it is still in the proposed_features ?!. I found no strong opposition on the tagging@ mailing list, except for => landuse=winter_sports can be orthogonal to other landuse (ie. in summer). that can be put in its own proposal linking to other way to map ski resort, and why not other area=yes issues.

Any change or addition to this well-established scheme could then be discussed on its own page.

Any objection ?--Yvecai (talk) 17:36, 26 February 2014 (UTC)

Done! Links should be changed, and I suppose there should be made individual pages for the different keys and such. Also, this isn't done by the book, but the book doesn't quite make sense, so better fix things now, if still imperfect. --Guttorm Flatabø (talk) 13:40, 4 March 2014 (UTC)

classic+skating vs. classic;skating

Why this wiki pages prefers '+' as separator, while the default seperator for multiple values in one key in osm is ';'? This seems to me like a mapping for the renderer hack. I can't find a discussion about this. --Klumbumbus (talk) 16:43, 21 May 2015 (UTC)

Any sensible renderer will take both values, and I still don't know any separating semicolons. Consider that the same machine grooms the two tracks together and then the + also make sense. Matter of point of view grooming vs user that is not worth mentioning :) --Yvecai (talk) 18:45, 21 May 2015 (UTC)

I notice that the Potlach 2 map editor only recognises the semicolon as a separator of multiple tag values - and so warns that those multiple tags might not be properly interpreted. This to me is confirmation that the historical separator has been the semicolon, and this seems to supported by all documentation and examples that I have ever seen. Except for "classic+skating" - which I actually saw first, so causing me to mistakenly believed for quite some time that the documentation was wrong, rather than this grooming value... --Neil Dewhurst, Lyon France (talk) 21:26, 21 May 2015 (UTC)

So we should just change the wiki and declare 'classic+skating' as deprecated? --Klumbumbus (talk) 13:48, 22 May 2015 (UTC)
I changed it. --Klumbumbus (talk) 16:07, 30 May 2015 (UTC)
I don't think it really matters if the wiki shows a preference for a '+' or a ';' probably you're wasting your time here. Anyway, with your last edit, the wiki is contradictory with the usage, see taginfo. --Yvecai (talk) 13:04, 14 June 2015 (UTC)
I changed it back to classic+skating. This is in line with current usage.

Proposal: piste:snowmaking=yes

--CanmoreTrailMapper (talk) 20:20, 31 May 2016 (UTC)

I would like to propose piste:snowmaking=yes for use on ski pistes with permanent snowmaking infrastructure. This could be snowguns, etc. or even just the gas and air pipes that allow for regular snowmaking on that piste. This would apply to both downhill and nordic ski areas. Is this the right place to suggest this or should it be proposed elsewhere? --CanmoreTrailMapper (talk) 20:20, 31 May 2016 (UTC)

Not sure it's that useful, since we already have Tag:man_made=snow_cannon that can be spotted from aerial imagery quite well. Feel free to use it if you want and see if it get any traction.--Yvecai (talk) 13:08, 1 June 2016 (UTC)

This is metadata for the piste itself, as not all snow cannons are in a fixed position. A lot of ski areas have fixed infrastructure (air and water pipes) in place on certain runs allowing early/late season usage. The runs without this are natural snow only. This will be useful for rendering piste-maps in a similar way to the piste:lit tag. For example, pistes with snow-making could be rendered with a snowflake after the name. Indeed it is this way on many printed piste maps. At downhill centres it gives a better ideas of snow coverage. At nordic centres it can make a huge difference in trail selection and wax for man-made v natural.--CanmoreTrailMapper (talk) 14:23, 1 June 2016 (UTC)

Area/way distinction for pistes

Unlike roads, which are generally uniform in width, pistes often vary greatly in width and can indeed be quite wide, so sometimes mapping them as ways seems inappropriate. What would the general opinion be on having a dual tagging system like they do for streets at Proposed_features/Street_area? Doing this would allow us to map the actual area used by the pistes and retain the more typical way-represented pistes for backwards-compatibility. --Jackdpage (talk) 17:21, 5 June 2016 (UTC)