[Tagging] Re : Re : Re : Ski resort (once again)

[yve...@gmail.com]

Remains one question, site=piste or site=ski ?
The former is consistent with pistemap tagging, the other easiest to find in 
the wiki.
The rationale about route=piste covering also snowshoeing doesn't really apply 
here. Is there sites dedicated to this practice only ?
Yves

- Reply message -
De : "Martin Koppenhoefer" 
Pour : "Tag discussion, strategy and related tools" 
Cc : "Tag discussion, strategy and related tools" 
Objet : [Tagging] Re :  Re : Ski resort (once again)
Date : lun., févr. 4, 2013 23:25






Am 04/feb/2013 um 22:54 schrieb "yve...@gmail.com" :

> For nordic and downhill, two sites or a semicolon ? That is the question.


IMHO put the piste:type on the route relations and put those route relations 
into a site relation (or group with tags) but don't repeat the piste:type on 
the grouped object


cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Re : Ski resort (once again)

[Martin Koppenhoefer]

Am 04/feb/2013 um 22:54 schrieb "yve...@gmail.com" :

> For nordic and downhill, two sites or a semicolon ? That is the question.


IMHO put the piste:type on the route relations and put those route relations 
into a site relation (or group with tags) but don't repeat the piste:type on 
the grouped object


cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Re : Re : Ski resort (once again)

[yve...@gmail.com]

Martin : that's where the type 'site' make sense, it could either be a resort 
or a 'domaine skiable'.

For nordic and downhill, two sites or a semicolon ? That is the question.

- Reply message -
De : "Martin Koppenhoefer" 
Pour : "Tag discussion, strategy and related tools" 
Objet : [Tagging] Re : Ski resort (once again)
Date : lun., févr. 4, 2013 22:44


2013/2/4 yvecai :
> Anyway, these site=piste relation members would simply be related by ...
> ski.
> Minimal tagging would be:
>> type=site
>> site=piste
>> piste:type=nordic
>
> or
>
>> type=site
>> site=piste
>> piste:type=downhill
>
> Then, optionnally, name, operator, url.


aren't there resorts which offer both, alpine and nordic pistes?


> I came here about this idea when I was shown this:
> http://taginfo.openstreetmap.org/keys/piste%3Aamenity#values
> Maybe these cafes, shelters, ... could be members of the site relation,
> maybe not, but there is apparently a need here to link them to the nearby
> pistes.


by looking at what wikipedia writes about resorts in various languages
(en,de,fr) it seems as if the piste is more an extra for one or more
hotels, and that it might actually be the hotels which constitute the
main part of the resort. http://fr.wikipedia.org/wiki/Resort

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Martin Koppenhoefer]

2013/2/4 yvecai :
> Anyway, these site=piste relation members would simply be related by ...
> ski.
> Minimal tagging would be:
>> type=site
>> site=piste
>> piste:type=nordic
>
> or
>
>> type=site
>> site=piste
>> piste:type=downhill
>
> Then, optionnally, name, operator, url.


aren't there resorts which offer both, alpine and nordic pistes?


> I came here about this idea when I was shown this:
> http://taginfo.openstreetmap.org/keys/piste%3Aamenity#values
> Maybe these cafes, shelters, ... could be members of the site relation,
> maybe not, but there is apparently a need here to link them to the nearby
> pistes.


by looking at what wikipedia writes about resorts in various languages
(en,de,fr) it seems as if the piste is more an extra for one or more
hotels, and that it might actually be the hotels which constitute the
main part of the resort. http://fr.wikipedia.org/wiki/Resort

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[yvecai]

On 02/04/2013 08:26 PM, Peter Wendorff wrote:

...


There is always an overpass query for every need :)

Anyway, these site=piste relation members would simply be related by ... 
ski.

Minimal tagging would be:
> type=site
> site=piste
> piste:type=nordic

or

> type=site
> site=piste
> piste:type=downhill

