Messages

Hello Orux,
maybe it's possible to address the problem I mention in my post
https://oruxmaps.org/forum/index.php?topic=3894.msg51970#msg51970
that for the new high resolution 0.5" DTM for Austria [DTM Austria 0.5" v2 by Sonny], OruxMaps does not indicate elevation on the dashboard [Elevation (DTM)/Höhe (DTM) shows "--- m"] for these 0.5" .hgt-tiles, while elevation for neighboring 1" hgt-tiles is correctly displayed.
Likewise, creating a track by hand yields waypoints with elevation 0.
Regards, Wolfgang

I have been using the excellent 1" DTMs by Sonny for quite some time with OruxMaps.

Now, after downloading the new high resolution 0.5" DTM for Austria [DTM Austria 0.5" v2 by Sonny], I realized that OruxMaps does not indicate elevation on the dashboard [Elevation (DTM)/Höhe (DTM) shows "--- m"] for these 0.5" .hgt-tiles, while elevation for neighboring 1" hgt-tiles is correctly displayed.
Likewise, creating a track by hand yields waypoints with elevation 0.

The underlying data, however is correctly displayed in Terrain Shading/Geländeschattierung of maps.
Also, when creating a route with brouter, brouter utilizes altitude information from the 0.5" DEM correctly.

Can orux please comment on this - maybe OruxMaps (I am currently using OruxMaps v.8.1.10 GP) needs an update for this display problem.

Orux: thank you for the explanation. Unfortunately I have the same problem on my Samsung Galaxy Note 3; in my case also the time for the individual trackpoints (however not for the waypoints!) suffers from this bug.
I detected it with Oruxmaps 7.4.22 and also 8.0.1 GP - but I just learned that for the 8.0 GP versions there is a remedy: Sensors>GPS>Replace GPS time stamp.
I haven't tried it yet, but I am confident that it will work.

Could you please include this GPS week number rollover fix also for the old free version - or, better still, publish an updated free version?

I have noticed the same problem with wrong date (not time!) e.g. 2000-11-19 instead of 2020-07-05 in gpx trackpoints (not waypoints, however!) and <desc> Startzeit and Zielzeit (e.g. 03.10.2000 instead of 19.05.2020) on my Samsung Galaxy Note 3 with Android 5.0.
I have been using Oruxmaps 4.7.22 and 8.0.1 GP.
The error does not show on my Honor 8x with Android 10.
In the past this error never occured, now it seems to occur regularly.
System time is and was always correct.
The error occurs because of the "GPS Week Number Rollover" problem and has apparently been corrected by Orux in the beta release (7.5.9beta3) and also in the new GP VERSION 8.0.1 (Sensors>GPS).
I have not yet checked this, however...
See post "Error en la fecha de inicio del track".

[φλ Coordinates]

There is an issue I encountered when calibarating maps using the φλ Coordinates displayed by oruxmaps. It does not strictly apply to the new beta versions, I know, but maybe it could be addressed within the changes made with the new user interface:



In Global settings/Units/Coordinates one can choose degrees (00.0000°), but the precision is only given to four digits after the decimal point. Here six digits would be highly preferable for high resolution maps at high zoom levels. Maybe one could be allowed to choose the required accuracy, or a new item degrees (00.000000°) could be added.



It would also be nice if one could choose the font size (or a smaller font size) for the display of items chosen in

Global settings/User interface/Dashboard/Dashboard controls (like Map name, Datum, Coordinates, Altitude etc).

In particular, Map name could use a smaller font...



Aside from this, for me the latest release candidates leave little to be wished for! Thanks a lot for this excellent app - my favorite!

[Android 4.4.2]

Hello orux,

on my Samsung Note 3, Android 4.4.2 I have been working with OruxMaps (Playstore version 6.5.9 and several 6.5.Xbeta versions) for some time. Everything workes fine with the normal version 6.5.9.



I have also been quite satified with several beta versions, but beginning with 6.5.11.beta17 I noticed dislocation effects (by 300 to 600 m in various directions) with raster offline maps that I generated with Mobac as OruxMaps Sqlite (OruxMapsImages.db and <mapname>.otrk2.xml).

Some (but not all) of these maps I had to recalibrate and generate a new otrk2-file with OruxMapsDesktop 2.1.0beta to datum/projection different from WGS84/Mercator.



All vector maps (openandromaps, freizeitkarte) of type <mapname>.map are fine.



Unfortunately I did not save beta versions older than 6.5.11.beta17, so I cannot pin down the problem to a specific version change. The effect persists also with the latest 6.5.11.beta20. The shift for raster offline maps is noticed also by jaimecy and steed.