Re: [Tagging] Antwort: Re: Aerialway stations

[yvecai]

On 14.08.20 10:00, dktue wrote:


So why oppose to the suggested tagging of 
station=lower_station/mid_station/upper_station? What harm would this 
cause?


There is concerns expressed by the tag value lower/upper that imply the 
elevation difference, do you want to tag this difference or someting 
else? In other word, can you draft here the definition for those values ?


Yves



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

Re: [Tagging] Antwort: Re: Aerialway stations

[yvecai]

On 14.08.20 10:40, dktue wrote:

I would define it as:

lower_station: station that has the lowest elevation (exact elevation 
is not necessary to know, it's obvious)

upper_station: station that has the highest elevation
mid_station: any other station
I want to add: At least in Germany, Switzerland and Austria there are 
well-established german words which you often find in the name of the 
stations themselves:


* "Talstation" ("valley station")
* "Bergstation" ("mountain station"), sometimes also "Gipfelstation" 
("summit station")

* "Mittelstation" ("mid station")

There should be a machine-readeably tagging to get this information 
that is so often encoded in the name. That's why I'm suggesting this 
tagging.



Then why not valley / mid / mountain as values ? If the mountain station 
is lower than the mid- one, there is no discussion.


But also, my feeling is that it's more defined by the destination of the 
stop rather than a property of the aerialway node in question: you 
expect maybe a restaurant in the 'mountain station', more rarely in the 
'valley station', you also expect to put your skis on or start riding 
your bike in the former, etc ...


There is more to a 'mountina station' than being up/down.

Yves



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

Re: [Tagging] Antwort: Re: Aerialway stations

[yvecai]

I would propose, if you want to use altitude as a definition:

   bottom: the end station with the lower altitude
   up: the end station with the higher altitude
   mid: any station, not being a base or a head station, irrespective
   of the altitude

Or, alternatively one that does not compete with the ele tag and carry a 
destination meaning (my preference):


   base: the 'valley' station, usually with the lower altitude
   head: the 'mountain' or 'top' station, usually with the higher altitude
   mid: any station, not being a base or a head station.

aewrialway:station has my preference

Yves

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

[Tagging] Feature Proposal - RFC - Ski jumping

[yvecai]

Hi,

I just figured out somebody removed piste:type=ski_jump on the 
Pyeongchang facilities because the tag is 'still a proposed feature'. 
Strange thing, but then here I am again in the proposal process.


https://wiki.openstreetmap.org/wiki/Proposed_features/Ski_Jumping

I reopen the RFC informally opened on a previous thread in 2014: 
https://lists.openstreetmap.org/pipermail/tagging/2014-January/016284.html, 
with a goal to ask for a vote in the following weeks.


The proposal offer to map the ways or area dedicated to skiers along the 
piste:type scheme. Physical features of the facilities are also 
described, so that we can safely apply the widely used (586 ! keep in 
mind the number of this type of facilities over the world) 
sport=ski_jumping to an existing feature.


All specialized tags (piste:type=ski_jump, piste:type=ski_jump_landing, 
man_made=ski_jump and sport=ski_jumping) are already in use.


On a personal opinion, I have found this scheme easy to map, and easy to 
render at Opensnowmap.


Yves


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

[Tagging] Ski resort (once again)

[yvecai]

The problem is the following: in this link, the nordic pistes belong to 
several interconnected 'resorts' or 'domains':


http://www.pistes-nordiques.org/?zoom=13&lat=46.80895&lon=6.43328&layers=&e=false&m=raster

There is the pistes of 'L'Auberson', 'Les Fourgs', 'La Seigne' and 'Jougne'.

I think a relation where we could find those names would be great. To 
tag each way and relation with a 'resort' tag why not, but error-prone.
I agree this is a just 'collection' of stuff, but these 'resorts' 
doesn't necessarily obey to administrative boundaries or geographical 
features.


So what about a relation:
type=site
site=piste
piste:type=nordic
name='La Seigne'
role=entrance could be helpful to know where to park.

What do you think ?

Yves

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

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)

[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

[Tagging] Feature Proposal - RFC - relation site=piste

[yvecai]

Finally I took site=piste for consistency with pistemaps and route=piste 
proposal.


http://wiki.openstreetmap.org/wiki/Relations/Proposed/Tag:site%3Dpiste

Yves

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

Re: [Tagging] Feature Proposal - RFC - landuse=pasture

[yvecai]

To refine mowing & grazing, it would be better to separate the two.
Whatever tagging form it take, something like mow=yes/no , graze=yes/no

Yves

On 07/03/2013 07:24 PM, Volker Paul wrote:

Sorry, forgot to add the discussion link.

I made this proposal because
currently, the tag landuse=meadow is for grassland used for mowing or 
grazing.

I often find that a meadow is really for grazing, i.e. a pasture,
but I could not provide this information with the currently official 
tags.

Should landuse=pasture be introduced for this?

Here is the link to the proposal page:
http://wiki.openstreetmap.org/wiki/Proposed_features/pasture

Please discuss on
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/pasture

Regards,

Segatus


___
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] preproposal : internet webcam

[yvecai]

