Metadata: Estimate location by Google's Location History

deekerman commented

2026-02-20 00:00:31 -05:00

Owner

Originally created by @GuiltyFox on GitHub (Apr 5, 2021).

Export Location History from https://takeout.google.com/
then use it for estimate location of pictures

Originally created by @GuiltyFox on GitHub (Apr 5, 2021). Export Location History from https://takeout.google.com/ then use it for estimate location of pictures

deekerman added the

idea

metadata

labels

2026-02-20 00:00:31 -05:00

deekerman commented

2026-02-20 00:00:32 -05:00

Author

Owner

@lastzero commented on GitHub (Apr 13, 2021):

Oh wow, you may export the full Location History... that's nice.

Is the format documented or standardized? An example would be great.
How much effort is it? What steps are needed?

@lastzero commented on GitHub (Apr 13, 2021): Oh wow, you may export the full Location History... that's nice. - Is the format documented or standardized? An example would be great. - How much effort is it? What steps are needed?

deekerman commented

2026-02-20 00:00:32 -05:00

Author

Owner

@GuiltyFox commented on GitHub (Apr 15, 2021):

Inside my takeout-20210416T015533Z-001.zip

Takeout
├── [4.0K]  Location History
│   ├── [661M]  Location History.json
│   └── [4.0K]  Semantic Location History
│       ├── [4.0K]  2015
│       │   ├── [544K]  2015_AUGUST.json
│       │   ├── [687K]  2015_DECEMBER.json
│       │   ├── [205K]  2015_JULY.json
│       │   ├── [2.8K]  2015_JUNE.json
│       │   ├── [675K]  2015_NOVEMBER.json
│       │   ├── [976K]  2015_OCTOBER.json
│       │   └── [587K]  2015_SEPTEMBER.json
.........
│       ├── [4.0K]  2020
│       │   ├── [179K]  2020_APRIL.json
│       │   ├── [390K]  2020_AUGUST.json
│       │   ├── [838K]  2020_DECEMBER.json
│       │   ├── [705K]  2020_FEBRUARY.json
│       │   ├── [608K]  2020_JANUARY.json
│       │   ├── [413K]  2020_JULY.json
│       │   ├── [131K]  2020_JUNE.json
│       │   ├── [438K]  2020_MARCH.json
│       │   ├── [179K]  2020_MAY.json
│       │   ├── [917K]  2020_NOVEMBER.json
│       │   ├── [599K]  2020_OCTOBER.json
│       │   └── [493K]  2020_SEPTEMBER.json
│       └── [4.0K]  2021
│           ├── [416K]  2021_APRIL.json
│           ├── [843K]  2021_FEBRUARY.json
│           ├── [843K]  2021_JANUARY.json
│           └── [956K]  2021_MARCH.json
└── [329K]  archive_browser.html

File format description in archive_browser.html

Location History
Location data collected while opted-in to Location History

JSON
The JSON Location History file describes device location signals and associated metadata collected while you were opted into Location History which you have not subsequently deleted.

locations: All location records.

timestampMs(int64): Timestamp (UTC) in milliseconds for the recorded location.

latitudeE7(int32): The latitude value of the location in E7 format (degrees multiplied by 10**7 and rounded to the nearest integer).

longitudeE7(int32): The longitude value of the location in E7 format (degrees multiplied by 10**7 and rounded to the nearest integer).

accuracy(int32): Approximate location accuracy radius in meters.

velocity(int32): Speed in meters per second.

heading(int32): Degrees east of true north.

altitude(int32): Meters above the WGS84 reference ellipsoid.

verticalAccuracy(int32): Vertical accuracy calculated in meters.

activity: Information about the activity at the location.

timestampMs(int64): Timestamp (UTC) in milliseconds for the recorded activity.

type: Description of the activity type.

confidence(int32): Confidence associated with the specified activity type.

KML
A KML file stores geographic modeling information in XML format that can be used to display geographic data. Refer to the kml documentationfor more information. You can load your KML file into Google Earth to view all the locations you have visited.

Semantic Location History
Semantic location history consisting of inferred place visits and activity segments.

JSON
The JSON Semantic Location History file(s) describe Google Timeline objects such as inferred place visits and activity segments between place visits.

