If it is signposted, there is a case to be made for using it in `name=` . But the most common name from addresses of the tenant seems to be "Facilities" . That's why I asked. Signs can also have problems. It's complicated.

Ok it's not. But it's the same minor mistake.

@Patrickov This is fixing a previous changeset. It's fine.

Are you sure?

Village names should not be added to the `landuse=residential` . Housing estates inside a village are separately drawn and named, but are still part of the village. `addr:place=` and `addr:village=` / `addr:hamlet=` (some village don't use village name address numbering) is enough.

On the contrary, this cause duplication on finding data centers. You still have to de-duplicate them. If there is no site drawn, only individual buildings, this becomes impossible. `telecom=data_center` is conceptually one facility.
Your example still doesn't qualify them. Does it matter if there's a separate building for the internet connection or control room? Is it "part" of the data center? Also for size, you want to count floor area, not number of individual structures.
It's very common flaw to specify such `building=` to be one-to-one with the facility. This won't do what you want, because people will still tag everything inside a `telecom=data_center` as `building=data_center` blindly. I recently discussed `building=fire_station` , and it may be used on all buildings, not only the main fire truck depot building with duty station.
It is a very common documentation shortcoming to require combination with `building=` . `man_made=works` was once such case, later corrected to be used on the entire site.
Problems with `building=data_center`:
https://taghistory.raifer.tech/?#***/building/data_center
1. Significant use come from mass modifications
2. Only ~350 in 2020
3. Relatively small number for a `building=`
4. Continued issue with British vs American English
I find it prudent to exercise caution on creating more `building=` .
Relatedly, it already won't work for `telecom=exchange` . `building=exchange` is meaningless. Creating `_exchange`=* for `=telephone_exchange` etc is unscalable.

Please don't add descriptor labels to `name=` . That's for proper names only. It should be akin to what it would be named after completion.

You misunderstood this. There is already `telecom=` on the `landuse=industrial` way/854227561 of the site. That `industrial=` is for the `building=` , because I don't agree with `building=data_center` yet. This would cause duplicate `telecom=` features.

Please don't delete them directly, as they contain an address, and represents a shop space. Change it to a plain "point" , which removes the tags.

You misunderstood the situation. The original park is of course by LCSD. That's not related to who the new part's underground or frontage belongs to.

Please don't include objects inside as `inner` . They are part of it.

Please notice that the 2 `inner` has been wrong included here. They should be excluded.

Please don't delete it directly, as it contains an address. Change it to a plain "point".

`access=military` is not standard. At least `private=military`

1. Please don't use `historic=castle` for non-"historic" features. This is fake and misleading.
2. `tourism=attraction` should not be used for individual `attraction=` inside a `=theme_park` . This is meaningless duplication and pollution.

This is a rock under the mountain Lion Rock. Local names won't be translated accurately.

I mean if you take it to the extreme, it won't be realistic to split it based on whether construction has started on each section either. The exact flow belongs to OpenHistoricalMap.
The project ceremony commenced at the end of last month. Temporary sites have already been handed over before. Contract signed with contractor this week.
Also remember OSM is not always updated frequently in applications.
Other `proposed:*=` features are much more loose. You won't put Route 11 and Tuen Mun Bypass in the same namespace as this.

Please don't remove addresses. They should be preserved somehow.

You can at least discuss why they should be deleted? Unneccessary doesn't mean not accepted.

Warning:
This guy (GSF1200S), knowing nothing about the difference between different users, accuses others of doing things they didn't do on random changesets of others.