5. Don't use uppercase

4. Please stop adding "號" in `addr:housenumber=`

1. Please stop adding lot info on `landuse=` directly. This is not the standard practice locally.
2. Please don't duplicate the same info on every `building=`
3. Please don't delete other objects you have no concern in. They have other uses.

On the contrary, there are footbridges between buildings that aren't enclosed, eg Central Elevated Walkway between Hang Seng and 100 QRC (considering Exchange Square section to be a separate section). Or they may connect between "outdoors" part at the top of the podium (Can't think of an example yet, but Yeung Uk Rd Market has an outdoor hub at NIna Square). Then these may not be `building=bridge` .

For clarity, what I had in mind:
One-sided enclosed footbridges: Kwun Tong Apm, Quarry Bay Station Taikoo Place, Standard Chartered Bank Battery Path
Long `=viaduct` type examples: Tsuen Wan Station Discovery Park

Of course, many other `bridge=covered` are mistakes...

If something is considered a `building=bridge`, thus `indoor=yes` , logically the `bridge=yes` might be redundant. This is especially the case in more significant `building=bridge` (depending on interpretation` ) eg IFC across Man Cheung St as actual "buildings" with shops inside.

For `aeroway=terminal` + `building:part=` which I can't quickly find yet, what I thought is it's common for 1 `building=` to be divided into domestic and international terminals....

Ok maybe they aren't, but as I said, this definition of `=terminal` is overly dependent on `building=` vs `building:part=`

Still, why should connector parts that don't check-in or access to aircraft be `=terminal` ? I don't see any reason in that. As you may have asked above, this causes questions on other connectors, people mover stations, train station, parking, etc.

I don't understand your take on `aeroway=terminal` + `building:part=` cases. They are proper terminals, not `=concourse` . By such definition, only `aeroway=terminal` + `building=` is valid. Are they wrong?

It's unclear how others deal with them, https://en.wikipedia.org/wiki/Covered_bridge#Roofed_bridges
The 2 Vietnam examples seem to be "covered bridges" https://en.wikipedia.org/wiki/Covered_bridge#Roofed

If these are defined as `bridge=yes` + `indoor=yes` (what's the use of `covered=yes` then?) , it creates the question of why aren't fully enclosed `bridge=covered` the same? The presence of openings that aren't covered by windows?

Originally, it wasn't defined for timber only osm.wiki/w/index.php?oldid=1550838#Bridge_key:_ways_and_relations

Admittedly, `=covered` is used for "covered" wooden bridge. But that could be `covered=yes` + `bridge:material=wood` . `indoor=yes` don't fit for these, unless you consider these to be `building=bridge` , which is inapplicable.
As a side note, a "skyway" is connecting the higher levels of buildings. That's difficult to define here, as the bus terminal side is not very indoors.

`bridge=yes` + `indoor=yes` would be a a walkway on a bridge indoors. It would further be interpreted as indoors of the landscape deck here, which doesn't have an indoors space. `covered=yes` is for the top only. They don't describe the sides.

Please stop deleting and redrawing randomly. You are removing info as well.

Please don't delete `=footway` connected to a `=pedestrian` . They are needed to make crossing across it anywhere work.

Please don't add lot info as `landuse=` . This is not suitable.

The other situation aside from concourses is when the domestic and international, or departures or arrivals (apparently the case in CDG T3) in 1 terminal.
Many `=terminal` in France seems to be wrongly added by `source = cadastre-dgi-fr source : Direction Générale des Finances Publiques - Cadastre. Mise à jour : 201*`

Another example of connector section having `=terminal` in CTS way/1106836257
Using `=terminal` to mean this is a terminal building simply conflicts with the idea of this is 1 terminal/concourse where there are multiple `building=` .

For named ones, eg Brussels certainly have `=terminal` as the 2 piers, but `=terminal` is also wrongly used on the connector section. Are there 1, 3, or 4 terminals? Worse there is a 5th way/367788803 for the military part. Applications can't make use of such ill-defined data reliably. That's why expanding the use of `=terminal` is poorly conceived.
Maybe you agree `=concourse` can at least be used inside one `building=` . What about others that think it's fine to use `=terminal` on every "part" of the airport? The definition of `=terminal` is best not be diluted and turned to meaningless.
In CDG where `=terminal` is used for separate satellite concourse `building=` , the "Liaison" section between 2A and 2C also has `=terminal` added. way/141149076

1. The question is at the same time about why should overlapping `=terminal` inside another one be valid. This makes them redundant, and causes definition and consistency problems. Besides, how do you know why they exist as `=terminal` + `building=` ? Users may not know other solutions, they didn't touch the `building=` , or someone like you added the`terminal` back, etc. There are many possibilities. What I want to show there is as titled, and your point 2, about the possibility of `=terminal` `=multipolygon` without `building=` .
3. They can still understand the `building=` . What's the difference? When they need more detailed info, they have to look at `building=` , `building:part=` , etc anyway.
4. Skypier is a different tab or bookmark, They are simply shown as next to each other on the map. What I want to ask is if main T1 + NSC is 1 `building=` , how should the `=terminal` be handled? If the examples show `building:part=` + `=terminal` is also used, is `=terminal` really defined as always `=terminal` + `building=` ? Many `=terminal` are also wrongly duplicated.

There are 5024 `wr[aeroway=terminal][!name];` results , that's more than half of the 9804 instances in total. Many could be valid as the unnamed only one in many small airports, but many more look invalid as being close to each other. It seems `=terminal` is not mostly used properly.