@GuiltyFox commented on GitHub (Apr 15, 2021): Inside my takeout-20210416T015533Z-001.zip ``` Takeout ├── [4.0K] Location History │ ├── [661M] Location History.json │ └── [4.0K] Semantic Location History │ ├── [4.0K] 2015 │ │ ├── [544K] 2015_AUGUST.json │ │ ├── [687K] 2015_DECEMBER.json │ │ ├── [205K] 2015_JULY.json │ │ ├── [2.8K] 2015_JUNE.json │ │ ├── [675K] 2015_NOVEMBER.json │ │ ├── [976K] 2015_OCTOBER.json │ │ └── [587K] 2015_SEPTEMBER.json ......... │ ├── [4.0K] 2020 │ │ ├── [179K] 2020_APRIL.json │ │ ├── [390K] 2020_AUGUST.json │ │ ├── [838K] 2020_DECEMBER.json │ │ ├── [705K] 2020_FEBRUARY.json │ │ ├── [608K] 2020_JANUARY.json │ │ ├── [413K] 2020_JULY.json │ │ ├── [131K] 2020_JUNE.json │ │ ├── [438K] 2020_MARCH.json │ │ ├── [179K] 2020_MAY.json │ │ ├── [917K] 2020_NOVEMBER.json │ │ ├── [599K] 2020_OCTOBER.json │ │ └── [493K] 2020_SEPTEMBER.json │ └── [4.0K] 2021 │ ├── [416K] 2021_APRIL.json │ ├── [843K] 2021_FEBRUARY.json │ ├── [843K] 2021_JANUARY.json │ └── [956K] 2021_MARCH.json └── [329K] archive_browser.html ``` File format description in archive_browser.html > Location History Location data collected while opted-in to Location History >>JSON The JSON Location History file describes device location signals and associated metadata collected while you were opted into Location History which you have not subsequently deleted. >>- locations: All location records. >>- timestampMs(int64): Timestamp (UTC) in milliseconds for the recorded location. >>- latitudeE7(int32): The latitude value of the location in E7 format (degrees multiplied by 10**7 and rounded to the nearest integer). >>- longitudeE7(int32): The longitude value of the location in E7 format (degrees multiplied by 10**7 and rounded to the nearest integer). >>- accuracy(int32): Approximate location accuracy radius in meters. >>- velocity(int32): Speed in meters per second. >>- heading(int32): Degrees east of true north. >>- altitude(int32): Meters above the WGS84 reference ellipsoid. >>- verticalAccuracy(int32): Vertical accuracy calculated in meters. >>- activity: Information about the activity at the location. >>- timestampMs(int64): Timestamp (UTC) in milliseconds for the recorded activity. >>- type: Description of the activity type. >>- confidence(int32): Confidence associated with the specified activity type. >>KML A KML file stores geographic modeling information in XML format that can be used to display geographic data. Refer to the kml documentationfor more information. You can load your KML file into Google Earth to view all the locations you have visited. >Semantic Location History Semantic location history consisting of inferred place visits and activity segments. >>JSON The JSON Semantic Location History file(s) describe Google Timeline objects such as inferred place visits and activity segments between place visits.

deekerman commented

2026-02-20 00:00:33 -05:00

Author

Owner

@GuiltyFox commented on GitHub (Apr 15, 2021):

For example files

Takeout\Location History\Semantic Location History\2015\2015_JULY.json
2015_JULY.txt

First 1000 lines of Takeout\Location History\Location History.json
first1000 of Location History.txt

