Strava and Komoot can be used to plan bicycle trips and to record them. Both tools can be used for both purposes, but it seems that Strava is better for the recording and Komoot better for the planning. Btw. it works also for walking or running, for example. But I will stick with the bicycle as the main example…
Now the normal process is to plan a trip and then cycle it and it gets recorded. If you use wandrer.earth also and connect it to Strava, you will see a map of the aggregated routes that you have cycled and coverage of areas in % and stuff like that. Recording can also be done by a smart speedometer, which is again connected to Strava…
Now there are trips that have been performed in the past, where recording was not yet in place, but you want to have them in the collection as well.
In this case the process is slightly different. You have already cycled it long ago and then plan it in komoot to exactly match what you cycled. This can be difficult, because roads may no longer exist, have bicycle forbidden or Komoot just thinks so, even though it is not true. Or they have become forbidden after you cycled them. In all these cases Komoot will refuse the actual route. There are two approaches to solve this. Either you put „off grid“ intermediate points and mark the actual route. Or if it is still present, you can plan it with mymaps of google, export it as kmz-file, convert kmz to gpx (using some of the sites that offer such a conversion or a program) and then you can import the gpx to Komoot and still change the parts that Komoot thinks are allowed.
Then it will be possible to export the route as gpx, use https://gotoes.org/strava to import it to Strava and provide some additional information, mostly the actual date and speed. Or the rough date and speed, if you do not know it exactly and do not find that important. Please put lower speed in doubt, so you do not become a cheater for speed records of certain sections. And make sure you use the right unit for speed and to use „bike“ as elevation speed calculation parameter…
Now it turns out that there will be hundreds or thousands of trips. There will be multiday trips, which you might want to handle as separate trips that kind of belong together. Or because of ferries or reuse of sections already planned or complexity you might even want to split the day into several parts.
Now both Komoot and Strava allow to give their trips names.
For multiday trips, I have numbered them and 3 digits are still sufficient. So their name in both Komoot and Strava is something like
R
where
or for longer trips D01, D02, D03 or even D001, D002,…
Now if a route segment is used multiple times, in Komoot it will have a different name than in Strave, something like this:
S
where
If the Strava segment of a multiday trip is based on such a multiply used segment from komoot, it is named like this:
R
For one day trips, that consist of only one segment that is specific to it, the description looks like this (in Strava and Komoot):
T
where
For one day trips, that consist of only one segment that is multiply used, the description looks like this (in Strava and Komoot):
T
This case is quite unlikely to occur…
For one day trips, that consist of several segments, the description looks like this:
T
If it is based on a multiply used segment in Komoot, the S
To support hiking or running or others, I suggest to just add this „means of transport“ as a keyword to the descriptions, making bicycle the default, if that is most commonly used.
So using some pseudo data structure in the description fields will help being able to have useful searchability even when the number of trips gets to large to page through…
What we can learn from this: Whenever we have some amount of data in some software, it is good to think of how to organize it and how to be able to find and connect the data. Even if the tool is quite dumb in this aspect.
The primary example of such a (less dumb) software is of course the database, where we actually do exactly this in very sophisticated ways.
