Just read through your google doc, interesting! But what about additional family members, with their own cameras, and no interest in any clever workflow activities :) I'm currently using Google Photos as my main service, and it's working good enough for now: each family member has the Google Photos app which uploads pics automatically, to their own account. We all share our Google Photos with each other. This way I (as main curator) have access to everyone's pics, without anyone having to do anything. Google lets you store the original size pics, so that is great (not like iCloud that resizes all pics!). Google also adds face recognition, which is very practical, and also provides a good interface for everyone to view the pictures. Regarding safekeeping: I use the Google Drive interface to backup all my photos to my local linux storage (combination of rsync and https://github.com/astrada/google-drive-ocamlfuse to mount Google Drive). This way I always have all original photos locally. Finally I backup everything offsite using BackBlaze.

All this relies heavily on Google Photos, but I have my own local backup of all original files. So if I need to change service, it should just be a one-time effort to migrate.

I also rely mostly on Google Photos as my viewing and sharing app. This includes sharing photos with family which is done through Google Photos shared albums.

I'm really the only one who cares about archiving photos so I'll transfer the shared photos from Google Photos to Google Drive (using the "share" functionality from the mobile app).

This kicks off a workflow that simultaneioously organizes the shared photo into my library and copies it too Dropbox and uploads it to my Google Photos library [1]. (I use Google Drive as a transport mechanism to get photos off my phone and onto my Synology).

Not ideal but once I got it set up it's worked really well.

[1] https://github.com/jmathai/elodie/tree/master/elodie/plugins...

> I use the Google Drive interface to backup all my photos to my local linux storage

I thought this was killed recently[1]

(this = google photos appearing in google drive)

Does it still work for you?

If yes, how? :)

[1] https://www.blog.google/products/photos/simplifying-google-p...

Uploading to both services is still supported through the Backup and Sync app. But once uploaded they are independent copies and deleting from one doesn't delete from the other. I also expect that this support will be deprecated at some point in the future.

Not keeping Drive and Photos in sync really killed it for me. I ended up switching from Google Drive to Dropbox but I still use Google Photos.

I have photos added to my library in Dropbox automatically added to my Google Photos library and this has worked well so far. [1]

[1] https://github.com/jmathai/elodie/tree/75e65901a94e14e6fd1ff...

I see. I was hoping there was still some way to quickly backup from google photos directly to linux.

You can use https://github.com/mholt/timeliner (open source)

There's also rclone. https://github.com/rclone/rclone

I cringe at the thought of what Google is using that face recognition for.

I'm using resilio sync on all phones to sync to a computer. All the family needs to do is start Sync and wait until it's done. Does not matter on what network they are on, it still syncs.

This looks great and feels a lot like beets [1] for music, only that they use a database. I'll try it when I have the time to re-organize ~20 years of photos.

[1] http://beets.io/

elodie looks amazing! I definitely need to try it out

it was just the thing I was thinking of building recently as it was getting really tiring to manually organize photos

one extra idea that I had: there's a cool project that would enable offline geocoding[1], which would help get rid of API limits while making the reverse geocode queries almost instant

(the included dataset is pretty limited, but it's not hard to extend from an openstreetmap planet dump)

[1] https://pypi.org/project/reverse_geocoder/

I had looked into local geocoding databases but did not want to add a database file in the git repository. reverse_geocoder looks really interesting though and I may have a look at adding that.

For the time being, elodie does cache responses from the MapQuest API. And to reduce the number of API calls it does some approximation by seeing if an entry exists in the cache within 3 miles of the current photo --- if so, it uses that instead of looking up the location. [1]

[1] https://github.com/jmathai/elodie/blob/75e65901a94e14e6fd1ff...