-
Notifications
You must be signed in to change notification settings - Fork 72
Profile: show nb_points #3743
Comments
Regarding increasing number of points: basically increasing the number of point increase the denivelation... 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. |
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) All have performance impact. And question to answer: do we make the above optional to the user (so he can choose what he wants?) |
don't make the user think.
The more I think the more I'm convinced we should use dependent on distance different sources dhm25 or srtm. They are officially sampled |
I don't see how a different elevation model would help? Yes, we have to decide on a sampling model. |
TBD on Friday 1:1 |
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 |
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 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... |
We can remove the smoothing effect. That s d3js here. Or enable/disable it on demand. I can show you easily there difference. |
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. |
ping @gjn : see chmobil solution. They use our height/profile service and get correct results |
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).
|
How does chmobil solve this ? See-example above |
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. |
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. |
offset 1 is used like chmobil |
As an standard "outdoor" user (my2cents):
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 |
@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"). |
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:
action
to test
The text was updated successfully, but these errors were encountered: