Timed=yes for self-timed courses in ski resorts (and beyond)

General talk Tagging general discussion
, ,
1

Hi everyone,

Across Alpine ski resorts there is an extremely common and popular feature that currently has no standardized way of being tagged: self-timed race courses. These are permanent installations where you scan your lift pass at a start gate, ski through a gated slalom or giant slalom course (or a straight speed run), and get your time displayed on a screen at the finish.

These exist in hundreds of resorts across the Alps and beyond. Kids and adults love them. Yet I couldn’t find any established tagging convention for them.

What are these called?

The naming varies wildly by country and resort:

Country Common names
Austria / Germany Rennstrecke mit Zeitmessung, SkiMovie, Speedcheck, Self Timer
France Stade de slalom, piste chronométrée, parcours chronométré
Italy / South Tyrol Speed Check, SkiMovie Line, pista cronometrata
English (international) Self Timer, timed race course, speed check

The commercial system Skiline by Alturos is installed in 350+ resorts across 14 countries and uses the product names SkiMovie (timed course with video) and Speedcheck (radar speed measurement).

Current situation in OSM

There is no piste:type value for this. The wiki page for piste:type lists 12 values (downhill, nordic, skitour, etc.) but nothing for timed race courses. I searched taginfo for self_timer, timed, slalom, skimovie, speed_check, rennstrecke, chronométré and found no established convention.

Proposal: timed=yes

I’d like to propose a simple top-level tag: timed=yes

For a self-timed ski slalom course, the tagging would be:

piste:type=downhill
piste:difficulty=*
timed=yes
name=Self Timer  (or whatever the resort calls it)

Why timed=yes and not piste:timed=yes?

Because self-timing infrastructure is not exclusive to pistes. The same concept exists on:

  • leisure=track + sport=running — athletics tracks with timing
  • leisure=track + sport=karting — go-kart tracks
  • highway=raceway — motorsport circuits
  • sport=bobsleigh / sport=luge — timed runs
  • sport=climbing — speed climbing walls with timing

It’s analogous to lit=yes — a generic property that works across many feature types. Nobody created piste:lit or highway:lit, just lit=yes everywhere. Similarly, timed=yes means: “this feature has permanent self-service timing equipment that measures your performance.”

What about speed checks (radar)?

Speed checks (where you get your speed measured via radar on a straight run, not your time through a course) are a related but different feature. They could be tagged with something like speed_check=yes or we could differentiate values: timed=time vs timed=speed. But I think keeping it simple with timed=yes for the course timing is the right first step. Speed checks could be discussed separately.

Questions for the community

  1. Does timed=yes seem reasonable as a top-level key?
  2. Is anyone already tagging these in a way I missed?
  3. Should the timed slalom course be mapped as a separate way overlapping the main piste, or as additional tags on the existing piste way?
  4. Any thoughts on how to tag the start gate and finish display as nodes?

I’d love to hear from mappers in Alpine regions who encounter these features regularly. Even if you’re not mapping pistes, the timed=yes concept could be useful for your sport/leisure features too.

Thanks!

1 Like
2

With such a variety of potential future developments in the area, I strongly feel that a =yes tag should be firmly avoided in favor of tag values that describe specific timing styles. =yes should always be reserved for “the mapper has knowledge that such a feature exists but couldn’t figure out the specifics”.

E.g. (with no personal experience or knowledge of these systems) tap-in-tap-out for the described style of the skiier holding a physical token that they touch to a device at the top and bottom of the course, versus camera for a system that compares the video of you crossing the start and finish lines.

1 Like
3

IMHO timed as a tag is much too broad for such a narrow use case. Defining this would require that any other feature in any other context that has some kind of timer would need to find another tag to describe that it is timed (like a feature that opens and closes based on a timer but not by the clock).
Like the other piste-related tags such information should be inside a namespace, e.g. some sport-related one.

Second, it doesn’t seem to make sense to add this tag to single ways - these measuring stations usually cover some distance that might be build from several ways in OSM. To be useful there needs to be a relation that groups the ways that are timed and clearly marks start and endpoint.

4

Maybe timekeeping=automatic/yes/no could narrow it down a little?

I guess this feature could be found on some (water) slides as well, or at some attractions/rides in amusement parks.

I like the idea of modeling it as relation with start/finish nodes and way(s) as members.

1 Like
5

I’m not against you guys fiddling with fancy relations, as long as mappers can just also add a simple tag to the underlying ways :wink:

2 Likes
6

There is no meaningful way to have these tags on ways - they rely on a start point, an end point and a route between them.

Imagine a timed route that consists of 3 OSM ways, because it e.g. goes over a bridge. Will this bridge be tagged with “timed=yes”? There is no infrastructure there, no installations or timekeeping machinery. If somebody uses this bridge coming from another direction there is no way to get timed. The “timed” feature only applies to the full route and not to every small piece of it, so it must be on a relation.

It’s also not possible to find out where the “timed” part starts and ends by extrapolating from any short way - if there is more than one timed track in an area they can easily form loops or meshes and nobody knows where to start and which way to take towards the end, so it must be on a relation.

2 Likes
7

The way you map is not the real world, or a particular use case.

I’m always in favor of keeping thing simple for the contributor: imagine the effort needed to make such a relation in an editor (and then the chance to make it right). If the goal is to have this information mapped at all, keep it simple.

8

What definitely can be mapped without relation is the sensor objects at the start and the finish line.

We currently have 7 objects with man_made=sensor.

Also there is sensor=* with 180 instances, but most of them are =no.

I could imagine man_made=sensor + sensor=timekeeping added at the start and finish nodes. Feel free to improve my tag suggestions.

2 Likes