Discrepancy between address levels and tag labels?

[darkostanimirovic]

Customizing address levels is possible with the address-levels.json config file.

However, when those levels are used to determine the label tag for output, it looks like Nominatim just divides by 2 and uses that to determine the administrative level again.

This doesn't always play well together.

For example, if I state in my address-levels.json file that "administrative8": 18 I clearly want 18 to represent lvl 8. But when I query Nominatim, it will divide by 2 for some (undocumented) reason.

The getBoundaryLabel() hard-codes the map between levels and labels:

static $aBoundaryList = array (
                             'default' => array (
                                           1 => 'Continent',
                                           2 => 'Country',
                                           3 => 'Region',
                                           4 => 'State',
                                           5 => 'State District',
                                           6 => 'County',
                                           7 => 'Municipality',
                                           8 => 'City',
                                           9 => 'City District',
                                           10 => 'Suburb',
                                           11 => 'Neighbourhood',
                                           12 => 'City Block'
                                          ),
...

So my 18 now becomes 9 which is "City District" and not 8 as I specified in the config file. I guess for a newcomer to the project, this is a little confusing. My intention was to have complete control of which address tags are used, and ideally the label of the tags. If not directly the labels themselves, then at least how they map between address levels to labels. I hope that makes sense!

I suggest:

1. Document why division by 2 is happening. It sounds like manipulating address levels needs this context. I can probably design my address levels a bit better with this in mind.
2. Make the label map configurable as well so that we can fully customize the API output. So perhaps a new JSON config file which maps address ranks to different labels.

Thanks for reading this far and sorry if I'm missing something obvious.

[lonvia]

I think you misunderstand the purpose of the rank assignment. Search and address ranks are fixed Nominatim-internal concepts. The meaning of the numbers is explained in the documentation The choice of numbers were indeed initially derived from admin_level*2 but this is more of a historical curiosity. With respect to labeling, the address rank is the one that is relevant for you. And, yes, the meaning of each address rank is hard coded. That is the whole point of its existance: to create a consistent point of reference about where a in the address hierarchy an object should be placed and what kind of real world equivalent there is.

address-levels.json can be used to assign each OSM object the appropriate address ranking. When you state "administrative8": 18 then you state that a administrative boundary with admin_level=8 should be assigned a search and address rank of 18. Not the other way around.

Nominatim does not support customized labels at the moment.

[darkostanimirovic]

Let me try to explain it better:

1. In my OSM data, cities are tagged as administrative level 7.
2. In the Nominatim docs for address ranks, cities are in the range of 13-17.
3. I choose 13 for the rank: "administrative7": 13. <-- Am I doing this wrong?
4. Nominatim API labels this as a municipality. (13 / 2 = 6.5 = 7. The hard-coded array specifies 7 => 'Municipality')
5. My expectation is that it would label it as a city instead.

Thanks for helping me navigate this. I'm pretty sure I'm missing something obvious as I'm new to the project, but I don't yet see what exactly. Is my expectation above wrong?

[lonvia]

The documentation gives you the coarse-grained grouping of address ranks. The labeling uses a finer sub-grouping which further splits city into 'Municipality' and 'City'. The code you cite above gives you these subgroups. Again, you need to do your calculations the other way around because the address rank is the fixed part: if you want the sub-group 'city', then that is 8 * 2 => address rank 15 and 16.

[darkostanimirovic]

Thanks, I'll give that a shot.