[ios] Add more time in recent track

[itfarrier]

This PR implements https://github.com/organicmaps/organicmaps/issues/6462 only for iOS:

• added 3 days duration;
• added 1 week duration;
• added Belarusian, English and Russian translations for them;
• renamed Day duration as OneDay.

Fix: #6462

[biodranik]

Thanks! Did you test:

1. How much data will it take to store 3 days or a week of points?
2. How is the app slowed down with a week of points present/rendered on the screen?
3. Is the map still usable if you travel/move a lot? Won't points cover all the screen and distract you from everything else on the map?

[itfarrier]

Thanks! Did you test:

1. How much data will it take to store 3 days or a week of points?
2. How is the app slowed down with a week of points present/rendered on the screen?
3. Is the map still usable if you travel/move a lot? Won't points cover all the screen and distract you from everything else on the map?

Sorry, but of course not. Could you please guide me through the processes for addressing each of the three inquiries you've outlined?

Should I implement my own log in map/gps_tracker.hpp (cpp) for debug? Maybe we already have some approaches for above? I would be appreciate for assist me. Thanks.

[biodranik]

1. The size can be estimated from existing data size. You can check/log it programmatically on a device or simulator and then multiply by a number of seconds/minutes/hours etc.
2. Battery usage can be tracked/compared on the release build on the same device.
3. By knowing how many points will be stored there (I assume that in the worst case 1 point for 1 second, meaning 606024*7 = 604K points, theoretical maximum for 7 days), you can generate/simulate these points in different coordinates nearby. I think 100-200K points would be enough. And check if the app is still usable (I highly doubt it).

Check the underlying code that stores data to better understand how to simulate a lot of data there.

It would be also great to profile how CPU/GPU usage increases depending on a number of points, and where is the issue in the code that consumes a lot of CPU/GPU, which can be improved.

[Jean-BaptisteC]

Can you remove merge branch commits and rebase your branch?

[itfarrier]

Can you remove merge branch commits and rebase your branch?

Yes, of course. Sorry for that. P. S. And for automatically closed and reopened by hand PR too.

[Jean-BaptisteC]

@itfarrier did you check the last commentary of biodranik?

[itfarrier]

@itfarrier did you check the last commentary of biodranik?

Hello, @Jean-BaptisteC, of course. I've implemented test file with 1 week data and now trying to render it in Simulator. For now app works with replaced file, but not render any dot, so I'm trying to debug the reason. My file: https://github.com/itfarrier/dtgogtd/blob/main/gps_track_1_week.dat And for now I'm too busy at main work so not enough time for finish this MR quickly, sorry.

[biodranik]

Storing and rendering 36Mb of points can be a huge overhead. A solution could be to apply some kind of simplification algorithm that will remove unnecessary intermediate points and reduce their count.

By the way, did you observe any issues with the app? Was it killed by the system for any reason or was the recent track recorded reliably during the whole week?

[itfarrier]

Storing and rendering 36Mb of points can be a huge overhead. A solution could be to apply some kind of simplification algorithm that will remove unnecessary intermediate points and reduce their count.

By the way, did you observe any issues with the app? Was it killed by the system for any reason or was the recent track recorded reliably during the whole week?

Hello, @biodranik. I've profiled the Simulator with a freeway geolocation simulation for one night. We have 38,912 points over 10 hours, 48 minutes, and 32 seconds, stored in a 2,529,284 bytes DAT file. The Simulator displays only 1 FPS when rendering the map with our points (refer to the attached video at https://github.com/organicmaps/organicmaps/assets/4352168/827caf30-422d-47f9-8f0c-f3caaea81b16). There are no other issues except for an extremely slowed recent track render.

On my iPhone 12 mini, I've recorded 1,720 points over 1 day, 15 hours, and 23 minutes, stored in an 111,804 bytes file. There are no issues with the app on my phone.

These are battery and activity data from the device:

I'd like to conduct a test on a real device during a real trip spanning about 600 kilometers. Can you wait for the results?

[biodranik]

So at the moment one point takes 65 bytes of size. Not too bad, but likely could be better.

Rendering each point is a huge overhead, obviously. The way the track is drawn should be changed, maybe we need to render a line instead of points, and also "smooth" the line by removing a lot of points there.

Any additional results would be interesting. Especially comparing OM's battery consumption with and without recording a track.

[itfarrier]

Any additional results would be interesting. Especially comparing OM's battery consumption with and without recording a track.

@biodranik, these are app battery usage from iPhone 12 mini, iPhone 6s and iPad 6th with the same 600 km 15 hours route.

[biodranik]

Thanks! Considering that the DEBUG build may use 5x-20x more CPU, the results are great :) To compare with production a release build should be used...

[itfarrier]

Thanks! Considering that the DEBUG build may use 5x-20x more CPU, the results are great :) To compare with production a release build should be used...

Hello, @biodranik, these are production app battery usage from iPhone 12 mini, iPhone 6s and iPad 6th:

[biodranik]

Thanks! So what are your conclusions and estimates for a weekly long recording? Would 3 days be enough/better?

