Proposal to enable wiki for place=subdistrict

Proposal:

place=subdistrict is a subdivision of a district used for administrative or other purposes.

See Subdistrict on Wikipedia for more details.

Context:

Thailand’s administrative divisions include provinces, districts, and subdistricts.

In OpenStreetMap (OSM), we have place=province and place=district, but there’s currently no place=subdistrict tag.

Normally, I’d consider reusing an existing place value like place=county, but I noticed that place=state, which is equivalent to place=province, already exists.

Additionally, I found that addr:subdistrict is already in use for addresses.

Is there a specific reason why place=subdistrict hasn’t been documented yet, apart from the fact that subdistricts haven’t been mapped extensively yet?

Is there a specific reason why place=subdistrict hasn’t been documented yet, apart from the fact that subdistricts haven’t been mapped extensively yet?

I’d rather ask the opposite question: what’s the purpose of place=district, province or county? Isn’t boundary=administrative with appropriate admin_level sufficient?

2 Likes

Good question! It seems that mappers often use “place” for administrative boundaries on top of mapping its areas. I’m quite curious about the reasons behind this choice.

Is it mainly for how it rendering on maps (custom label location) ? Or does it have broader uses, like being picked up by geocoding services or routers? I have asked this question in this other related thread:

First of all, you don’t need to ask these questions. A wiki means you can go ahead and do it.
But foremost on the topic, having “District” and “subdistrict” as the translation of a subdivision doesn’t mean you must use place= district= and =subdistrict . Eg in India, it could be a =town . In PRC, “street” Subdistrict is a =suburb . Avoid using them first, unless no other standard one fits.
As a corollary, addr:*= doesn’t need to be exactly the same as the place= . It seems India is using addr:subdistrict= , while it has been said there’s no consensus or standard.

I am not asking permission to create a new wiki page, I am asking if it makes sense or not :slight_smile: e.g. creating a new tag might not be supported by renderers/routers.

Thailand has also special cases which have been covered already with other place tags in the Thailand wiki. However currently we do not have any place tag recommended for subdistricts.

As dieterdreist said above, we’re quite skeptical about practical value of such tags…

place tags were originally intended to map cities, towns, villages and named localities that can be represented by a single point on a map, i.e. something that can be rendered from a single point.

However, later on we devised the boundary=administrative relation schema, whereby one can draw administrative areas, i.e. named places represented by areas. Those have an additional advantage that they unambiguously “contain” other map features, e.g. a city boundary can be used to determine all addr:city values without explicit tagging.

As you know, the convoluted relationship between the values of admin_level and country-specific administrative units is documented at Template:Admin_level.

Now, in my worldview, some places are inherently administrative, bounded by areas, and hence should be represented only by administrative boundaries. Those are certainly macro-regions such as states and provinces, and I don’t see the need for place=state or place=province. Same goes for “micro-regions” such as districts and subdistricts – if they always have well-defined borders, and an ill-defined center, they’re better represented as administrative boundaries than as places.

P.S. It would make certain sense to have place tags used along with admin_level to provide a human-readable information about the boundary. For example, tag the Canadian province of Ontario with admin_level=4; place=province to explicitly specify “in Canada, this is second-level division called a province”. However, currently we have a node named Ontario tagged as place=state at an arbitrary location, which is used as role=label within the admin_boundary relation. That’s just… bad.

2 Likes

I think some “districts” are informal, used to refer to an area that used to have a predominant industry but doesn’t anymore.

For such “districts”, a place=quarter would do the job just fine.

I regard the place taxonomy as a best-effort attempt to standardize place types across the world, with approximations and judgment involved, not as a free-for-all affair (despite “any tags you like” mantra). So, in my opinion, expanding the list of values with ever more country-specific ones is not beneficial.

For example, in my part of the world a common occurrence are “weekend settlements”, featuring more or less concentrated weekend houses with allotments, with only a few permanent residents, but having a couple of amenities such as restaurants and grocery stores. Those typically arose in the last 50-100 years, are not incorporated, and thus have no administrative area. But for most of them, place=hamlet does the job, even though they don’t quite fit the definition, rather than inventing a place=weekend_settlement or something.

Thanks for the valuable explanations!

It is. I think it’s ok that place is used for administrative boundaries but it should be available on a single element, otherwise it breaks the One feature, one element OSM concept.

I wonder why renderers require place and name tags on the node with role=label, so I will try out and report.

The “one feature one element” rule is very relative, because there aren’t features in the real world, it is us who define features by creating a tag for them. We could just say “place” on a node is about the center of a place, and place on a polygon is about the area of a place, so that both could coexist, because they describe different “features”.

1 Like

place= is an abstract concept of a community, which can have many different interpretations on its extent. boundary=administrative is a precisely defined official border. They are different. This doesn’t violate the principle.

2 Likes

Well no, they should not coexist, not with the same tags. Draw either a point or a polygon, but not both.

What are arguably different things, but with the same name, are a place and its administrative area. But not every place has a formally defined administrative area, or is an admin_centre of one.

And in turn, there are administrative areas which are only defined by their legal boundaries, not by a strong association with a pre-existing settlement. Hence, those do not need a place tag. Like I said, those are states, provinces, most US counties, and probably districts and subdistricts in most countries (although situation may vary by country, I’m only operating with the common notion of “district”).

2 Likes

Update: I’ve gone ahead and crafted a new wiki entry for place=subdistrict to better align with Thailand’s complex administrative levels.

Although I agree that place=* should be exclusively added on nodes, I’m still grappling with how to address the issue of duplicated and inconsistent names on both relations and their label nodes.