Evaluate addr:city to assign a location and an address to a region

[Framstag]

While assigning locations and addresses to a region we currently rely on simple geometric "is_in" handling. A location and a address gets assigned to the deepest nested region that contains the geographic location of the object. While this works for the vast majority of the cases it does not always work.

To further improve the index (and possibly also for performance reasons) we should also optionally evaluate the value of the addr:city tag. I would suggest to still follow the region tree to it second deepest level and then look for the region with the given name. If no such nest exist we still assign the region my containment. This should solve:

• Lookup of the right region is still fast, since we can pre-index region based on the location using a simple map
• We make sure that we choose the right region even in cases where multiple regions with the same name exist (but on different levels or on different locations). A common corner case is where the city itself contains a suburb the the same name.
• We can push out mapping errors in cases where addr:city exists bt cannot be matched.

See #191 for the issue triggering this change.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[aquiles2k]

AFAIK there is also a "place" key. http://wiki.openstreetmap.org/wiki/Key:place

This gives something like place:town place:village. Perhaps this can be useful too?

[rinigus]

Do we still need it? I have no problems with within search as it is now and suggest to skip implementing this as it may bring more problems than solving anything. I would suggest to close this issue.

[Framstag]

Yes. There are corner cases where addresses for a region outside of the boundaries of the region. The question though is: Will this actually improve the index quality or will be have more errors due to wrong mapping while improving support for the good mapping case?

[rinigus]

I guess we cannot really reply to that question without thorough analysis. And for that analysis, we may just not have resources to do it properly. I don't know any case where it would help. I would suggest to close it until we have these cases and then see whether we can do anything about it.

[Framstag]

Since I want to use the issue list not only as bug list but as "TODO" list, I would like to keep the issue. I share though your opinion that there are more important things to do, especially if we look at "invested time" vs. "feature gain".

I use the Milestone 2017 milestone to tag strategic issue for this year (besides "bug" and "easy to fix" issue of course). I removed it from this list now :-)