Ski pistes: areas in route=piste relation

According to the wiki, a route relation with the subtype route=piste may contain points, ways, and areas [1].

I understand the rationale for this approach. A ski piste may consist of e.g. a narrow initial section (way), a wide central section (area), and a final narrow section (way). A relation would combine all three sections into a single entity.

However, I feel that allowing area elements in a route relation is deeply flawed. Firstly, there was a similar issue for rivers. Initially, area elements (with role=riverbank) were allowed in waterway relations. After some debate, though, this approach has been deprecated, and now the wiki discourages the use of riverbank areas in waterway relations [2]. I believe that the same principle should be adopted for pistes as well.

Secondly, at least for pistes with piste:type=downhill (i.e. alpine skiing), dowhill direction is important. For ways, downhill direction is simply the way direction. For areas, though, this is not clear at all. I did read everything on [3] and other places, but didn’t find a clear indication on how dowhill direction should be implied when considering areas.

To address this issue, some people use both an area and a way, similar to what is done with rivers [4]. I believe this is the right approach–in fact it is the only possible approach. It is also useful for routing applications. It seems completely unreasonable to add both the way element and the area element in the piste relation, though.

To sum up, in my view piste relations should never include area elements. They should consist only of way and point elements. If you agree with this idea, I would change the wiki [1] accordingly. I would also clarify in [3] the use of areas, following the approach defined for rivers.

Please give me some feedback.



Ok, I feel a bit sorry, this start on Github, I sent you to help@ and somebody else sent you here :expressionless:

I think that despite your thorough search, you miss this bit of information:
What you refer to is not a route=piste relation, but a type=route relation, on which areas does not makes a lot of sense.
Routes relation are described in general here:
I think that the areas as members as the route relation in was a mistake, I just allowed myself to correct it.

To come back to your general issue, here is what happens in the database, and how I see things (me myself, but I’m just one data user):
**1) Contributors usually starts to map ski pistes with ways. **
That renders easily, and can easily be used for routing. Good.

**2) More thorough contributors map ski pistes as areas to record the real extent of the pistes. **
It’s just a closed way with area=yes. Opensnowmap renders nicely the piste extent, and route trough the edges of the pistes because my router (pyroute) doesn’t handle routing trough areas. Maybe I’m lazy, maybe nobody jumped in to provide Opensnowmap with a better routing tool, but it’s Opensnowmap problem, nothing wrong with the data model.

3) Some use both, a way AND an area.
Opensnowmap renders nicely the piste extent and a fine way in the middle, and route trough the central way or edges of the piste area. Also here, I don’t see anything wrong with the data. Just a ‘normal’ mapping with a way, and a micro-mapping with details up to the single pine tree. It’s tricky to render both way+ areas nicely, but a nice challenge. Routing is better.

4) Some use routes relations
If a way is shared by several pistes, that’s a good method so that the way shares the two names. Otherwise, there is absolutely no need to complicates editing and maintaining the data with relations.
Unless there’s a bug in Opensnowmap, this should be handle exactly the same way as 1).

5) Some use relations of type=multipolygon
I saw this I don’t remember where, but pistes were drawn as areas with holes made of trees in the middle. Why not? I see no problem with the data here.

Now, I think that you are looking for an area with a direction, and this does not exists (yet) for ski pistes.

You can propose another type of relation for this, like the proposal for steps
Or, the data consumer can use a good routing algorithm coupled with an elevation model to route to the right direction through areas. No need no relation.
Or, you can map as 2) (way + area). Then, the way being contained with an area of same piste:type AND same piste:difficulty AND same piste:name, the data consumer knows they’re the same and deduce a direction for the area. Postgis is really good, you have plenty of options if you take the time. No need no relation.

Also, please note that if there is a set of ways connected to each other with the same piste:type AND same piste:difficulty AND same piste:name, the data consumer knows they’re the same. Postgis is really good, you have plenty of options if you take the time. No need no relation.


No problem, but rather I should have referenced those discussions–I forgot!

Yes, piste relations are type=route relations with subtype route=piste. As I wrote, an area in a relation like this doesn’t make much sense to me either. Still, I find a reference to areas also in the wiki page for relation:route, specifically when the platform role for public transport routes is described. This is confusing.

OK, thanks, much better now! I also removed the word area from the table header.

Regarding the downhill direction…

