Skip to content
This repository has been archived by the owner on Jul 17, 2024. It is now read-only.

Profile: show nb_points #3743

Open
4 tasks
davidoesch opened this issue Mar 21, 2017 · 18 comments
Open
4 tasks

Profile: show nb_points #3743

davidoesch opened this issue Mar 21, 2017 · 18 comments

Comments

@davidoesch
Copy link
Contributor

davidoesch commented Mar 21, 2017

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
image

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
Copy link
Contributor

procrastinatio commented Mar 22, 2017

Regarding increasing number of points: basically increasing the number of point increase the denivelation...
#3492 (comment)

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
Copy link
Contributor

gjn commented Mar 22, 2017

This is related to #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
Copy link
Contributor Author

davidoesch commented Mar 22, 2017

don't make the user think.
other options

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
Copy link
Contributor

gjn commented Mar 22, 2017

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

Yes, we have to decide on a sampling model.

@davidoesch
Copy link
Contributor Author

TBD on Friday 1:1

@procrastinatio
Copy link
Contributor

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
Copy link
Contributor Author

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

image

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

image

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
Copy link
Contributor

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

@oterral
Copy link
Contributor

oterral commented Mar 23, 2017

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
Copy link
Contributor Author

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

@procrastinatio
Copy link
Contributor

procrastinatio commented Feb 13, 2018

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).

@davidoesch
Copy link
Contributor Author

How does chmobil solve this ? See-example above

@gjn
Copy link
Contributor

gjn commented Feb 13, 2018

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
Copy link
Contributor

gjn commented May 1, 2018

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
Copy link
Contributor

oterral commented May 29, 2018

offset 1 is used like chmobil

@Philo81
Copy link

Philo81 commented May 6, 2019

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 #4299
Eventually they can be merged.

@davidoesch
Copy link
Contributor Author

@Philo81 #4305
And many other proposals: key is: open access to the profile service will solve a lot

@Philo81
Copy link

Philo81 commented May 8, 2019

@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").

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants