Extreme negative elevation values in some run coordinates

[dhimmel]

The following downhill runs have coordinates with extreme negative elevations (100 meters below sea level or more) in data downloaded on 2024-10-13.

run_id	run_name	min_elevation	max_elevation
"7beec7a36a8b105bdb7fa238f839a5ed1c2a133c"	"Aguila Mora"	-8465.8	943.77
"884dca6c4e1865e840375175b92464cc7c299d21"	null	-8132.58	725.59
"59fbc3dde2cbbfb29bdf796f84a3308fe20e2aa2"	null	-8465.8	493.79
"a7d307b6dd86b7e601eb4e7bb3ccb3b373024324"	"Cuncuna"	-6771.8	1295.73
"0660748101b87fafd8d447bc4d923766e0574915"	null	-3.4028e38	-3.4028e38
"df94cabdf126c62652eaf367b5d9a1bc7193e9ae"	null	-3.4028e38	-3.4028e38
"2318f7ed627435427ee11163db10d8d6129c7fa6"	null	-8144.89	662.72
"6b1c3dd2f88eb74b1b59b1902b74369096d47a55"	"パノラマパーク"	-5267.0	1151.59
"81ef48be1f94990da5963debdf29076458b29df7"	"エキサイティングBコース"	-5197.31	1307.21
"a30b125ff3bc173bf6bdd1d6491cbad7c9e3524f"	null	-5697.11	435.3
"284a0e5c63367bd8ab4f59ee78dd87c4deaa6c6a"	null	-8132.58	1012.96
"1b8b2a273fcebdf601c2b32f5d2860a7a505602e"	"Центар, Centar"	-3.4028e38	-3.4028e38
"7b1d552031ca58ee09e639b2ec080144dd6be374"	null	-7307.49	665.59
"89b477ac617ea18631686015a41d600e099aee1b"	"ビギナーズコース"	-5259.04	1151.59
"346a65fd338daab24ea820ca6cdfe01285403292"	"ダイヤモンドコース"	-5060.16	1512.26

Going to these now, the issue only shows up on the frontend for some the runs. For example, this run is currently exhibiting the issue:

Another run with the issue currently is Hslcón Peregrino of Cerro Castor in Argentina, although this issue did not exist in the download.

[dhimmel]

Side question: how stable are run and slope IDs across time? What goes into their derivation?

[russellporter]

I think that can happen because there are voids in the SRTM elevation dataset. Probably ideally we'd use a dataset which doesn't have these issues or just remove the elevation data entirely for a feature when invalid data is detected.

Side question: how stable are run and slope IDs across time? What goes into their derivation?

I think the id's are determined by a hash of feature geometry + feature type. They are not super stable.

https://github.com/russellporter/openskidata-processor/blob/master/src/transforms/FeatureBuilder.ts#L8

[dhimmel]

I think that can happen because there are voids in the SRTM elevation dataset

Ah good to know. I see on the SRTM data page that there are three data sets:

• SRTM Non-Void Filled
• SRTM Void Filled
• SRTM 1 Arc-Second Global notes "Some tiles may still contain voids"

From this description it's not entirely clear to me whether any of these datasets entirely avoid voids.

just remove the elevation data entirely for a feature when invalid data is detected

I'm -1 to removing elevation for the entire feature, since in the screenshots above only a single elevation value is bad for the entire run. Not sure if the geojson and infra supports single element null values?

Thanks for the feature hashing link.

[russellporter]

You are right, it makes more sense just to exclude elevation for specific points. It might also require adaptation on the frontend to account for that.

Given this appears to affect a very small fraction of the overall dataset affected, I probably won't work on this soon.

[dhimmel]

Given this appears to affect a very small fraction of the overall dataset affected, I probably won't work on this soon.

Not a problem. Nullifying elevations < -100 meters solved the issue for my application, so the fix was easy once I was aware of the issue.