Acknowledging provinces in website search results

[Minh_Nguyen (Minh Nguyễn)]

@lonvia

The border_type tag is returned as part of Nominatim’s response. You can simply use the same magic that you use for the query function when you have an object with a class place and an additional tag border_type.

As you can see from the linked post, the website already is using border_type=* for Nominatim search results too, but it prefers place=* over border_type=* in case it refers to something like a city or hamlet that the user was more likely searching for than the boundary that belongs to that city or hamlet. We could always prefer border_type=* over place=*, but probably nix “Boundary” from the label so it looks more like we’re ignoring place=* altogether.

@lonvia

For one thing, as you correctly state, it has real political implications and the push towards American/Canadian/British/Australian terminology leaves us vulnerable to serious edit warring.

I’m afraid this might be a misreading of the political context in which the website change took place. The linked thread goes into more detail. On the other hand, misunderstanding about place=* is one of the common causes of disputes and edit-warring in OSM’s history. Examples include:

• New England place name inflation
• [Talk-us] Place classifications / Changeset: 28183982 | OpenStreetMap
• Changeset: 134794693 | OpenStreetMap
• Probably others in User:Minh Nguyen/Place classification discussions - OpenStreetMap Wiki that I’m overlooking

The distinction between “state” and “province” is a national distinction, not a dialectal distinction. Americans like me have no qualms about referring to Ontario as a province.

@lonvia

For another, it poses problems in understanding for those who only speak and understand Openstreetmaplish.

I certainly wouldn’t want to be accused of discriminating against the native-speaking OSMian minority, but this change was actually a response to charges of anglocentrism. These strings have always been translatable, but the accusation is more specifically that the website favors the U.S. administrative structure over that of other countries. The irony, of course, is that the former admin_level=*-based labels didn’t correspond to any country at all when viewed as a set.

In the past, some localizations had to translate the admin_level=4 string to mean “State or Provincial Boundary” if the language doesn’t have a convenient word for both, as German does, but other localizations didn’t bother: for example, Esperanto translated it as “Provincial Boundary” while Interlingua translated it as “State Boundary”.

Now each localization can translate the terms more specifically. As of writing, “province” and “state” have been translated into three languages besides English, with room for many more. These translations landed a few hours ago and will be live on the site shortly.

@Jarek

Is there a major technical reason that prevents OpenMapTiles from labelling in centroid of area, or is it a “mere matter of implementation” that noone has done yet?

Probably just technical debt on OpenMapTiles’ part. In a series of unfortunate events, it even relates to OpenMapTiles support for the Gulf of Mexico:

@ZeLonewolf

Another valid possibility is to support place=sea area features like this one in the renderer, so if people feel that the way Gulf of Mexico is mapped is an acceptable way to map a large sea, I would submit a PR to OpenMapTiles to add that support. However, I’m inclined to classify this class of object as a tagging error.

Important sea labels missing in water_name