GSoC 2024 Path Recorder: Phase 2 - Basic Track Recorder

[oleg-rswll]

Overview
Add recording functionality to the Trace Path feature.

Use Cases

• Save stats: A hiker goes on a hike and wants to record the trails they took, the amount of time it took, and elevation changes during that time. They start recording when at the beginning, and at the end stop the recording and that is when the track is saved to a list in Favorites.
• Share: A cyclist takes a certain bike trail and wants to share it with his friends. After recording and saving the track, he exports it and sends it, which can then be used in OM or other apps. An OSM contributor is mapping new ground to be contributed to the community. They record the track and export the file into OSM.
• Mark Locations Along Track: Record track and mark favorite places along the track.

Problem Statement
The absence of functionality to record means that people have to use other apps to record, and can only use Organic Maps to view paths/tracks. This severely limits the extent to which OM can be used, and requires many additional steps for importing.

Criteria
Initiating

• The 'Record Track' feature is initiated from the Main Menu, in place of the 'Trace Path' button.
• When the recording starts, change the icon to an icon that indicates recording is active and can be stopped. Show in red.
• When recording starts, a status bar displays on the main screen, at the top center, showing that recording is active. A Stop button is also shown.

In Progress

• When recording is in progress, display the path on the map as...
• The current path which is being recorded stands out compared to the existing paths which are displayed on the map.
• When pressing the Stop button, display a message asking "Do you want to stop recording now?" Buttons: 'Stop' and 'Continue'.

Saving Track

• To save a recorded path, when the stop button is pressed, displays a page:
  • A field for the name, with a pre populated name
  • A drop down list with a default Favorite List selected for where to save the path. The default can be a new List that is pre-created, called "Recorded Tracks". People can select a different List.
  • Buttons to Save and Cancel.

[rtsisyk]

There are at least 2 duplicating tickets:

#613
#2147

Please see Track Recording Track Recording

[oleg-rswll]

Thanks, I'll combine these 3 into one Issue.

[rtsisyk]

Thanks, I'll combine these 3 into one Issue.

Thanks! Gathering all the requi^Wwishes probably can be useful. We have a draft of the design and competitor analysis already in Figma.

[biodranik]

I propose to brainstorm how to seamlessly merge two features (recent track and active track recorder) into one, to make it simple for users, and for us.

For example:

• There is only one button to start "track recording and recent path" in settings, in menu or on the map
• When it is pressed, a recent track is displayed on the map, and the button changes to "stop recording and recent path" (exact naming is TBD).
• When "stop recording and recent path" is pressed, the path is no longer displayed on the map, and user has an opportunity to save the recorded track if necessary
• Track saving can be done at any moment by selecting the recent track on the map, and defining its start and end, if necessary (a whole recent track is selected by default, or the start point can be the end point of a previously saved track). User can drag start and end to define the necessary part of the recent path to save.

Any other ideas are welcome. IMO having two distinct features is more complicated than just one.

[kavikhalique]

• Track saving can be done at any moment by selecting the recent track on the map, and defining its start and end, if necessary (a whole recent track is selected by default, or the start point can be the end point of a previously saved track). User can drag start and end to define the necessary part of the recent path to save.

since this kind of recorder will only be showing last x hours track on map, what if the user want to save track before this duration which have been deleted from the map?

[biodranik]

since this kind of recorder will only be showing last x hours track on map, what if the user want to save track before this duration which have been deleted from the map?

It doesn't look like a significant issue to me. I see several options:

1. We leave it as is. If a user needs to save longer tracks, a longer period should be selected. It is more or less equal to explicitly starting the recording. Making the current saving interval clearer for users might mitigate this issue, e.g. we can print "last 10 hours" or the date/time of the first point of the track directly on the map (at the start, or along the line), together with the length of the recorded track. So users will always see it and will understand what they can save at any moment of time.
2. Always store internally the max possible length of data (all collected GPS data) without displaying it (display only what user has selected, to avoid polluting the map). When a track is selected to be saved, highlight previously saved parts too. The issue here is that not everything can be saved if a recent track was disabled before. But if it was disabled, then user explicitly made this decision, so it's not our problem.

