rilling/opentracks-winter-soen-6431_2024

OpenTracks is a sport tracking application that completely respects your privacy. SOEN 6431

OpenTracks: a sport tracker

OpenTracks is a sport tracking application that completely respects your privacy.

Free (F-Droid)	Free (Nightly for F-Droid)	Donations

Translations are hosted on hosted.weblate.org.

Screenshots

Features

• Tracking: track your sport and outdoor activities

• Voice announcements

• Photos and Markers: mark interesting locations while tracking

• Export:

  • export tracks either as KMZ 2.3 (incl. photos), KML 2.3, or GPX 1.1
  • export automatically after each recording (e.g., to sync via Nextcloud)
  • avoid duplication: each exported file contain a random unique identifier (i.e., opentracks:trackid)

• Altitude:

  • gain/loss via barometric sensor (if present)
  • shown in EGM2008 (above mean sea level); exported as WGS84

• Bluetooth LE sensors:

  • heart rate
  • cycling: speed and distance
  • cycling: cadence
  • cycling: power meter
  • running: speed and cadence
  • support for BLE sensor training only (i.e., without GPS) for indoor training

  An overview of tested sensors: README_TESTED_SENSORS.md

Gadgetbridge integration

OpenTracks can be used with Gadgetbridge:

• shows statistics via notification on smart watches (requires Gadgetbridge 0.56.1 or later), and
• Gadgetbridge's GPX exporter generates opentracks:trackid to avoid duplication (Gadgetbridge 0.53.0 or later).

Privacy

• No Internet access: Internet is not used
• No advertising
• No in-app analytics
• No use of Google Play Services

Only required permissions:

• ACCESS_FINE_LOCATION: required to use the GPS.
• ACCESS_BACKGROUND_LOCATION: required to start recording with GPS while phone is in standby. (e.g. when triggered by Public API from an external device)

Public API

OpenTracks includes an API for starting/stopping recording by another installed application (e.g., Automate, Tasker, or Easer). The API can be invoked by sending an explicit Intent to start an activity.

Package (depends on the variant installed):

• F-Droid: de.dennisguse.opentracks
• GooglePlay: de.dennisguse.opentracks.playStore
• Debug: de.dennisguse.opentracks.debug
• Nightly: de.dennisguse.opentracks.nightly

Class:

• Start a recording: de.dennisguse.opentracks.publicapi.StartRecording
• Stop a recording: de.dennisguse.opentracks.publicapi.StopRecording

For testing via adb: adb shell am start -e someParameter someValue -n "package/class"

StartRecording supports the following parameters:

• Set track data: TRACK_NAME, TRACK_DESCRIPTION, TRACK_CATEGORY, and TRACK_ICON (non-localized identifier see /src/main/java/de/dennisguse/opentracks/util/TrackIconUtils.java#L38). NOTE: if TRACK_ICON is not present, TRACK_CATEGORY will be used to determine the icon (localized).
• Send recorded data to another application via Dashboard API: STATS_TARGET_PACKAGE and STATS_TARGET_CLASS

The Public API is disabled by default to protect the user's privacy, but it can easily be enabled in the settings.

File formats compatibility with open-source software

	GPX 1.1	KML 2.3	KMZ 2.3
OpenLayers 7.1.0	?	no	no
Golden Cheetah 3.5	?	no	no
GpxPod	?	?	?
OsmAnd	?	no	no
FitTrackee	yes	n/a	n/a
SportsTracker	yes, single tracks only	no	no

Dashboard API (incl. map)

As of v3.3.1, OpenTracks supports custom dashboards for displaying previously recorded and live tracks.

The reference implementation is OSMDashboard, which presents an OpenStreetMap map (showing the current track, incl. updates). The Dashboard API is also used by Gadgetbridge for displaying live track statistics on supported wearables.

Alternatively, recorded tracks can be shared as KMZ/GPX with installed applications ( e.g., OsmAnd). However, this is rather slow and does not provide updates while recording.

The developer documentation is in README_API.md.

Project history

OpenTracks is based upon Google My Tracks app (code). My Tracks was initially released by Google in 2010 as open-source software. In 2016, Google decided to discontinue My Tracks and stopped distributing it via the Google Play store in April 2016. Then Plonk42 conducted some maintenance work until 2016, so My Tracks could still be used (based upon version Google's MyTracks version 2.0.6). Plonk42's version is available here. In 2019, OpenTracks was forked from Plonk42's My Tracks and major rework was conducted.

Rework of OpenTracks included:

• removing Google's analytics code,
• removing integration into Google Drive,
• removing Google Maps integration,
• removing Google Earth integration,
• removing use of Google Play service,
• removing calorie estimation and activity estimation,
• removing support for ANT+ and Classic Bluetooth,
• adding support for Bluetooth LE heart rate sensors,
• removing Protobuf (store sensor data in SQLite columns directly), and
• removing Android Service API for other apps.

Artwork, logos and user interface remained more or less unchanged.

More information about Google My Tracks:

• Wikipedia page
• Google code archive

opentracks-winter-soen-6431_2024's Issues

Add Selection and Validate Date and Month for Default Start Date of Ski Season

Describe briefly your feature.
The feature entails giving an application the ability to choose and verify the default start date of the ski season. The start date of the ski season can be set by users, and the system will confirm that the date chosen is valid and is within acceptable ranges. By giving users the option to alter the start date of the ski season to suit their tastes, this feature seeks to improve the application while guaranteeing that the chosen date satisfies the requirements for a successful start to the season.

Describe the solution you'd like
Validate the selected date to ensure it falls within an acceptable range.
Provide feedback to users if the selected date is invalid, guiding them to choose a valid date.
Ensure that the selected date is stored accurately in the system for further processing and reference.

To select the start date, users ought to be able to work with a date picker and there would not be year selection in the date picker.
The chosen date should be instantly or immediately after the submission is validated by the system.
The user should see the relevant error messages or notifications if the specified date is invalid.
Once the date has been successfully selected and validated, it should be accurately preserved for later use.

Describe alternatives you've considered
Localization: Support for different date formats and languages may be necessary for international users.
Testing: Thoroughly test the date selection and validation functionality to catch any edge cases or bugs.
Documentation: Update system documentation to reflect the new functionality, including instructions for users on how to select the start date of the ski season.
Allow users to sync the ski season start date with their external calendars (e.g., Google Calendar, Outlook).
This approach leverages existing calendar applications that users are familiar with, potentially enhancing usability and convenience.

Additional context
Consider the overall user experience and usability of the feature, including the interface design.
Aim to create a seamless and intuitive experience for users when selecting or updating the start date of the ski season.

Classes that need to be changed
UI Component
Data Validation Logic -
Configuration or Setting - settings_default.xml

Setting Ski Profile - Type of Skiing Datapoint

Describe briefly your feature.
The issue is that currently there is no dedicated subsection in the settings page for managing ski profile information, such as the type of skiing and others.

Describe the solution you'd like
The solution is to create a new page within the settings menu specifically for Ski Profile. Within this, an input field named as Type of Skiing will be added in the dropdown format which takes values -Downhill, Touring, and Snowpark.

The users should be able to easily view and edit their preferred type of skiing.

Also to ensure that this information is accessible through appropriate class/public functions and remain consistent.

Total # of days feature

Describe briefly your feature

The proposed feature aims to add functionality to OpenTracks that allows users to track the total number of days a chair lift has been used during a given skiing season. This will provide valuable insights into chair lift usage patterns and help users understand their skiing habits better.

Describe the solution you'd like
Total Chair Lift Usage Tracking
The solution involves automatically detecting and recording a day when a chair lift has been used for skiing activity, marking it as a "Days" within the app. This detection could be based on user activity within the app (e.g., starting and stopping recordings while using chair lifts). At the end of the season, the app will tally and display the total number of chair lift usage days accumulated. It is important to note that this feature presents a dependency with groups 4, 5, and 6 as they are the ones who calculate the statistics for chair lifts.

Describe alternatives you've considered

As an alternative, in case of difficulties with automatic detection, a manual entry system could be implemented. Users would have the option to mark a day as a chair lift usage day within the app when they have used chair lifts for skiing. While this method relies on user input and may not be as seamless or accurate as automatic detection, it ensures that the functionality can still be provided even with technical limitations. Manual entry could also serve as a supplementary feature, allowing users to correct or add to the automatically detected chair lift usage days.

Additional context
This feature can be used by the ski resorts for chair lift maintenance purposes. They could do a statistical analysis and know when to maintain their chairlifts in advance based on historic data.

Profile Settings: Allow users to view and update profile picture

Describe briefly your feature.
This feature adds a new profile picture data field to the Profile settings of the user. This would allow the identification of the user in future social interaction features and let the user have a sense of identity in the app.

Describe the solution you'd like

• Add a new profile picture field in the Settings > Profile screen.
• The profile picture field should contain one primary, circular image as the current profile picture of the user. If the user hasn't set a profile picture then a default image should be displayed.
• If the user clicks on the picture, an image picker should be displayed, allowing the user to select a profile picture. Once the process is completed, the new profile picture should replace the previous one.
• The profile picture should be stored locally as a bitmap instead of on a server. This should be retrieved easily for future usage via a public function.

Describe alternatives you've considered

• We can store the image on a server, which would complicate the implementation so I won't implement it.

Additional context
N/A

Rename this field "ON_IDLE" to "onIdle" match the regular expression ^[a-z][a-zA-Z0-9]*.

The field "ON_IDLE" was renamed to "onIdle" to adhere to Java naming conventions, starting with a lowercase letter followed by alphanumeric characters, improving code readability and maintainability.

Settings - Ski Profile - Adding sharpening info

Describe briefly your feature.
-Create a Ski Profile option under the Settings, then add sharpening info as a subsection to allow users to specify the sharpening interval for the edges (in km), this functionality should become the default option.
-The base and edge angle being used from 0 to 4 degree and the intervals should be 0.5 degrees.
-Also include the date of last sharpening.

Describe the solution you'd like
After user tap on settings option, ski profile will show up in the screen. Tap on ski profile to see several subsections. If users want to edit sharpening information they will see sharpening info as one of the subsections. Then they can specify sharpening interval, change the base and edge angle and also the date of last sharpening.

Describe alternatives you've considered
The feature will be implemented by adding a new window which redirect users to sharpening info page and allow they to make changes regarding their sharpening interval, angle and the date.

Additional context
User input should be only numerics and error messages will prompt out if they are trying to input letters or symbols. Also in the angle option certain degrees will be given so users are only allowed to choose from one of the options. Additionally, specific date format will be given.

Statistics (aggregate per day (ski/chairlift) - Total Waiting Time for Chairlifts)

Describe briefly your feature.
This feature is to design and implement a UI element for displaying the total time spent waiting for chairlifts throughout the day. It depends on the functionality developed by Groups# 4 - 6, related issue link #123.

Describe the solution you'd like
Members of Groups # 4-6 will work on the methods for creating the statistics(service functions, Ski statistics) and provide a function for the total waiting time. Once this method is created, the code to find the aggregate data per day can be added which will in turn be used by the XML file which can be modified with the required attributes to display the required statistics.

Describe alternatives you've considered
If the previously mentioned method fails, an alternative approach could involve allowing users to manually input the total waiting time. However, relying on this data may be unreliable due to its potential inaccuracies.

Additional context

Settings (Voice Announcements) - Announce Max Speed at End of Each Run

Feature Description
At the end of each run, a voice announcement can be made to inform the user about the maximum speed of the recording if the user has enabled the feature.

Solution Description
A button should be available in the settings menu for voice announcements to enable the feature. Once enabled, the voice announcement should announce the maximum speed at the end of the run.

Alternatives
The button might also be available for setting at the end of the run page.

Statistics (service functions, Ski statistics) - Speed of the chairlift

Describe briefly your feature.
Service function to calculate the speed of the chairlift

Describe the solution you'd like
Calculate the speed of each chairlift.

Additional context
This feature can allow users to see at what speed they can move through the chairlifts.

Profile Settings: Create a new Profile menu item in settings and open new screen accordingly

Describe briefly your feature.
This is the foundation work for the Settings > Profile epic feature. The feature will implement a screen for users to manage all the settings for their Profile.

Describe the solution you'd like

• Firstly, I'll add one item to the list under the Settings screen called Profile.
• Secondly, I need to implement the new fragment for displaying the Profile settings page. For the purpose of this issue, the screen can be just blank.
• Finally, I will implement the necessary navigational logic so that clicking on the item would open a new Fragment screen for the Profile settings.
• Validation logic: None

Describe alternatives you've considered

• We can access the Profile settings by making a dedicated item under the hamburger menu. However, putting it there would cause the settings to be fragmented and not good for user experience as well as future maintenance tasks.
• We can also display the Profile settings in a dialog after pressing the menu item. This is only acceptable if there's only 1 or 2 items. However, we have 8 fields so I don't go with this solution.

Additional context
Suggested location of the item on the list:

Statistics (service functions, ski statistics) Feature Request: Calculate Elevation for OpenTracks App

Describe briefly your feature.
Enhance the OpenTracks app by implementing a feature to calculate and display elevation data for each ski run. This addition will provide users with essential information for performance tracking and analysis on the OSM Dashboard.

Describe the solution you'd like
Introduce a function within the app to calculate elevation data. This data will be utilized to compute and present the elevation profile of each ski run accurately. The app will ensure accuracy in mountainous areas by incorporating GPS data. Moreover, it will adhere to the app's offline capability and privacy-centric design principles.

Additional context
Elevation data plays a vital role in assessing skiing performance and optimizing training strategies. By integrating this feature, users will have access to comprehensive session summaries on the OSM Dashboard, enriching their experience and facilitating progress tracking.

Statistics - Showing Total Number of Ski Sharpening/Waxing

Describe briefly your feature.
We propose a feature within our Ski Application that will display the total number of maintenance activities performed on a Ski. This will help the user to get an immediate overview on the maintenances performed.

Describe the solution you'd like

• Create a statistics subsection under the info section for Ski Profile.
• This will display the number of maintenance activities performed on the ski.
• The display will have the option to view stats based on types of maintenance activity or the time period.

Describe alternatives you've considered
Alternatively, we could've displayed in-depth details of each and every maintenance activity, like time, type etc. However, it does not add much value to the product and may make affect the user experience negatively.

Additional context
A graph can be added to the screen which shows the maintenance based on the dates to get a more detailed view as to when the most maintenance is required during a season.

Creating a field to add, edit, save and Validate Weight in the Profile section

Describe briefly your feature:
This feature enables users to view their weight profile information, specifically their weight, in either pounds (imperial) or kilograms (metric) units. The displayed unit will automatically adjust based on the default unit settings within the app (Settings -> Default Units).

Describe the solution you'd like:
The app retrieves weight data and stores it along with a unit preference (pounds or kilograms) after validating whether the given value is greater than zero. The unit preference is pulled from the default unit setting. Based on this preference, the app converts the weight data and provides a rounded-off display. For instance, if weight is stored in kilograms and the default or selected unit is pounds, the app will convert kilograms to pounds before displaying it on the profile.

Describe alternatives you've considered:
Manual Conversion: Users could manually convert their weight to the required unit before inputting it into the application. However, this might lead to errors.
Separate Versions: Another option is to create separate versions of the application for pounds and kilograms, but this could be less convenient for users.

Additional Context:
Accurate weight input is crucial for optimizing ski performance, including stability and maneuverability. The feature prioritizes user convenience and integrates with their preferences.

Statistics (service functions, Ski statistics) - Waiting time at the chairlift

Describe briefly your feature.
This feature aims to develop and implement service functions for ski runs to accurately identify the waiting time at chairlifts.

Describe the solution you'd like

• Identify ski runs and define service functions for each run, including the start and end points.
• Implement logic to detect the end of a run, marked by a sustained elevation threshold followed by an elevation increase at a constant speed.

Describe alternatives you've considered

Additional context
This feature is crucial for enhancing the overall user experience and providing users with reliable data for analyzing their skiing sessions.

Statistics (service functions, Ski statistics) - Identify when a user is waiting at a chairlift (waiting times)

Description:
This feature aims to accurately identify when a user is waiting at a chairlift during a skiing session. The ability to track waiting times at chairlifts is essential for providing comprehensive statistics and insights into the user's skiing experience.

Solution:

• We solve this issue by calculating if the user is stationary or moving very slowly near the minimum altitude point. when this continous for about 5 trackpoints we start adding the passed duration in totalChairliftWaitTime until the altitude begins to rise continously again.
• We apply this solution in TrackStatisticsUpdater.java to check the conditions and increment a counter in TrackStatistics. Once this counter hits 5 we start adding the passed duration while user is near the position or slightly moving to the variable totalChairliftWaitingTime in TrackStatistics.
• Developers can fetch this information from the method de.dennisguse.opentracks.stats.TrackStatistics#getTotalChairliftWaitingTime().

Describe alternatives you've considered:
Utilizing elevation data and GPS data to calculate the proximity to the ground level or the level at which user started the skiing recorder in OpenTracks and calculate the time spent at that elevation continuously before the elevation rises[at the user will enter the chairlift].

Additional context:
Integration with the elevation change detection algorithm used for identifying chairlift entry in Issue #61 could provide valuable insights into waiting time for chairlift usage. Collaborating with ski resorts or lift operators to access real-time data on chairlift status and usage patterns could enhance the accuracy of waiting time detection and help predicting what can be done to improve the waiting time.

Rejected Solution
We propose implementing a waiting time detection algorithm based on elevation data and chairlift-entering data, calculated as part of Issue #61.
We can calculate the total time waiting for chairlift as the continuous time elapsed while waiting at the same elevation at which the user enter the chairlift.

Statistics - Aggregate Per Day (Ski/ChairLift) - Shortest Wait at Ski Chairlift

Brief Description:
This feature aims to introduce a UI component for displaying the shortest wait time at the ski chairlift, aggregated per day.

Proposed Solution:
Team members from Groups # 4-6 will focus on developing methods for generating statistics (e.g., service functions, Ski statistics). Once these methods are established, additional code can be integrated to compute aggregate data per day. The computed data will then be utilized by an XML file, which can be configured with the necessary attributes to showcase the shortest wait time at the ski chairlift.

Alternative Considerations:
Should the initially proposed method prove ineffective, an alternative approach involves allowing users to manually input wait times at the ski chairlift. However, this method may be less reliable due to potential inaccuracies in user-provided data.

Additional Context:

Statistics - Aggregate Per Day (Ski/ChairLift) - Longest Wait at Ski Chairlift

Description:
This feature is aimed at implementing a UI component to showcase the longest wait time at the ski chairlift, aggregated daily.

Proposed Solution:
Groups # 4-6 concentrates on developing methods for generating statistics (e.g., service functions, Ski statistics). Once these methods are established, additional code can be integrated to compute aggregate data per day. The computed data will then be utilized by an XML file, configurable with necessary attributes to present the longest wait time at the ski chairlift.

Alternative Considerations:
If the initial approach proves ineffective, an alternative involves enabling users to manually input wait times at the ski chairlift. However, this method may be less reliable due to potential inaccuracies in user-provided data.

Additional Context:

Settings (Voice Announcements) - Announce Average Speed at End of Recording

Feature Description

Under "Statistics Announcements" in the settings, an option will be added to announce the average speed at the end of the recording.
This feature enhances the user experience by providing real-time feedback on performance metrics without needing to check the app interface constantly.

Solution Description

A toggle button will be used to check whether or not a user wants to hear their average speed at the end of the recording.

Alternatives

A radio button might be used to bulk enable/disable statistics that can be grouped together and announced at the end of the recording.

Additional context

N/A

Statistics- Aggregate Per Day (Ski/ChairLift)- Average Speed (Kilometre per hour) at Ski Chairlift

Describe briefly your feature.
This feature aimed at implementing a UI component to showcase the average speed at chairlift, aggregated daily. It depends on the functionality developed by Groups# 4 - 6, related issue link #55.

Describe the solution you'd like
Members of Groups # 4-6 will work on the methods for creating the statistics(service functions, Ski statistics) and provide a function for the average speed (Km/h). Once these methods are established, additional code can be integrated to compute aggregate data per day. The computed data will then be utilized by an XML file, configurable with necessary attributes to present the average speed (km/h) at the ski chairlift.

Describe alternatives you've considered
Should the initially proposed method prove ineffective, an alternative approach involves allowing users to manually input average speed (km/h) at the ski chairlift. However, this method may be less reliable due to potential inaccuracies in user-provided data.

Additional context

Creating a field to add, edit, save and validate Height in the Profile section

Describe briefly your feature.
This feature allows you to view your ski profile information, specifically your height, in either feet and inches (imperial) or meters (metric) units. The displayed unit will automatically adjust based on your default unit settings within the app (Settings -> Default Units)

Describe the solution you'd like
The app retrieves your height data and stores it along with a unit preference (feet/inches or meters) after validating whether the given value is greater than zero. The unit preference is pulled from your default unit setting. Based on this preference, the app converts the height data and gives you a round-off for display.
For example, if your height is stored in meters and your default or selected unit is feet/inches, the app will convert the meters to feet and inches before displaying it on your profile.

Describe alternatives you've considered
Manually entering your height in both feet/inches and meters: This would require you to update your profile twice whenever you want to see your height in a different unit system. Not very user-friendly.
Fixed unit display: The app could always display height in just one unit system (feet/inches or meters). This wouldn't be ideal for users who prefer the other system.

Additional context
This feature ensures a personalized user experience by allowing users to view their height in their preferred unit system.
Consider future features: The ability to handle unit preferences could be valuable for future features that might involve other measurements.

Persist data locally on mobile device for default start date of Ski season

Describe briefly your feature.
The feature involves the ability to persist data locally on a mobile device for the default start date of the ski season. This feature would allow users to store and retrieve the default start date of the ski season on their device, even when they are offline or do not have an internet connection.

Describe the solution you'd like
This solution involves implementing a data storage mechanism, such as a local database, and a repository class to handle storage and retrieval operations. The solution should also handle offline access by using the locally stored date and provide the option for synchronization with a remote server when an internet connection is available. Integration with the app's user interface layer, thorough testing, documentation, and ongoing maintenance are also desired.

Describe alternatives you've considered
One alternative solution to persist the default start date of the ski season locally on a mobile device is to use shared preferences or a simple file-based storage system instead of a local database. This could be a more lightweight approach, especially if the data structure is relatively simple and doesn't require complex querying or relational capabilities.
Additionally, an alternative solution could be to implement a background sync mechanism that periodically checks for updates to the default start date and stores it locally on the device. This way, the locally stored date stays up-to-date even when the app is offline, and any modifications made on the server are reflected in the local storage upon synchronization.

Additional context
The methods getSkiSeasonStartDate() src/main/java/de/dennisguse/opentracks/settings/PreferencesUtils.java allows you to access .

Statistics (service functions, Ski statistics) - Identify when a user enters a chairlift

Description
This feature can accurately detect when a user enters a chairlift during a skiing session. This functionality is crucial for providing detailed activity tracking and statistics related to chairlift usage.

Solution
we employ a threshold value, denoting when elevation remains constant for a predefined duration. Once this threshold is met, and elevation subsequently increases at a consistent pace, it signifies the user's entry onto the chairlift. pinpointing the exact moment just before the elevation begins to rise enables accurate determination of chairlift entry time.

Describe alternatives you've considered:

• The period between meeting the threshold and the onset of elevation increase constitutes the time of chairlift entry.

Additional context
We can use the track point and pervious track points in order to determine the elevation changes, which could help in indication that a user entered a chairlift.

Statistics (service functions, Ski statistics)- Calculate average speed

Description of the feature
Calculate average Speed based on the data.
Adding a feature to calculate a skier's average speed during their runs, enhancing the OpenTracks app with vital stats for performance tracking

Describe the solution you'd like
Create a function to calculate Average speed. This data will be provided for the OSM Dashboard.
The app will use GPS data to calculate and display the average speed for each ski run, excluding inactive periods, and present this in the session summary.

Describe alternatives you've considered
We've considered manual time entry for start/stop runs and using accelerometer data as alternatives to GPS.

Additional context
Accuracy in mountainous areas is crucial; hence, the feature will include GPS data smoothing techniques and comply with the app's offline, privacy-centric design.

Statistics (aggregate per day (ski/chairlift) - Total Skied km

Describe briefly your feature.
This feature is used to implement UI element to display total skied kilometers aggregated per day. It depends on the functionality developed by Groups# 4 - 6, related issue link #59.

Describe the solution you'd like
Group number # 4-6 works on the methods for creating the statistics(service functions, Ski statistics) and this function is provides with the total skied km. Once this method is created, the code to find the aggregate data per day can be added which will in turn be used by the xml file which can be modified with required attributes to display the Total skied kilometers .

Describe alternatives you've considered
When aforementioned method doesn't work then there can be one alternative like user can manually add total skied km and with the help of that data i can aggregate total kilometers per day but this is not a trustworthy as this data is inaccurate.

Additional context

Statistics (service functions, Ski statistics) - Calculate maximum speed per run

Feature Description:

We need to add a new ski-related statistics service that calculates the maximum speed achieved by a skier during a single run. This service will be part of a broader set of statistics functions aimed at providing comprehensive insights into skiing activities. This feature is closely related to other statistics services, such as average speed calculation and distance skied, as it contributes to a holistic understanding of skiers' performance and experiences on the slopes.

Solution Description:

1. Implement a function that identifies the start and end of a ski run based on predefined criteria, such as significant changes in elevation and speed patterns.
2. During each identified run, track the skier's speed continuously.
3. Calculate and record the maximum speed achieved by the skier during each run.
4. Store this information along with other relevant statistics, associating it with a unique session ID to facilitate data organization and retrieval.

Considered Alternatives:

1. Calculate the maximum speed over a sliding window of GPS data points (e.g., maximum speed over the last 10 seconds) instead of considering the entire run. This approach may be more suitable for real-time speed monitoring or applications where immediate feedback is required. The trade-off should be considered between efficiency and accuracy.
2. The system could rely solely on GPS data to determine the start and stop points, but this might not be as reliable in areas with weak GPS reception.

Additional Context:

Integrating this feature will enhance the capability of our ski statistics service, providing valuable insights to skiers about their performance on individual runs. It will also contribute to a more comprehensive analysis of skiing activities which will benefit both casual skiers who can track their progress and professional athletes who can use the data to refine their technique and optimize training plans.

Statistics (service functions, Ski statistics)-Distance Skied

Feature Description:
The feature involves calculating the distance skied based on the provided data.

Proposed Solution:
A function will be created to calculate the distance skied. This function will utilize the provided data and will be integrated into the OSM Dashboard to display the skied distance.

Alternative Solution:
An alternative solution could involve utilizing existing libraries or APIs specialized in calculating distances based on geographical coordinates. This approach may offer additional features or optimizations compared to a custom implementation.

Additional Context:
The calculated distance skied can provide valuable insights for users of the OSM Dashboard, allowing them to track their skiing activities and monitor their progress over time. Integration of this feature will enhance the functionality and usability of the dashboard, providing users with a comprehensive overview of their skiing endeavors.

Settings (Voice Announcements) - Announce Total Waiting Time at End of the recording.

Description of the feature
We propose enhancing the Voice Announcements feature to include the option to announce the Total Waiting Time at the end of a recording. This addition aims to provide users with comprehensive information regarding their recorded data, facilitating better understanding and analysis.

Solution

• Create a radio button within the Voice Announcements section of the Settings menu dedicated to announcing Total Waiting Time.
• Implement functionality to manage the announcement of Total Waiting Time, allowing users to toggle this feature on or off.

Alternatives

• Implement a single radio button to control all Voice announcement options together. This approach could streamline the settings interface but may limit user customization.
• Provide advanced customization options for different types of voice announcements, allowing users to tailor their experience further.

Additional context
N/A

Statistics (service functions, Ski statistics) - Total travel time on the chair lift

Describe briefly your feature.
Service function to calculate the total travel time on the chair lift

Describe the solution you'd like
Calculate the total travel time on the chair lift

Additional context
This feature can allow users to see the total travel time they spent on the chairlifts.

Statistics (service functions, Ski statistics)-Identify the segment when a user is on the chairlift

Describe briefly your feature.
This feature can accurately identify when a user is on a chairlift by recognizing specific patterns in motion data or location tracking.

Solution
We can utilize the user's device's barometer data to identify elevation changes. After that, we can start estimating the user's segment on the chairlift starting from when they enter chairlift #61 and continuing until the is no elevation gain #75. With this information, this method enables us to follow the user's journey on the chairlift with accuracy.

Describe alternatives you've considered
An alternate solution would involve analyzing the speed and direction of the user movement recorded. Typically user's speed remains constant throughout the chairlift trip. By identifying speed patterns and direction the chairlift segment can be calculated, this method relies on GPS speed and direction information.

Additional context
This issue provides users with accurate chairlift information, which gives valuable insights to understand the chairlift trip and improves user experience.

**Commit link : ** JSM2512@dc8d09c

Settings (Voice Announcements) - Announce Average Speed at End of Each Run

Feature Description

Under "Statistics Announcements" in the settings, an option will be added to announce the average speed at the end of each run.
This feature enhances the user experience by providing real-time feedback on performance metrics without needing to check the app interface constantly.

Solution Description

A toggle button will be used to check whether or not a user wants to hear their average speed at the end of their run.

Alternatives

A radio button might be used to bulk enable/disable statistics that can be grouped together and announced at the end of the run.

Additional context

N/A

Profile Settings: Allow user to view and change nickname

Describe briefly your feature.
This feature adds a new Nickname field to the Profile settings of the user. This would allow the identification of the user in future social interaction features and let the user have a sense of identity in the app.

Describe the solution you'd like

• In the Settings > Profile screen, add one list item titled Nickname, the description should be the current nickname or "Not set" if the nickname is empty.
• When clicking on the item, a dialog with an input field should be displayed to allow the user to enter their preferred nickname. Clicking on OK will save the nickname. Clicking Cancel or outside of the dialog would close the dialog without saving anything.
• The nickname data should be persisted via the PreferenceUtils class for usage of other parts of the application.

Validation rules:

• Maximum length: 20 characters
• Minimum length: 0

Describe alternatives you've considered

• We can store the data on a server but it's complex and out of the scope of the feature.
• We might need to also check if the nickname is already used but it'd require a server setup and out of the scope of the feature.
• We can display an input field directly inside the Settings screen. However, it'd go against the current convention of the settings in other screens, so I went with the default convention.

Additional context
Mock UI:

Statistics (service functions, Ski statistics)-Elevation

Feature Description.
Add a feature to the OpenTracks application by introducing a feature that accurately calculates and showcases elevation metrics for each ski run. This integration will help users with insights crucial for optimizing and evaluating their skiing performance and gaining deeper insights through the OSM dashboard

Proposed Solution
Add a feature to the app that computes elevation data. The precise computation and presentation of each ski run's elevation profile will be made possible by this data. By using the phone's built-in barometer, supplemented with GPS data, the program will guarantee accuracy while calculating elevation changes during ski suns in mountainous locations. It will also follow the app's offline functionality and privacy-focused design guidelines.

Alternative Solution
An alternative would be to include a comprehensive elevation analysis tool in the app that makes use of cutting-edge topographical algorithms and real-time satellite imagery. This technology will provide previously unheard-of accuracy in elevation profiles for ski runs by not only computing elevation data but also adjusting for atmospheric conditions.

Additional Context
Elevation data is essential for calculating calorie burn, evaluating skiing performance, and optimizing training regimens.This feature enhances the user experience, increases user engagement, and makes progress monitoring easier by giving the user advanced session summaries on the OSM dashboard.

Statistics (aggregate per day (run/lift) - Total time skiing (moving)

Describe briefly your feature.
Create a function to determine the total time skiing and create a UI element for displaying this statistic.

Describe the solution you'd like
From the outcome of Group #4-6 - Statistics (service functions, Ski statistics), we will have distance skied, average speed, so for calculating time, we can divide distance by speed.

Describe alternatives you've considered
There is no alternative for this.

Statistics (aggregate per day (run/lift) - Average % Slope

Describe briefly your feature.
This feature is for including the UI element to display Average % Slope.

Describe the solution you'd like
We will take the "slope %" method's outcome from Group 4-6 - Statistics (service functions, Ski statistics) and make this this UI element visible.

Describe alternatives you've considered
There is no alternative solution for this.

Settings (Voice Announcements) - Announce Average Slope at End of Each Recording

Feature Description

we purpose a feature to Extend Voice Announcement Feature

-The user will be able to enable/Disable the Voice Announcement of Average Slope at the end of recording

Describe the solution you'd like

• Create a radio button under Statistics Announcements Section in Settings.
• Create Voice Announcement section for "Average Slope" in "PreferencesUtils".
• Test the voice announcements to ensure functionality and accuracy.

Describe alternatives you've considered

• Create a single radio button to select all Voice announcement options together.
• Offer customization options for types of voice announcements, allowing users to tailor their experience further

Additional context

• Ensuring the clarity and conciseness of voice commands is imperative, as it directly impacts user experience. Providing relevant information without overwhelming the user is a key objective.

Settings (Voice Announcements) - Announce Max Slope at End of the recording.

Description of the feature
We propose extending the Voice Announcement feature to include the ability for users to enable/disable the announcement of the Maximum Slope at the end of a recording. This enhancement aims to give users more control over the information provided via voice announcements, allowing them to tailor it to their preferences and needs.

Solution

• Create a radio button within the Statistics Announcements Section in Settings specifically for the Maximum Slope announcement.
• Create a Voice Announcement section for "Max Slope" in the PreferencesUtils module, enabling users to toggle the announcement on or off.

Alternatives

• Implement a single radio button to select all Voice announcement options together. While this would simplify the settings interface, it might limit user customization.
• Offer customization options for types of voice announcements, allowing users to tailor their experience further. This would provide more flexibility but could increase complexity for users who prefer simpler settings.

Additional context
N/A

Statistics (service functions, Ski statistics) - Total Travel Time Calculation for Chairlifts

Describe briefly your feature.
The feature aims to accurately calculate the total travel time on chairlifts, to provide users with precise data regarding their skiing sessions.

Describe the solution you'd like
We need to review and potentially refactor the existing implementation for calculating total travel time on chairlifts. This involves:

1. Ensuring accurate identification of user entry and exit from chairlifts.
2. Proper segmentation to determine when users are on chairlifts.
3. Accurate measurement of waiting times at chairlifts.
4. Calculation of total travel time, including both travel time on chairlifts and waiting time.

Describe alternatives you've considered
An alternative approach could involve using additional sensors or technologies to track user movement more accurately. However, this may introduce complexity and cost implications.

Additional context
This issue is crucial for enhancing the overall user experience and providing users with reliable data for analyzing their skiing sessions.

Solution

Added following function as a part of proposed solution.

Statistics (aggregate per day (run/lift) - Total time on the chairlifts

Describe briefly your feature.
Total time on chairlifts determines the time total time for the during which the person happened to be on the chairlift.

Describe the solution you'd like
We have a dependency on Group #4-6 - Statistics (service functions, Ski statistics) where they will find the "Total travel time on the chair lift" and this function can be used to provide a UI element for displaying this statistic.

Describe alternatives you've considered
As an alternative, if the aforementioned function doesn't work well, we can use "Identify the segment when a user is on the chairlift" and add all the segments in the day to find out the total time on chairlifts.

Settings - Ski Profile - Add New Ski Profile Subsection in Settings

Describe briefly your feature.
We propose adding a new subsection called 'Ski Profile' in the settings section of the mobile app. This will allow users to view and manage their ski information.

Describe the solution you'd like
When the user clicks the vertical three-dot menu at the top right of the mobile app and selects 'Settings', they'll see a section named 'Ski Profile'. Clicking on this section enables them to view and adjust ski details like skiing type, sharpening information, and waxing details.

Describe alternatives you've considered
At the moment, no other options have been explored.

Additional context
In the future, if there is a need to capture information about new types of sports in the app, a new subsection can be added in the settings section to accommodate profiles for all sports. The ski profile would then be relocated within this new subsection.

Changes in Settings => Default Units and Activities

Description:

• In the Settings option specifically in Default Units and Activities, there should be a list of predefined activities(including road bike, walking, downhill skiing, cross country skiing) and there should also be an option to define your own activity.
• The default activity should be used each time unless the activity is changed.

Proposed Solution:

• Add a separate text input box under the list of activities box in order to allow the user to enter the activity they want.
• Make sure default activity is set as skiing and is changed as per the users changes.

Additional Context:

Screenshot of the page where changes will be made

Statistics (service functions, Ski statistics) - Speed of the chairlift

Describe briefly your feature.
Service function to calculate the speed of the chairlift

Describe the solution you'd like
Calculate the speed of each chairlift.

Additional context
This feature can allow users to see at what speed they can move through the chairlifts.

Statistics (service functions, Ski statistics)-Slope %

Description of the feature.
Core functionality: Calculate slope% based on the data. Adding this feature to calculate the slope% of the mountain will enhance the OpenTracks app with vital stats for performance tracking

Describe the solution
Create a function to calculate the slope %. This data will be provided for the OSM Dashboard.

Describe alternatives you've considered
We've considered using test data and accelerometer data as alternatives to GPS to calculate slope%.

Additional context
The accuracy of the mountain slop data is crucial.

Settings - SKI Profile - Add, and Validate the Country, and Province for Favorite Ski Resort

Describe briefly your feature
We propose the introduction of a new feature within our ski maintenance tracking application that allows users to input and manage details of their favorite ski resort, including the country and province where it is located. This feature aims to enhance the skiing experience by providing users with easy access to information about their preferred skiing destinations.

Describe the solution you'd like

• Implement a subsection in the settings menu where users can enter and edit the details of their favorite ski resort, including the country and province where it is situated.
• Ensure that the entered information is validated to prevent errors and inconsistencies.
• Make the entered information accessible through class/public functions to ensure it can be utilized by other groups or features within the application.
• Ensure that the entered information is persistent on the user's phone, allowing them to access and update their favorite ski resort details whenever necessary.

Describe alternatives you've considered
An alternative approach could involve integrating a feature that allows users to search for ski resorts based on their preferences, such as location, terrain, amenities, etc. However, providing users with the ability to input and manage their favorite ski resort details directly offers a more personalized and customizable experience.

Additional context
This feature could also be expanded in the future to include additional details about favorite ski resorts, such as trail maps, weather forecasts, lift ticket information, and user reviews. By integrating comprehensive resort information within the application, users can better plan and enjoy their skiing adventures.

Show statistics for day specific run/Chairlift

Feature description.
Improve the application by introducing a feature that provides aggregated statistics for each day, including metrics such as average speed, average slope, top speed, and total time for all completed runs/chairlifts on that day. This addition will offer users detailed insights into their physical activity for specific skiing sessions throughout the day. To implement this enhancement, we've broken down the feature into the following tasks:

Task 1: Restructure the data received from Group 4-6 to align with the required format.
Task 2: Compute any necessary new features.
Task 3: Organize the data with headers for better organization and clarity.
Task 4: Convert the array/dictionary/JSON data into a UI-friendly format to facilitate easy visualization and interaction.

Describe the solution you'd like
Our plan is to develop a new interface where users can view data for a chosen date, which they select from a calendar on the previous screen. Additionally, we will format the data obtained from the features developed by Group 4-6 into a layout suitable for display in the user interface (UI). Furthermore, we'll introduce any extra features not initially present in the received data.

Alternative Solution
Initially, we aimed to display daily run data solely at day's end, limiting users to real-time views. To enable access to past-day data, we've opted for a calendar widget implementation. This widget allows users to navigate and retrieve historical skiing session details conveniently. With the calendar, users can review past-day data at any time, offering a more comprehensive understanding of their skiing activities over time.

Additional context
To enable the OSMDashboard plugin to retrieve and display data from the OpenTracks app, communication between the two is essential. We intend to facilitate the transfer of information between the two, allowing Group-14 working on OSMDashboard to access and showcase relevant data captured for a specific run/chairlifts.

Statistics (service functions, Ski overall (aggregated) statistics per Season) - Seasons favorite lifts

Describe briefly your feature.
Adding a new feature that allows us to see the season's top 5 used chair lifts by the user for the season.

Describe the solution you'd like
This part depends on the members from groups 4 -6, as they are responsible for calculating the aggregated statistics for chairlifts. Once those stats have been calculated, we can count the number of times a user has taken each chair lift, and identify the most used ones based on that. To display this information as a UI element we also require the chair lift names that we can get from the OSMDashboard groups.

Describe alternatives you've considered
If in case the aggregate function breaks or does not function, we can request the user to enter the name of the chairlift that they are taking at any point, and keep a count in this manner. We then fetch this information to do the required ordering and display the top 5 chairlifts used by them.

Statistics (service functions, Ski statistics) - Max Speed(Kilometer per hour) on a particular date

Describe briefly your feature.
This feature aimed at implementing a UI component to showcase the max speed per hour covered along with the date. It depends on the functionality developed by Groups# 4 - 6, related issue link #56.

Describe the solution you'd like
Members of Groups # 4-6 will work on the methods for creating the statistics(service functions, Ski statistics) and provide a function for the max speed per run(Km/h). Once these methods are established, additional code can be integrated to compute max speed per hour along with a date of that day. The computed data will then be utilized by an XML file, configurable with necessary attributes to present the max speed along with the date at the ski chairlift.

Describe alternatives you've considered
Should the initially proposed method prove ineffective, an alternative approach involves allowing users to manually input speed of the run out of which maximum will be calculated and displayed along with the date associated with that speed. However, this method may be less reliable due to potential inaccuracies in user-provided data.

Additional context

Settings - Ski Profile - Adding Waxing info

Describe briefly your feature.
This feature will allow user to add information related to waxing of skis. It will allow user to add below information in this window:

• Waxing interval for the skis (in km) – this should become the default option.
• The type of wax being used (warm, cold, universal)
• The date of the last ski waxing

Describe the solution you'd like
The feature will be implemented by adding a new window which would let the user add the details and save.
After the user opens the application, settings option can be selected which would then show Ski Profile option under it. Then the user can select Waxing information which will load a new window where user can enter the information or update the previously entered information.
Below are the 2 sections:

1. Waxing Info
2. Last waxing date

Waxing info lets the user enter waxing interval and type of wax. The entered information gets saved and updated in summary when Waxing information option is chosen from main menu.
Last waxing date lets the user choose a date from calendar which again gets updated and can be seen when the user re-enters the menu.

Describe alternative that you have considered
There can be various ways to let the user enter information, which will include showing previous info and letting the user delete it and enter new information or clearing it altogther and letting the user enter new information.
Initially I did not use Calendar but then worked on it and replaced it with a nice date picker.

Additional context
It will also involve some validation checks to be enforced. For example any numeric field wouldn't allow alphabets to be entered.
Validations used:

1. For the Waxing interval, a user can not enter any invalid value in this text box. Only decimals are allowed.
2. For Last waxing date, the calendar disables the dates which are in the future so as to ensure valid data.

Settings - SKI Profile - Enhanced Tracking and Notifications for Ski Maintenance Intervals

Describe briefly your feature.
We propose the introduction of a new feature within our ski maintenance tracking application that enhances the visibility and management of ski maintenance intervals for sharpening and waxing. This feature is designed to provide users with a detailed and immediate overview of their ski maintenance needs, improving the overall maintenance schedule and ski performance.

Describe the solution you'd like

• Implement a tracking system that displays, on the same screen, the kilometers skied since the last sharpening and waxing activities.

• Calculate and show the percentage of the specified maintenance interval that has been reached based on the kilometers skied.

• Generate notifications for users in two scenarios:

1. When the skied distance approaches the specified interval for either sharpening or waxing, indicating the maintenance service is due soon (e.g., when the completion percentage is close to 100%).
2. When more than 10 months have passed since the last maintenance service (either sharpening or waxing), a reminder notification is issued even if the skied distance has not reached the specified interval. This is to ensure maintenance is not neglected over time, which could affect ski performance and safety.

Describe alternatives you've considered
Alternatives such as manual tracking or reminders based solely on time or distance without combining these factors were considered. However, integrating both distance skied and time elapsed since the last service provides a more comprehensive and automated approach to maintenance scheduling, reducing the likelihood of oversight and ensuring skis are maintained in peak condition.

Additional context
This feature could leverage user data more effectively to prompt timely maintenance actions, enhancing user experience by ensuring skis are always ready for optimal performance. Integration with calendar apps for automatic maintenance scheduling and reminders could further streamline the maintenance process for users.

Settings (Voice Announcements) - Announce Average Slope at End of Each Run

Feature Description

we purpose a feature to Extend Voice Announcement Feature

• The user will be able to enable/Disable the Voice Announcement of Average Slope at the end of Run.

Describe the solution you'd like

• Create a radio button under Statistics Announcements Section in Settings.
• Create Voice Announcement section for "Average Slope" in "PreferencesUtils".
• Test the voice announcements to ensure functionality and accuracy.

Describe alternatives you've considered

• Create a single radio button to select all Voice announcement options together.
• Offer customization options for types of voice announcements, allowing users to tailor their experience further

Additional context

• Ensuring the clarity and conciseness of voice commands is imperative, as it directly impacts user experience. Providing relevant information without overwhelming the user is a key objective.

Settings (Voice Announcements) - Announce Max Speed at End of Each Recording

Feature Description
At the end of each recording, a voice announcement can be made to inform the user about the maximum speed of the recording if the user has enabled the feature.

Solution Description
A button should be available in the settings menu for voice announcements to enable the feature. Once enabled, the voice announcement should announce the maximum speed at the end of the recording.

Alternatives
The button might also be available for setting at the end of the recording page.