On 11/30/2013 06:40 PM, Egil Hjelmeland wrote:


So my revised suggestion to tag a webcam public on internet is

man_made=surveillance
surveillance= indoor|outdoor|public *
surveillance:type=camera *
surveillance:zone=weather|traffic|scenic *

contact:webcam=

name=*
operator=*
description=*
camera:direction= compass degrees *
camera:angle = horizontal angle of view  *

* means optional


This sound completely crazy to me.
Why not:
 man_made:surveillance:url:contact=http://... ; 
image_only_it's_a_camera_please_do_not_phone_the_device


A newbie looking for a way to map a webcam will just not map it.

A scheme with camera=webcam/surveillance/... url=* should be sufficient, 
like Nounours proposed.


Having a new proposal with a camera=... key is a big task, but 
"man_made=surveillance" seems insanely pompous to me.


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

Re: [Tagging] preproposal : internet webcam

[yvecai]

On 12/01/2013 03:18 PM, Egil Hjelmeland wrote:
I am not at all interested in spending months of my life arguing about 
an elaborate schemes for cameras. I will just Get It Done.

I can't blame you for that :)


I think the key here is to use contact:webcam= . That alone is 
enough to get make an overlay map of webcams. And it makes sense to 
reuse much of man_made=surveillance tags for more detailed annotations.
Yes, you have a single tag is sufficient to map a webcam. I don't like 
it, but it's simple !


Cheers
Yves

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

[Tagging] Winter sports share the same way

[yvecai]

Scott, I relay your question to the tagging mailing-list: As I am a 
mapper and a renderer, I may not be partial :)


I was face recently with a piste shared by alpine skiers and sleds and I 
choose the easy way: I just tagged the way for skiers.

This is not satisfactory, I know.

With relations, one can make one relation by activity, however it won't 
be appropriate to tag piste:difficulty for nordic.


Yves
 Original Message 

I really like your OSM renderer for ski areas.  I'm using it to map out some 
backcountry skiing
areas in Southwest British Columbia, particularly near Whistler BC.  I have 
some questions,
and some suggestions for improvements:
 
1. In my area it is very common for backcountry trails to be used for both backcountry skiing

and snowshowing.  Can a way (or relationship) be tagged for both snowshoeing 
and ski touring?
If so, how?  I was thinking that I would use 
piste:type=hiking;piste:grooming=backcountry for
snowshoe only, piste:type=nordic;piste_grooming=backcountry for ski only and 
piste\:type=skitour
for trails that permit both.  Or should I just tag the piste for the primary 
use and then add ski=yes
or snowshoe=yes?

 -Scott



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

Re: [Tagging] Winter sports share the same way

[yvecai]

On 01/09/2014 07:27 PM, Tod Fitch wrote:


I could go for relations which would solve the multiple use and multiple 
difficulty issues.

Unless you map difficulties like it should: by section, or in OSM, by ways.

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

Re: [Tagging] Winter sports share the same way

[yvecai]

Bryce,
There is already a documented scheme for snowshoeing:
piste:type=hike + piste:grooming=backcountry (250 use)
With piste:type=hike + piste:grooming=classic being for 'winter hiking' 
(111 use).


Yves

On 01/13/2014 08:02 PM, Bryce Nesbitt wrote:
On Thu, Jan 9, 2014 at 10:27 AM, Tod Fitch > wrote:


In the areas I cross country ski at in the California mountains
many trails are used by both nordic skiers and snowshoers. Since I
am ski centric I've tended to tag them as piste:type=nordic. Could
one simply tag them as piste:type=nordic;snowshoe? A bit ugly and
the difficulty is an issue as the skill level required for
snowshoeing a trail can be quite different from skiing it.


This is a case where one type of use degrades the other.

'nordic;snowshoe' says both uses are allowed.  But a nordic skier may 
in fact seek out that more rare breed 'nordic; showshow-prohibited', 
just as an equestrian may seek out fire roads on which mountain bikes 
are prohibited.  Who wants to glide ski in someone else's snowshoe tracks?




Thus, I think that marking a snow trail by intended use may be the 
wrong approach.


  * It's a marked route where the markings are visible about the snow
line (e.g. on trees or poles).  Map that characteristic.  This is
the key physicall mappable quality of a snow trail.
  * It may have access restrictions (e.g. no snowmobiles).  Map that.
  * It may have a certain width or slope.  Map that.

But listing all the types of devices that may be used on the snow, or 
rating the difficulty?
That seems too fragile and too prone to interpretation and change over 
time.  Are sleds allowed?

Snow bikes?  The yet-to-be-invented rolling insulated snow bubble?

Map what's there -- the snow route markings -- and perhaps let the use 
conventions be documented elsewhere.


Note that many snow routes follow a summer route or road exactly.  But 
on occasion the snow markings deviate, perhaps taking a shortcut, or 
smoothing out a slope, compared to the summer route.  Both cases 
should be considered.



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


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

Re: [Tagging] aerialway=drag_lift

[yvecai]

Thing is, you can expect the average mapper to map an 
aerialway=drag_lift, but you can't expect every average mapper to 
distinguish between xyz-bar, platter, rope tow by reading the wiki 
toroughly.
Drag_lift is the default and general tag for lazy mappers for lifts 
where the user is dragged.