Let's brainstorm on how to keep it simple, and easier to use compared to all other apps.

[biodranik]

An important moment about storing recorded tracks. In some cases, users may also add bookmarks not far from the current position, when the trip is recorded. It would be very convenient to store these bookmarks by default into the same list/KML file where the track is recorded.

[oleg-rswll]

@biodranik The scenario you describe sounds like a merging of Track Recorder and Recent Path, which would place the limitations of Recent Path on the Track Recorder. Recent path cuts off the path at the set number of hours, because it’s a rolling time period. While theoretically Track Recorder can go as long a person wants. Not clear why it would make sense to place a limitation on Track Recorder.

Also, it sounds like you are mentioning an editor for where to cut off the track, similar to how video editing can cut off video at beginning or end; this is a track recording feature, not really related to Recent Path. Also, this is more advanced functionality, would be lower priority at this point, can be added after core functionality is done.

Theoretically, to have only one feature, the Track Recorder feature can do the functionality of Recent Path, the person would record, but not save the track; in this case the Recent Path feature can be removed altogether.

[biodranik]

Theoretically, to have only one feature, the Track Recorder feature can do the functionality of Recent Path, the person would record, but not save the track; in this case the Recent Path feature can be removed altogether.

I like that idea, can you please elaborate?

[biodranik]

Historically, due to excessive battery usage, any track recording required explicit activation and deactivation. From my and our users experience, the current implementation of the recent track works more or less ok. You don't care and don't think about it. It just works. And when you suddenly need a map, there's already a track there, so you can solve your use-case easily. The desire to turn it off comes from the fact that it saves battery life, especially if you know that you don't move anywhere. But there's already a system API for such cases that will pause unnecessary location updates! (Another improvement would be to draw a recent track and many points at the same place in a bit cleaner/less intrusive way).

Other use-cases:

• A tourist comes back to the parked tourist bus.
• A tourist or local from another part of the town/city comes back to the bus or subway/train station.
• A person does walking/running/cycling fitness exercises and needs to track the time, distance and whatever else info (e.g. calories) either directly in OM or in some other app that can get track data from OM.
• A hiker or cycler or driver wants to check the traveled distance and time. And see elevation on the way.
• A solo, couple, or family makes a diary of their traveling and shares their experience immediately or later, after the trip. Total travel time and distance have an important value when shared with others on social networks or personal blogs.
• A boat travels on the river/lake/sea/ocean and should come back the same way or share the safe path with others.
• A trip organizer records the track to later add important notes, bookmarks, photos and share it with other trip participants.
• A local wants to build a travel guide in his city and record the best routes together with bookmarks to later share or sell.
• A delivery company wants to track the distance and optimize routes of their couriers.
• A privacy-friendly traffic database is built by OM users from recorded tracks.
• A traveler wants to automatically mark/track visited cities and countries to share in social networks and compete with his friends.

Note that many use cases also imply active bookmarking of the most important/interesting places nearby.

There are several key parts here:

1. Easy to use when track is recorded.
2. Easy to use when track is saved/organized/shared.
3. Very low battery use. As low as possible. If the battery is drained fast, nobody will use this feature for the second time. Note that there's already a battery-related setting in OM which we may later reuse to, for example, record only some points at lower intervals (if we prove that it will significantly save the battery).

[oleg-rswll]

Looks like all of these real-world scenarios will be covered by the 4 use cases at the top.

[oleg-rswll]

A number of the scenarios you mentioned are essentially activity recorders. For sports related activities, the word "Track" makes a lot of sense, especially as a noun, like a race track. For other scenarios like tours and travel, "Track" makes less sense. Maybe it's worth considering language that better works for all of those scenarios.

[biodranik]

We can only learn from our users. There is an option to make a list of proposed names and check how community reacts to it.

[oleg-rswll]

Surveying users is definitely good, we need to do that. Currently we don't have a process for that.

