New beta version 8.5.x [CLOSED]

[notbru]

Hola orux,
i have one gpx-file with two tracks <trk> inside.
with 8.5.5beta6 only the first track is shown, when loading the gpx.
with 7.4.24 both tracks are shown, as it is preferred.

Could you please have a look at the beta.
Thank you,
notbru

Hello!
Now when you import a gpx with more than one track, each track is imported separately, as a different Track. Do you mean when you mean when you load that gpx into the map?


orux

Yes, I mean the loading of gpx into the map (option: do nothing when loading) >> only the first <trk> is visible, the second <trk> is missing, also in the statistics.
How can I see the second <trk> on the map?

saludos, notbru

[notbru]

Hola orux,
i have one gpx-file with two tracks <trk> inside.
with 8.5.5beta6 only the first track is shown, when loading the gpx.
with 7.4.24 both tracks are shown, as it is preferred.

Could you please have a look at the beta.
Thank you,
notbru

Hello!
Now when you import a gpx with more than one track, each track is imported separately, as a different Track. Do you mean when you mean when you load that gpx into the map?


orux

Yes, I mean the loading of gpx into the map (option: do nothing when loading) >> only the first <trk> is visible, the second <trk> is missing, also in the statistics.
How can I see the second <trk> on the map?

saludos, notbru

ok, gpx with more than one <trk> are now splitted in orux tracklog-database, but I mean loading a track from a folder (like the download-folder). In this case I get only the first <trk> onto the map. The work-around with saving first the gpx from the folder into the database, then loading the splitted tracks from the database is a bit complicated.
Would be nice to get all the <trk>, when loading gpx from a folder as it was in earlier versions. No need to copy the gpx first to the database (neither manually nor automatically).

Thanks a lot, notbru

[orux]

ok, gpx with more than one <trk> are now splitted in orux tracklog-database, but I mean loading a track from a folder (like the download-folder). In this case I get only the first <trk> onto the map. The work-around with saving first the gpx from the folder into the database, then loading the splitted tracks from the database is a bit complicated.
Would be nice to get all the <trk>, when loading gpx from a folder as it was in earlier versions. No need to copy the gpx first to the database (neither manually nor automatically).

Thanks a lot, notbru

New beta uploaded.
The problem with the multi trk files should be solved,


orux

[notbru]

Thank you, orux!
Problem solved

[YvanCB]

Hello,
When I import  a GPX file into the database the new entry have a strange name. For example "Track_1639850099214".
Before, the new entry had the same name that the  file name:
File name = "2021-12-18 135043.gpx" gave an entry called "2021-12-18 135043".
Is it possible to have this function again?
Regards.

[eartrumpet]

beta1:
-->Android 30 SDK storage limitations.

Hi Orux,
I've tested scoped storage with an Android 11 device.
As I can only choose internal OR external private folder right now, are these the only options with scoped storage - or would it be possible to set some folders like maps to external, and tracks to internal?
Wouldn't it be possible to have huge files (maps, DEM) in the "download" folder that still should be available to all apps? Even read only would be fine if you manage it with a different app.
Regards,
Tobias

[orux]

Hello,
When I import  a GPX file into the database the new entry have a strange name. For example "Track_1639850099214".
Before, the new entry had the same name that the  file name:
File name = "2021-12-18 135043.gpx" gave an entry called "2021-12-18 135043".
Is it possible to have this function again?
Regards.

Hello!
With the new filesystem sometimes the app does not know the name of the file. That name is only used when the track itself has no name (within the GPX). I review it.


orux

[YvanCB]

Hello Orux,
This new filesystem in Android is a little bit annoying 🤨. We can't browse anymore our folder as easy as before and now this entry name issue 😕...
I know it's for security but ...
Thank you our more time for your work and this marvellous software🙂🙂🙂.
Regards.

[orux]

beta1:
-->Android 30 SDK storage limitations.

Hi Orux,
I've tested scoped storage with an Android 11 device.
As I can only choose internal OR external private folder right now, are these the only options with scoped storage - or would it be possible to set some folders like maps to external, and tracks to internal?
Wouldn't it be possible to have huge files (maps, DEM) in the "download" folder that still should be available to all apps? Even read only would be fine if you manage it with a different app.
Regards,
Tobias

Hello!

