Open hhornburg opened 3 years ago
QMS 1.16.0 Win 10 : looks like no gpx-Files were loaded as pois:
Hm, probably that's why the ticket is still open :thinking: :wink:
Just wanted to mention the difference to the screenshot in WIKI:
@wthaem think you have to update the Wiki. @pingurus do you plan to restart the PR in the near future?
@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.
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:
I might be restarting work on this soon. My thoughts so far:
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.
There are different possibilities on how to derive the internal category tree:
<sym>
and <type>
come to my mind for doing so.The gpx files would be directly displayed in the POI widget.
Do you have any preference for any of these approaches or a new approach?
I currently prefer 1a or 2.
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.
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.
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?
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:
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.
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
Additional context
As I think #294 is almost done, I think we can tackle another POI data type without causing too much headache.