<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 04.02.2013 19:00, schrieb yvecai:<br>
</div>
<blockquote cite="mid:510FF723.1010303@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Janko, to group a bunch of elements into a relation or add same a
tag to all these elements is not quite the same. A relation carry
a meaning (type), while with all these tags, It's seems to me just
a collection that you can find with a query :)<br>
(Actually, we all know that both are technically feasible, no need
to fill up the history for testing ;-).<br>
</blockquote>
I would like to disagree partly here.<br>
You're right: a relation should carry a meaning, but if all meaning
is "these piste routes belong to the resort X", then a tag
resort:name=X would carry exactly the same meaning.<br>
IMHO to make sense out of a relation here, there has to be more
meaning due to the relation, like e.g. the office of the resort (if
it's organized centrally somehow), information signs with maps of
this resort, a common website for the resort and the like.<br>
This way it's more feasible to use a relation for a ski resort.<br>
<br>
The tag resort=X only is not a good argument IMHO, as with that you
would get the very same result by querying all piste routes tagged
with resort=X by grep from a planet or using overpass.<br>
<br>
The issue that one route may belong to more than one resort is a
slightly better argument, but there was an overpass solution for
that as well in an earlier mail.<br>
<blockquote cite="mid:510FF723.1010303@gmail.com" type="cite">
Quoting the wiki page you linked:<br>
"Grouping relations really only make sense if the grouping is
neither geographical (as discussed above) nor exclusive ..."<br>
<br>
Exclusive you take care of with a semicolon, why not.<br>
<br>
For the geography, I think of this 'resorts' as a kind of
geography by itself, after all (not sure I use the term properly,
pretty sure I don't, in fact).<br>
When I go skiing to 'Le Risoux', I don't speak about the forest (<a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://fr.wikipedia.org/wiki/For%C3%AAt_du_Risoux">http://fr.wikipedia.org/wiki/For%C3%AAt_du_Risoux</a>),
nor the mountain (<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://fr.wikipedia.org/wiki/Mont_Risoux">http://fr.wikipedia.org/wiki/Mont_Risoux</a>),
but rather of a bunch of pistes, along with the 3 entry points and
their cabin where people drink tea selling you tickets, and so ...<br>
</blockquote>
but you could even describe it by "the resort Le Risoux roughly
at/around Mont Risoux" which could be translated to a nice overpass
query using a bbox around Mont Risoux (or a around statement) and
the resort='Le Risoux' as a filter.<br>
<br>
IMHO you should keep in mind what belongs to the "resort". I'm not
skiing, but I guess, there are<br>
- the pistes<br>
- the lifts to transport people uphill again<br>
- signposts with hints about routes, probably difficulties...<br>
- probably lot more.<br>
<br>
If you want to go for a relation, think about how to tie that
together, and why it's useful to put that into a relation.<br>
"Relation" is not "Collection". The verb of "relation" is "to relate
to [each other]". <br>
How does the bus stop relate to a street segment? they are related
by a bus route where the bus uses that street to serve that bus
stop.<br>
For a ski resort this might be something like:<br>
- lifts and the like have the role "transport_upwards"<br>
- pists and the like have the role "piste"<br>
- the resort as a whole might have a fee=yes if not the single
pistes have to be paid but you can pay one bill for the whole resort<br>
<br>
I'm sure there's more which could be incorporated, but find reasons
for the relation, and what value the relational concept adds to the
tagging solution alone.<br>
<br>
regards<br>
Peter<br>
</body>
</html>