Messages

... I wonder if I can add another heatmap, for example, run&bluered...

Yes, of course.
You only have to duplicate all the lines relative to this map in onlinemapsources.xml (only one onlinemapsources.xml file, with all lines defining the map repeated in the same file)

Actually, not exactly "duplicate", since
- parameter will be different in both paragraphs according to your need (run vs. ride)
- but also uid=... (in 1st line of each map definition) has to be different (actually, all maps defined in onlinemapsources.xml must have a unique uid)
- and also <name>....</name>  has to be unique as well (actually, I'm not 100% sure it has "technically" to be unique, but at least to allow you to identify uniquely the map in the list....)

For various heatmaps, in the URL, there are two parameters ("all" and "hot" in the example provided above)
The first parameter can be
  all (ie. all tracks, whatever the sport)
  ride (ie. bike)
  run (ie. hike and running)
  water (ie. water sports)
  winter (ie. skiing and other winter sports)

The second parameter can be
  hot
  blue
  purple
  gray
  bluered
and acts on tracks color.

Personnally, my preferred "color" is bluered that better "filters" tracks and do not show very rarely used tracks, but focus only on tracks above a minimum level of usage, and have a color varying from blue to red depending on usage level (low usage in blue, high usage in red)

[how to retrieve the xsd]

Both are URI,s not URL,s.

The xsd used for validating the xml is here:

https://www8.garmin.com/xmlschemas/TrackPointExtensionv2.xsd

Hi @orux, thanks, I've (almost.... ) understood.

And I can see inside the XSD that it points to the URI.
And the difference between XSD v1 and v2 is that "Speed" (and some others) do not exist in v1, but only in v2, that obviously explain the issue.

But please help me once again : how to retrieve the xsd when provided only the URI ?

(in other word : how to determine the https://www8.garmin.com/xmlschemas/TrackPointExtensionv2.xsd URL when only URI "http://www.garmin.com/xmlschemas/TrackPointExtension/v2" is provided...? )

[choose to export it or not]

A residual doubt would be: Why the problem appear in the new OM version? Was something changed in the way OM build the GPX file or what?

The speed parameter (that is "behind" the issue) was not exported at all in old OM versions (at least in "free" version, 7.4.26)
But, as Orux mentioned in his own answer, in recent versions of OM, you can choose to export it or not. If you choose to do not export it, no more issue.

And, on a more long term perspective, I'm quite sure that in the next version of OM, Orux will modify the xmlns:gpxtpx parameter to v2, and the issue will disappear...

[it works in Basecamp]

I was imagining that URL in xmlns:gpxtpx could be the cause (even if I don't know exactly the use (and role) of this url)
And I just did the test you recommend, and with xmlns:gpxtpx updated to v2 as you indicate, it works in Basecamp.

But it remains very surprising to me, since both URL (/v1 and /v2) are responding the same, ie. "Page not found" !

Surely something I don't understand clearly....

[ignored]

I'm not sure it's the best idea to have done modifications in files... even if it is to reduce size and increase readability....
It would be preferable to analyse "original" files...

Nevertheless, I've analysed your files.

1) I confirm that 1st file is not "readable" by BaseCamp, while the second one is. On the other hand, even the 1st file is readable by some other apps, like JOSM or GoogleEarth, or french Geoportail, ... or OruxMaps itself, even "old free" version, ie. 7.4.26
This (readability by other tools) leads to think that issue is in BaseCamp and not in GPX file itself.

2) I then compared both files.
The "reprocessed" file contains the same data than the "original" one, except some data :

- Both files contain some "Metadata", but not with the same content
- The two waypoints "Start" and "End" are not at all in the reprocessed file
- The track type ("Bicicletta su strada") is not in the reprocessed file
- Extension data relative to Track and/or to TrackPoints are also missing in the reprocessed file

Surely, issue in basecamp cannot come from different metadata. But it could from any of the data that are missing in the reprocessed file.
So I only had remove all of them except one and see if file became readable by basecamp to determine which one was the cause of problem.

And the result is that basecamp fails when extension data relative to trackpoints are present, giving speed at each trackpoint.
These extensions are all in the form

Code Select Expand

<extensions>
<gpxtpx:TrackPointExtension>
<gpxtpx:speed>0.25</gpxtpx:speed>
</gpxtpx:TrackPointExtension>
</extensions>


If these data are not managed by Basecamp, they should be simply ignored, and not cause to fail.

Please note also that there are also extension data associated to the two waypoints that do not prevent loading by basecamp

Code Select Expand

<extensions>
<om:oruxmapsextensions>
<om:ext type="ICON" subtype="0">38</om:ext>
</om:oruxmapsextensions>
</extensions>


and also relative to track itself (that do not prevent loading as well)

Code Select Expand

<extensions>
<om:oruxmapsextensions>
<om:ext type="TYPE" subtype="0">8</om:ext>
<om:ext type="DIFFICULTY">0</om:ext>
</om:oruxmapsextensions>
</extensions>

Result of my analysis : GPX file generated by OM is perfect from formal standpoint, and it is Basecamp that contains a bug, preventing it to ignore some extension data


Finally, I did a last test : let extension data for trackpoints, but modify them to make them with same format than other (the ones accepted in basecamp) oruxmaps extension, ie. replace their definition with

Code Select Expand

<extensions>
<om:oruxmapsextensions>
<om:ext type="SPEED">0.25</om:ext>
</om:oruxmapsextensions>
</extensions>

In such a case, file becomes "loadable" by basecamp, even with extension data on trackpoints.

This means that basecamp is not "troubled" by the fact that there is extension data on trackpoint, but only if it is "gpxtpx" extension....

It would be a good idea to share with us
- the GPX file that Basecamp fails to load
- and its conversion you did (that Basecamp loads)

We (and Orux) could then compare both, trying to find what, present in the 1st one but not in the 2nd, could be problematic...

[the best choice to be used in OruxMaps]

I would be very very surprised that it may have a link with the fact that the map has been generated in 32 or in 64 bits in MOBAC. Once generated, the resulting map is no more "MOBAC dependent".
The most likely (from far IMHO) is that the map has not been correctly copied from MOBAC atlas folder to your smartphone.
Or that there were a problem during map generation in MOBAC, and the file(s) not correctly created by MOBAC.

First question : which atlas format did you choose for your map : OruxMaps sqlite, or MBTiles ?

If it is MBTiles (the best choice to be used in OruxMaps, according to Jose Vasquez (Orux) himself), the map is made of only one file, [name_of_the_map].mbtiles, that is a sqlite database.
You could try to open it with SQlite db browser (https://sqlitebrowser.org/). Does it open ?
If you still have it on MOBAC folder, does original file open ?

If you chose Oruxmaps Sqlite format, map is made of two files in a folder, one is a xml file, and the second a db file, that is also a sqlite db. Do you have the two files on your smartphone ? Does the xml file "looks like" xml file of another (working....) map ? (xml files can be open with any text editor)
And can you open the .db file with SQLiteDbBrowser (mentioned just before) ?
Same questions about original files in MOBAC folder if you still have them.

If you still have the map in Atlas directory of MOBAC, I would suggest to erase it from your smartphone, then copy it again from MOBAC to the smartphone.

And lastly, if you do not have it any more in MOBAC, or if you still have it but even there it is not OK with test mentioned above, try to re-generate it with MOBAC

What do you mean exactly when you write "when trying to reload maps" ?

You're right Orux!

Orux is ALWAYS right ! 

No, the "problem" is not linked to any Android limitation.
I have an quite old smartphone, with a old version of Android : v7, and limitations of android come only with more recent versions.

But whatever the selected folder is on the SD card or in internal memory, the oruxmapstracks.db is NOT stored in the selected folder. The "Route/Tracks drectory" selected in settings is ONLY used for exports of tracks and Routes.
Not for the "internal" database that remains always in the same place, whatever folder defined in settings.

This at least in v7.4.26

[always]

Maybe Juanjo's answer is correct in rev 9 (ie. GP version), I don't know, but in the "free" version 7.4.26, oruxmapstracks.db is always stored in oruxmaps/tracklogs directory in phone memory (and never on the SD card) whatever the folder defined in settings.

Hi Orux,

in order to be able to use it outside from OM app itself (and take advantage it is a sqlite db), it woud be great to have a technical description of the datamodel of OruxmapsTracks.db

Some of the tables / fields / relationship are quite "obvious", but not all of them.
So, rather than to "decrypt" it, with all associated risk of misunderstanding, it would be great to get an "official" technical description.

I guess that such a documentation already exist ? If yes, where could it be available ?

Thanks in advance

[et les jalons restent bien affichés sans tourner quand la carte tourne]

J'avais crus "sur parole" ta copie d'écran.... mais elle est fausse !
Je viens de faire un essai (certes en OM 7.4.26, ie. la version gratuite), et les jalons restent bien affichés sans tourner quand la carte tourne......

Donc ce que je t'avais dit deux posts plus haut est bel et bien vrai.

Sauf si ça a changé avec la version 9.4, ce qui m'étonnerait fort....

Ci dessous un jalon "Tourne à gauche" sur une carte tournée pour être mise dans le sens de la marche.
Le jalon lui même reste bien avec sa flèche vers la gauche...

En fait, ce à quoi je n'avais pas pensé, c'est que le dessin des jalons tourne avec la carte quand celle-ci tourne.

Mais cela dit, je ne comprends toujours pas pourquoi tu voudrais absolument que la flèche sur l'cône de jalon indique la direction sur la carte.
C'est important de savoir s'il s'agit d'un jalon "tourner à droite", "tourner à gauche", ou "aller tout droit". Le dessin du jalon lui-même...