russellporter / openskimap.org Goto Github PK

Although not an officially approved tagging scheme, site=piste is adopted at ~900 ski areas now. Although most ski areas can be easily tagged using landuse=winter_sports, the site=piste scheme has some benefits for more complex cases.

piste:grooming=backcountry runs that are part of a site=piste can be assumed to be part of the ski area and not sidecountry ski routes (currently, they are never members of a ski area, unless tagged with patrolled=yes out of an abundance of caution for safety).

Will need to take care to merge all redundant ski areas together. For example, a single ski area could have all of landuse=winter_sports, site=piste, and Skimap.org ski areas, or even multiple of each. site=piste should be used for the first pass as it's the most fine-grained.

It's probably a bit difficult to accurately determine which trains are used for skiing, but a starting point would be to add cogwheel trains (in addition to previously added funiculars).

For both cogwheel/funiculars, we could add a postprocessing step in the processor to remove them from the map if they are not associated with a ski run in the feature graph.

User feedback:

Openskimap seems to display abandoned:aerialway, but not disused:aerialway. And neither abandoned:piste nor disused:piste. Maybe you can add these?

Probably the best way to display these would be dotted, like lifts with the tag "abandoned=yes".

Especially for cross country ski trails, website links can provide useful information about how to access the trail (parking, public transport), and so on.

• Show avalanche slopes
• Show slopes by estimated difficulty

If there are multiple sources of ski run properties (way & relations) these are flattened into a single representation to allow for a simpler UX.

The current approach treats all data sources equally. For example: run difficulty is merged by taking the easiest value from the available sources.

A somewhat common case for nordic ski trails is a longer trail, tagged as a relation has piste:difficulty=easy, but one of its ways may be tagged as piste:difficulty=intermediate.

In the case currently we show the whole trail as easy. However, the ways data should be closer to the ground truth, given relations work at a higher level.

The improvement would be to treat the way data as primary, and only fall back to the current strategy if the way doesn't have a difficulty value.

Similar to how Google Maps presents information, it would be better for the visibility of selected map content to show an overlay instead of popover.

Also show nodes with man_made=snow_cannon (https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsnow_cannon)

landuse=recreation_ground + sport=skiing

For input objects that are associated with a site=piste through several layers of relations, the association is lost when the features are processed.

Example: Wendelsteinbahn

When you highlight a lift, highlight the connected runs in another colour. That would allow you to see routes from the lift much more clearly. Maybe primary, secondary and further connections.

Re-explore adding icons for different lift types.

At minimum, distinguish:

• surface lift
• chair lift
• gondola
• cable car

The existing criteria to generate a downhill ski area is just to find a "groomed" downhill ski run. This can create false positive generations as some backcountry ski runs are not tagged as ungroomed. Avoid this by also requiring a lift to be in the connected graph before generating a ski area

We can calculate the approximate aspect of each segment of a run as we have elevation data. Need to decide the best way to display this information, also a single run might have multiple aspects in varying percentages.

One option could be to bucket segments of the run into aspects N, S, E, W, NE, NW, SE, SW, and display an aspect if the % of run exceeds some threshold.

Some ideas:

• run difficulty distribution (pie chart)
• run length
• ski resort area (might be difficult to do accurately)
• number of lifts (could open list view)
• number of runs (could open list view)

They should be filtered out by the skimap.org api

Hi!

Feature request:

Would be super to see parking lots and rest stops on the map. Because often one goes by car and the car needs to be parked somewhere.

OSM data can be filtered with "access=yes" if needed.

Currently agglomerations are dropped because there isn't a good UX to visualize them on a map.

For something like this: https://www.openstreetmap.org/relation/8896547#map=10/47.3509/13.3880&layers=Y it would be nice to at least show the agglomeration on the child ski area's information with a link to the agglomeration, and also surface the agglomeration in search.

Instead of only using the name tag, we should at least additionally use the name:en tag to get the English localization. This would be pretty useful in Japan: https://openskimap.org/?obj=8f92803adb9b1d0e7fc61dcdf9a3e6a4ace13768#14.12/36.77738/137.88542/-34.8/2

This code is responsible for name extraction: https://github.com/russellporter/openskidata-processor/blob/master/src/transforms/OSMTransforms.ts

A new tagging scheme has been approved for avalanche transceiver training zone and checkpoints. I think OpenSkiMap should render this ski related object. Thanks a lot!

https://www.openstreetmap.org/way/645467069

is coded as an operating rack railway when actually it's a proposed gondola.

It should be probably filtered out, unless this is actually a valid osm lifecycle tagging scheme.

Just wanted to let you know that your mapbox token is hardcoded and committed into the repo.

The informal=yes OSM tag likely is relevant for tagging ski trails. It would be nice to check how often this combination is used and incorporate it in the rendering. Likely informal=yes could be handled similarly to piste:grooming=backcountry.

Apply same processing as for runs (combine localized name tags, with "name" first)

If the run/lift is tagged with a "ref", use that instead of the name to improve display at lower zooms.

You should really link the repo on your website. (in the about section)

Or maybe add one of the well-known "fork me on GitHub" button…

The top left and bottom right overlays are not consistent with the Mapbox GL standard overlays

When processing features, assign country and principal subdivision. Include ISO code and name.

Eventually these could be clickable to show a region overview.

Indicate run difficulty using standard symbols when zoomed in.

https://blog.mapbox.com/introducing-gl-js-v1-6-0-with-rich-text-labels-96f87830c58f

User feedback: showing the grooming thpe for winter hiking trails can be useful

piste:grooming=classic trails are maintained, and suitable for walking/hiking
piste:grooming=backcountry trails are not maintained

Currently ski routes are broken down into parts and can't be viewed as a whole. This makes it very hard to visualize longer ski routes. Ideally there should be a way to see the overview of an entire route on the map.

https://www.openstreetmap.org/relation/1819422

The website looks pretty good when embedded in other pages, but the increased page views is a concern for the Mapbox usage. We could support this use case explicitly by allowing passing a custom access token to the site. Optionally also banning iframe usage when no access token is provided.

When the user selects a ski area, highlight the area that is thought to be part of the ski area (based on pre-processed graph traversal of OpenStreetMap data).

Below zoom level 11, make the area of the ski area clickable (will open the ski area info)

User feedback. Usage is still small but growing.

Hi!

Would be nice to see which ski trails you can go with a dog. Osm taggings for those is piste:type=nordic & dog=yes. Is it possible to draw dog symbol over the ski trail line on the map? I find this easiest to read than using different line symbol.

Here is example of dog ski trail
https://openskimap.org/?obj=0b8a236c379837611d2a454af1959606efe461b0#12.48/66.51309/25.75701

For safety reasons, it would be valuable to render patrolled=no runs differently.

When a piste area is tagged as natural=wood or landuse=forest, it can be assumed to be a gladed run.

It would be very helpful if a map legend was included somewhere on the website to explain how different features are displayed. I would recommend including the legend in the hamburger button menu to the left of the Search bar. Some elements I recommend including based on what I see depicted in OpenSkiMap are:

• The Blue and Green dots for the resort (Downhill & Backcountry vs Nordic)
• Colors for Piste difficulty (Easy, Intermediate, Advanced, Expert, Freeride terrain, etc)
• Piste grooming type (if depicted differently - I've seen solid vs dashed lines)
• Lit Pistes (I noticed these have a yellow outline)
• Aerialways

I appreciate this website and use it quite a bit for researching ski locations, and I hope to see it's development continue! Thanks!

• needs to cover linear and area styling

Generating the name for https://www.openstreetmap.org/way/860260235 results in Mount Snow, Q617699. Need to limit which name tags are used.