Elev Corrections Issue

The solution could be very simple from my point of view. Data needs to be smoothed before each elev correction.

Yes, smoothing is one possibility, though not the best one, because it could lead to incorrect results in case you are really moving in a rugged terrain. Better would be either excluding the watch-provided elevation data if it does not match exactly with the topographic values, or auto-calibrating it before merging, so that both of the sets are based on the same altitude.

Yes, I'm able to handle this issue by one click workaround after each import, but I have to to do it every single time.
I hope that the Garmin is able to fix this issue by better way.

You are posting to the comunity forum, so we, the users, cannot influence that. We can only offer help, and suggest existing solutions. Besides the possibility to disable the elevation correction, I also suggested to try improving the accuracy of the elavation reading on your watch (altimeter calibration prior the activity, and/or advanced GPS settings like activating Gps+Glonass, or similar)

jmto said:

it's just the bad data.

You can test it easily. Compare the elevation values at some key points of an activity with enabled elevation correction, then note the elevation at the very same keypoints without the correction, and compare to the data you trust (you posted a link of alegedly good data, so you can use that source for example). You can also use Google Maps, Google Earth, HERE, OpenStreetMaps, or another source, of course.

jmto said:

Can you explain who do you think it's combining?

I superimposed the profiles from the initial post with and without the correction. It shows that the basic lower profile comes from the watch, while the spikes of a higher altitude come from the topographic data. The elevation correction resorts to combining both sources, whenever the density of the source data is not high enough to use the topographic data only. It can only work if the elevation data from the watch matches the topographic data. The algorithm is currently not capable of compensating any discrepancies in the two data sources, and it is clear it needs some tweaking.

As written earlier, smoothing is an option, but there are better ways of doing it as well. In the meantime you simply either need to have good altitude reading on your watch, or continue turning off the correction, when you see it causes problems.

So the first totally wrong thing (8913m) is done by combining? And then if disabled it's watch only (41m)? and then enabled it's just the bad correction data (75m)?

Why would anyone think that combining two totally different data (even with smoothing) would be good idea? I don't really get it. And then if you change enabled/disabled of the corrections, you will do the corrections differently than in the first place? That's just plain stupid.

And the solution isn't disable the corrections, as you can't disable the corrections when creating course. Garmin will always use their bad corrections on course.

I fully agree that GC has this issue of incorrectly displaying the elevation data when importing files from Suunto. It does the same with my uploads in FIT format from by Suunto barometric watch, turning my 20-30 m ascent runs into 1000 m mountain climbs.

So you have to calibrate ist every time before a run? What about the option of consistently correcting during the activity? Would that solve it automatically?

DanielM said:

What about the option of consistently correcting during the activity? Would that solve it automatically?

Some Garmin devices indeed offer auto-calibration during an activity. However, you have to check first that it really does what it promisses. I am not quite sure the auto-calibration works reliably on all models. If you verfied, and know it is reliable, then of course, you should be using it. If not, calibrate the altimeter manually just before the activity.