Hi ada,

yes, this will impact the visit calculation. Visits are calculated in building clusters of at least 5 points in a range of 100m over a duration of at least 5 minutes. If there is only one point logged for example at work or home, Reitti is not able to detect when you left it because every point is just an instant in time and does not carry any duration information with it.

The more points we have to calculate Visits the more accurate it will be. I personally have set up GPSLogger to log every 30 seconds no matter how far I travelled but with at least 40m of accuracy.

I am glad it worked out for you in importing the first file. I am still puzzled why it took that long.

For the new format, did you have Android or iOS? With the timeline export from Google Maps on iOS, we can not do anything at the moment because there is actually no raw data in it. Only information like you stayed in this timeframe at that point and you traveled between these points. It's actually a little bit funny that it aggregates to the same data Reitti uses in the end.

If you are on Android, it could also be a bug when importing that file. I only had a small one from one of my accounts to test. If you mind creating a bug report, I will have a look. If you do not want to attach the export file there, feel free to send it to daniel@dedicatedcode.com. I will have a look at it then privately. No problem.

For the overlap in exports, it depends. If the points are the same, meaning they have the same timestamp, then Reitti will discard them. If not, they will be handled like every other new data and will end in recalculating visits and trips around that particular time.

Glad I could help :)

This process is not triggered by any external events.

Every ten minutes, an internal background job activates. Its function is to scan the database for any RawLocationPoints that haven't been processed yet. These unprocessed points are then batched into groups of 100, and each batch is sent as a message to be consumed by the stay-detection-queue. This process naturally adds to the workload of that queue.

However, if no new location data is being ingested, once all RawLocationPoints have been processed and their respective flags set, the stay-detection-queue should eventually clear, and the system should return to a idle state. I'm still puzzled as to why this initial queue (stay-detection-queue) is exhibiting such slow performance for you, as it's typically one of the faster steps.

It is actually awesome if you have some old photos with the geodata attached and scim through Reitti and suddenly one of them shows up :)

Oh, i had the idea in mind what i want to create and than it was a matter of a couple of Google queries but in the end one of the LLM suggested a list of different names in foreign languages and reitti somehow sticked 😊

Thanks :)

No, did not occur to me. What would the integration look like? Connecting it to the message bus to receive location updates? Honestly it is a couple years ago I played with HA.

Not really, I stopped using IOS a year ago because of exactly this reason. Had a lot of problems syncing files because of the power saving. I understand why IOS is doing it and for a normal user I think it is the way to go. But anything beyond that, it only hinders the experience you get out of apps. Maybe someone here as any experience with an app which works reliably.

Thanks :) As a German I really like the name Dawarich. First it sound really nice for me but also that "Da war ich" means "There have i been" in german makes, at least for me, an awesome project name.

Take this with a grain of salt because I have no idea what the plans are for Dawarich or have ever been and this is solely based on my external view. For me the main differences are:

• visits and trips are our main data, everything else is just the way to calculate them. For Dawarich it looks to me, that it is the other way around. It displays all the location data in good way with the heatmap and so on but visits or places seems so tacked on. This should not be an offense against it. I actually still have an instance running and it was the main pushing point to finally start working on Reitti.
• the sleek UI but this depends on your taste

In the end, they are not that far off. Maybe a matter of taste.

Thank you.

At the moment i do not have any plans of providing a way of running it without docker. Mainly because of time to support that.

Since it is a Spring-Boot-Application it would be possible to create a jar file which you can execute or deploy as a service with systemd. But then you have to make sure all prerequisites are also running. That is the one thing I like about docker and especially docker compose.

But short answer: Yes, it is possible but you are on your own at the moment. I would help and maybe we can add a section to the readme how to do it.

I do not think it is that complicated. The front-end sends a request to the back-end with the current selected day. This triggers a search in Immich returning all photos taken on that specific day. This is returned to the front-end and this than does the heavy lifting like filtering them to the current map bounds, displaying them on the map at a specific location. We proxy all request from the front-end through our server because of CORS issues and I did tried to avoid having to configure Immich besides creating a token for the API.

One would need to either create a specific IntegrationService like ImmichIntegrationService and then figure out a way how the user can configure that. The easiest would be that we just then call all available ones even if I do not see the use case of having multiple Photo-Servers. But it would make the code in Reitti cleaner and would not hurt if we do not configure 20 simultaneous servers :D

If you use Photon and only have your main country available, it will fallback to the configured external Geo-coding-services since Photon will not return a result then. So the order of execution is:

• first try Photon
• if it does not return anything, try to call one or all of the available Geo coding services.