Then, optionnally, name, operator, url.

Members would be the ways described in the pistemap tagging scheme, and 
relations route=piste or route=ski.


I'm not sure pistes ways or relation should be given the role 'piste' as 
it is implicit. Same for upward lifts :)
The only role that came to mind are the role 'entrance', 'link' (to 
another site),'perimeter' (if avail.).



I came here about this idea when I was shown this: 
http://taginfo.openstreetmap.org/keys/piste%3Aamenity#values
Maybe these cafes, shelters, ... could be members of the site relation, 
maybe not, but there is apparently a need here to link them to the 
nearby pistes.


Yves


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Peter Wendorff]

Am 04.02.2013 19:00, schrieb yvecai:
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 :)
(Actually, we all know that both are technically feasible, no need to 
fill up the history for testing ;-).

I would like to disagree partly here.
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.
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.

This way it's more feasible to use a relation for a ski resort.

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.


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.

Quoting the wiki page you linked:
"Grouping relations really only make sense if the grouping is neither 
geographical (as discussed above) nor exclusive ..."


Exclusive you take care of with a semicolon, why not.

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).
When I go skiing to 'Le Risoux', I don't speak about the forest 
(http://fr.wikipedia.org/wiki/For%C3%AAt_du_Risoux), nor the mountain 
(http://fr.wikipedia.org/wiki/Mont_Risoux), 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 ...
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.


IMHO you should keep in mind what belongs to the "resort". I'm not 
skiing, but I guess, there are

- the pistes
- the lifts to transport people uphill again
- signposts with hints about routes, probably difficulties...
- probably lot more.

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.
"Relation" is not "Collection". The verb of "relation" is "to relate to 
[each other]".
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.

For a ski resort this might be something like:
- lifts and the like have the role "transport_upwards"
- pists and the like have the role "piste"
- 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


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.


regards
Peter
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[Malcolm Herring]

On 04/02/2013 18:54, Douglas Fraser wrote:

Have design decisions been made?


Only the design outline has thus far been discussed. In summary, any 
feature tagged as a port, harbour, marina or anchorage will have the 
relevant symbol rendered on the OpenSeaMap Seamark layer. The renderer 
will communicate the co-ordinates of this symbol to a separate database 
which will overlay an invisible button over that position in the 
OpenSeaMap Harbour layer. A right-click on the symbol will then invoke a 
pop-up panel that will display the meta-data. The Harbour layer database 
will have extracted the metadata form divers public database sources, 
including the OSM tags on any feature that invoked the Seamark layer 
symbol. This metadata would include LOCODEs where available.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Ronnie Soak]

2013/2/4 Janko Mihelić 

> 2013/2/4 Ronnie Soak 
>
>>
>> Works exactly as long as no piste belongs to more than one resort. If
>> anyone does, you still need to switch to relations.
>> I don't know about nordic pistes, but there are definitely lifts for
>> alpine pistes that are used by visitors of two ski resorts.
>>
>
> There, I fixed it to work with semicolon delimited values:
>
> 
>

You may want to read this wiki page:
http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

It gives you a lot of reasons not to use semicolon delimited values. But
admittedly it doesn't give relations as an alternative.

While I also see that skiing resorts are kind of geographically and
therefore could be expressed as an area instead of a relation, I'm having
trouble with how anyone would be able to determine where to put that border.
They are, for the part I know, mostly defined by the pistes/lifts/amenities
that belong to it instead of  a border on the map. And I'm somehow not
comfortable with an area which borders are defined by a mapper at his own
discretion instead of a survey-able feature on the ground.

My favorite therefore is still a relation, but I'm cutting out of this
argument now, as skiing definitely isn't my area of expertise.

Regards,
Chaos
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[Martin Koppenhoefer]

2013/2/4 Douglas Fraser :
> as for LOCODE and locode, it is an acronym and so I tend to capitalize it.
> but if iata isn't...  There are LOCODE / locode / harbour:locode / unlocode
> tags - what are the general guidelines about cleaning up tag confetti?


general tagging guidelines say: no abbreviations, no capitalization,
underscores instead of spaces

this would mean the key should be:
"united_nations_code_for_trade_and_transport_locations"  ;-)

