Hey everyone!
I’m excited to introduce Reitti, a location tracking and analysis application designed to help you gain insights about your movement patterns and significant places—all while keeping your data private on your own server.
Core Capabilities:
- Visit Tracking: Automatically recognizes and categorizes the places where you spend time, using customizable detection algorithms
- Trip Analysis: Analyzes your movements between locations to understand how you travel whether by walking, cycling, or driving
- Interactive Timeline: Visualizes all your past activities on an interactive timeline with map and list views that show visit duration, transport method, and distance traveled
Photo Integration:
- Connect your self-hosted Immich photo server to seamlessly display photos taken at specific locations right within Reitti’s timeline. The interactive photo viewer lets you browse galleries for each place.
Data Import Options:
- Multiple Formats Supported: Reitti can import existing location data from GPX, GeoJSON, and Google Takeout (JSON) backups
- (Near) Real-time Updates: Automatically receive location info via mobile apps like OwnTracks, GPSLogger or our REST API
Customization:
- Multi-geocoding Services: Configurable options to convert coordinates to human-readable addresses using providers like Nominatim
- User Profiles: Customize individual display names, password management, and API token security under your own control
Self-hosting:
- Reitti is designed to be deployed on your own infrastructure using Docker containers. We provide configuration templates to set up linked services like PostgreSQL, RabbitMQ and Redis that keep all your location data private.
Reitti is still early in development but has already developed extensive capabilities. I’d love to hear your feedback and answer any questions to tailor Reitti to meet the community’s needs.
Hope this sparks some interest!
Daniel
That’s good, but I still question why it is so slow. If you receive these timeout exceptions more often, at some point the data will cease to be analyzed.
I just re-tested it with multiple concurrent imports into a clean DB, and the
stay-detection-queuecompleted in 10 minutes. It’s not normal for it to take that long for you. The component that should take the most time is actually themerge-visit-queuebecause this creates a lot of stress for the DB. This test was conducted on my laptop, equipped with an AMD Ryzen™ 7 PRO 8840U and 32GB of RAM.Since I last commented, the queue has jumped from about 9000 outstanding items, to 15,000 outstanding items, and it appears that I have timelines for a large amount of my history now.
However, the estimated time is still slowly creeping up (though only by a minute or two, despite adding 6000 more items to the queue).
I haven’t uploaded anything manually that might have triggered the change in queue size.
Is there any external calls made during processing this queue that might be adding latency?
tl;dr - something is definitely happening
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
RawLocationPointsthat 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 thestay-detection-queue. This process naturally adds to the workload of that queue.However, if no new location data is being ingested, once all
RawLocationPointshave been processed and their respective flags set, thestay-detection-queueshould 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.