See it like a note=fixme if you want.

Yves

On 01/22/2014 09:14 PM, Janko Mihelic' wrote:

and a rope_tow is a kind of drag_lift and j-bar is a kind of drag_lift.

drag_lift + aerialway:occupancy=2 can be a t-bar, but it can also be 
some other type of drag_lift which may exist somewhere and we don't 
know about it.


Janko


2014/1/22 Martin Koppenhoefer >



2014/1/22 remont...@free.fr 
mailto:remont...@free.fr>>

And if drag_lift != platter != tbar,




no, the oppposite:
a platter is a kind of drag_lift and a t-bar is also a kind of
drag lift.

cheers,
Martin

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




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


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

Re: [Tagging] Ski_jump_take_off

[yvecai]

According to taginfo:

97sportski_jump_take_off
21historicski_jump_take_off
19nameOlympic Cross-Country / Ski Jump Loop
18piste:typeski_jump
7buildingski_jump
6sportski_jump
6sportski_jump_landing

97 sport=ski_jump_take_off, given the number off such facilities in the 
world can be considered as a massive use of the tag. Should we really 
change the key even if leisure, man_made or piste:type would seems more 
appropriate ?


This could advocate for moving the page 
"http://wiki.openstreetmap.org/wiki/Proposed_features/Ski_Jumping"; to a 
normal page, de-facto accepted, isn't it ?

Yves

On 01/22/2014 02:31 AM, Martin Koppenhoefer wrote:



Am 21/gen/2014 um 19:04 schrieb "remont...@free.fr" :

I like sport=ski_jump_take_off. Do you think it is a good idea?


it is not IMHO, consider putting it into the leisure key, sport is used for 
types of sport (attribute) rather than physical objects

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




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

Re: [Tagging] Ski_jump_take_off

[yvecai]

I've checked the 8 piste:type=ski_jump mapped and a part one that is 
obscured by cloud, the others are what they are: the piste on the on the 
ski jump facility (I even forgot I mapped some myself from Bing). I was 
afraid this tag would be already used by freestyle jumps.


So I propose:

* piste:type=ski_jump

   for the actual ski_jump_take_off way (this is why the piste:type tag
   is here, and keep it simple, no take_off, no in_run)

* man_made=ski_jump

   for the facility

* piste:type=ski_jump_landing

   possibly with area=yes , this would allow an orthogonal leisure= to
   be mapped for summer.

What do you think ?

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

[Tagging] Pistemap proposal

[yvecai]

Is there any objection to move this page out of the Proposed features?
http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps

This is widely used, and the page is stable for long now. From time to 
time some opensnowmap.org users feels like they shouldn't use it because 
of its 'proposal' look on the wiki.
Also, maybe a few changes could be proposed, but it would be easier to 
first settle this wiki page in the 'accepted' ones.


If there is no objection, and someone knows how to do, please do.
Yves

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

Re: [Tagging] Pistemap proposal

[yvecai]

Janko, I think you understood: I posted here because the proposal is 
widely used, and pretty stable for a long time.  It hasn't undergone any 
voting process whatsoever, but here it is (in km):


{
"downhill": 24105,
"nordic": 29593,
"aerialway": 16051,
"skitour": 1171,
"sled": 931 ,
"snowshoeing": 356,
"date": "2014-02-25T03:01:02Z"
}

Settling this as a wiki page instead of a proposal is just recognising 
this mapping effort. 931 km of sled pistes, mind you !


The page is huge, and there is maybe some change to be made about a few 
points. Also, other proposals or tags can be found from the winter 
sports wiki page.

Discussion can then undergo to change a few tags if needed.

Yves

On 02/25/2014 10:27 PM, Janko Mihelic' wrote:

I have a few objections about that proposal:

landuse=winter_sports
I don't like this way of confining a ski resort. First, 
landuse=winter_sports here is used to tag a ski resort. That can't be 
right, because a restaurant can be a part of a ski resort, and it 
isn't used for winter sports. Second, the areas are going to be 
arbitrary because ski resorts don't have explicit borders as far as I 
know.


aerialway=mixed_lift
This value is a bit vague. How are you going to tag 
aerialway:occupancy of both types of lifts? What if there is a mixed 
lift with chairs that have 4 seats and chairs that have 2 seats? I 
have a feeling only relations can tag this right, but maybe there is a 
better solution.


Other than those, the proposal looks ok to me.

Janko



2014-02-25 20:58 GMT+01:00 yvecai <mailto:yve...@gmail.com>>:


Is there any objection to move this page out of the Proposed features?
http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps

This is widely used, and the page is stable for long now. From
time to time some opensnowmap.org <http://opensnowmap.org> users
feels like they shouldn't use it because of its 'proposal' look on
the wiki.
Also, maybe a few changes could be proposed, but it would be
easier to first settle this wiki page in the 'accepted' ones.

If there is no objection, and someone knows how to do, please do.
Yves

___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging




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


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

Re: [Tagging] Pistemap proposal

[yvecai]

