Discussion: Route Storing

cevi / automatic_walk-time_tables

Automatically creates a walk-time table from an exported track from Swisstopo-App, SchweizMobil, or from an arbitrary GPX-file

http://map.cevi.tools

GNU Affero General Public License v3.0

16 stars 4 forks source link

Discussion: Route Storing #458

Open maede97 opened 1 month ago

maede97 commented 1 month ago

This issue should help us track several possibilities on how to tackle route storing (#457 )

Idea 1: Docker container with (mongo?) db and one with a simple API to store & retrieve routes & settings and https://github.com/mongo-express/mongo-express for viewing (on local-dev only)
Idea 2: firebase

wp99cp commented 1 month ago

The big question is, what kind of data do we need to store?

Data That Needs to be Stored:

[x] some id or hash that indicates the route --> can then be used to retrieve the data via URL (UUID?)
[ ] encoded path (string)
[ ] encoded waypoints (string)
[ ] additional metadata per waypoint (to be future-proven, e.g., duration of a break at that waypoint, colour, etc.)
[x] creation and modification date
[x] all fields from the form (created by, map scale, etc.)

wp99cp commented 1 month ago

I would argue against using Firebase; it's a nice solution and would (potentially) fit our use case; however, setting up a local dev system is a pain... Also, for automated testing, it is not ideal.

maede97 commented 1 month ago

then, I propose something like "https://map.cevi.tools/recreate/UUID" which will recreate the export and create a new zip or, for QR codes: "https://map.cevi.tools/gpx/UUID".

maede97 commented 1 month ago

I would tend to use the same UUID we already use to get states and logs. This makes it much easier to generate the buttons for sharing in the frontend (and generating the QR code)