Label administrative boundaries by real-world designation

[1ec5]

Search results for Nominatim and Overpass queries now label administrative boundaries according to the real-world designation according to the border_type=* tag. If the value of this tag is unrecognized, the label falls back to a more generic “Administrative Boundary (Level n)”, where n is the admin_level=* value. The English localization no longer attempts to translate these administrative levels to a fictional country’s administrative hierarchy.

Before	After

There are many tagging schemes for the real-world designation, each with their advantages and disadvantages, but I focused on border_type=* for now because it’s the most common scheme globally.

Fixes #5450.

[1ec5]

For starters, I added a translatable string for each of the 30 or so border_type=* values that occur most frequently with boundary=administrative. Only one translatable string is provided per border_type=* value globally. This will likely present a problem for some languages that would translate English words like “district”, “county”, or “town” differently depending on the country. I think we’ll need to add some more specific strings qualified by country code, as explained in #5450 (comment), but it’ll require a bit more research to find out which values are important in which countries.

[tomhughes]

I'm not totally convinced showing the numeric level is useful but generally this looks good apart from the specific point I've mentioned in a comment.

[tomhughes]

I think nil would be a better initial value here given they are going to be strings if any match is found.

[AntonKhorev]

Those are longer prefixes, results often don't fit on one line and have line breaks in inconvenient places:

[1ec5]

I noticed that other boundary types don’t say “Boundary”. For example, boundary=electoral is just “Electoral”. We could shorten “Administrative Boundary (Level 4)” to just “Administrative (Level 4)”, but I’m ambivalent about similarly truncating the border_type=*-based labels, such as “City Boundary”. That would easily get confused with the place=*-based labels; “City” means something different according to that classification system.

Another option would be to drop the level suffix, since @tomhughes doesn’t seem enamored with including this information. To the extent that this introduces ambiguity in the search results, the solution would be to tag boundaries with border_type=*, which is a good idea anyways.

[AntonKhorev]

I noticed that other boundary types don’t say “Boundary”. For example, boundary=electoral is just “Electoral”.

Those are constructed here:

openstreetmap-website/app/assets/javascripts/index/query.js

Lines 91 to 100 in 5d76ec0

	for (key in tags) {
	value = tags[key];
	if (prefixes[key]) {
	var first = value.slice(0, 1).toUpperCase(),
	rest = value.slice(1).replace(/_/g, " ");
	return first + rest;
	}
	}

[AntonKhorev]

I thought about using icons in search/query result lists, like on changeset/element pages. For administrative boundaries it could be something like a square with a border similar to the boundary line rendered on the map, maybe with a number inside for the level.

[1ec5]

Not a bad idea overall, though the numbers probably aren’t as intuitive for many mappers as designations coming from either border_type=* or place=*. I had forgotten about the code to transform an unrecognized tag into a label. As long as we have labels, we could fall back to a format string like “Border Type Boundary” if border_type=* is present but set to an unrecognized value.

[AntonKhorev]

Numbers tell how relatively big/important the area is, something that may not be clear otherwise.

[AntonKhorev]

Shouldn't :default be border_type and place_type correspondingly, given that later the values are combined with place_type || border_type || prefix_name?

[1ec5]

Yes, good catch. I originally had two loops that set prefix_name directly, so your suggestion makes sense.