I suggested on the pistemap discussion page to move the page to
http://wiki.openstreetmap.org/wiki/Piste_Maps
Along with creating a proposal on its own for 'landuse=winter_sports'

About this, piste:boundary= is discussed on the discussion page. There 
is also a proposal for site=piste relation, allowing for creating a 
fuzzy area as wanted. Skiing area and ski resort proposal could also be 
discussed.

Let's make it another subject.

Yves


On 02/25/2014 11:59 PM, Andreas Labres wrote:

On 25.02.14 22:27, Janko Mihelić wrote:

landuse=winter_sports
I don't like this way of confining a ski resort.

Agreed. This probably is an area where grass is growing. Maybe it is used as a
meadow in summer, maybe this is covered with straw, maybe it is used to produce
hay. This could only be tagged additionally: "this is grass here" plus "it is
used for winter sports in winter, if there's snow there". But the latter seems
not even necessary to me, as there of course should be some kind of "piste" way
on this area that would indicate that this (part of the) area is used as a piste
(so it's winter sports).

/al

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



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

Re: [Tagging] Ski_jump_take_off

[yvecai]

All talk and no action :)
Remontees, do you want to make a nice proposal page ?

Yves

On 01/23/2014 10:51 PM, Tod Fitch wrote:

On Jan 23, 2014, at 12:35 PM, yvecai wrote:

I've checked the 8 piste:type=ski_jump mapped and a part one that is 
obscured by cloud, the others are what they are: the piste on the on 
the ski jump facility (I even forgot I mapped some myself from Bing). 
I was afraid this tag would be already used by freestyle jumps.


So I propose:

* piste:type=ski_jump

for the actual ski_jump_take_off way (this is why the piste:type
tag is here, and keep it simple, no take_off, no in_run)

* man_made=ski_jump

for the facility

* piste:type=ski_jump_landing

possibly with area=yes , this would allow an orthogonal leisure=
to be mapped for summer.

What do you think ?

Yves


+1 Sounds good to me and seems to fit the current piste:*=* usage.

Tod


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


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

[Tagging] Feature Proposal - RFC - Route=piste

[yvecai]

This proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Tag:route%3Dpiste
... is a bit behind route=ski in taginfo.

The goal is to extend route relations to other winter sports along with 
a piste:type=whatever tag.
While route=ski is straightforward, this extension is good for 
snowshoeing, for instance, and make sense with the pistemap tags.


There is no particular goal to re-tag route=ski relations, but just to 
remove the 'proposal' state of this tag used on 1207 relations so far.


Yves

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

[Tagging] RFC : sport=ski_jumping

[yvecai]

Following this discussion: 
https://lists.openstreetmap.org/pipermail/tagging/2014-January/016284.html


Please find: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Ski_Jumping


Yves

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

[Tagging] Feature Proposal - Voting - Route=piste

[yvecai]

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:route%3Dpiste 
is open for voting.


Yves

On 03/19/2014 10:40 PM, yvecai wrote:

This proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Tag:route%3Dpiste
... is a bit behind route=ski in taginfo.

The goal is to extend route relations to other winter sports along 
with a piste:type=whatever tag.
While route=ski is straightforward, this extension is good for 
snowshoeing, for instance, and make sense with the pistemap tags.


There is no particular goal to re-tag route=ski relations, but just to 
remove the 'proposal' state of this tag used on 1207 relations so far.


Yves



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

[Tagging] Feature Proposal - Voting - site=piste relations

[yvecai]

https://wiki.openstreetmap.org/wiki/Relations/Proposed/Tag:site%3Dpiste 
is now open for voting


Yves

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

Re: [Tagging] Feature Proposal - Voting - site=piste relations

[yvecai]

On 03/30/2014 05:03 PM, fly wrote:
Do not like piste as value, as it is easily misunderstood and you do 
include other features. Better use winter_resort or similar. fly 

Hi Fly,
I can  follow you on this, but personally I choose piste for the 
following reasons:


   1) semanticaly in line with the so-called 'Pistemaps' namespace
   'piste:*='  and also with 'route=piste' routes.
   At least within OSM we have something consistent, and somebody
   willing to map winter sports will end up knowing what 'piste' means
   for us.
   2) ski/skiing is a bad choice, as resorts extends beyond ski
   practice only
   3) wintersports / winter_resort ... do it take a '-' , a '_' or
   nothing? wintersport or with an -s?

I don't know if it's common practise, but feel free to copy-paste the 
proposal with another value, and add a link in both for cross-voting. 
Someone emailed me with 'site=winter_sports'.


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

Re: [Tagging] access=designated - what do we think it means?

[yvecai]

Yes, you're right. I did use this, maybe one or two mistakes, only  :)

On 04/11/2014 06:40 PM, Nelson A. de Oliveira wrote:

On Fri, Apr 11, 2014 at 1:35 PM, Yves  wrote:

I always assumed it was for street where traffic is allowed for residents or
delivery, but not for traffic passing through.

This one is "destination" and not "designated" :-)

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




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

Re: [Tagging] Feature Proposal - Voting - site=piste relations

[yvecai]

More opinions appreciated on this:
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Tag:site%3Dpiste
Yves

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