It complicates the system a bit, but I could review it (select later individually if some resources are wanted in the external/internal folders).

My initial idea was to use a folder within Downloads/ for maps and other resources, but you cannot grant permission to an app to access a folder within Downloads, only individual files. Apps can access the files they create in Downloads, but not the others. And if you uninstall and reinstall the app, you lose access to the files created. The new file access system is a bit complex. Everything that is outside the private folders has a lot of complexity to access the files in an ordinary way (low-level access, necessary with databases,...).


orux

[eartrumpet]

It complicates the system a bit, but I could review it (select later individually if some resources are wanted in the external/internal folders).

That would be great!

My initial idea was to use a folder within Downloads/ for maps and other resources, but you cannot grant permission to an app to access a folder within Downloads, only individual files. Apps can access the files they create in Downloads, but not the others. And if you uninstall and reinstall the app, you lose access to the files created. The new file access system is a bit complex. Everything that is outside the private folders has a lot of complexity to access the files in an ordinary way (low-level access, necessary with databases,...).

That's too bad, would have been too easy ;-)
What's also important in this context would be a possibility to backup the track database and app settings without too much hassle. I used to have a nice solution to sync the internal & external SD to my NAS, but not that's not possible with the sync app for the android folder. I can use an explorer app and copy manually, but this is no good strategy. So maybe a backup function in OruxMaps would make sense (cloud, smb, whatever), especially when all data can be lost by uninstall.

[eartrumpet]

Locus already has an update with scoped storage, and of course the same problems. Here are some interesting findings by my fellow OpenAndroMaps colleague Michael in one of the comments here https://www.locusmap.app/de/android-11-bringt-eine-wichtige-aenderung-fuer-locus-verzeichnisse/:

Michal,
the number of different map types is pretty much irrelevant.
You have to differentiate mainly two dimensions:
- the requirement profile of the various Locus files
- the access methods available for different locations of Android 11

Requirements:
- log files and alike - sequential write (and pot. read)
- themes - handling huge number of small files (the graphics) in a performant way
- track and POI DBs - random and fast access, safe storage
- map files - fast random access - and this is the same for Mapsforge 3 and 4 and 5
- SRTM - pot. many files in the folder, I do not know how access works (sequential or random)

Assessment of access methods for those categories:
- log file and alike - business as usual, no hassle
- themes - performance mess on ext SD -> separate the themes folder from the mapsVector location (trivial exercise) and put themes on int SD ALWAYS; or deal with the zip version instead (c:geo and Cruiser are doing such and have no performance problem)
- track and POI DBs - similar as themes - int SD is the best location
- map files - private folder on ext SD seems to be tricky; latest tests bei Willi and Wolfgang showed that /Android/media is a better place; again, c:geo and Cruiser can handle this location efficiently. Also, this allows multiple usage of the same maps (raster and vector) by different apps. In addition, file managers can read/write to /Android/media, even on ext SD.

I think it is obvious what nees to be done - and this will bring benefits for Locus functions, and peace and happiness into the user community.

Good luck and cheers
Michael

[YvanCB]

Hello,
It's no more possible to copy saved track into the app folder :Android/data/com.orux.oruxmapsbeta/files/oruxmaps/tracklogs.
I used to use X-plore:
https://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore.

How can we do now?

Regards.

[Agus]

Hello,
It's no more possible to copy saved track into the app folder :Android/data/com.orux.oruxmapsbeta/files/oruxmaps/tracklogs.
I used to use X-plore:
https://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore.

How can we do now?

Regards.

https://play.google.com/store/apps/details?id=com.cxinventor.file.explorer

[YvanCB]

Hello Agus!
This file explorer seems to work perfectly!
I will use it now.🙂😉
Regards.

[Lenz]

Hello Orux,
I recognized some problems with beta 10:

- max/min icons for altitude are not displayed neither for a route created with brouter nor one created by hand, although the fuction is activated in tracks/routes settings (I don't know if max/min speed icons are shown as i didn't record a track)

- The screenshots for the surface and road type look great, also the possibility to display the surface type of a route on the map ... but it doesn't work for me. In the route statistics nothing concerning surface or type is shown and on the map the route is displayed in blue independent of the surface. Is there anything I have to activate in Oruxmaps or the Brouter app? I couldn't find anything.

Regards