but this is not very handy. There are a few exceptions to the general
guidelines, e.g. "ref", and especially in the context of imports you
will usually find a lot of abbreviations (not sure how welcome they
are, this surely saves a lot of space (if uncompressed) but (human)
readability is much worse. A key like
"united_nations_code_for_trade_and_transport_locations" looks absurd
on the first glimpse but it is much easier to understand than "locode"
or "un/locode". Nonetheless personally I'd go for "un/locode" and let
people discover in the wiki what this is about.

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[Douglas Fraser]

well, I'd like to contribute but I don't want to stomp all over already done work - we have a fairly complete and 
authoritative set of LOCODEs, including the shipping carrier specific ones (shipping companies feel free to make up 
their own set of LOCODEs sometimes)

so the big question is where should I stick this locode data?  Have design 
decisions been made?


On 04/02/2013 18:48, Malcolm Herring wrote:

On 04/02/2013 18:26, Douglas Fraser wrote:

The data management issues are important, so I'm inclined to update the
wiki page to direct people to OpenSeamap as that seems like a more
logical place to keep specialized metadata like this and they'd be more
inclined to keep the data updated.


OpenSeaMap currently map the physical features of ports, but not metadata. We do have a project underway to do this, 
but it is in its infancy. So if you need this anytime soon, please don't wait for us!



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[Malcolm Herring]

On 04/02/2013 18:26, Douglas Fraser wrote:

The data management issues are important, so I'm inclined to update the
wiki page to direct people to OpenSeamap as that seems like a more
logical place to keep specialized metadata like this and they'd be more
inclined to keep the data updated.


OpenSeaMap currently map the physical features of ports, but not 
metadata. We do have a project underway to do this, but it is in its 
infancy. So if you need this anytime soon, please don't wait for us!



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[Douglas Fraser]

I was going to add some text about port terminals to the wiki page - I'll update what I can.  There is at least one 
thing that is incorrect.  The data management issues are important, so I'm inclined to update the wiki page to direct 
people to OpenSeamap as that seems like a more logical place to keep specialized metadata like this and they'd be more 
inclined to keep the data updated.  The UN list does change, so letting dead data sit around in OSM doesn't seem great.


as for LOCODE and locode, it is an acronym and so I tend to capitalize it.  but if iata isn't...  There are LOCODE / 
locode / harbour:locode / unlocode tags - what are the general guidelines about cleaning up tag confetti?



On 04/02/2013 16:42, Brad Neuhauser wrote:

Doug,

Since you're pretty knowledgable about this topic, it'd probably also be good if you could flesh out the harbor:LOCODE 
page on the wiki (http://wiki.openstreetmap.org/wiki/Key:harbour:LOCODE). It's part of this big harbour proposal: 
wiki.openstreetmap.org/wiki/Proposed_features/Harbour 


Cheers, Brad

PS--one side question: shouldn't LOCODE be locode (that is, lowercase)?  that's how iata and icao are handled for 
aerodromes...


On Sun, Feb 3, 2013 at 11:47 AM, mailto:doug.fra...@tarisoga.com>> wrote:

Followup to my post:
I am here at the London OSM Hack Weekend and spoke to someone who explained 
to me the larger issues and questions
about importing / updating metadata like LOCODEs that can't be surveyed - 
i.e. data where managing the process of
keeping it current may be troublesome.
I agree with everything he explained and so now I don't think updating the 
LOCODEs that are present, etc would be
the best idea.  Letting the existing tags die off sounds like the best idea.
But locodes are assigned to harbours and they are surveyable, can be 
verified by the public, all that sort of
thing.  So the UN list could be used to update or verify that cities have 
appropriate harbour tags associated with
them.  IIRC, Long Beach (or LA) was one test case I looked at and it didn't 
have a tag that i'd expected.
So now my idea is to check the harbour tags against the UN data (this could 
also be done for rail stations) and
then determine how much data is missing and what ought to be improved.
A related idea is that port terminals (for commercial shipping) are 
becoming prominent features (e.g. they are
getting their own locodes) and perhaps a new tag harbour:terminal (like 
harbour:pier) could be created for
handling this data.  Container terminals are physical features and won't 
arbitrarily change, so they aren't
metadata like LOCODEs.
If anyone has any feedback, I'd appreciate it.  I don't plan on doing 
anything until I fully understand the
details of all this, so I can write it all up, etc.
doug

[Imports] RFC - Adding UN LOCODE tags to OSM writes:

Hi everyone,
This is a duplicate of a email I sent to the Tagging list:
The company I work for deals with shipping ports, UN LOCODEs, and 
shipping schedules - I had hoped to use OSM
to correlate geographical type info and LOCODEs.  The problem has 
become messier than I ever thought, and
unfortunately OSM does not have much in the way of LOCODE related data.
At this point, we have a well maintained list of LOCODEs and other such 
data that I keep track with the UN
list as it is updated.  So I thought it'd be useful to put all that 
into OSM and clean up the handful of
LOCODE tags that I have seen in OSM.  This list also includes IATA data 
and some other port type info -
everything has been gleaned from public data sources like the UN, so 
I'm sure there are no license related
issues.  I'm also confident of the accuracy since I'm the one 
responsible for maintaining the data.
I will write up a feature proposal on the wiki to outline the details, 
but first I wanted to see if there were
any comments or advice people might have.  I do plan to automate the 
updates - none of this is map data per
se, but just tags, so I assume there won't be any real complications. 
So I will read all about the guidelines
around automation.
The questions I had are:
1) the UN provides geographical coordinates of these LOCODEs, typically 
the city center.  Is there any
standard that OSM adheres to regarding the location of cities?  Anyone 
have any pointers to info I should read?
2) alternative place names - the UN provides some data and we have data 
from other sources.  The data is good,
but is there any consensus on this topic about how OSM ought to operate?
3) locations/cities not in OSM at all - adding these in is a separate 
task entirely so I will leave that till
I understand OSM better.  But if someone could point me in the right 
dir

