Proposal:Tag:site=piste
(Redirected from Relations/Proposed/Tag:site=piste)
Jump to navigation
Jump to search
| Tag:site=piste | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | Yvecai |
| Tagging: | site=piste |
| Applies to: |  Relation:site
|
| Definition: | Site dedicated to winter sports (skiing). |
| Statistics: |
|
| Draft started: | 2013-02-05 |
| RFC start: | 2013-02-05 |
| Vote start: | 2014-03-30 |
| Vote end: | 2014-04-30 |
Voting
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)
I approve this proposal. N76 (talk) 17:49, 11 April 2014 (UTC)- 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 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. 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. 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. --Dieterdreist (talk) 14:11, 18 April 2014 (UTC)
- I approve this proposal. Neuhausr (talk) 16:26, 18 April 2014 (UTC)
- 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. As others have already pointed out, relations are not categories. Zimba (talk) 18:50, 30 April 2014 (UTC)
7 approvals, 5 oppositions, 1 ignore. All in all we don't see a massive approval for this proposal.
Opponents considers that:
- a landuse=winter_sport area is easier to map
- relations as categories. I must admit I don't understand how this applies to the current proposal: a site=piste relation is a category of what ?
Approvers use it taginfo
Nevertheless, it's probably good to have the usage of such a relation documented, people being free as always to use an alternative landuse=winter_sport area.
Usage
A site relation with the subtype site=piste can be used to combine the way or route relations (for example pistes, lifts, etc.) that make a ski site or ski resort used for downhill skiing, snow-shoeing, cross country skiing and various winter sports.
Any particular way segment can be associated with zero, one or multiple relations of this type.
| A site=piste relation is not intended to map a single piste. See Piste Maps Proposal, Tag:route=piste, Tag:route=ski, or Winter sports for tagging a particular winter sport feature. |
Rationale
Members of a site=piste relation are related by the practise of skiing and/or other winter sports. Such a site doesn't necessarily have a well-defined perimeter, but is rather described by its management by a particular organization (ski resort), geographical features, or local knowledge.
The name under which the site is known describes the site as for the practise of winter sport rather than a locality.
Members
| Element | Role | Recurrence? | |
|---|---|---|---|
|
- | zero or more | piste or ski route member of the site. |
 |
- | zero or more | piste member of the site. |
|
link | zero or more | piste that link to another site. |
 |
entrance | zero or more | Entry point to the piste network or the door of the skiing area. |
Tags in Relation:route
Necessary Tags
Optional Tags
- name=* the name of the site
- url=* web link to the official page of the resort
- website=* web link to the official page of the resort (alternative)
- operator=*
See also
Examples
With a rendering example: the relation centroid is rendered with its name, icons show available activities from the relation members.