Re: [Tagging] Feature Proposal - Voting - site=piste relations

[yvecai]

Extended voting period for two weeks.
Maybe people still want to express their opinion here, though I have to 
admit the vast majority of mappers is not concerned: 7 votes is not that 
bad.


Yves

On 04/12/2014 09:57 AM, yvecai wrote:

More opinions appreciated on this:
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Tag:site%3Dpiste
Yves



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

Re: [Tagging] Subsequent wikipedia links

[yvecai]

On 01.07.2014 18:08, Tobias Knerr wrote:

OSM is open for all new tags. Once we admit wikidata references, what
would prevent someone to add the MusicBrainz or freebase.com reference
directly in OSM ? Why should we accept one and not the others. Where
is the breaking point ?

Technically, we entered the slippery slope when we included wikipedia
links. But consider this: If you don't want tons of links to other
databases, then you should be happy about Wikidata. After all, they are
managing a collection of links to these databases already, so we don't
have to do it again. It could be the one external reference to rule them
all.



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

Re: [Tagging] Subsequent wikipedia links

[yvecai]

On 01.07.2014 18:08, Tobias Knerr wrote:

OSM is open for all new tags. Once we admit wikidata references, what
would prevent someone to add the MusicBrainz or freebase.com reference
directly in OSM ? Why should we accept one and not the others. Where
is the breaking point ?

Technically, we entered the slippery slope when we included wikipedia
links. But consider this: If you don't want tons of links to other
databases, then you should be happy about Wikidata. After all, they are
managing a collection of links to these databases already, so we don't
have to do it again. It could be the one external reference to rule them
all.
I would find more logical to make links between databases with queries 
rather by adding external references in one or the other. The later 
looks like the poor man job (oversimplifying, I don't want to put down 
the great job done at Wikidata).
I have the feeling that wikidata references add visibilty to OSM data, 
but no content. On the contrary, for an OverpassAPI query to succeed, 
you need good OSM data.


Yves

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

Re: [Tagging] Subsequent wikipedia links

[yvecai]

On 01.07.2014 21:04, Eugene Alvin Villar wrote:


I disagree. If the goal is to make separate databases function as one 
big normalized database[1] such that there is no overlap in data, then 
these inter-database references are, in fact, necessary.
I must admit, when I read 'big normalized database', I don't exactly 
read 'rich', or 'lifely', and I loose interest in this particular goal.


Yves

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

Re: [Tagging] Subsequent wikipedia links

[yvecai]

On 01.07.2014 21:56, Andreas Goss wrote:

Am 7/1/14 20:48 , schrieb yvecai:

but no content


Maybe not directly to OSM, but definitely to the maps you can make out 
of it.


http://osm.lyrk.de/wappen/

I think this is a much better solution than upldating all those image 
links in OSM. And if you want to have them in OpenStreetMap you could 
write a bot that puts them there.


This map could also be done with a third project linking OSM and 
Wikidata by automatically linking both datasets instead of manual tag 
entry of technical references.
Call Overpass for OSM data (admin boundaries), then search wikimedia 
commons for flags with the corresponding name.


I don't say it's already existing nor easy to do, but that would be a 
nice project.

Yves

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

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

[yvecai]

Calculating relief features from a DEM is doable. Naming them is not.


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

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

[yvecai]

This proposal is not a bad idea: refining an existing tag can't do no harm.

However, if rendering is an interesting topic, wiki is full of rendering 
examples and advices that aren't followed anywhere. Let the renderer 
render and the cartographer style the map, and trust them to understand 
tags of interest to them.


Yves

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

Re: [Tagging] Proposal: Rename wiki status "Approved" to "Published"

[yvecai]

On 05.04.2015 19:01, Dan S wrote:
It's such a chuffing tiny innocent suggestion, and it's thoroughly 
bikeshedded into the ground!
As always,  voices againt may sounds louder, howeverI have the feeling 
that changing 'approved' to 'recommended' or 'published' is doable.

Yves

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

Re: [Tagging] named spots in settlements (toponyms)

[yvecai]

It's unfortunate the wiki definition of place=neighbourhood defintion 
allows 'fluid borders' and 'well-defined legal and administrative 
borders' at the same time.


Having a tag for informally named places would be a good idea, if the 
*informal* nature survives the wiki definition subsequent edits.
Place=locality covers this for the countryside, so I guess this 
tagshould be populated places-only.


Yves

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

[Tagging] Route=* for ways ?

[yvecai]

I have a concern with this page:

https://wiki.openstreetmap.org/wiki/Tag:route%3Dpiste

Somebody found it useful to document the usage of the route=piste tag on 
ways, That looks strange to me, and rather contradict the usage.


The original page before june 2017 was concerning relations type=route, 
route=piste.


The edit looks quite formal, though, so did I miss something about the 
usage of the 'route' tag or am I free to correct ?


Yves



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

Re: [Tagging] Map Feature Samples

[yvecai]

It's not exactly what you are looking for, but I'm working on a script 
to render mapkeys (legend) images from a stylesheet. It creates a 
database with node/way/area associated with the tags found in the 
spreadsheet, then renders it with nik2img.

