Added AssetGrid/Timeline to Map
Description
Added an AssetGrid/Timeline to map page. By default the grid is closed to avoid loading a large set of timebuckets and images. When Grid is opened it updates when map is zoomed or relocated.
Implements feature #4519
Code partly from discussion #11893
Did not add an option to mapsettings. The grid is always available (but closed).
Next steps: Show App Bar, when images are selected in grid. Right now nothing happens on selecting images. Show images from the same timeframe as the current images shown in grid. This could be useful when shooting with a phone (geolocation is set) and a mirrorless camera (without geolocation).
How Has This Been Tested?
Manually tested with 6000 geolocated images and around 1300 images per location.
Screenshots (if appropriate)
API Changes
api/timeline/buckets and api/timeline/bucket accept coordinates as x1, x2, y1, y2 parameters updated TimeBucketDto
Checklist:
- [X ] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation if applicable
- [ X] I have no unrelated changes in the PR.
- [X ] I have confirmed that any new dependencies are strictly necessary. (no new dependencies)
- [ ] I have written tests for new code (if applicable)
- [X ] I have followed naming conventions/patterns in the surrounding code
- [ X] All code in
src/servicesuses repositories implementations for database calls, filesystem operations, etc. (no new code) - [ X] All code in
src/repositories/is pretty basic/simple and does not have any immich specific logic (that belongs insrc/services) (no new code)
Does this truly need server modifications? Just wondering because such a feature is present on the mobile app already.
The mobile app can query the local database.
This type of query won't perform very good on a lot of assets. Zack and I talked about adding a polygon based index, similar to the other geocoding stuff that we already have.
This type of query won't perform very good on a lot of assets. Zack and I talked about adding a polygon based index, similar to the other geocoding stuff that we already have.
Ok. That means? I just refactored / cleaned the code and implemented all comments from @danieldietzler.
Cann you point me to some code, where you implemented the polygon based index?
Awesome PR, I was about to look into implementing something similar. Is there anything in particular that we can do to help get this merged? :)
Thanks for the feedback. The last thing I heard about were thoughts about performance, which is understandable as there is a lot of data loaded from the server to place the markers on the map. @danieldietzler any idea how to go on?
As jrasm already said the key here is probably to fetch assets that are currently in frame. I don't really have experience with polygon/geospatial indices though. That's probably something @zackpollard could chime in on.
As jrasm already said the key here is probably to fetch assets that are currently in frame. I don't really have experience with polygon/geospatial indices though. That's probably something @zackpollard could chime in on.
Don't currently have that all in my head, would need to look into it some more before I could comment on it, but there should be an efficient way for us to query like this without using PostGIS. I don't really have time to look into this right now though.
I would love to see this feature released someday.
Unfortunately I have zero skills to help, but I have a comment on the appearance: since most desktop screens are horizontal a vertical split dual pane would be way more efficient.
pardon the atrocious photoshop work on the original screenshot:
Is this still being worked on?
This PR as-is is probably unlikely to get merged at this point. For one it requires some thinking about how to make the look ups efficiently. Also, the whole web timeline is currently undergoing a huge refactor, which will render most of the frontend work here obsolete or at the very least incompatible. (also, the PR is like >2000 commits behind which will be incredibly painful to rebase 😅) We'll hopefully get this feature implemented eventually (primarily when the dust around the web timeline settles), sorry!