Cool, thanks for the feedback.

For: 1: There should be something about downloading in the Photon logs. You can check with docker compose logs photon. I do not remember how long it took to download the index for Germany, but it was noticeable. It depends a lot on how you are connected to the internet and then how long it takes to extract the index.

2: You should also see that in the log of Photon. If the default does not work reliably, you can create an account on Geoapify; it is free, and you get 3000 reverse geocode requests per day. I personally have Photon for DE and then the default service and additional Geoapify.

3: Yeah, I was also thinking about that. In the end, a per-user setting and then the overlay should be disabled, but it could take a while until I can get to it.

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 [email protected]. 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 :)

Thank you for testing Reitti. 🙏

It depends on two key requirements for Reitti:

1. First, it finds all photos from Immich taken on the day you selected.
2. Then, it filters these photos based on the selected map bounds, using the embedded EXIF geolocation data (where the photo was shot).

If the EXIF data does not contain geolocation information, we currently cannot display those photos because their placement on the map cannot be determined.

Could you please verify in Immich if the expected photo has its location in the metadata? If it is available there, then the issue might lie in how Reitti is parsing that specific data.

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 :)

It was not intentional but after bothering not about it because i had other things on my mind i got used to it and now like it the way it is.

But for everyone who is bothered by that. If Reitti reaches 1k stars on Github I will add a switch to use a centered one 😊

Congratulations 😆

To help with that I would need some information:

• does it show anything in the logs?
• what do you mean by several years or how big was the Records.json?

Thank you for testing 🙂

I would not say compete. They are different in how things are done from my point of view. I want to focus more on the visits we have done in the past to relive some lost memories whereas Dwarich looks more "technical" for me. I have no better words for it, I hope you get my point in what i am trying to achieve with Reitti. So there should be enough room for both 🙂

I also do not have any intentions to offer a hosted version in the foreseeable future or even anytime.

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 :)

I understand your concerns, this is something every additional app would have to deal with.

For me it is ok to have GPSLogger running all the time, I think for what it is doing it is quite easy on the battery but I do not use my phone actively that much and I am happy if it survives a day which it does.

I have no clue if a raspberry will handle it. There a a couple of services involved to make it fast, but they are then another burden like RabbitMQ. Which make ingesting data instantaneous but you need extra processing power to handle the queues. It all comes with a tradeoff.

For size, there is mainly the PostGIS DB. I just checked and my db is around 800 MB for roughtly 8 1/2 Years of data.

Photon (the reverse geocode enabled in the compose file) is another beast. For Germany it takes 14 GB of storage while running, if you let PARALLELL updates enabled you can double that every time the index is updated. But you can remove that from the compose file and rely on external Geocoders. It is described in https://github.com/dedicatedcode/reitti?tab=readme-ov-file#reverse-geocoding-options

Reitti on its own does not run on your phone. It relies on external apps to track your GPS location like GPSLogger or Owntracks. They will increase the battery consumption but I think it is bearable. I personally have setup GPSLogger to fetch every 30 seconds a GPS location and then sends it every hour to reitti. With that i do not see that more power usage. Currently starting to test how the power drain is with a 15 seconds interval.