How does pyroute infer the downhill direction? Does it employ an elevation model like you describe in the following?

After examining several examples, I believe this is the best approach:

Thank you for pointing out that also the piste:name=* tag is important, although I noticed that unfortunately many mappers omit it on the area. Normally I would use name=* rather than piste:name=*, though.


Could you briefly summarize why you consider waterways and pistes shall have the same restrictions? For me, they appear so much different.

According to taginfo, there are some 5600 usages of piste+area. So there seem to be good reasons to invest the additional mapping effort of an area compared to a simple way.

I agree for that fact. But for other piste types like cross country skiing, hike or sleighs no incline is requried and sometimes not even desired - think of e.g. a dog slight for tourists: Downhill, the sleigh *easily *becomes faster than the dogs and can injure or even kill the dogs - it’s hard physical work to avoid it (it made me sweat at around -15°C in a thin longsleeve), you need sufficient physical strength & weigth, and you do need to know how to properly handle a sleigh and the different breake systems for different snow/ice conditions.

Why shall we *forbid *area for *all *piste types? I.e. also those not needing incline.

And what do you suggest as tagging for an area that is designated for XC skiing (skating technique) and part of a longer piste relation? Using many single, short way segments with different width tags to “simulate” a polygon seems quite cumbersome to map.

Instead of forbidding areas, I would welcome a note on the wiki page telling for which piste types an area as member is discouraged for which reason (in a nutshell, incline needed for downhill, sled etc but inclinre not existing in an area) **and showing up a preferred solution **(map way and area, add either only the way or both way+area to the relation).


As stated above, I do not see good reasons to forbid areas as relation members. Areas are explicitly allowed e.g. in DE wiki page, so we now have an inconsitency. Why do you think areas are a mistake?

Best regards, Georg

@schoschi, I thought it was a mistake because route relation inclusion of areas is for platform only.
Do you have an example of areas in a type=route, route=piste relation ?

Yes, by randomly browsing I have found and was finally successful in creating an according query for

//find all ways with tagging area=yes, store in variable areaWays
way["area"="yes"] ->.areaWays;  
//find the relations that have any of the areaWays as members, and filter to those relations with tagging route=piste 
rel["route"="piste"](bw.areaWays) ->.pisteRelationsWithAreas;  
//TODO: How to show only the routes, not the ways (they include many false positives)?
);   out body; >;  out skel qt;

But IMHO more relevant than the fact that single instances exist, I would like to discuss whether such tagging makes sense. I can well imagine a piste area=yes to be part of a ski tour, e.g. could be a beginner’s piste:type=skitour from the peak in one corner to the other peak in the other corner. Without the possibility to use this area as member of a relation of route=piste, we would need to create a second way that’s identical except it’s just a line instead realistic shaped. What would be the benefit of that dublication compared to allowing area=yes as relation members?

Best regards,

Actually, I do not like areas in route relations. I know them from bicycle and hiking routes and in my eyes the two concepts of strings represents and areas should not be mixed. I would always use an area in addition to a linear way. If you allow areas you also need to allow MP relations and then we have nested relations.

If the outline should be included in the route=piste relation, I’d prefer an own role for these members.

That is a problem of general pages. Yes, PT allows areas but only with special role and not as routing element.

+1, yes, two objects one a linear and one an area, like we do it with highways and waterways.

piste:name=* is needed in cases where the name is already used for e.g. the highway=track below the cross-country piste and both one object.

Nice, one, untouched since eight years and note that the area has role=variant and the linear way underneath is mapped as the main route in the relation.

Not allowing areas would stay in sync with other route relations. We use the duplication already for highways, though, I am a fan of area:highway and would prefer area:piste for the areas. Still for piste relations role outline could be defined to add the outline to the relation.

Another Overpass query:

out geom;

