New beta 10.6.x [CLOSED]

[Tronpo]

Hello, I would rather bet that the problem comes from the Android updates, in particular 14 is the one that is giving the most war (I have several colleagues with orux and Android 14).
If you have all the public folders, with the permission to access all the files you should have no problems.
I have Android 11.
I use Oruxmaps Gp in public folders all ok
And Oruxmaps beta in private folders.
In the case of the beta, if I have problems accessing the Android data folders

[Tronpo]

Hello orux!!
I like the planner more and more, to keep moving forward to see what you think :
1-Add a dashed line from the last waypoint to the center of the map with the distance above the line (maybe + azimud/dem height). It's a very useful reference
2-Fortunately, with the planner open, we have the possibility to create waypoints in the traditional way (button) at the end of the creation, being in the planner, would it be possible to add as a waypoint directly?
Currently it can be added but you have to do it from the list of POIs.
It would be a more direct way

Best regards!!

[Tronpo]

Good afternoon!!
In reference to the new search on waymarkedtrails.
-currently opens at the last GPS position, for me it would be more useful to open in the same position as the general map viewer, or add an option to move map to a point without fear than to navigate the whole map.
-many routes on the web have links that can provide a lot of information about the routes,
It would be very interesting if this could be seen from Oruxmaps.


-pass the route from the Waymarkedtrails screen to the planner.... Too much to ask?

Pd:The translator doesn't help😅
Best regards!!

[Lenz]

Hello Orux,
I found a bug in the lateral dashboard and the trip computer: only the first two elements can be edited by long pressing. I think this problem occurred already in version 10.6. beta 2.

By the way:
Could you please take a look at this problem again:

Maybe you also could take a look at the elevation gain and loss calculation. When you plan a round trip with the route planner there are big differences in gain and loss which should be zero (or at least close to zero because of rounding errors). I tried it with some routes with a length of about 10 - 12 km an an elevation gain of 1000-1200 m which led to differences between 90 to nearly 200 m depending on the terrain. Even after an altitude correction with Sonny's DEM files the differences were huge. But when i joined the segments everything was ok.

My attempts with the latest beta 3 where even worse than at the time I posted the problem. The uncorrected gain/loss was as bad as back then but the "corrected" values (with Sonny's DEM files) were really terrible: the gain/loss differed about 10 % to more than 100 % (!) from the uncorrected values, which were at least in a realistic dimension. The difference of gain and loss of the corrected values is even further apart from zero than the difference of the uncorrected ones.
When you join the segments, everything is ok: the difference gain-loss is close to zero and the values sound realistic.

Best regards.

[Tronpo]

Hello, for me this has improved in beta 3.
This beta is the first one to use the Dem files in the scheduler, when we use brouter.
It is different if the path contains straight lines, this if it distorts the calculations
Routes created with the planner have many segments, due to the road/surface type information. This influences the algorithm of the calculation of elevations, each beginning and end of segments will be taken into account for the calculation
But if we make a dem correction, or join segments, the points taken for the calculation will not be exactly the same as when the route was plamized, so we always have differences in the results

Best regards. (it's an opinion)

[Lenz]

Hello Tronpo,

differences in the results are hardly avoidable due to rounding and of course they are acceptable if they are within a realistic and limited range. But some - not all - tracks I created with the new route planner without straight lines show huge and not realistic values when I corrected them via Sonny's latest DEM files.


I attached a GPX file of the track with the worst values as shown in the track manager:

1) track saved from route planner to database - profile alpine - segments - no correction: up 1082.0 m - down 792.1 m
2) track 1 + height correction with DEM (Sonny's Austria 0,5"): up 1930.9 m - down 2452.0 m
3) track 1 - exported as GPX - imported GPX: up 1090.4 m - down 973.9 m
4) track 3 + height correction with DEM (Sonny's Austria 0,5"): up 1930.9 m - down 2452.0 m (same values as track 2)
5) track 3 + joined segments: up 1135.0 m - down 1135.0 m
6) track 5 + height correction with DEM (Sonny's Austria 0,5"): up 1129.6 m - down 1129.6 m

I tried also Sonny's Austria DEM 1"
7) track saved from route planner to database - profile alpine - segments - no correction: up 903.7 m - down 710.3 m
8 ) track 1 + height correction with DEM (Sonny's Austria 1"): up 1894.3 m - down 2391.2 m

When I import a GPX file from tracks 3 and 4 (huge differences!) in MyTourbook on Windows, the elevation gain/loss are +1179 m and -1179 m.

I can reproduce the same results from 3) and 4) in version 10.6.3 GP - so sorry, it didn't get worse but also not better.

