Acknowledging provinces in website search results

Communities Canada
, , , ,
1

Due to reasons we probably don’t need to get into, there’s a bit of sensitivity around the terms “state” and “province” these days. Our main website fortunately doesn’t refer to Canada as a state. However, you can get it to refer to Ontario etc. as a “State” due to admin_level=4. Yesterday, we put a change into the main website that should mitigate this issue to some extent:

Unfortunately, this currently only works when you use the Query Features function. Searches still turn up states, such as the State of Quebec. As far as I know, it’s always been this way. (If it’s an American conspiracy, then Mexican, Australian, and German states are probably in on it too.)

State Quebec, Canada; City Quebec, Urban agglomeration of Québec, Capitale-Nationale, Quebec, Canada
State Quebec, Canada; City Quebec, Urban agglomeration of Québec, Capitale-Nationale, Quebec, Canada700×562 30 KB

The culprit is the place=state tag on the relation’s label member, which Nominatim equates with the boundary. Even with the recent change to the website, it still prefers a localized description of the place=* tag over a localized description of the border_type=* tag, because OSM has traditionally described populated places as cities, towns, villages, and hamlets regardless of the official designation.

There was an attempt a few months ago to retag the provinces’ place POIs to place=province, but it was quickly reverted because that tag enjoys much less software support than place=state. Among other things, it caused OpenMapTiles-based maps including OpenStreetMap Canadiana to stop labeling the provinces at all.

Unfortunately, the place=* tagging scheme isn’t well suited to describing political subdivisions that don’t correspond to populated places. It’s supposed to be internationally harmonized in some fashion, but there’s nothing to harmonize about a space-filling partition of a larger political subdivision, other than perhaps its numeric admin_level=*. After all, some of Canada’s admin_level=4s aren’t even provinces, but there’s no corresponding place=territory tag.

How should we solve the issue of mislabeled provinces when searching? Should the website ignore the place=* tag in favor of border_type=*? If so, can the territories be tagged border_type=territory instead? Would it be confusing if searching for Saint-Louis-du-Ha! Ha! turns up a “Parish Boundary” instead of a “Village”?

Or should we nix the place=state points altogether? The U.S. community has all but concluded that these arbitrarily placed centroid points are pointless, so to speak. OpenMapTiles still depends on them, but most renderers including openstreetmap-carto have been capable of automatically generating centroid points for years now, so maybe it’s finally time to rip off the band-aid.

2

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.

I object to calling them mislabeled.

To reiterate what was already said in the discussion on Americanisation of the website: the words used in our tagging schemas only happen to look like English. They have in the meantime developed a meaning of their own. As Andrew Harvey just put it so nicely, we are speaking Openstreetmaplish (en_OSM) here. I have reservations pushing again more towards one or more of the national English dialects. 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. For another, it poses problems in understanding for those who only speak and understand Openstreetmaplish.

3

If I’m understanding this correctly, it sounds like we can just make openstreetmap-website prefer border_type over place for this particular website fragment. That should be correct since border_type captures “how we describe this boundary” vice place which is effectively an enumerated category.

Is there any reason this wouldn’t work?

4

Personally I am fine with deleting the place=* label nodes for Canadian provinces and territories. Their placement is arbitrary anyway.

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?

1 Like
5

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.

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:

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.

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.

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