Extreme runs not associated with resorts

[samjbobb]

@russellporter Thanks again for this awesome project. I've been working on a data issue and wanted to get your feedback on the approach to solving it.

For many US resorts there are runs that openskidata-processor does not associate with a resort when they should be (see screenshots below) .

These runs all have the following tags:

name = Some Name
piste:difficulty = expert
piste:type = downhill

This happens because these runs are missing a piste:grooming tag and the patrolled tag.

Because the runs are missing the piste:grooming tag, openskidata-processor sets the RunGrooming to backcountry based on difficulty, here: https://github.com/russellporter/openskidata-processor/blob/307df259d5cef2bb738f96a0bbaea96f3dbe32eb/src/transforms/RunFormatter.ts#L162C1-L169

The run is then not associated with a resort because of these lines: https://github.com/russellporter/openskidata-processor/blob/307df259d5cef2bb738f96a0bbaea96f3dbe32eb/src/clustering/ArangoGraphLoader.ts#L124-L129

I think in this case openskidata-processor is interpreting the data correctly according to the OSM Wiki, but the results are poor because the existing data is incomplete / doesn't follow the guidelines.

The relevant wiki entry is: https://wiki.openstreetmap.org/wiki/Key:piste:grooming#piste:grooming=backcountry

piste:grooming=backcountry
Un-groomed descent, can also be used for an alternate off-piste skitour descent see piste:type=skitour.

The term 'backcountry' can be misleading, here it just means 'un-groomed', nothing more. For these runs, it is important to specify patrolled=yes or operator='Resort name' if the piste is part of the official pistes of a resort or patrolled.

So these un-groomed runs that are patrolled as part of the resort should have the tags piste:groomed=backcountry and patrolled=yes.

I've fixed this in a couple of resorts by adding the patrolled=yes tag to all patrolled runs in the resort. Example: https://www.openstreetmap.org/changeset/138593201#map=14/39.4772/-106.1625&layers=C

Instead of trying to fix all runs in OSM, should the rules in this repo that associate runs with resorts be less conservative?

Example problems:

[samjbobb]

Maybe it's necessary to ask:

How often are there un-patrolled runs within the polygon of a resort?

If it's very infrequent, maybe it's safe to assume that runs within a resort polygon are patrolled.

(I vaguely remember that there's a resort polygon at some point in the code, but I can't find it right now. Might be wrong about that.)

[russellporter]

Thanks for the comprehensive write up.

The current logic leans towards safety, in Europe it's quite common to have un-patrolled runs adjacent to a ski area. Unfortunately as you noted tagging often doesn't follow the specification, but I think showing it this way encourages people to improve the tagging at least.

If it's very infrequent, maybe it's safe to assume that runs within a resort polygon are patrolled.

I agree, if a run is fully in the polygon we can assume it's part of a ski area, unless patrolled = no.