@GuiltyFox commented on GitHub (Apr 15, 2021): For example files Takeout\Location History\Semantic Location History\2015\2015_JULY.json [2015_JULY.txt](https://github.com/photoprism/photoprism/files/6322122/2015_JULY.txt) First 1000 lines of Takeout\Location History\Location History.json [first1000 of Location History.txt](https://github.com/photoprism/photoprism/files/6322125/first1000.of.Location.History.txt)

deekerman commented

2026-02-20 00:00:33 -05:00

Author

Owner

@el-tiuri commented on GitHub (May 24, 2021):

FYI: you can do this with digiKam if you have gpx files (which you should be able to create from kml files). If you enable writing the location to metadata it becomes usable in all applications that pull from that metadata, including Photoprism.

@el-tiuri commented on GitHub (May 24, 2021): FYI: you can do this with digiKam if you have gpx files (which you should be able to create from kml files). If you enable writing the location to metadata it becomes usable in all applications that pull from that metadata, including Photoprism.

deekerman commented

2026-02-20 00:00:33 -05:00

Author

Owner

@n-patiphon commented on GitHub (Jul 22, 2021):

It seems like ExifTool can also be used to geotag photos using a GPX file as well. See https://exiftool.org/geotag.html.

@n-patiphon commented on GitHub (Jul 22, 2021): It seems like ExifTool can also be used to geotag photos using a GPX file as well. See https://exiftool.org/geotag.html.

deekerman commented

2026-02-20 00:00:34 -05:00

Author

Owner

@motey commented on GitHub (Nov 3, 2022):

Proposal: If this feature will ever reach implementation, i would appreciate to prioritize support of gpx files instead of the custom google kml format. We move here in the "selfhosting"-realm and gpx-track-support would be compatible with a wider range of use cases. (e.g. i track myself via Nextcloud/PhoneTrack). Also: KML files can be converted to gpx files. So maybe we can rename the issue to Places: Estimate location by gpx track data

Hint: The tricky part is that many cameras tag images with none timezone aware timestamps. In practice most image timestamps can be still matched too a gpx trackpoint if source data is not ambiguous (multiple gpx tracks, timezone crossing at same day)

From time to time i tinker on a python solution for the same problem https://github.com/motey/auto-photo-geo-tagger
But at the moment i dont have enough time to bring this project over the finish line in the foreseeable future. But maybe i can provide some help for a solution in photoprism.

@motey commented on GitHub (Nov 3, 2022): Proposal: If this feature will ever reach implementation, i would appreciate to prioritize support of gpx files instead of the custom google kml format. We move here in the "selfhosting"-realm and gpx-track-support would be compatible with a wider range of use cases. (e.g. i track myself via Nextcloud/PhoneTrack). Also: KML files can be converted to gpx files. So maybe we can rename the issue to `Places: Estimate location by gpx track data` Hint: The tricky part is that many cameras tag images with none timezone aware timestamps. In practice most image timestamps can be still matched too a gpx trackpoint if source data is not ambiguous (multiple gpx tracks, timezone crossing at same day) From time to time i tinker on a python solution for the same problem https://github.com/motey/auto-photo-geo-tagger But at the moment i dont have enough time to bring this project over the finish line in the foreseeable future. But maybe i can provide some help for a solution in photoprism.

deekerman commented

2026-02-20 00:00:34 -05:00

Author

Owner

@lastzero commented on GitHub (Nov 3, 2022):

Either someone contributes it or we can grow our team. Both would be perfect.

@lastzero commented on GitHub (Nov 3, 2022): Either someone contributes it or we can grow our team. Both would be perfect.

deekerman commented

2026-02-20 00:00:34 -05:00

Author

Owner

@Symbianx commented on GitHub (Aug 16, 2023):

I made a go tool that reads the google takeout location history file and tries to add locations to photos based on the time the picture was taken: Symbianx/google-takeout-photo-location-fixer.

@lastzero How do you envision this functionality being integrated into photoprism?

@Symbianx commented on GitHub (Aug 16, 2023): I made a go tool that reads the google takeout location history file and tries to add locations to photos based on the time the picture was taken: [Symbianx/google-takeout-photo-location-fixer](https://github.com/Symbianx/google-takeout-photo-location-fixer). @lastzero How do you envision this functionality being integrated into photoprism?

deekerman commented

2026-02-20 00:00:35 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 16, 2023):

@Symbianx I guess the easiest way would be a CLI subcommand!?

@lastzero commented on GitHub (Aug 16, 2023): @Symbianx I guess the easiest way would be a CLI subcommand!?

deekerman commented

2026-02-20 00:00:35 -05:00

Author

Owner

@StudioLE commented on GitHub (Aug 17, 2023):

@Symbianx I guess the easiest way would be a CLI subcommand!?

@lastzero Would it not make more sense to implement this kind of feature as a Plugin?

This is a feature that some but not many users will want, by integrating it fully into PhotoPrism you may end up maintaining it yourself but implement it as a plugin and the community take on that responsibility. That also makes it easier to fork the feature and adapt it to other data sources. Such as location tagging based on Strava data etc?

I see there's already an issue for plugins #117 so I'll add my other thoughts there.

@StudioLE commented on GitHub (Aug 17, 2023): > @Symbianx I guess the easiest way would be a CLI subcommand!? @lastzero Would it not make more sense to implement this kind of feature as a Plugin? This is a feature that some but not many users will want, by integrating it fully into PhotoPrism you may end up maintaining it yourself but implement it as a plugin and the community take on that responsibility. That also makes it easier to fork the feature and adapt it to other data sources. Such as location tagging based on Strava data etc? I see there's already an issue for plugins #117 so I'll add my other thoughts there.

deekerman commented

2026-02-20 00:00:35 -05:00

Author

Owner

@Symbianx commented on GitHub (Aug 17, 2023):

I guess the easiest way would be a CLI subcommand!?

I don't know the code base but I assume that would be a straight forward thing.

@StudioLE A plugin system would be a great fit for this kind of stuff, for sure. I wonder what's the status on that issue is.

@Symbianx commented on GitHub (Aug 17, 2023): > I guess the easiest way would be a CLI subcommand!? I don't know the code base but I assume that would be a straight forward thing. @StudioLE A plugin system would be a great fit for this kind of stuff, for sure. I wonder what's the status on that issue is.

deekerman commented

2026-02-20 00:00:36 -05:00

Author

Owner

@StudioLE commented on GitHub (Aug 17, 2023):

@Symbianx It looks like your solution works by directly editing the EXIF of the image files themselves whereas I would imagine a PhotoPrism plugin would edit the geolocation information stored in the database.

By taking that approach you could:

Add a google-takeout-photo-location-fixer to the docker-compose.yml
Include the google location .json as a volume.
Run the container via docker compose run
On entry the containerized app searches the PhotoPrism database for images without geo location data.
Get the date/time of those photos from the PhotoPrism database (no need for exif as PhotoPrism has already extracted it all).
Apply your google-takeout-photo-location-fixer logic to match the date/time to the location.
Write the location to the database.

As far as I'm aware that workflow would be possible without any modification of PhotoPrism itself. Although in future I imagine:

It would be preferable to access the database via an API
You may want a simple UI and menu entry within PhotoPrism to upload the location .json and trigger the workflow rather than relying on the docker compose CLI

@StudioLE commented on GitHub (Aug 17, 2023): @Symbianx It looks like your solution works by directly editing the EXIF of the image files themselves whereas I would imagine a PhotoPrism plugin would edit the geolocation information stored in the database. By taking that approach you could: 1. Add a `google-takeout-photo-location-fixer` to the `docker-compose.yml` Include the google location `.json` as a volume. 2. Run the container via `docker compose run` 3. On entry the containerized app searches the PhotoPrism database for images without geo location data. 4. Get the date/time of those photos from the PhotoPrism database (no need for exif as PhotoPrism has already extracted it all). 5. Apply your `google-takeout-photo-location-fixer` logic to match the date/time to the location. 6. Write the location to the database. As far as I'm aware that workflow would be possible without any modification of PhotoPrism itself. Although in future I imagine: - It would be preferable to access the database via an API - You may want a simple UI and menu entry within PhotoPrism to upload the location `.json` and trigger the workflow rather than relying on the docker compose CLI

deekerman commented

2026-02-20 00:00:36 -05:00

Author

Owner

@lastzero commented on GitHub (Aug 17, 2023):

@StudioLE @Symbianx PhotoPrism has a REST API. It could be better documented, but it works and many apps already use it. So I'm not sure what additional plugin system you would need for a pure backend solution? Maybe event hooks that can be invoked when indexing is done, for example? You could also write directly to the SQL database, or update the file metadata and then simply re-index...

@lastzero commented on GitHub (Aug 17, 2023): @StudioLE @Symbianx PhotoPrism has a REST API. It could be better documented, but it works and many apps already use it. So I'm not sure what additional plugin system you would need for a pure backend solution? Maybe event hooks that can be invoked when indexing is done, for example? You could also write directly to the SQL database, or update the file metadata and then simply re-index...

deekerman commented

2026-02-20 00:00:36 -05:00

Author

Owner

@Symbianx commented on GitHub (Aug 17, 2023):

@StudioLE Yes, the general idea would be to handle any metadata, including geolocation using the photoprism and not have to deal with the image itself. My solution was obviously a more general use case solution.

@lastzero

Maybe event hooks that can be invoked when indexing is done, for example?

Yes, that's exactly the kind of thing I would expect from a plugin eco-system. I will take a look at the REST API.

@Symbianx commented on GitHub (Aug 17, 2023): @StudioLE Yes, the general idea would be to handle any metadata, including geolocation using the photoprism and not have to deal with the image itself. My solution was obviously a more general use case solution. @lastzero > Maybe event hooks that can be invoked when indexing is done, for example? Yes, that's exactly the kind of thing I would expect from a plugin eco-system. I will take a look at the REST API.

Rows
Columns

Metadata: Estimate location by Google's Location History #869