Read GPX files as POIs

[hhornburg]

Important Notice:

Do not delete any of the sections. Read what is requested. Replace(!) the instructions by your answer(!). Feature requests reports that are not properly filed might be closed without further notice.

Choose a good title

What is a good title? The title will be listed in the changelog when the issue is fixed. Do you think someone else would understand what's fixed or done from your title? Does it really name the real topic of the issue?

Is your feature request related to a problem? Please describe.

I would love to load thousands of geocaches without having to wait unnecessarily long. It makes no sense to load them into the workspace, as an enumeration of all the geocaches only will clutter the workspace.

Other use-cases are possible where one has much data in GPX format and only needs it read-only with the possibility to copy it to the workspace.

Describe the solution you'd like

Handle them just as the *.poi files.

Describe alternatives you've considered

Do nothing :wink:

Give a reason why someone else should spend time on that request

1. I'll implement it myself
2. There is a more or less frequent complaint that loading enormous amounts of data takes long. There would be a response to this complaint other than "Stop using QMS in a way that it was not intended for"

Additional context

As I think #294 is almost done, I think we can tackle another POI data type without causing too much headache.

[flock-vi]

QMS 1.16.0 Win 10 : looks like no gpx-Files were loaded as pois:

[kiozen]

Hm, probably that's why the ticket is still open :thinking: :wink:

[flock-vi]

Just wanted to mention the difference to the screenshot in WIKI:

[kiozen]

@wthaem think you have to update the Wiki. @pingurus do you plan to restart the PR in the near future?

[wthaem]

@kiozen, @pingurus: I wasn't aware that this nice feature didn't reach the dev/release version. I'll remove its description as soon as its future is clarified.

[hhornburg]

I'd love to restart it, but I'm not sure when I'll find the time. I guess that's only a maybe for the near future, but the next winter will come for sure :wink:

[hhornburg]

I might be restarting work on this soon. My thoughts so far:

Approach 1: Convert gpx file to SQLite database:

I would code a page similar to the VRT builder to enable the user to convert gpx files to a SQLite database that then can be used for POIs. I would simply dump the <wpt> objects into the sqlite file as string so it can be fully reconstructed when copied to the workspace.

• Upsides:
  • probably faster loading times as not the complete file has to be indexed again and again
  • The databases that currently are supported are SQLite files, so there might be more code reuse in the part in which a good performance is needed.
• Downside:
  • setup step needed

There are different possibilities on how to derive the internal category tree:

1a: Categories by folders

• The category tree equals to the tree in which the gpx files are located.
• Upsides:
  • maximal flexibility in defining the category tree
  • simple category coding
• Downsides:
  • User has to possibly first split his gpx file to match a tree structure, however this is doable with QMS

1b: Categories by gpx tags

• The code automagically derives the categories from the gpx tags. <sym> and <type> come to my mind for doing so.
• Upsides:
  • single step for user
• Downsides:
  • categories might not be that useful
  • less flexibility for user

Approach 2: Read gpx file directly

The gpx files would be directly displayed in the POI widget.

• Upsides:
  • large flexibility for user (quickly add and remove data)
• Downsides:
  • categories can only be derived from gpx tags, however as above the user can always split gpx files according to taste
  • probably slower as files have to be indexed

---

Do you have any preference for any of these approaches or a new approach?

I currently prefer 1a or 2.

[kiozen]

I would prefer a tool that converts gpx files into POI files. By that we do not have to duplicate any code regarding POI files. The POI builder can be a bit more sophisticated if well documented in the dialogs and tool tips.

[hhornburg]

There has to be some sort of code "duplication" regarding the choosing of the symbol of a poi, as that will be derived from <sym> for a gpx file and for the currently supported files it is done by some lookup table magic.

Also the process to convert a poi to a waypoint can't be the same: In a gpx file there is already a waypoint saved that we want to restore, whilst there are only some data key/value combinations in the currently supported files.

The only way to remove all code duplication in the reading of the files would be to convert the currently supported files as well, which would lead to even more code in turn. However adding more supported file types would then be easier, as there would be a defined scheme to which a file has to be converted and no changes would need to be made to the code that reads the files.

[kiozen]

Sorry, I do not get that :smile. If the GPX would be converted into a POI database as we already support there shouldn't be a change to the POI related code. There would be only additional code to create the POI file from the gpx. Or do I miss the obvious?

[hhornburg]

We could create a sqlite file that has exactly the same tables and columns. In that case we would have to put the xml of the waypoint into the data column which in the currently supported files holds a list of osm key-value pairs. The contents of that data column would have to be processed differently depending on the source of the file (osm/gpx), requiring detection of the file source and code "duplication" for symbol choosing and transforming a poi into a wpt.

Hope that clarifies it a bit :smile:

[wthaem]

And there is more:

The POI files have a more or less unique OSM-based data structure. Looking at different GPX files with waypoints/POI (like bettundbike or huettenliste and others) makes clear that the GPX data structures can be rather different and a mapping of these different GPX structures to a unique reasonable POI-file structure would need some file-specific settings. Attaching the different GPX waypoint structures (the "xml of the waypoint") to a QMS POI could be much easier and would even avoid the creation of additional (POI) files.