http://dev-yves.dyndns.org/dev/legend2osm_09-06-2010.tar.gz
Some pre-rendered pics can be found in the archive.

Actually, I could probably modify it to take your spreadsheet as input 
instead of a stylesheet.

Yves

On 29. 09. 10 19:14, Sean Horgan wrote:

Hi Sam,

Do you have a link to the google spreadsheet?  Do you plan to make it 
viewable to public (as in a webpage)?  What about editor privileges?


Sean

On Wed, Sep 29, 2010 at 08:25, Sam Vekemans 
mailto:acrosscanadatra...@gmail.com>> 
wrote:


Hi,

On Wed, Sep 29, 2010 at 7:35 AM, Dave F. mailto:dave...@madasafish.com>> wrote:
>  On 29/09/2010 06:15, Sam Vekemans wrote:
>>
>> Hi all,
>> I'm creating a list of all of the existing map features, and
looking
>> for a nice example (node/way/area/relation) of every feature.
>>
> Hi Sam
>
> To check, are you planning to replace the images in map
features, even the
> ones that are already there?

Nope,
The images are fine.

I'm looking at sample for each feature with a link
ie.
This is an example of

amenity=parking
http://www.openstreetmap.org/browse/way/68394042

amenity=pub
http://www.openstreetmap.org/browse/node/823183114

...
So a complete list of every map feature with an example of each would
be helpful :)

It would be great to have a sample link on every wiki page, so then
users can easily see how it's mapped.

The map Features chart is great, im just making it into an open access
GoogleDocs chart form, with more details.

Cheers,
Sam

>
> Cheers
> Dave F.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> http://lists.openstreetmap.org/listinfo/tagging
>

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



___
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] New tag?

[yvecai]

Yes, exactly. It's the same thing. Anyway, the minicab_office is a UK
definition. Nobody will understand that here.
Well, if it is exactly the same thing, maybe it is good to find a common 
tag. Minicab would not be understood outside UK, neither 'remis' outside 
South America.

What about amenity=taxi, booking=yes or private_hire=yes.

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

Re: [Tagging] bridge=aqueduct mapped as polygon riverbank?

[yvecai]

Besides riverbanks are tagged as "waterway=riverbanks" which will lead 
to problems when one day routing on waterways will be possible. 
Therefore I and others have switched to mapping rivers as water with 
"natural=water" and not use riverbanks anymore.


Wyo
In any case, for routing it is better to keep a way waterway=canal in 
the middle, no?

Yves

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

Re: [Tagging] Feature Proposal - RFC - sluice_gate

[yvecai]

On 03. 01. 11 11:37, John Smith wrote:

On 3 January 2011 20:04, Ulf Lamping  wrote:

What's the difference to waterway=weir?

A lot of weirs I've seen don't have any kind of gates, they just
semi-dam a river to provide a water supply for nearby towns, the water
freely flows over the top of the weir.


My use for weir would be a small dam with water flowing on top.
Maybe sluice_gate would be a small dam with water flowing under?

Size does not matter: 
http://www.farmingpictures.net/wp-content/plugins/WPRobot3/images/d5c3b_3498687571_9ca83598fd.jpg


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

Re: [Tagging] Feature Proposal - RFC - sluice_gate

[yvecai]

Let's take it on the opposite, we have devices to control water, sort of 
'dams'.

* Water can go above, under, trough, or between gates
* Can be fixed, moving, removable
* Can be nodes, ways, or polygons

I'm no expert in english, but somebody here could end up with a set of 
english word that would fit?


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

Re: [Tagging] Mountain passes

[yvecai]

On 14. 02. 11 21:08, Ulf Lamping wrote:

Am 14.02.2011 14:22, schrieb M∡rtin Koppenhoefer:

2011/2/14 Steve Bennett:

On Mon, Feb 14, 2011 at 11:32 AM, Ulf Lamping
  wrote:
That was the start of the discussion in 2007, but was changed due 
to the

changes (around the same time) of highway=tunnel / highway=bridge to
tunnel=yes / bridge=yes - so using the same logic for passes seemed 
like a

good idea then ...


Ah, yes, good point. Although it's slightly complicated by a pass
theoretically being a point rather than a stretch of road. And that
presumably makes it hard to render - you'd need to work out which way
the point is oriented.



IMHO you don't. Simply render "Simplonpass, 2005 m" at the given point
in a pleasant font. Done.


Rendering a single point and a label is often found on topological maps.

For street maps, you'll usually have a "bridge like" symbol which 
needs an orientation of the corresponding way to be drawn properly (as 
Osmarender is already doing).



Obviously, it would be "much better than nothing" if mapnik at least 
would just render a point with a label ... :-)


Actually, Mapnik would render a 'pointSymbolizer', how would it look 
like? Just a label could be enough.


Yves

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

Re: [Tagging] landuse:illegal and illegal:yes/no

[yvecai]

On 08. 03. 11 12:00, grin wrote:

Hello,

Your valuable input is welcome and would be much appreciated.

http://wiki.openstreetmap.org/wiki/Proposed_features/illegal

Thanks,
[[user:grin]]

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

