immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

Reverse geocoding is frequently incorrect #2982

New Issue
Closed
opened 2026-02-05 07:18:01 +03:00 by OVERLORD · 11 comments
OVERLORD commented 2026-02-05 07:18:01 +03:00
Owner
Copy Link

Originally created by @hermesespinola on GitHub (Apr 20, 2024).

The bug

I have a bunch of photos from one place that get incorrect location tags. This makes it difficult to correctly search for photos from one particular city. Most of the times it's neighborhood names that get classified as cities, cities as states.

Here are some examples:
image

  • Actual:

    • City: Paseos del Valle
    • State: Tlajomulco de Zuñiga, Jalisco
    • Country: Mexico
      Expected:
    • City: Tlajomulco de Zuñiga
    • State: Jalisco
    • Country: México

image

  • Actual:
    • City: Brooklyn Heights
    • State: Kings County, New York
    • Country: United States of America
  • Expected:
    • City: New York City (Brooklyn might be alright too)
    • State: New York
    • Country: United States of America

The OS that Immich Server is running on

Linux raspberrypi 6.1.0-rpi7-rpi-2712

Version of Immich Server

v1.101.0

Version of Immich Mobile App

v1.101.0 build.147

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

Not relevant?

Your .env content

Not relevant?

Reproduction steps

1. Open up place search.
2. Search for a place that is not a city inside "City" or open a photo and see the location tag.

Relevant log output

No response

Additional information

No response

Originally created by @hermesespinola on GitHub (Apr 20, 2024). ### The bug I have a bunch of photos from one place that get incorrect location tags. This makes it difficult to correctly search for photos from one particular city. Most of the times it's neighborhood names that get classified as cities, cities as states. Here are some examples: ![image](https://github.com/immich-app/immich/assets/6611754/484bf62d-887e-4c39-bdd2-a9bdc90bd831) - Actual: - City: Paseos del Valle - State: Tlajomulco de Zuñiga, Jalisco - Country: Mexico Expected: - City: Tlajomulco de Zuñiga - State: Jalisco - Country: México --- ![image](https://github.com/immich-app/immich/assets/6611754/1567484c-e11a-4391-9cff-a9fda7d385bb) - Actual: - City: Brooklyn Heights - State: Kings County, New York - Country: United States of America - Expected: - City: New York City (Brooklyn might be alright too) - State: New York - Country: United States of America ### The OS that Immich Server is running on Linux raspberrypi 6.1.0-rpi7-rpi-2712 ### Version of Immich Server v1.101.0 ### Version of Immich Mobile App v1.101.0 build.147 ### Platform with the issue - [X] Server - [X] Web - [X] Mobile ### Your docker-compose.yml content ```YAML Not relevant? ``` ### Your .env content ```Shell Not relevant? ``` ### Reproduction steps ```bash 1. Open up place search. 2. Search for a place that is not a city inside "City" or open a photo and see the location tag. ``` ### Relevant log output _No response_ ### Additional information _No response_
OVERLORD commented 2026-02-05 07:18:18 +03:00
Author
Owner
Copy Link

@mertalev commented on GitHub (Apr 20, 2024):

This is not so much an incorrect classification as it is the fact that we're trying to squeeze four fields (name, admin1Name, admin2Name, country) into three (city, state, country). The "name" part is inconsistent: sometimes it's a city, sometimes it's a neighborhood. admin2Name is also similarly sometimes a county and sometimes a city.

Concatenating admin1Name and admin2Name as the "state" is what we've gone with for now, but it isn't perfect, as you've noticed. Maybe concatenating the name and admin2Name fields would make more sense since they're more "city-like"; admin1Name is generally consistent in being a state/province.

@mertalev commented on GitHub (Apr 20, 2024): This is not so much an incorrect classification as it is the fact that we're trying to squeeze four fields (name, admin1Name, admin2Name, country) into three (city, state, country). The "name" part is inconsistent: sometimes it's a city, sometimes it's a neighborhood. admin2Name is also similarly sometimes a county and sometimes a city. Concatenating admin1Name and admin2Name as the "state" is what we've gone with for now, but it isn't perfect, as you've noticed. Maybe concatenating the name and admin2Name fields would make more sense since they're more "city-like"; admin1Name is generally consistent in being a state/province.
OVERLORD commented 2026-02-05 07:18:24 +03:00
Author
Owner
Copy Link

@mertalev commented on GitHub (Apr 20, 2024):

To give an example, admin1Name is New York (the state), admin2Name is Kings County, and then there are a bunch of neighborhoods like Brooklyn Heights for the name. So let's say we change it to show admin2Name, admin1Name and the country to get Kings County, New York, US. Now if you search for the city "Marseille", you'll get no results because it's listed as a name and admin2Name in this case is a department.