[oleg-rswll]

For the use case where multiple points are involved, what would be the reason to record a track rather than be able to save a multi-stop route?

[biodranik]

Which case do you have in mind? A multi stop route is ok if it's correct and there's underlying OSM map data. No map data means the only way is to record a track. Well, or save/export our ruler-based router :)

The real cases for that are the desert (there were several support letters from Arab countries), taiga, or other remote areas without any connection at all.

[oleg-rswll]

The challenge is that the people who currently use Recent Track, may not know that it's possible to use Track Recorder to accomplish what they want. So it would have to be obvious, and maybe do highlight of the different usages of the feature.

One way to combine features is to rename the feature so it's clearer about usage. For example instead of "Track Recorder" it can be "Path Recorder" as that would be good for sport activities, but also for travel/tourism.

Also, at the end when there is the option of how to save the Track/Path, it's important how this is communicated, a design is needed for this.

[biodranik]

The "path" may not be understood well by cyclists and car drivers. This is a great UX question: how to implement an easy track recording and saving without an explicit button ) CC @euf

[oleg-rswll]

"Path" is quite a generalized word, it applies to "bike path", or the way forward, for example “career path”, and it’s associated with “Route” and “Road”. “Track” is definitely a more narrow definition.

[biodranik]

The name of the universal feature should be very familiar and recognizable to those who know it already (e.g. under the "Record track" name) and to new users, who don't know it at all.

If there is no any option in settings, then the name won't be visible anywhere except the news/features list in the app store, right?

[biodranik]

What if we always record everything and show all passed paths on the map by default, when a setting is enabled, and offer an easy way to remove/delete/organize/rename/share only important parts of the recorded paths/tracks?

Then the only action that the user needs to do is to enable this feature in settings or disable it if it's not needed.

It requires some ideas on how to better work/organize the recorded information, any ideas on that?

[oleg-rswll]

Isn't the problem with recording everything is that the battery is drained too fast?

Recorded tracks will go into a pre-created default List in Favorites (Bookmarks and Tracks), called something like "Recorded Tracks", and user can organize the recordings as they want.

[oleg-rswll]

About the new feature which we have been discussing in this Issue, so far we have been referring to it as a "Track Recorder". Since this feature is new, it can be named to whatever is the best description and most understandable for a broad audience.

A few ideas:

• Path Recorder
• Route Recorder
• Track Recorder
• Activity Recorder

Since it is intended to be turned on/off as needed, and it's not going to be used as often as other features, such a traveling a route, the idea is that it will be in the Main Menu (and definitely not in Settings).

[biodranik]

Note: GPS is updated anyway if navigation is active in the foreground or in the background, or if a user keeps the app on the screen in another mode and follows the position.

It may be useful to record the path anyway in these modes, even without asking anything or enabling anything. Or offer to enable recording at these moments.

[Misalf-git]

It may be useful to record the path anyway in these modes, even without asking anything or enabling anything. Or offer to enable recording at these moments.

I might not want to let everyone who gets hands on my phone to know where I have been.

Say one uses a wifi or bluetooth triggered garage opener app, installs Organic Maps, then looses phone on a walk.

Or the Cops asking: "have you been at that demonstration for freedom and peace?"
Me: "I know you'll gonna beat the shit out of me if I say yes. So... No, I wasn't."
Cops: "Gimme your phone!"

[oleg-rswll]

Definitely not a great idea to record without user specifically enabling a feature.

[oleg-rswll]

A significant point still needs to be addressed - combining Recent Path and Track Recorder, or keeping the features separate. To use Path Recorder as Recent Path, there would need to be functionality to use the recorded track like a Route. This would be useful, although probably beyond the scope of this project.

For the scope of this project it seems to make sense to keep the features separate.

@biodranik

[biodranik]

Please read my comments in the related issue: #8214 (comment)

[RedAuburn]

not urgent, but instead of the notification text "recording your traversed tracks in the background", the text "logging your travels in the background" may be nicer