Talk:Tag:site=piste

From OpenStreetMap Wiki
Jump to navigation Jump to search

Previous discussions

Happenned on tagging mailing-list

Personal rationale

I often look for crosscountry-skiing areas I don't know yet to enjoy the pleasure of mapping.

There is a lot of forums and website available when you're looking for such a place. But when it comes to actually find the entry points of a crosscountry network with a small printed ski map flyer, on snowy roads, it can take quite some time.

Don't get it? Look for 'Le Risoux'. A well-known place for cross-country skiing between France and Switzerland. Nominatim doesn't get quite the essence of this place.--Yvecai (talk) 19:55, 5 February 2013 (UTC)

Alternatives

According to the definition, only route=piste or route=ski could be members--Yvecai (talk) 19:55, 5 February 2013 (UTC)

There is not necessary a defined area around a ski site--Yvecai (talk) 19:55, 5 February 2013 (UTC)

There is not necessary a defined area around a ski site--Yvecai (talk) 19:55, 5 February 2013 (UTC)

  • Perhaps we could use relations with "type=site + site=sport + sport=skiing" ? By analogy, for other "site", that would become "type=site + site=sport + sport=*", or "type=site + site=leisure + leisure=*", or else "type=site + site=amenity + amenity=*" - as the case may be - along the same lines as pre-existing definitions for sporting/leisure/social/cultural/service map-feature... --Neil Dewhurst, Lyon France (talk) 09:32, 7 February 2013 (UTC)
Site=sport I'm not sure, after all the so called winter sports can often be considered equally as a 'leisure'. I choose site=piste to be consistent with piste:type and route=piste.Somebody suggested site=winter_sports or site=skiing by email. Skiing is too narrow, but I like winter_sports too.--Yvecai (talk) 19:49, 7 February 2013 (UTC)

Limits

Should the relation member list be explicitely limited to winter sports features only, or may it implictely allows to add cafés, restaurants, hotels, parkings, ...? This would well describe a ski 'resort' as it is common for dowhill skiing. It seems that there is a need for that: piste:amenity tag on Taginfo --Yvecai (talk) 20:03, 5 February 2013 (UTC)

URL / Website

Good proposition, I've tested it here.

But, I think that website=* is better than url=*


Disagree

Rationale: Relations are difficult to maintain. When ading a new feature, the mapper must know which existing relations to add it to, with which role, and if order of relation members matters for that particular relation. This is a source of errors – I am speaking from my own experience with bus routes I had mapped some time ago: Over time, the route members gradually erode away as ways are replaced, ways are reversed without reflecting that in the forward/backward role and other things. This is a reason why relations should be kept to the necessary minimum and avoided when there is another way to sufficiently tag things. I have often heard site relations mentioned as examples of relations that can and should be avoided.
Yvecai's use case seems to be piste stats for OpenSnowMap – certainly a great idea. However, since Yvecai mentions he created the site relation for Les Trois Vallées from the polygon around the area, I believe it would be less error-prone to do this kind of calculation on the fly rather than have mappers maintain a relation: for the stats, simply replace the expression "members of the site relation" with "all features within the polygon which have certain tags". That is a standard GIS function, available out of the box in PostGIS or spatialite, to name just two. The beauty of it is that as soon as someone adds a new lift or piste, that logic will recognize it as part of the skiing resort – no need to do anything more.
I hear a counter argument being that ski resorts may be difficult to represent as a polygon and have tried to imagine where this might be the case:
  • Concave polygons – easily solved over the shape of the polygon.
  • Multiple ski resorts, not connected by lifts and pistes between them, but part of the same ski pass area – can be solved with a multipolygon. (Which is still a relation, but with fewer members and less likely to change.)
  • Lifts that can be used without a ski pass (which is the case with some beginner lifts near the village) – for those I have used fee=no in the past and would otherwise count them as part of the ski resort.
  • Areas or parts of an area in which different ski passes are valid – complexity of this scenario is fairly unlimited and may be well beyond what can be reasonably represented in a map. Here I would suggest the network=* tag, with one entry for each ski pass that is valid there. The tag itself could go on lifts, or even on the polygon. This would be sufficient for the most common cases, i.e. the ski passes which have full and unlimited validity in the area (and leaving out such special cases as "holders of a week pass for 3 Vallées, Paradiski or Espace Killy can ski one day in each of the other two systems" or "holders of a ticket for Warth-Schröcken can get a discounted day pass for Ski Arlberg".
Conclusion: The information contained in the relation can be conveyed in less maintenance-intensive and less error-prone ways, which I would favor over the relation. --Stanton (talk) 22:20, 1 April 2014 (UTC)

Hi Stanton, allow me to put this part into the discussion page, that's a long piece of an argument :)

  • Relations are difficult to maintain, that's true. However, like everything in OSM, they can be maintained by users daring to take care of them.
  • The same collection can be composed programmatically from a bounding polygon: true enough. Opensnowmap even build site=piste polygons from relations internally :)

I don't see no use of a site=piste relation that couldn't be done from a landuse=winter_sports polygon neither, apart the role 'entrance' but that could be deducted by other tags.

The discussion is more choosing between a relation or a bounding polygon (not really, fortunately we can use both, who cares ?).

I'm a cross-country skier, and the 'resorts' I know would be enclosed by a landuse=winter_sports polygon with a *very* small fraction of a percent would be temporarily occupied by skiers a few month of the year. Nothing is left in summer, except a few forgotten signs.

I have trouble enclosing them with a few clics. For me it's the pistes that make the skiable area, not the 99% of forest in between.

Also, the landuse tag has some issue here: how its border is defined ? A fuzzy polygon can bug some people too and is a bit away from 'ground-truth mapping', don't you think? --Yvecai (talk) 19:07, 3 April 2014 (UTC)