Re: [Tagging] Re : Ski resort (once again)

[yvecai]

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 :)
(Actually, we all know that both are technically feasible, no need to 
fill up the history for testing ;-).


Quoting the wiki page you linked:
"Grouping relations really only make sense if the grouping is neither 
geographical (as discussed above) nor exclusive ..."


Exclusive you take care of with a semicolon, why not.

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).
When I go skiing to 'Le Risoux', I don't speak about the forest 
(http://fr.wikipedia.org/wiki/For%C3%AAt_du_Risoux), nor the mountain 
(http://fr.wikipedia.org/wiki/Mont_Risoux), 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 ...


Now, my 'rationale' :
As I go skiing here and there for mapping, I more than often go to place 
I don't know yet. I check websites and forums about snow and skiing and 
resorts and try to find out how I go there on low-res scanned maps. It 
took me quite some icy road to find 'Le Risoux', and I first found these 
pistes by the longest road. I'd like to be able to find it more easily.


When I look for 'La Seigne' in nominatim, I found 'Locality La Seigne, 
Les Hôpitaux-Vieux, Doyenné du Haut-Doubs forestier, Doubs, Freie 
Grafschaft, France 
'. 

Although geographicality close, it's not the same as the  'Resort La 
Seigne, Les Hôpitaux-Vieux, Doyenné du Haut-Doubs forestier, Doubs, 
Freie Grafschaft, France 
' 
I'm looking for.



Also, IMHO it would be good if we could avoid this: 
http://taginfo.openstreetmap.org/search?q=piste%3Aamenity%3Dcafe


Yves
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Janko Mihelić]

2013/2/4 Ronnie Soak 

>
> Works exactly as long as no piste belongs to more than one resort. If
> anyone does, you still need to switch to relations.
> I don't know about nordic pistes, but there are definitely lifts for
> alpine pistes that are used by visitors of two ski resorts.
>

There, I fixed it to work with semicolon delimited values:

Overpass-turbo

And here is an inverted query, that only shows piste:type=nordic that are a
part of these resorts:

Overpass-turbo

Janko Mihelić
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Imports] RFC - Adding UN LOCODE tags to OSM