The role=variant seems to be used here and there (, and seems a good idea. If I wonder if a relation is really needed, this gives the possibility to do so for mappers with a tendency to ‘over gardening’.
I’ve also seen some role=outer (?) and also some genuine mapping error.

Do not forget to look for MPs, even without area=yes.
A specific role is, in my eyes, the solution but, please, not with variant. We need a role for areas and allow MPs so outer does not fit either but outline fits perfectly, as it is used in building, bridge and tunnel relations.

I have no use case when mapping myself, Yet as a data user at, I like to understand unsuspected way people are mapping.
Here is what I found with the above query:

The following seems genuine examples to way + outline of the piste in a type=route, route=piste relation: (The complete resort here is mapped this way)
They seem extremely rare.

(way(r:"outer");>;);out geom;

Returns lot of multi-polygons, notably in Scandinavia.

(way(r:"outer");>;);out geom;

Return no results where I looked so far.

@skyper, you mention building, bridge and tunnel relations, but they are not ‘type’=‘route’ relations.
Per its definition, a ‘type’=‘route’ doesn’t allow areas, except public transport platform, so I don’t think it’s a good idea to add another exception here.

  • You can perfectly have a type=route, route=piste relation composed of a continuous set of ways at the middle of the piste.
  • In addition the outline can be mapped separately as area (area=yes or multi-polygons relations).
    As long as they have the same name and tags, and share the same geographical space, it is really not necessary to collect everything under a relation.

If really someone feel the need to, then we should avoid ‘type’=‘route’ or ‘type’=‘multipolygon’.
But a ‘type’=‘piste’ relation that collects everything related to a single piste may be met by a few frowns …

Nice examples. They show again that people like to add areas and that is OK, in my eyes, as long as we describe, it properly.

I rather see type=route as a loosely collection/group and the definition starts with route=* and additional tags. The wiki is a mess regarding documentation of roles, I have to admit.
We already have exceptions and individual roles for certain routes like PT or road. Last year, new roles were approved (Recreational route relation roles) for some type=route and another example is guideposte, so, I do not really see a point here, for not introducing it. That is how OSM works. The major point is finding a proper role which is not used with a different meaning. That is why I am against variant which should be replaced by alternative on the wiki, by the way.

I do not like it if there are multiple objects for one object in reality especially when overlapping like the line vs area problem. That is why I would prefer to have an own tag for the area not using the broken “highway” + area=yes concept, but it might be already too late.

We already have site and I am by far a fan of collection. Additionally, I doubt that one additional relation is the solution or makes it less complicated.

In the end, we need a nice concept to group as much interest as possible for a useful data system and simply excluding all areas might not be accepted by some people. So I am looking for possible compromises.

You may have noticed that only ways or type=route relations can be members of a recreational route, no areas nor nodes.

The example I found above are extremely rare. To have more complete figures, I had a look to opensnowmap’s database.
Number of members of route=piste/ski + type=route/superroute: 85298 (7760 relations)
Number of polygons members of route=piste/ski + type=route/superroute : 137 (19 relations)

That’s 0.16% of members, 0.24% of relations. After 15+ years, I’m not really sure we absolutely need this :roll_eyes:

But anyway they do exists. Your idea here would be to welcome areas in a type=route, route=piste relation, with roles ‘outline’ (and subsequently also ‘inner’) on the way members. The issue I see here would be breaking things (existing routers or renderers).

  • We expect that a type=route relation contains linear features, that can be stitched together to (hopefully) build a continuous multi-linestring.
  • In a relation type=multipolygon, we expect to find proper geometry to build a multi-polygon.
    This legacy is important to keep things simple for data user, which in turn is desirable if we want more ski maps made out of OSM data.

If you feel the need to collect into a relation both linear and polygonal features, that’s ok, but bear in mind that those beast are very difficult to deal with.
So please, test so on a new ‘type=something’ relation so that you make sure people get what they are expecting in the data.

Something fun, we also have a route=nordic, type=broad_leaved relation :smiley:

Think you got me a bit wrong. I do not plan to map this way and I am fine with area:piste=* for the area without membership. I simply tried to show a solution if people insist to have areas within the route relation.
I only thought about areas as optional and additional to the “routing” line string represented by ways. With role outline, I would allow areas as closed ways and MPs so no “inner” is in the route relation.
Software using the data should just drop unknown roles as usual, so there should be no impact by adding areas with role outline.

Think you got me somewhat off-base. I don’t plan to plan thusly and I am fine with ‘area:piste=*’ for the space without participation. I essentially attempted to show an answer if individuals demand to include territories inside the course connection.

I just considered regions discretionary and extra to the “directing” line string addressed by ways. With job ‘layout’, I would permit territories as shut ways and MPs so no “internal” is in the course connection.

Programming utilizing the information should simply drop obscure jobs not surprisingly, so there ought to be no effect by adding zones with job ‘layout’.