Hmm, I can imagine edit wars by lawyers ...
Otherwise illegal=yes/no sounds OK, but landuse I'm not sure. 
landuse=landfill + illegal=yes would be sufficient, I guess.


Yves

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

Re: [Tagging] Transportation center that serves both buses and trains?

[yvecai]

On 24. 04. 11 21:32, Paul Johnson wrote:

On 04/21/2011 08:15 PM, Nathan Edgars II wrote:

Using both railway=station and amenity=bus_station gives two labels in
Mapnik. I reported this as a bug but apparently it's not fixable:
http://trac.openstreetmap.org/ticket/3478 What should be done?
There is certainly a way to find a rule in the Mapnik sytlesheet to sort 
this 'issue', but is there an issue here? The name is rendered as a bus 
station AND as a rail station. That's an interesting information, no?


Yves

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

Re: [Tagging] Transportation center that serves both buses and trains?

[yvecai]

On 24. 04. 11 23:24, Richard Welty wrote:

On 4/24/11 5:11 PM, yvecai wrote:

On 24. 04. 11 21:32, Paul Johnson wrote:

On 04/21/2011 08:15 PM, Nathan Edgars II wrote:

Using both railway=station and amenity=bus_station gives two labels in
Mapnik. I reported this as a bug but apparently it's not fixable:
http://trac.openstreetmap.org/ticket/3478 What should be done?
There is certainly a way to find a rule in the Mapnik sytlesheet to 
sort this 'issue', but is there an issue here? The name is rendered 
as a bus station AND as a rail station. That's an interesting 
information, no?
wontfix/"Can't see a way to filter to say if double-tagged only label 
once"

is what was indicated when Nathan's ticket was closed. not exactly the
same thing.
Please note that I am not related to the team maintaining the slippymap 
stylesheet. Also, this post should go to dev or mapnik-user list.


In the actual stylesheet, If an element is tagged as 
amenity=bus_station, its name is rendered light blue[1], and if an 
element is tagged railway=station, its name is rendered 'railway' blue[2].
These are two separate rules that apply successively on the same element 
(on distinct layers), hence the two labels.

To avoid that, the stylesheet rules should be changed to something like:
1. if an element is tagged as amenity=bus_station AND NOT 
railway=station, its name is rendered light blue,
2. if an element is tagged as railway=station AND NOT 
amenity=bus_station, its name is rendered 'railway' blue,

and a new rule:
3. if an element is tagged as railway=station AND amenity=bus_station, 
its name is rendered 'choose your nuance here' blue.


I understand the 'won't fix' fairly well, because this would be a lot of 
rules to add in the stylesheet to cope with all possible double-tagging 
(and triple, quadruple, ...), not only for buses and train. Hard to find 
a general way to deal with that, and to take the decision which tag 
takes the precedence.


Where the actual stylesheet is well done, is that the railway station 
label is displaced 10 pixels upward, and the bus station label 9 pixels 
downward, so we can see both and know that there is both a bus and a 
railway station there.
It seems that mapnik does not allow such displacements for icons 
(pointsymbolizer) though. However, the bus_station icon is specified 
with allow_overlap="false" [3], I'm not sure what it would look likes 
without.


Yves

[1]http://trac.openstreetmap.org/export/25892/applications/rendering/mapnik/osm.xml, 
line 924

[2]http://trac.openstreetmap.org/browser/applications/rendering/mapnik/inc/layer-amenity-stations.xml.inc
[3]http://trac.openstreetmap.org/browser/applications/rendering/mapnik/inc/layer-amenity-points.xml.inc

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

Re: [Tagging] towers, why limit communication towers to 2way and broadcasting?

[yvecai]

Why not putting the limit around 1 THz ?
http://xkcd.com/273/
Yves

On 03. 11. 11 14:46, John Sturdy wrote:

On Thu, Nov 3, 2011 at 1:35 PM, Martin Koppenhoefer
  wrote:

or maybe even better:
"Communication towers are intended to hold equipment for broadcast,
two-way communications or reception; such as radio, television,
cellphones, two-way radio and optical communication."

At first I thought of this as a joke, but then realized perhaps we
should include it for real: does optical communication include
traditional fire/smoke beacons and semaphore towers?

__John

___
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] Tag desired for "maintenance"

[yvecai]

I am a little bit out of scope, but to me it would make sense to add 
this kind of information in an external database.

What is the point of having this kind of information in OSM  ?

I think this is how projects like http://www.fixmystreet.com are doing.

Yves

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

Re: [Tagging] Tag desired for "maintenance"

[yvecai]

On 15. 11. 11 21:09, Bryce Nesbitt wrote:

On 11/15/2011 09:17 AM, yvecai wrote:
I am a little bit out of scope, but to me it would make sense to add 
this kind of information in an external database.

What is the point of having this kind of information in OSM  ?


Is the difference between a broken toilet and a working toilet worth 
reflecting in OSM?

What if you had a mobile client to toggle the status?
A broken toilet is supposed to be fixed, and we can hope that it is 
fixed fast, so this tag would be highly volatile if useful.
I think it will be more useful in a local db maintained by local people 
and used from local services aware of what is to be fixed around.
Except if there is a world plumber squad parsing 40MBdiffs a day from a 
remote bunker somewhere, ready to jump in a plane to avoid us the 
disagreements underlied in the present example :)