[Brad Neuhauser]

Doug,

Since you're pretty knowledgable about this topic, it'd probably also be
good if you could flesh out the harbor:LOCODE page on the wiki (
http://wiki.openstreetmap.org/wiki/Key:harbour:LOCODE).  It's part of this
big harbour proposal: wiki.openstreetmap.org/wiki/Proposed_features/Harbour

Cheers, Brad

PS--one side question: shouldn't LOCODE be locode (that is, lowercase)?
that's how iata and icao are handled for aerodromes...

On Sun, Feb 3, 2013 at 11:47 AM,  wrote:

> Followup to my post:
> I am here at the London OSM Hack Weekend and spoke to someone who
> explained to me the larger issues and questions about importing / updating
> metadata like LOCODEs that can't be surveyed - i.e. data where managing the
> process of keeping it current may be troublesome.
> I agree with everything he explained and so now I don't think updating the
> LOCODEs that are present, etc would be the best idea.  Letting the existing
> tags die off sounds like the best idea.
> But locodes are assigned to harbours and they are surveyable, can be
> verified by the public, all that sort of thing.  So the UN list could be
> used to update or verify that cities have appropriate harbour tags
> associated with them.  IIRC, Long Beach (or LA) was one test case I looked
> at and it didn't have a tag that i'd expected.
> So now my idea is to check the harbour tags against the UN data (this
> could also be done for rail stations) and then determine how much data is
> missing and what ought to be improved.
> A related idea is that port terminals (for commercial shipping) are
> becoming prominent features (e.g. they are getting their own locodes) and
> perhaps a new tag harbour:terminal (like harbour:pier) could be created for
> handling this data.  Container terminals are physical features and won't
> arbitrarily change, so they aren't metadata like LOCODEs.
> If anyone has any feedback, I'd appreciate it.  I don't plan on doing
> anything until I fully understand the details of all this, so I can write
> it all up, etc.
> doug
>
> [Imports] RFC - Adding UN LOCODE tags to OSM writes:
>
>> Hi everyone,
>> This is a duplicate of a email I sent to the Tagging list:
>> The company I work for deals with shipping ports, UN LOCODEs, and
>> shipping schedules - I had hoped to use OSM to correlate geographical type
>> info and LOCODEs.  The problem has become messier than I ever thought, and
>> unfortunately OSM does not have much in the way of LOCODE related data.
>> At this point, we have a well maintained list of LOCODEs and other such
>> data that I keep track with the UN list as it is updated.  So I thought
>> it'd be useful to put all that into OSM and clean up the handful of LOCODE
>> tags that I have seen in OSM.  This list also includes IATA data and some
>> other port type info - everything has been gleaned from public data sources
>> like the UN, so I'm sure there are no license related issues.  I'm also
>> confident of the accuracy since I'm the one responsible for maintaining the
>> data.
>> I will write up a feature proposal on the wiki to outline the details,
>> but first I wanted to see if there were any comments or advice people might
>> have.  I do plan to automate the updates - none of this is map data per se,
>> but just tags, so I assume there won't be any real complications. So I will
>> read all about the guidelines around automation.
>> The questions I had are:
>> 1) the UN provides geographical coordinates of these LOCODEs, typically
>> the city center.  Is there any standard that OSM adheres to regarding the
>> location of cities?  Anyone have any pointers to info I should read?
>> 2) alternative place names - the UN provides some data and we have data
>> from other sources.  The data is good, but is there any consensus on this
>> topic about how OSM ought to operate?
>> 3) locations/cities not in OSM at all - adding these in is a separate
>> task entirely so I will leave that till I understand OSM better.  But if
>> someone could point me in the right direction, that'd be great.
>> Thanks
>> doug
>> __**_
>> Imports mailing list
>> impo...@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/imports
>>
>
> __**_
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Ronnie Soak]

