Skip to content

Conversation

@AyushDharDubey
Copy link
Contributor

@AyushDharDubey AyushDharDubey commented Dec 11, 2025

Closes #2463

This PR adds a fallback lookup that uses the persistent search_name table when the update information tables have been dropped. The existing lookup logic remains the primary path; only when an undefined_table exception is raised do we resolve the road via search_name instead.

The new getNearestNamedRoadPlaceIdSlow function leverages the existing idx_search_name_name_vector GIN index, which efficiently filters candidates by checking overlap between name_vector and the provided token_info, keeping the fallback reasonably fast (still slower than getNearestNamedRoadPlaceId).

Copy link
Member

@lonvia lonvia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, that's the general direction I had in mind. I added a few inline comments,

There is a little gottcha here: the table search_name might not exist either, when Nominatim was set up in reverse-only mode. You could in that case fall back to doing name matching on placex entries or just tell the user that import is not possible.

@AyushDharDubey
Copy link
Contributor Author

Hello, thanks for the reviews. I’m still getting familiar with parts of the codebase. Going through the sql-preprocessor code was very helpful.

the table search_name might not exist either, when Nominatim was set up in reverse-only mode. You could in that case fall back to doing name matching on placex entries or just tell the user that import is not possible.

based on my understanding, falling back to name matching on placex would be prohibitively slow for practically large databases, thus I’ve leaned towards explicitly reporting that the import is not possible in this configuration.

Copy link
Member

@lonvia lonvia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tested this against a planet database. It's fairly fast but it leaves quite a few interpolations unmatched because the street name doesn't fit well enough. It would be good to have a replacement for getNearestParallelRoadFeture() as well which uses the placex table (again address_rank between 26 and 27 only) to find any parallel road.

@AyushDharDubey AyushDharDubey force-pushed the fix/issue_2463-Use-search_name-table-for-TIGER-data-imports-on-'dropped'-databases branch from fc02d24 to 5063b08 Compare January 9, 2026 11:41
@AyushDharDubey AyushDharDubey force-pushed the fix/issue_2463-Use-search_name-table-for-TIGER-data-imports-on-'dropped'-databases branch from 5063b08 to eefd0ef Compare January 9, 2026 12:30
@AyushDharDubey
Copy link
Contributor Author

AyushDharDubey commented Jan 9, 2026

Thanks for testing over planet db. I have added placex lookups for both parallel and nearest roads respectively, also squashed and force-pushed for cleaner commits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use search_name table for TIGER data imports on 'dropped' databases

2 participants