Author: dpp
[Added to the original trac issue at 2.00pm, Sunday, 3rd April 2011]

I imagine that when the location is determined, the closest region waypoint is selected. The closest region waypoint is Ogachi, so it is automatically selected. If this is the case, it is probably an issue for all places in Japan where no region is specified. I believe that locations in Japan may be specified as follows: "village - town - city (sometimes doesn't exist) - region (sometimes doesn't exist) - prefecture".

Author: dpp
[Added to the original trac issue at 2.04pm, Sunday, 3rd April 2011]

Also, prefecture is not universal. Could be any of , , , and .

Author: spod
[Added to the original trac issue at 12.23am, Tuesday, 19th April 2011]

If you click on the 'Details' link after doing the search, you will see that it is deciding that the place searched for is inside "Ogachi", which is a 'place=county' node. In the Japan tagging standards:
http://wiki.openstreetmap.org/wiki/Japan_tagging
'place=county' is used to tag a District or Gun.

What follows are my guesses as to what is happening - I don't know anything about the internal details of how Nominatim works - but I have seen a similar address problem when searching for places in Kyushu in Japan!

The problem is almost certainly happening, because "Ogachi" is defined as a node, instead of an area, and is the nearest 'place=county' node to the node you are searching for.

Basically, there is an inconsistency with most of the OSM data for places, because most places are defined as nodes, but they should really be specified as areas. When Nominatim tries to build an address 'hierarchy' for a base-level place, it looks for parent-level places above the place. In this case it finds a 'place=county' node for Ogachi and, because it has no way of knowing the real area referred to by the node, it inserts it into the 'county' level of the address hierarchy. If it finds a number of 'place=county' places, then presumably it selects the one (in this case, Ogachi) that is nearest to the base-level place.

It could probably be solved by correctly redefining Ogachi to be an area instead of a node - then presumably Nominatim would not think that base-level places outside this area are in Ogachi.

As described so far, the problem is really because the data in OSM is not accurate - districts/guns should be defined as areas, not nodes, otherwise it is impossible to create a correct address hierarchy. The same problem can happen if 'place=city' are defined as nodes - Nominatim has to use the nearest 'place=city' to the base-level place, but obviously this might be incorrect for a particular address (the base-level place may be be nearer to another city node than it's real city). If the OSM data is relatively "complete", then the problem is reduced, but if the data is sparse, then the problem gets worse.

This leads to the possibility that there may actually be a problem in the way Nominatim works, that would need fixing for similar cases. For Japan, some places are inside guns, and some are not, so if Nominatim always tries to insert the nearest 'place=county' into the addresses hierarchy, then that is incorrect, because many places do not have a district/gun in their address hierarchy, so Nominatim shouldn't try to insert one.

Author: lonvia
[Added to the original trac issue at 10.44am, Saturday, 14th July 2012]

spod's explanation is correct. The only fix for this issue is to define the guns, cities etc. as areas in OSM.

The problem of missing administrative levels is being addressed, see bug #4247.