2013/2/4 Janko Mihelić 

> 2013/2/4 Martin Koppenhoefer 
>
>>
>> if they don't have a common operator and the resort doesn't have a
>> "border" (i.e. it isn't an area but a mixture of areas and routes) you
>> cannot map them? Btw.: the OP is asking for nordic pistes, so there
>> won't necessarily be any lifts.
>>
>
> Why not "resort=L'Auberson" on all nordic pistes? Yvecai says it's error
> prone, but so are names and operators of banks and atm machines. If you
> want to find errors, use tools like http://overpass-turbo.eu. I have made
> a small script to find all nordic pistes without the tag resort=L'Auberson
> or Les Fourgs or La Seigne or Jougne:
> 
>
> Works exactly as long as no piste belongs to more than one resort. If
anyone does, you still need to switch to relations.
I don't know about nordic pistes, but there are definitely lifts for alpine
pistes that are used by visitors of two ski resorts.

Regards,
Chaos
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Janko Mihelić]

2013/2/4 Martin Koppenhoefer 

>
> if they don't have a common operator and the resort doesn't have a
> "border" (i.e. it isn't an area but a mixture of areas and routes) you
> cannot map them? Btw.: the OP is asking for nordic pistes, so there
> won't necessarily be any lifts.
>

Why not "resort=L'Auberson" on all nordic pistes? Yvecai says it's error
prone, but so are names and operators of banks and atm machines. If you
want to find errors, use tools like http://overpass-turbo.eu. I have made a
small script to find all nordic pistes without the tag resort=L'Auberson or
Les Fourgs or La Seigne or Jougne:

Link to 
overpass-turbo.

And I put a few resort=L'Auberson tags just to check the script.

Janko Mihelić
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Martin Koppenhoefer]

2013/2/4 Janko Mihelić :
> I think relations are not applicable for this case. To me it seems as if you
> want to put everything from inside a village in one relation, because they
> are all in that village. That's just not how OSM works. Either that resort
> has borders, and you draw them, or the ski lifts and piste have the same
> operator and you put operator=* on everything that is operated by them.


if they don't have a common operator and the resort doesn't have a
"border" (i.e. it isn't an area but a mixture of areas and routes) you
cannot map them? Btw.: the OP is asking for nordic pistes, so there
won't necessarily be any lifts.

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Janko Mihelić]

I think relations are not applicable for this case. To me it seems as if
you want to put everything from inside a village in one relation, because
they are all in that village. That's just not how OSM works. Either that
resort has borders, and you draw them, or the ski lifts and piste have the
same operator and you put operator=* on everything that is operated by
them.

Again, relations are not
categories.

Janko Mihelić
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Re : Ski resort (once again)

[Martin Koppenhoefer]

2013/2/4 yve...@gmail.com :
> There is already route=piste relations (the colors on the link provided).
> This is something else.


what kind of objects do you propose would be grouped in these site
relations, just the nordic piste or also connected services, hotels,
etc.? I guess you want to group linear features (piste) with areas and
points (hotels, parkings, restaurants,...)? In case the answer to the
latter question is yes a site relation might indeed be appropriate.
Alternatively you could suggest a new tag for "belonging to resort
foo", or maybe even reuse an established key (e.g. "network").

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging