Take geography into account for address computation #617
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use the more complex way of computing the address from Nominatim for computing the rank 30 address. That makes sure that address parts are not blindly taken from the parent but geographic relations are taken into account. When streets go over boundaries, all address fall then into the right side of the boundary. Requires advanced SQL which is not supported by H2. Thus use the previous simpler query for tests instead.
|
I pulled this branch, compiled with Loaded the Nominatim DB with data only from Hyderbad, India. Total no of records imported by photon: 18983 The address hierarchy issue appears to be fixed with this branch on testing a few data points. |
|
This isn't really working as intended. Trying a different approach. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use the more complex way of computing the address from Nominatim for computing the rank 30 address. That makes sure that address parts are not blindly taken from the parent but geographic relations are taken into account. When streets go over boundaries, the addresses along that street will be corrected as necessary according to the administrative entity that contains them. See also Nominatim PR osm-search/Nominatim#2082
Requires advanced SQL which is not supported by H2. Thus use the previous simpler query for tests instead.
Sadly, this PR is incompatible with #547. If it gets merged, then import time will again increase by around 50%. So it would be useful if others tested this a bit to figure out if it is worth the performance loss. I haven't made up my mind yet if I want to merge it or not.
See also discussion in #609.