Nature Photo GPS Tracker: geotagging camera photos for iNaturalist

Goal of the tool:

Help people geotag photos from cameras without GPS and add matching locations on iNaturalist with less manual work.

Niche it fills in the iNaturalist ecosystem:

A workflow that connects Android GPS track recording, Windows timestamp-to-location matching and EXIF copies, and iNaturalist batch editing.

Is there a commercial component, or do you plan into include one in the future? Are donations requested? (yes/no, explain):

Yes. The Android app is free to use and includes banner ads. Donations are not requested.

What sort of data (if any) does your app collect from its users?:

By default, GPS trips and saved places are stored locally on the Android device. If the user signs in with Google and manually backs up a trip, GPS tracks, trip metadata, and saved places are stored in Firebase under that user account. Photos remain local on the Windows computer. The Chrome extension uses the iNaturalist API to read observation times and fills matched coordinates into the batch-edit form; it does not save automatically.

Link to your iNaturalist profile:

https://www.inaturalist.org/people/weiting_chen

Description:

Many cameras do not record GPS data, so adding locations one by one when uploading photos to iNaturalist can be time-consuming.

I built an Android and Windows workflow to help with this. The Android app records a GPS track while you are taking photos. Trips are stored locally by default and can optionally be backed up manually after signing in with Google.

On Windows, sign in with the same Google account, select a trip and a JPG/JPEG folder, and run the desktop tool. It matches photo timestamps with the GPS track and creates geotagged copies in gps_output. Original photos are never modified.

A Chrome extension is also available for the iNaturalist batch-edit page. It uses the iNaturalist API to read observation times and prefill matching coordinates. It never saves automatically—you must review the results and click Save All.

Links:

Discussion questions or areas seeking feedback:

I would appreciate feedback from people who upload photos taken with cameras without GPS. Is this workflow useful, and are there any situations I should test?

2 Likes

why is your workflow better than any of the existing apps / workflows that will geotag the image files?

1 Like

That is a fair question. I would not claim that this workflow is universally better than existing geotagging tools. If the only goal is to geotag image files, mature tools such as Geotag Photos Pro, digiKam, Lightroom, GeoSetter, or ExifTool may be better choices. Some of them support more operating systems, RAW formats, GPX interoperability, interpolation, and advanced metadata editing.

The niche I am aiming for is a simpler, iNaturalist-oriented workflow:

  • The Android app records the trip, with local storage by default and optional manual cloud backup.
  • The Windows tool can retrieve the selected trip, match JPG/JPEG photos by capture time, and create geotagged copies without modifying the originals.
  • If users do not want to modify their image files at all, the Chrome extension can match the same trip directly against observation times on the iNaturalist batch-edit page. It only prefills the coordinates and leaves the final Save All action to the user.
  • The desktop tool also supports camera time-zone and clock-offset correction and reports photos that could not be matched.

So its main advantage is not a more advanced geotagging algorithm. It is the integrated and reversible path from Android GPS recording to either safe photo copies or reviewed iNaturalist batch editing. Currently, the Windows tool only supports JPG/JPEG and uses the nearest recorded GPS point, so it still has important limitations compared with more mature tools. Thanks for asking—I should make these trade-offs clearer in the original post.

1 Like

perhaps the browser extension does provide a unique workflow, but i don’t understand how your Android GPS track app improves upon any existing app that can create such a track, and i don’t understand how your Windows application improves upon existing reversible / non-destructive workflows that can be achieved in other existing apps.

maybe i’m just too paranoid, but it seems like giving a small developer access points to your Android and Windows OS, plus browser and Google credential access, seems like a lot of potential incremental risk for not much incremental benefit.

1 Like

That is a fair concern, and I agree with much of what you said. The Android component is not technically a better GPS logger than established alternatives, and the Windows copy-only EXIF workflow is not unique. If someone already has a satisfactory workflow using GPX with tools such as digiKam, Lightroom, GeoSetter, or ExifTool, there may be little reason to switch.

The benefit I intended is a narrower integration for iNaturalist users:

  • When saving the current GPS location in the Android app, users can enter a species name. The app queries the public iNaturalist API and suggests matching common and scientific names. Only the search text and interface language are sent to iNaturalist—not the GPS coordinates, track, notes, photos, or Google account.
  • The same recorded trip can be used by either the Windows tool or the iNaturalist browser extension.
  • The Windows tool always writes matched JPG/JPEG files to a separate gps_output folder and reports files that could not be matched. This is a safety default rather than a unique technical capability.
  • The browser extension is the more distinctive part: it can match the trip directly against iNaturalist observation times and prefill coordinates without modifying the image files. It never automatically clicks Save All.

Regarding permissions, Google sign-in and cloud backup are optional for the Android and Windows workflow. Users can keep their tracks locally, export a local trip file, and process photos on Windows without signing in. Photos remain on the computer and are not uploaded.

When Google sign-in is used, authentication takes place through Google-provided interfaces or the system browser, and the applications do not receive the user’s password. The Chrome extension requests Google openid and email access and limits its website access to the required Firebase and iNaturalist endpoints and the iNaturalist batch-edit page.

However, you are correct that installing an Android app, a Windows application, and a browser extension increases the attack surface. The source code is not currently public, so users cannot independently audit the implementation. The Windows installer also does not yet have a publicly trusted Authenticode signature. I understand that these points increase the level of trust required, and cautious users may reasonably prefer to continue using established tools.

I do not want to claim that the added convenience eliminates those risks. The intended value is reduced friction in this particular iNaturalist workflow, not fundamentally better GPS recording or EXIF technology. Your comment makes it clear that I should document the permissions, data flows, local-only option, and security boundaries more prominently. Thank you for raising this.