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 ---
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 gro
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 : [Tagg
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 resor
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:typ
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,
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 co
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
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 abbrevia
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 s
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.
OpenSe
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
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
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 fix
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
Ch
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 b
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
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
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
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
20 matches
Mail list logo
