After lots of Googling, talking on IRC, and futzing with things, I’ve learned how to get Nominatim to properly link boundaries and place nodes, and thus get addressing to work correctly (at least on the county level). I’m assuming this also works at the city level, though I’m still in the process of fixing Texas counties and haven’t tried it with cities yet.

The ‘key’ is in the names and alt_name, and using the ‘label’ role on the boundary relation. For example, “Anderson County, Texas” has ‘name=Anderson County’ and ‘alt_name=Anderson’, while the county node has ‘place=county’ and ‘name=Anderson”. Also, importantly, the county node is a member of the boundary relation, with the role ‘label’.

This is how it looks in Nominatim when working right…. the boundary: the county node:

This is an example of one I haven’t fixed yet, that is still working wrong… the boundary: the county node:

As you can see, in the one that works right, the county node is listed as a ‘linked place’ in the boundary relation entry, and all of the places in the county are ‘addressed’ to the boundary relation instead of split between it and the county node. Also, if you look at the places located in the county, such as you can see that Nominatim is no longer having to ‘guess’ at the county addressing, as it’s now explicit.

I’m also setting the boundary ways as “boundary=administrative and admin_level=6”, but I don’t think this is really essential…it’s more a backup for if those keys get removed from the relation.

Thanks to the people who’ve talked this out with me on IRC, and especially lonvia, who gave the final part of getting it to work correctly. Now, we get to fix lots of counties…


Comment from ToeBee on 2 February 2014 at 19:41

Thanks for pulling it all together into one place. I’ve done a lot of editing of county relations but it is an ongoing process. In particular I don’t think I was aware of the alt_name tag being of use. But it does make sense.

And I agree on leaving the generic boundary=administrative and admin_level=6 tags on the ways. That way even simple editors that don’t handle relations well will still be able to tell users that it isn’t just a tagless way.

Comment from revent on 2 February 2014 at 22:58

Having the tags on the ways also appears to be needed to make the itoworld admin boundary map work correctly, as it does not see the relations.

Note this works off a cached copy OSM (apparently) and doesn’t show recent fixes.

Comment from revent on 3 February 2014 at 08:26

Something else I just learned is that a place node (with a boundary relation) needs to NOT have an is_in field, as it sometimes breaks linking.

Comment from stephan75 on 3 February 2014 at 11:40

Hello revent,

please be aware that the boundary display style from itoworld ist just missing the feature to display boundary relations themselves!

This feature was asked for at the OSM-Wiki page about ito years ago … no enhancement yet.

Instead, please try the service at with grayscale base tiles and boundary overlay at the layer chooser in top right screen corner.

So please don’t tag boundary lines only to get a better display in feature-lacking itoworld display.

Comment from Pieren on 3 February 2014 at 14:54

Note : when the place node is a village or town, the role linking the admin boundary and the place node is ‘admin_centre’, not ‘label’ (which was intended for rendering purpose initialy). nominatim doesn’t distinguish the two roles but it’s better to use the correct one in OSM.

Comment from revent on 3 February 2014 at 22:54

Re the boundary lines, I’m not just adding the keys just for the itoworld display, I was just using it as an indication of how many were missing. As ToeBee put it, to paraphrase, “It’ll prevent editors using feature-poor programs from thinking it’s just a random line”, lol. Thank you for that link, though, it’s much prettier, though it also seems to run off of a cache (I fixed some city lines for Midland Texas that were the wrong admin_level, and they are still shown as county lines). The main point, really, was not to just have completely untagged and unlabeled lines floating around that could accidentally go away, and so the counties wouldn’t break if the tag were accidentally taken off of the relation. It’s one of those things that, if it’s an issue somehow, doesn’t ‘have’ to be done AFAIK, and if it did cause an issue somewhere I could not do it.

Re admin_centre. On the county boundaries, I’m actually setting the ‘label’ role for the county node, and the ‘admin_centre’ role for the place node of the county seat, which from what I read is the intended way of doing it. I’m not messing with any of the cities yet, but I was aware they are supposed to work off just the “admin_centre” role.

Comment from revent on 3 February 2014 at 22:58

Oh, and also re keys on the boundary ways…. I’ve noticed that the JOSM validator does not complain about things like roads accidentally linked to an admin boundary unless the keys are explicitly set on the way, which seems like a bit more compelling reason for doing it.

Comment from maxerickson on 23 January 2016 at 19:54

For future reference, here is an overpass script for checking that each county has admin_centre and label roles, and a wikipedia link:

rel(bn.labels) ->.labelcounties;
rel(bn.admins) ->.admincounties;
(.counties - .labelcounties)->.nolabel;
(.counties - .admincounties)->.noadmin;
out geom;

And a link:

At the moment, most counties are in good shape. The biggest outstanding issues are the independent cities in Virginia and the counties in Connecticut (which are no longer administrative entities). Other than those issues, it’s mostly false positives, where the region does not really have an administrative center.

Log in to leave a comment