Just my opinion, though.
Yves

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

[Tagging] Value separator

[yvecai]

Hi,

What is the best way to 'separate' values?
I think about piste:grooming='classic;skating' or 'classic+skating'.

Actually, this can be argued that this is a particular grooming type of 
crosscountry ski pistes, not a simple addition of a 'classic' and 
'skating' grooming.


So, is there any reason to prefer a semicolon or a plus?

Yves

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

Re: [Tagging] Feature Proposal - RFC - Require proposal announcements to be made on the new forum instead of the mailing list

[yvecai via Tagging]

From your settings, you can suscribe to notiifcations about a 
particular tag, here this would be 'tagging'.
A 'Tagging' category (that you can also suscribe too) could  be 
requested to the admins.


Yves

On 24.09.22 20:04, Mateusz Konieczny via Tagging wrote:

My question was about getting notifications of new topics -
to avoid missing RFC/vote.

Right now it is working for me and I am unwilling to lose it.


Sep 24, 2022, 19:48 by y...@mailbox.org:

There is a 'follow' drop down at the end of a topic.
Yves

Le 24 septembre 2022 19:19:17 GMT+02:00, Mateusz Konieczny via
Tagging  a écrit :

How can I do "There you can select to get emails"?

Is it about
"Email me when I am quoted, replied to, my @username is mentioned,
or when there is new activity in my watched categories, tags
or topics"
option in account settings?

Because that seems more spammy than tagging mailing list.

What worse, I cannot assign a separate email account from
email assigned to my OSM account
(I have a separate account just for mailing lists due to volume)

I see there "Email can be updated from authentication provider."
without option to set a different one for Discourse notifications.

Sep 24, 2022, 14:32 by tagging@openstreetmap.org:

Yes, if you click on a tag, you see all topics with that
tag. On the top right, you see a bell icon. There you can
select to get emails.

That is why I proposed to use the tag "wiki-proposal" on
all proposals (RFC) and votes.

Additionally, you can get an RSS feed. Click on a tag and
add .rss to the website URL like:
https://community.openstreetmap.org/tag/tagging.rss

Greetings,
Vincent



24 sep. 2022 10:51 van
tagging_at_openstreetmap_org_seblajk...@simplelogin.co:

(1)
Is there a way to subscribe somehow to get
notifications via email, without getting
notified about for example postings in talk-de subforum?

"Using simple rss or email notifications, people can
subscribe to new proposals
on the community." is mentioned but it is not clear
how it can be done

Sep 24, 2022, 09:34 by tagging@openstreetmap.org:

Require proposal announcements to be made on the
new forum instead of the mailing list


https://wiki.openstreetmap.org/wiki/Proposed_features/Require_proposal_announcements_to_be_made_on_the_new_forum_instead_of_the_mailing_list

Please discuss this proposal on its Wiki Talk page.

Greetings,

Vincent






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


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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[yvecai via Tagging]

Vincent,
I do appreciate your effort with this new proposal.
Are you aware that this week a new category "Tagging general discussion 
" has been 
created on https://community.openstreetmap.org ?
It's probably better to follow this category than suscribing to tags 
(to-date) wiki, wiki-proposal, rfc, vote, proposal, ...

Regards,
Yves


On 29.10.22 09:34, Cartographer10 via Tagging wrote:

Hello everybody,

Based on the feedback, I updated the proposal to start using the new 
forum for proposal announcements.


Please discuss this proposal on its Wiki Talk page.

https://wiki.openstreetmap.org/wiki/Proposed_features/Start_moving_proposal_announcements_to_the_new_forum 



Kind regards,
Vincent

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


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

[Tagging] [RFC] Deprecate piste:type=yes (winter sports)

[yvecai via Tagging]

There is about ~1600 object tagged piste:type=yes in the database.

This value is undocumented, and it's hard to give it a meaning ('yes' is 
not a 'type').
I've created a [Maproulette 
challenge](https://maproulette.org/challenge/48875) to browse through 
these elements and guess the original meaning of the mapper.

What I have seen so far:
* **Error due to editor auto-completion from taginfo**
In that case, it's pretty straightforward to replace it with one of 
these 
[values](https://wiki.openstreetmap.org/wiki/Key%3Apiste%3Atype#Values) 
with a bit of research or directly by infering the type from connection 
with neighbouring ways.

* **Small connection between pistes, or between a piste and a lift**
Here 
[piste:type=connection](https://wiki.openstreetmap.org/wiki/Tag:piste:type%3Dconnection) 
can be used, or just prolonging the existing pistes.

* **Small areas around baby-lifts**
What about piste:type=downhill or piste:type=downhill;sled and 
piste:difficulty=novice, area=yes ?

* **Landuse paving**
If really one is into landuse paving, 
[landuse=winter_sports](https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dwinter_sports) 
is as good a tag as any.


Does anyone objects me creating a page at 
https://wiki.openstreetmap.org/wiki/Tag:piste:type%3Dyes documenting the 
above with status deprecated ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging