Proposal talk:Avalanche-transceiver
redefining checkpoint tag
Not familiar with topic, but looks like a good idea.
Though note that it would also redefine https://wiki.openstreetmap.org/wiki/Key%3Acheckpoint for a broader use.
Maybe avalanche_transceiver=checkpoint or amenity=avalanche_transceiver_checkpoint or something else would be better?
Mateusz Konieczny (talk) 11:35, 17 October 2021 (UTC)
- Fully agree: a checker device is a public service; It does not urge anybody to follow a certain trail or collect check-point-visits. It has an operator, but the trail most always lacks any operator, so it does not fit the checkpoint definition at all.--Hungerburg (talk) 21:56, 18 October 2021 (UTC)
- I do agree with both of you. I'm aware that the tagging checkpoint=avalanche_transceiver needs a modification of the checkpoint OSM's definition. I proposed to tag it with the checkpoint key for two reasons : in real life, it's most of the time called an AVD checkpoint, and secondly I prefered a symmetry between the training and checkpoint tagging scheme. But I'm OK if amenity=avalanche_transceiver_checker is prefered, I'll change the proposal before the vote. Babouche Verte (talk) 08:11, 19 October 2021 (UTC)
- The symmetry indeed makes for an elegant proposal, and if it were not for redefining checkpoint, might make it indisputably nice. I chose "checker", because that is what the manufacturers call the device, that turns the place into a checkpoint; not much of a preference for each, except maybe, a group can do the check anywhere they please. Lots of beautiful stuff in nature is not symmetric :) --Hungerburg (talk) 10:08, 19 October 2021 (UTC)
- I also think the keys checkpoint & training are not the best for this. I've never heard of the word checker used in this field, but I see at BCA that's what they call the device that they sell for this purpose. I still think checkpoint is a better term for the location, checker is the device. This article (vail-pass-avalanche-beacon-checkpoints) uses the term checkpoints many times, never uses the work checker. This article also calls them checkpoints: are-you-beeping. My local ski area has a 'Beacon Training Park'. beacon-basin . My suggestion, amenity=avalanche_transceiver_training_park and amenity=avalanche_transceiver_checkpoint . I know it's a mouthful. Does it make sense to have a new key? It could be avalanche_transceiver=training_park and avalanche_transceiver=checkpoint. --Bradrh (talk) 15:39, 22 October 2021 (UTC)
- I'd be fine with amenity=avalanche_transceiver_checkpoint; All the more, if this name rings so well-known. For the training area, I still see value in chaining: such it might get further specified with some "training:*=*" namespaced keys then, if those exist, that is. --Hungerburg (talk) 22:07, 24 October 2021 (UTC)
Consider using amenity for the checkpoints
I mapped one here once https://www.openstreetmap.org/node/8487349965 - I then read a bit literature, manufacturer handouts, to get at the name used. This is for a checker - You mostly need it, when you go alone. It is a device, it has a fixed location, it is a perfect fit for amenity. --Hungerburg (talk) 22:10, 17 October 2021 (UTC) Here a list of the checkers installed last years season in my local area https://www.bergwelt-miteinander.at/winter/ski-snowboardtouren/massnahmen/lvs-checkpoints.html It is an amenity, just like a vending-machine, an atm, a bench, etc. --Hungerburg (talk) 10:26, 19 October 2021 (UTC)
If you're short of a meaningfull key, you can also build one with the piste: prefix. I have no preference myself. Yvecai (talk) 16:22, 22 October 2021 (UTC)
Changing the tagging scheme
It's clear from all your contributions that nor the checkpoint=avalanche_transceiver nor the training=avalanche_transceiver is wanted. So as mentionned above, we have (at least) two different proposed tagging scheme.
- amenity=avalanche_transceiver_checkpoint & amenity=avalanche_transceiver_training_park
- avalanche_transceiver=checkpoint & avalanche_transceiver=training_park
- avalanche_transceiver=checkpoint & avalanche_transceiver=training_park combined with amenity=avalanche_transceiver
What would be your preference ? I prefer the option n°2, as the option 1 creates a (too) long value for the key. Babouche Verte (talk) 19:11, 25 October 2021 (UTC)
- 2 or 3 that I prefer has different semantics. It's showing the variety of transceiver more, which is better than amenity=training because the location is not holding any classes there. I would make it avalanche_transceiver=training.
- In this approach, I would use man_made=avalanche_transceiver on top of 3, to show it's a piece of equipment.
- ---- Kovposch (talk) 05:53, 27 October 2021 (UTC)
- For avalanche_transceiver=training, I'm not sure it would make sense to have it combined with a man_made=avalanche_transceiver, as most of the time there isn't any artificial structures : just a panel to indicate the location of the training park. Is that awkward ? Babouche Verte (talk) 10:08, 30 October 2021 (UTC)
Training Area
I am not positive, but I believe that a in the US a practice area for use of avalanche beacons is called a “beacon park”. I see in the proposal that some French ski areas have them labeled as “DVA parc”. So in this regard the French and American English are basically the same. If so rather than slightly overload the training=* tag with a use that may not have an instructor, perhaps amenity=avalanche_transceiver_park could be used.
The above discussion on points where beacon transmitters work when exiting the groomed piste being called an amenity=amenity=avalanche_transceiver_checker then the two tags would be in the same name space and not stretch the definitions of checkpoint=* or training=* --N76 (talk) 15:16, 19 October 2021 (UTC)
- I took a glance at the description of a local such site - https://www.hall-wattens.at/de/staendiges-lvs-trainingscamp.html - In my view, the redirection amenity -> training -> avalanche_transceiver would stretch the training term not nearly as much as above expansion would the checkpoint term. But the reasoning is not wrong either. Amenity is so broad already, its hard to stretch beyond the reasonable, so little opposition is to be expected, when this gets to vote :) --Hungerburg (talk) 18:48, 19 October 2021 (UTC)
- The thing is, the amenity tagging scheme is so broad that it means more or less nothing. That's why I wanted to put in the checkpoint and in the training tagging scheme which seemed to me more accurate. But I understand your point, and I'll change to amenity at least for the AT checker, and maybe for both if you all prefer it ! Babouche Verte (talk) 21:07, 19 October 2021 (UTC)
Not just skiing/snowboarding
Resolved Automated transceiver check stations also exist in at least one place (Cooke City, Montana) for snowmachine (snowmobile) users; I assume it's not the only one, although I wouldn't be surprised if it were an outlier.
- Yes, the text should mention snowmobiling/snowmachines too. vail-pass-avalanche-beacon-checkpoints mentions a new checkpoint going up on Vail pass which is a mixed use area, both snowmobiles and backcountry skiers.--Bradrh (talk) 14:01, 22 October 2021 (UTC)
- I've added it to the proposal's text. Thanks Babouche Verte (talk) 09:17, 26 October 2021 (UTC)
Not happy with new key
The change on Oct. 30 does not make me happy, I do not get, why a new key is warranted at all, as the reality can easily be described with two new values in the amenity "namespace":
- amenity=avalanche_transceiver_checkpoint - to control a device in sending mode (always on a node),
- amenity=avalanche_transceiver_training - to study operating a device in receiving mode (on node or area). Bundling in a key mixes
two quite different things and makes validation harder too.
--Hungerburg (talk) 11:26, 30 October 2021 (UTC)
- amenity=*, among famous others, is already overcrowded with many different things. Regarding its own coverage, making a different between avalanche transceivers activities is not appropriate. We should take care of using different keys to separate different concepts for Any_tags_you_like sake. Mixing avalanche_transceiver and their mode in one single value would violate 1st normal form as well. Fanfouer (talk) 14:11, 28 November 2021 (UTC)