@kapazao, hoping you can clarify what is "incorrect"?

Hi DaveF, to add more info to explain the reason for change.

I have found that adding the "place=district" tag to the district/borough to appropriately classify the borough in the Nominatim API. Even with the guidance on the page you provided (setting admin_level =8 plus boundary=administrative), without the "Place=district" tag, the borough relation is classified as a "town" in Nominatim.

That seems certainly incorrect to me; the borough can contain towns, but is not a town in itself. So the borough is misclassified in the API, and the towns within the borough do not have available the borough information via the API.

To show you an unmodified example of this situation, see borough of Rochdale:

https://nominatim.openstreetmap.org/ui/details.html?osmtype=R&osmid=146926&class=boundary

The Borough is marked as a "town" in Nominatim. In reality, the Borough of Rochdale is separate from the town of Rochdale. And other towns within the borough (for example, Littleborough) do not carry the borough/district information within the API response:

https://nominatim.openstreetmap.org/search/?format=json&addressdetails=1&limit=1&polygon_geojson=0&city=littleborough&country=gb

Contrast that with the API information for Glastonbury, within the borough of Mendip, which now has the right borough/town relationship available:
https://nominatim.openstreetmap.org/search/?format=json&addressdetails=1&limit=1&polygon_geojson=0&city=glastonbury&country=gb

Acknowledging that the "place=district" tag is not recommended for use, the existing documentation does not sufficiently explain the steps to make sure the district-town relationships are appropriately represented in the API. If there are alternative steps or processes in place, I'd definitely need to understand the "correct" way of doing things. I hope however, above explains why the change isn't necessarily introducing anything redundant.

Ok great, I'll follow this pattern going forward, and will make sure I revert the boundary that I added. Apologies if I altered your hard work, you've clearly put a lot of love into this.

Thanks for the additional information. So in this case, would it be more appropriate to place a Node representing the location of the town of st helens instead of a relation/ boundary?

Hi Colin, if you have any additional documentation that I can refer to regarding how the UK boundaries are implemented within OSM I'm happy to follow; I'm relying on this but it seems incomplete:
boundary=administrative#10_admin_level_values_for_specific_countries

Hi Colin, I lived in UK for several years , and admittedly while I don't understand the administrative and electoral boundary system to the granularity that you might (which probably puts in the same category as most people in the UK), I'm trying my best here to translate available information into tangible improvements to the data on OSM, which does not seem complete with regards to the relationship between boroughs/ districts & the sub-units incorporated within.

In this specific case, I'm trying to differentiate the entities of St Helens borough (preexisting) and St Helens the town which is within the borough. What is your guidance on how to do so?

Hello, I sourced from this OS data source. Officially, it is a "district ward"
https://data.ordnancesurvey.co.uk/doc/7000000000042418.

My interpretation here is that a district or borough (in this case, district of st helens (https://data.ordnancesurvey.co.uk/doc/7000000000006000) is subdivided entirely into a combination of "district wards" and "civil parishes" you will see the list on that page. The "district ward" and "civil parish" are at the same level of division The wards and civil parishes comprise the 16 "electoral wards" of St Helens .
(https://en.wikipedia.org/wiki/Metropolitan_Borough_of_St_Helens).

Hello, I will make additional amendments to correct. I was trying to differentiate the boundaries of the borough of st helens (already exists,
https://en.wikipedia.org/wiki/Metropolitan_Borough_of_St_Helens ) and the town of st helens (https://en.wikipedia.org/wiki/St_Helens,_Merseyside) , whose current OSM entry does not sufficiently differentiate with the surrounding villages. I will correct.

Hi bora, hoping you can clarify the documentation

To explain rationale for change:
First breaking down the specific decision to be made:
* Based on the Wikipedia articles,
https://en.wikipedia.org/wiki/Rochefort,_Belgium
https://fr.wikipedia.org/wiki/Rochefort_(Belgique)
Rochefort is a commune (municipality) and a "ville belge" which also indicates a commune /municipality level.
* As you pointed out, there are multiple preexisting entities for both--nodes, relations etc.
* The question is, does this node pertain to the municipality / commune, or the town?

I made the decision to add a "municipality" tag based on following information:

* Based on administrative level documentation on Nominatim wiki (boundary=administrative#admin_level.3D.2A_Country_specific_values)
the admin level 8 for belgium corresponds to "municipality"
* all preexisting tags on the node correspond to the commune / municipality , including the wikidata code and the INS code 91114 , which is the national statistics agency code for the commune (https://statbel.fgov.be/sites/default/files/Over_Statbel_FR/Nomenclaturen/REFNIS.xls) .
* The population number also seems to correspond to a commune/municipality level based on government info (https://statbel.fgov.be/fr/commune/rochefort#dashboard1)

* Also noting that there is a separate wikidata entry for Rochefort as a town. Q66312004, already tagged on the Rochefort- town entry

https://nominatim.openstreetmap.org/ui/details.html?osmtype=R&osmid=3715354&class=boundary

* This change also allows for the proper classification of the other villages within the Rochefort municipality; for example, previously Han-sur-lesse (https://nominatim.openstreetmap.org/ui/details.html?osmtype=R&osmid=3715236&class=boundary) was marked as a village within the town of Rochefort. Now, it is marked appropriately as a village within the municipality of Rochefort (which is the appropriate relationship according to https://en.wikipedia.org/wiki/Han-sur-Lesse and

Apologies for not responding in a timely manner, I am now seeing the changeset comments that you sent and am responding to them.

no need for review

HI bora, thanks for guidance. is this documented somewhere? I want to stay in line with existing standards, if any

I've seen and used that key in a few circumstances, particularly when the path to trying to fix the state information is not obvious...sometimes it's fairly obvious why the information isn't there (usually due to an intermediary later not having the correct information), but doign that diagnosis not always possible.

I am very happy to participate in any effort that cleanses the data scalably.

That's understood, but the data has to be set up in a certain way to flow through the API.

Another example:

Bulli tops near Wollongong. Via API, were state is not populated:

https://nominatim.openstreetmap.org/search/?format=json&addressdetails=1&limit=2&polygon_geojson=0&accept-language=en&extratags=1&q=bulli%20tops&state=new%20south%20wales&country=au

Am finding multiple examples of blank state /territory info, one would think the points within the polygon would inherit the state info from the polygon, but that's not happening in a number of cases.

Hey, thank you for the feedback. I"m just getting my feet wet with these edits, so apologies if I messed something up. I was trying to re-map the adminstrative level to the city instead of the suburb for the "label" --because the administrative level did not have the state name populated. I'm pulling some data for Australia via the API, and there are a number of items where the state-level data is not populated. Thanks for letting me know how to do it better next time!