[itfarrier]

Thanks! So what are your conclusions and estimates for a weekly long recording? Would 3 days be enough/better?

@biodranik, I believe everything is functioning well with the application's performance overall. However, there are a couple of notable issues:

• with the one-week file with data points recorded every second;
• with the device tends to overheat, causing the app to freeze even without recent track recording.

In my opinion, a recent track record of one day is sufficient (this is what I use personally). I only implemented the request for seven days based on an issue that was raised.

Thank you.

P. S. Perhaps we should implement a recent track history feature with the capability to render or export each item from it.

[biodranik]

Overheating? Did you observe it in Debug or Release? Only with 7 days of points or also with 1 day of points?

I think that adding 2 days history can be more or less safe. Maybe we can add 3 later.

It is important to filter out many unnecessary points at the same place at least before drawing them, and make the recording stable (does the system kill the app on its own?)

And important to see if the file size can be reduced by analyzing the current format.

Exporting/saving the recent track would be great too.

Please let me know in which area are you interested )

[itfarrier]

Overheating? Did you observe it in Debug or Release? Only with 7 days of points or also with 1 day of points?

Hello, @biodranik, I'm sorry for the inconvenience. My iPhone 12 mini overheats every time I use it in the car, regardless of the app: Waze, Yandex, Google, Apple Maps, or OM. So, the overheating issue is not specific to OM.

And important to see if the file size can be reduced by analyzing the current format.

Exporting/saving the recent track would be great too.

Please let me know in which area are you interested )

I've noticed that we're currently saving a lot of unnecessary information in the file. I'm considering investigating how much we could reduce the file size by only saving essential information such as latitude, longitude, and time.

P.S. I'm new to the OM project and Swift as well, so I'm unsure if I can quickly implement the file export.

[biodranik]

We're here to help, don't worry about the complexity, we all love to learn here )

I've noticed that we're currently saving a lot of unnecessary information in the file.

What exactly is currently stored there? In the context of the upcoming "Track Recorder" feature, we'll need precise track data.

[itfarrier]

We're here to help, don't worry about the complexity, we all love to learn here )

I've noticed that we're currently saving a lot of unnecessary information in the file.

What exactly is currently stored there? In the context of the upcoming "Track Recorder" feature, we'll need precise track data.

App writes to file to each point these parameters: timestamp, latitude, longitude, altitude, speedMpS, bearing, horizontalAccuracy, verticalAccuracy, source. But for render

[biodranik]

@rtsisyk slow rendering has also been reported during the tests. Did you miss it?

[rtsisyk]

@rtsisyk slow rendering has also been reported during the tests. Did you miss it?

I can't find any information about rendering issues in this thread.

[biodranik]

@rtsisyk it was mentioned here: https://github.com/organicmaps/organicmaps/pull/7951#issuecomment-2105681018

[rtsisyk]

. The Simulator displays only 1 FPS when rendering the map with our points (refer to the attached video at https://github.com/organicmaps/organicmaps/assets/4352168/827caf30-422d-47f9-8f0c-f3caaea81b16). There are no other issues except for an extremely slowed recent track render.

OK. It sounds like a showstopper. @itfarrier, I am afraid, but 1 FPS is not going to work.

[itfarrier]

@biodranik and @rtsisyk, given the performance issues discussed above, I suggest that we close this PR and the related issue for now.

[biodranik]

This PR can stay as a base for performance-testing. It would be great to record a long track and describe how to put it locally to measure the performance.

After we fix the performance, this change can be introduced.

@itfarrier are there other apps that can record/display a similar recent track for a week? How is it rendered?

Regarding the performance:

• Drawing circles takes more resources than drawing squares or rectangles (less triangles to render)
• Drawing less objects should be faster than drawing many objects (circles)
• While all original, unfiltered points can be stored in a file, rendering may use only a limited filtered number of points to draw less objects.

CC @kavikhalique @rtsisyk @vng

[rtsisyk]

Hi @itfarrier, the general direction here is to replace "Recent Track" with the proper track recorder. It probably will remove the limit. Please take a look at https://github.com/organicmaps/organicmaps/issues/8215#issuecomment-2182145188. It is for Android, but iOS will be reworked after finishing with Android.

[itfarrier]

This PR can stay as a base for performance-testing. It would be great to record a long track and describe how to put it locally to measure the performance.

After we fix the performance, this change can be introduced.

@itfarrier are there other apps that can record/display a similar recent track for a week? How is it rendered?

Regarding the performance:

• Drawing circles takes more resources than drawing squares or rectangles (less triangles to render)
• Drawing less objects should be faster than drawing many objects (circles)
• While all original, unfiltered points can be stored in a file, rendering may use only a limited filtered number of points to draw less objects.

CC @kavikhalique @rtsisyk @vng

OK, I've started checking some apps. Later write the result.

P. S. I've recorded track in Guru Maps. No freezes, no slows. You can see it in details in ZIP archive.

2024-06-23-0318 Трэк без назвы.001.zip 2024-06-23-0318 Трэк без назвы.002.zip