Profile: show nb_points

[davidoesch]

Since we the number of points used for the polyline segmentation is Default “200”. we have profile which do not fit the map ( see as well #3492) Customer feedback ID : 2017032015313745 like "Wird die Maus auf diesem Höhenprofil von links nach rechts bewegt, wird für jeden einzelnen Punkt auf der Linie die Höhe über Meer angezeigt. Diese Höhenangaben sind aber offensichtlich falsch. Der Fehler wird dabei umso grösser, je länger die Linie ist und je extremer die Höhenlage ist. Berge werden tendenziell zu niedrig und Punkte im Flachland zu hoch ausgewiesen."

as in https://s.geo.admin.ch/72175e971e

are common

task:

• improve profile accuracy even for transects covering whole switzerland

action to test

• [ ] test 2000 nb_points ( performance? ,limits)
• [ ] test np_points spacing of max 25m for a long transect
• [ ] when profile open : show nb_points in profile and line as ticks
• [ ] other options?

[procrastinatio]

Regarding increasing number of points: basically increasing the number of point increase the denivelation... https://github.com/geoadmin/mf-geoadmin3/issues/3492#issuecomment-251886284

We are returning imprecise altitude, because we cannot attribute altitude to point.

If we could return altitude for a point:

The most simple option is to attribute altitude to the given point on profile, if you want to simplify, you have to consider the concavity/inflexion of the slope, not the shape of the path, otherwise, it is very wrong

Store altitudes in KML

etc...

And please, consider that vector tiles are soon there, so we have artificial limitation.

[gjn]

This is related to https://github.com/geoadmin/mf-geoadmin3/issues/3492

It's all about the sampling. What options do we have?

a) stupid sampling (we currently do that with 200 points, distributed by length on the polyline, here we can play on number of points, but the sampling will remain stupid) b) use all vertices of a polyline. with this, user would be sure that drawn points are correct c) combine a) and b). Use all vertices and do stupid sampling between vertices

All have performance impact.

And question to answer: do we make the above optional to the user (so he can choose what he wants?)

[davidoesch]

don't make the user think. other options

• [ ] google uses sampling paramter as we do--do they have a limit? https://developers.google.com/maps/documentation/javascript/examples/elevation-paths

• [ ] use a different elevation modell: https://shop.swisstopo.admin.ch/de/products/height_models/dhm25200 for distances longer than 20km and GTOPO 30/SRTM for long transects

The more I think the more I'm convinced we should use dependent on distance different sources dhm25 or srtm. They are officially sampled

[gjn]

I don't see how a different elevation model would help?

Yes, we have to decide on a sampling model.

[davidoesch]

TBD on Friday 1:1

[procrastinatio]

In 2D, if you want something realistic, you have to choose you waypoint carefully. Same apply for a profile, user has to chose manually the inflexion points (summit, pass, thalweg, etc.). We don't use smart sampling in 2D, why should we do it for profile ? GIGO

[davidoesch]

to assure GIGO we have to take into account all GIGO which is under the profile line. So zoomlevel dependent we show all grid values of a base height dataset- the dataset is already denoted now in the profile (we can add the accuracy)

What astonishes me use CHMOBIL (based on our alti service) https://map.schweizmobil.ch/?lang=de&showLogin=true&bgLayer=pk&resolution=10&X=643863&Y=157179&trackId=3337842:

results in a correct height...the use the same height service and get good interpolation

transferring the exported gpx to kml (exactly the same line) we get a different alti (and obviously not correct due to sampling) for the same position approx 100m height diff https://s.geo.admin.ch/7222aa1647 (zip attached of export) _test.zip

so for me: if chmobil manages to get a decent and correct height..we should as well. since they are using our height service ( hey we built it for them....)

1:1 discussion...

[loicgasser]

We can remove the smoothing effect. That s d3js here. Or enable/disable it on demand. I can show you easily there difference.

[oterral]

I confirm if you right click on a point you don't have the same height in the context popup (the good one same as chmobil) and in the profile.

[davidoesch]

ping @gjn : see chmobil solution. They use our height/profile service and get correct results

[procrastinatio]

If you have a very long input line (many kilometers), you'll miss the pics and valley bottom, as points along the profile are choosen at random (from a height point of view, the 200 points are distributed horizontally).

• Increasing number of point to increase precision See https://github.com/geoadmin/mf-geoadmin3/issues/3492#issuecomment-251886284
• Increasing number of points: See https://github.com/geoadmin/service-alti/pull/25

[davidoesch]

How does chmobil solve this ? See-example above

[gjn]

Is suspect that they sub-sample their requests based on distance before tapping our profile service. But this would need to be analysed in detail. I will also ask Fred.

[gjn]

We are applying ma filtering per default on our profiles (it's the offset in the official doc, which, per default, is 3). So this naturally leads to the effect that the hight of a peak is never correct (it's smoothed out). This has been like this in the backend since the beginning of RE3 - and maybe even in RE2. Could be that chmobil uses offset 0 (can't see in logs because of post requests).

I create a PR with offset 0 applied to have comparison.

[oterral]

offset 1 is used like chmobil

[Philo81]

As an standard "outdoor" user (my2cents):

• I would recommend, when ever possible, not to modify the original KML/Drawing and I do expect the height/profile service&function to return the height information based on the original input data (of course there must be a limitation given by performance&infrastructure).
• Limitation of the function/service must be visible ("known") by the users (help documentation, warning or pop-up, ...)

As mentioned above CHmobile has actually a better functional implementation of the height-profile as map.geo.admin.ch and they're using the BGDI profile-service ;)

This ticket is pretty similar to https://github.com/geoadmin/mf-geoadmin3/issues/4299 Eventually they can be merged.

[davidoesch]

@philo81 https://github.com/geoadmin/mf-geoadmin3/issues/4305 And many other proposals: key is: open access to the profile service will solve a lot

[Philo81]

@davidoesch I agree of course. You're right but we can also go step by step. I think it's already "legally compliant" to access the height data for a function like "profile" within map.geo.admin.ch without limitation. In a second step we can then give access to the profile service (API) for everyone/application as soon as our politics have done the job ("OGD").