Have I missed any preference I should have made?

[Tronpo]

Well, something is slipping through our fingers my friend, I've reproduced your route using it as a template.
With brouter sicami, alpine
Without having Data  dem installed.
This is the result
https://drive.google.com/file/d/1ioOsX5jRp3v9X0gk0OHqENjjFOT_fqr1/view?usp=drivesdk

[Lenz]

Hello Tronpo,
I imported your GPX and the values were: up 844.5 m - down 877.0 m.
After height correction the up/down values become extremely unrealistic: 2097.4 m and 2649.5 m.

When I join the segments of the imported track I get 1088.0 m for both up and down and after the correction I have 1128.7 again for up and down.

Can you reproduce these values - or at least this strange behaviour of Oruxmaps?
When you'll get reasonable results, maybe I have try a new user profile.

[Tronpo]

Hello again friend, instsle the dem of Sonny 1" from Austria for the area, I made corrections and planning based on dem.... Then began the crazy dance you're experiencing


But I think I've found the crux of the problem
POINT-BY-POINT ELEVATION ALGORITHM

Change the Elevations algorithm to: BY DIFFERENCES

And plan the routes again, Oruxmaps seems to come to sense.






Try it and tell me if I'm right.

[Lenz]

Hello Tronpo,
you are absolutely right - the point-to-point algorithm is the problem.
Some time ago I tried and compared the two algorithms and in my opinion, I got better results with point-to-point. So this was my preference in Oruxmaps, I never changed it and forgot about it.
Thank you very much for your great support in this forum and on https://tronpoonpo.blogspot.com

[Tronpo]

This peer-to-peer algorithm is also generating problems in other cases, the developer is already aware of it, let's wait for a new beta
Best regards

[Tronpo]

Hello Orux,
I found a bug in the lateral dashboard and the trip computer: only the first two elements can be edited by long pressing. I think this problem occurred already in version 10.6. beta 2.

By the way:
Could you please take a look at this problem again:

My attempts with the latest beta 3 where even worse than at the time I posted the problem. The uncorrected gain/loss was as bad as back then but the "corrected" values (with Sonny's DEM files) were really terrible: the gain/loss differed about 10 % to more than 100 % (!) from the uncorrected values, which were at least in a realistic dimension. The difference of gain and loss of the corrected values is even further apart from zero than the difference of the uncorrected ones.
When you join the segments, everything is ok: the difference gain-loss is close to zero and the values sound realistic.

Best regards.

Hello Tronpo,
you are absolutely right - the point-to-point algorithm is the problem.
Some time ago I tried and compared the two algorithms and in my opinion, I got better results with point-to-point. So this was my preference in Oruxmaps, I never changed it and forgot about it.
Thank you very much for your great support in this forum and on https://tronpoonpo.blogspot.com

Hello friend, in the last beta there are changes regarding the algorithm from point to point, it would be interesting if you check the routes that in the past gave you those calculation errors, to see if anything has been improved
Best regards

[Lenz]

Hello Tronpo,
thank you for drawing my attention to the new beta!
I tried the route I sent you and the results are better or at least more realistic.
Here are the up/down values:

Planned route with brouter: 1120.1/1028.9
After correction with DEM:
1120.1/1028.9
After joining segments:
1147.2/1147.2
After repeated correction with DEM:
1147.2/1147.2

My conclusion:
1. No more totally unrealistic values - great!
2. No difference with or without altitude correction with DEM files. This is the expected result of the usage of the DEM files in the route planner you mentioned above.
3. A 90 m difference in a not too long track is still quite much for rounding differences (more or less the same with other tracks I tried).
4. The segmentation of the track still seems to cause problems as the values with the joined segments are the most realistic ones (in comparison to a calculation with high and low points).

Best regards

[bettellam]

Como premisa debo complementar el continuo desarrollo e implementación de la aplicación.
Recientemente tuve la oportunidad de experimentar con la función Viewshed y quedé realmente satisfecho con ella.
Quería preguntar si es posible guardar el resultado del procesamiento para poder usar la cuenca visual ráster en otras aplicaciones SIG.
Gracias
Atentamente

[Tronpo]

Como premisa debo complementar el continuo desarrollo e implementación de la aplicación.
Recientemente tuve la oportunidad de experimentar con la función Viewshed y quedé realmente satisfecho con ella.
Quería preguntar si es posible guardar el resultado del procesamiento para poder usar la cuenca visual ráster en otras aplicaciones SIG.
Gracias
Atentamente

Hola actualmente no, también pienso que seria muy interesante poder exportar la zona vista "polígono" como capa (kml/kmz)