@mertalev commented on GitHub (Apr 20, 2024): To give an example, `admin1Name` is New York (the state), `admin2Name` is Kings County, and then there are a bunch of neighborhoods like Brooklyn Heights for the `name`. So let's say we change it to show `admin2Name`, `admin1Name` and the country to get Kings County, New York, US. Now if you search for the city "Marseille", you'll get no results because it's listed as a `name` and `admin2Name` in this case is a department.
OVERLORD commented 2026-02-05 07:18:29 +03:00
Author
Owner
Copy Link

@hermesespinola commented on GitHub (Apr 21, 2024):

I wasn't sure how Immich is doing the reverse geocoding (and I'm still not 100% sure), but I see you have downloaded the txt files from https://download.geonames.org/export/dump/readme.txt. Is name coming from the file cities500.txt?

First off, I only have context on how this work in the US and Mexico, so I don't know if this is how other countries geographical areas are organized.

Reading the geoNames docs, it seems like admin1Name is considered the first level division of a country, so, at least in the US and Mexico, that's always a state:

grep "US\..*" admin1CodesASCII.txt 
US.AR	Arkansas	Arkansas	4099753
...
US.VA	Virginia	Virginia	6254928

As for admin2, again, in Mexico and the US, second level divisions are counties or municipalities which are not cities, while they are sometimes interchangeable and/or have the same name, using NY as an example:

grep "US\.NY\..*" admin2Codes.txt 
US.NY.001	Albany County	Albany County	5106841
...
US.NY.047	Kings County	Kings County	6941775

What's more, all end in "County". So this doesn't seem useful for Immich, at least not within the 3 location subdivisions that Immich uses.

In cities500.txt it seems there are any other sub-divisions, including neighborhoods, residential areas, etc.
In my examples "Brooklyn Heights" has the P tag "PPLX" which according to geonames docs it's a "Section of a populated place". In the case of NYC, NYC has the PPL tag, and each of the boroughs has the PPLA2 tag. (i.e.: Brooklyn, Bronx, etc.).

As for the Mexico example, "Paseos del Valle [Fraccionamiento]" is listed with "PPL". Then "Tlajomulco de Zuñiga" (which immic got from admin2 according to what you described) is the municipality, not the city, which would be again wrong, if it had a different name to the city. There's a "Tlajomulco de Zuñiga" entry in countries500.txt with the tag "PPLA2" which refers to the actual city :)

@hermesespinola commented on GitHub (Apr 21, 2024): I wasn't sure how Immich is doing the reverse geocoding (and I'm still not 100% sure), but I see you have downloaded the txt files from https://download.geonames.org/export/dump/readme.txt. Is `name` coming from the file `cities500.txt`? First off, I only have context on how this work in the US and Mexico, so I don't know if this is how other countries geographical areas are organized. Reading the geoNames docs, it seems like admin1Name is considered the first level division of a country, so, at least in the US and Mexico, that's always a state: ```bash grep "US\..*" admin1CodesASCII.txt US.AR Arkansas Arkansas 4099753 ... US.VA Virginia Virginia 6254928 ``` As for admin2, again, in Mexico and the US, second level divisions are counties or municipalities which are not cities, while they are sometimes interchangeable and/or have the same name, using NY as an example: ```bash grep "US\.NY\..*" admin2Codes.txt US.NY.001 Albany County Albany County 5106841 ... US.NY.047 Kings County Kings County 6941775 ``` What's more, all end in "County". So this doesn't seem useful for Immich, at least not within the 3 location subdivisions that Immich uses. In `cities500.txt` it seems there are any other sub-divisions, including neighborhoods, residential areas, etc. In my examples "Brooklyn Heights" has the P tag `"PPLX"` which according to [geonames docs](https://www.geonames.org/export/codes.html) it's a "Section of a populated place". In the case of NYC, NYC has the `PPL` tag, and each of the boroughs has the `PPLA2` tag. (i.e.: Brooklyn, Bronx, etc.). As for the Mexico example, "Paseos del Valle [Fraccionamiento]" is listed with `"PPL"`. Then "Tlajomulco de Zuñiga" (which immic got from `admin2` according to what you described) is the municipality, not the city, which would be again wrong, if it had a different name to the city. There's a "Tlajomulco de Zuñiga" entry in `countries500.txt` with the tag `"PPLA2"` which refers to the actual city :)
OVERLORD commented 2026-02-05 07:18:35 +03:00
Author
Owner
Copy Link

@hermesespinola commented on GitHub (Apr 21, 2024):

TL;DR; For "City" it seems to me it'd be good to always exclude PPLX places, as they seem to refer to not cities, prefer to use any tags more specific than PPL, and fallback to PPL otherwise. For State admin1CodesASCII.txt looks to be perfect. But I wonder if this would be a good generalization for other countries as well. I might be interested in contributing to improve this functionality if possible

@hermesespinola commented on GitHub (Apr 21, 2024): TL;DR; For "City" it seems to me it'd be good to always exclude PPLX places, as they seem to refer to not cities, prefer to use any tags more specific than PPL, and fallback to PPL otherwise. For State `admin1CodesASCII.txt` looks to be perfect. But I wonder if this would be a good generalization for other countries as well. I might be interested in contributing to improve this functionality if possible
OVERLORD commented 2026-02-05 07:18:41 +03:00
Author
Owner
Copy Link

@mertalev commented on GitHub (Apr 21, 2024):

That's a great idea! We don't even ingest these tags into the database, much less use them. For reference, we ingest the geodata here and do the reverse geocoding here.

@mertalev commented on GitHub (Apr 21, 2024): That's a great idea! We don't even ingest these tags into the database, much less use them. For reference, we ingest the geodata [here](https://github.com/immich-app/immich/blob/a2180a467d09c01ec41c1481e51c7485d5a82046/server/src/repositories/metadata.repository.ts#L104) and do the reverse geocoding [here](https://github.com/immich-app/immich/blob/a2180a467d09c01ec41c1481e51c7485d5a82046/server/src/repositories/metadata.repository.ts#L151).
OVERLORD commented 2026-02-05 07:18:43 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Apr 21, 2024):

cc @zackpollard, you had ideas about improving the geocoder detail level right?

@bo0tzz commented on GitHub (Apr 21, 2024): cc @zackpollard, you had ideas about improving the geocoder detail level right?
OVERLORD commented 2026-02-05 07:18:47 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Apr 21, 2024):

cc @zackpollard, you had ideas about improving the geocoder detail level right?

Yea, we do have a lot more detailed data available to us, however it needs a lot of sanitisation to be usable for what we want. It should offer some quite significant improvements to accuracy, especially when in built up areas though.

@zackpollard commented on GitHub (Apr 21, 2024): > cc @zackpollard, you had ideas about improving the geocoder detail level right? Yea, we do have a lot more detailed data available to us, however it needs a lot of sanitisation to be usable for what we want. It should offer some quite significant improvements to accuracy, especially when in built up areas though.
OVERLORD commented 2026-02-05 07:18:50 +03:00
Author
Owner
Copy Link

@zackpollard commented on GitHub (Apr 21, 2024):

As for the comments above, yea I have also noticed this behaviour previously, if there is a quick improvement we can make here with that date then I think it would be good to do it, but also yes let's check a few other countries to see if it's the same for them too.

@zackpollard commented on GitHub (Apr 21, 2024): As for the comments above, yea I have also noticed this behaviour previously, if there is a quick improvement we can make here with that date then I think it would be good to do it, but also yes let's check a few other countries to see if it's the same for them too.
OVERLORD commented 2026-02-05 07:18:52 +03:00
Author
Owner
Copy Link

@vernonadams commented on GitHub (Jun 12, 2025):

In some (many) cases, it's not just fitting the names in or picking neighborhood names. Sometimes the names are just wrong. For example, a number of my photos are geocoded to Lexington, Ky, USA (I grew up there) yet many are showing up under Mount Vernon, KY, USA which is quite some distance from Lexington.

It would be nice if the assigned name could be editted.

@vernonadams commented on GitHub (Jun 12, 2025): In some (many) cases, it's not just fitting the names in or picking neighborhood names. Sometimes the names are just wrong. For example, a number of my photos are geocoded to Lexington, Ky, USA (I grew up there) yet many are showing up under Mount Vernon, KY, USA which is quite some distance from Lexington. It would be nice if the assigned name could be editted.
OVERLORD commented 2026-02-05 07:18:54 +03:00
Author
Owner
Copy Link

@dima-ser commented on GitHub (Jul 26, 2025):

This is still very much an issue in the latest version (1.136.0). I got half photos taken in my home town labeled as the neighboring one.

Maybe let us pick which field Immich will use from Geonames? Or use a different provider?
At the very least we could have the ability to merge cities, like we can with people.

@dima-ser commented on GitHub (Jul 26, 2025): This is still very much an issue in the latest version (1.136.0). I got half photos taken in my home town labeled as the neighboring one. Maybe let us pick which field Immich will use from Geonames? Or use a different provider? At the very least we could have the ability to merge cities, like we can with people.
OVERLORD commented 2026-02-05 07:18:55 +03:00
Author
Owner
Copy Link

@Nixon506E commented on GitHub (Oct 30, 2025):

I am seeing the API responding with a county in the state exif property but the web and mobile do not show it. Hoping something just was missed in PR #9051?

@Nixon506E commented on GitHub (Oct 30, 2025): I am seeing the API responding with a county in the state exif property but the web and mobile do not show it. Hoping something just was missed in PR #9051?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#2982
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?