about "forest in between" As far as I know, in France that "in-between" skiable area has a special juridication status : off pist sking "in between" is partly covered by private staff when accidents are concerned. Because of that I would have no problem considering those "in between forest" as part of the ski resort. Of course, the border will be a bit fuzzy, but I don't necessarly see it as a proble. Is piste A in ski resort B ? then enclose A in B borders. Is it not ? then make the border so that the piste is not enclosed. sletuffe (talk) 21:27, 17 April 2014 (UTC)


April 2014 vote

  • I approve this proposal I approve this proposal. --Shernott (talk) 21:10, 30 March 2014 (UTC)
  • I approve this proposal I approve this proposal. -- Gustry (talk) 13:51, 1 April 2014 (UTC)
  • I oppose this proposal I oppose this proposal.
Rationale: Relations are difficult to maintain. When ading a new feature, the mapper must know which existing relations to add it to, with which role, and if order of relation members matters for that particular relation. This is a source of errors – I am speaking from my own experience with bus routes I had mapped some time ago: Over time, the route members gradually erode away as ways are replaced, ways are reversed without reflecting that in the forward/backward role and other things. This is a reason why relations should be kept to the necessary minimum and avoided when there is another way to sufficiently tag things. I have often heard site relations mentioned as examples of relations that can and should be avoided.
Yvecai's use case seems to be piste stats for OpenSnowMap – certainly a great idea. However, since Yvecai mentions he created the site relation for Les Trois Vallées from the polygon around the area, I believe it would be less error-prone to do this kind of calculation on the fly rather than have mappers maintain a relation: for the stats, simply replace the expression "members of the site relation" with "all features within the polygon which have certain tags". That is a standard GIS function, available out of the box in PostGIS or spatialite, to name just two. The beauty of it is that as soon as someone adds a new lift or piste, that logic will recognize it as part of the skiing resort – no need to do anything more.
I hear a counter argument being that ski resorts may be difficult to represent as a polygon and have tried to imagine where this might be the case:
  • Concave polygons – easily solved over the shape of the polygon.
  • Multiple ski resorts, not connected by lifts and pistes between them, but part of the same ski pass area – can be solved with a multipolygon. (Which is still a relation, but with fewer members and less likely to change.)
  • Lifts that can be used without a ski pass (which is the case with some beginner lifts near the village) – for those I have used fee=no in the past and would otherwise count them as part of the ski resort.
  • Areas or parts of an area in which different ski passes are valid – complexity of this scenario is fairly unlimited and may be well beyond what can be reasonably represented in a map. Here I would suggest the network=* tag, with one entry for each ski pass that is valid there. The tag itself could go on lifts, or even on the polygon. This would be sufficient for the most common cases, i.e. the ski passes which have full and unlimited validity in the area (and leaving out such special cases as "holders of a week pass for 3 Vallées, Paradiski or Espace Killy can ski one day in each of the other two systems" or "holders of a ticket for Warth-Schröcken can get a discounted day pass for Ski Arlberg".
Conclusion: The information contained in the relation can be conveyed in less maintenance-intensive and less error-prone ways, which I would favor over the relation. --Stanton (talk) 22:20, 1 April 2014 (UTC)
=>> Discussion continue here
  • I approve this proposal I approve this proposal. N76 (talk) 17:49, 11 April 2014 (UTC)
  • I approve this proposal I approve this proposal. NicolasDumoulin (talk) 19:40, 11 April 2014 (UTC)
  • I ignore this proposal. The only relation I am able to use are outer/inner multipolygon. I have never been able to understand how to modify route and other relations, so I just try to stay away from them. I wait for JOSM to provide a sane edition interface. Marc Mongenet (talk) 09:26, 13 April 2014 (UTC)
  • I approve this proposal I approve this proposal. I think it's a pretty helpful proposal, since I think that a relation is easier to maintain than tags at every object, plus additional information can be added to the resort as such more easily in a central placeMax-- (talk) 09:54, 13 April 2014 (UTC)
  • I oppose this proposal I oppose this proposal. Agreeing with Stanton's comments. I think an area based solution is better. Enclosing the ski resort with landuse=winter_sport looks fine to me as a wiki recommendation. (As ever, every one is free to use what ever tag they want, but I don't think this one should enter the "accepted" category.) sletuffe (talk) 21:16, 17 April 2014 (UTC)
  • I oppose this proposal I oppose this proposal. This is an example of using relations as categories. I don't know what this proposal should be. Is it a group of entities in a ski resort? Is it a group of ski slopes with the same operator? Is it a group of ski slopes you can access with the same skipass? Whatever this is, it's wrong to group it in a relation. Relations are not meant to be used for this kinds of things. Janko (talk) 23:12, 17 April 2014 (UTC)
  • I approve this proposal I approve this proposal. --Dieterdreist (talk) 14:11, 18 April 2014 (UTC)
  • I approve this proposal I approve this proposal. Neuhausr (talk) 16:26, 18 April 2014 (UTC)
  • I oppose this proposal I oppose this proposal. I agree with Janko and Sletuffe. I want to add that this proposal is way too vague on what constitues a piste. Person A may consider the a certain area to be part of a piste, while another person doesn’t. It is not even defined if forests are considered part of a piste, for example. The “borders” of a piste are doomed to be subjective. But I think OSM should only contain the hard facts. Wuzzy (talk) 14:06, 21 April 2014 (UTC)
  • I oppose this proposal I oppose this proposal. As others have already pointed out, relations are not categories. Zimba (talk) 18:50, 30 April 2014 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:site%3Dpiste&oldid=1156042"