Please note 深圳地铁前海车辆段 is a subway depot building above ground, so please DO NOT remove the building label. :)
I will fix it for this time.

感谢修正以及提供的额外信息，之后会再确认下。

注意到阁下在此编辑中新增了多个并未投用的车站，且在name中添加了描述性的“（建设中）”字样，这违背了OSM的数据规范，此情形应当使用生命周期前缀（lifecycle prefix）如construction:railway=station，而非在name中添加描述性文本。请阁下参考以下wiki页面：https://wiki.openstreetmap.org/wiki/Lifecycle_prefix
osm.wiki/Names#Name_is_the_name_only

注意到阁下将深岑高速深中大桥路段的name修改为桥梁名称，取代原有的路名“深岑高速”，这种做法不符合OSM Wiki指引，桥梁名在已有路名的情况下可放于bridge:name中，具体请参考=* bridge:name=* ，本人据此以修改集 #153362912 恢复此修改集中有关修改，烦请阁下根据指引进行后续编辑。
---

Published using OSMCha: https://osmcha.org/changesets/153358167

Please note, unfortunately, these land uses I sticked together share fences between each other. There is no way to represent the shared status other than sticking them together.

你好，根据OSM Wiki关于dual carriageway的指引，未作物理隔离的道路“不应被”双线化，这是被明确的标注规则，烦请阁下注意。请参考 osm.wiki/Dual_carriageway

注意到阁下在此Changset中将南山区后海片区海德二道进行了双线化，此路段应该并没有永久性的物理隔离。根据osm.wiki/Dual_carriageway ，没有物理隔离的道路不应被分离为两条对向行驶的`highway`。请问是该路段有新增永久性的物理隔离设施？若未新增，或在14天内没有得到阁下回应，我将退回至此前版本。=*

By saying “keep following the mainstream practical usage”, I mean the original tagging in HKIA. At the same time, it's totally fine to add some extra tags to make it detailed information like the 5 indoor concourses.

I don't think `aeroway=terminal` + `building:part=` is a good idea. "1 `building=` to be divided into domestic and international terminals" seems to be the operational perspective. They should be different indoor features in the same `aeroway=terminal` + `building:=`. If they just use 'Domestic SECTION' and 'International SECTION' as names, but everything else as the same, do you still think they should be separate `aeroway=terminal`? what about if the domestic and international terminals are in different layers in the same building?

What makes me think mapping the BRU connecter building as `aeroway=terminal` is reasonable, is that it is completely in the airside of the terminal, and took on partial functions to transfer passengers between airside (Pier A) and landside (main building).

I now understand that our core disagreement is whether the `aeroway=terminal` label is from the operational perspective or building property perspective. Your idea is that the tag describes the airport's operational organization, which could be so varied from airport to airport that it would be hard to establish a unified worldwide
understanding in OSM. My opinion is that the tag describes the building function of transferring passengers between the airside and the landside, and it's the currently used one in practice. I don't deny the reasonability of your point of view, but it's better to keep following the mainstream practical usage.

Reply to Kovoschiz:
Again, let's take the Carto as an example of data parser understanding (not "map for renderer"). Only `aeroway=terminal` + `buidling`=* is understood correctly to be rendered as the expected deeper color (usually used for public transportation buildings) described in Wiki. This is documented usage. So before `aeroway=concourse` is discussed (not only by two of us) and documented formally, I do not think it is proper to substitute the current practice of tagging all buildings used for checking in, boarding, or baggage stuff as `aeroway=terminal` + `buidling`=*. It will cause data misunderstanding.

To my knowledge, if we want to deal with the overlapping problem, we should use `type=site` relation instead of `type=multipolygon`. Accepting `type=multipolygon` is a compromise to the practice.

Back to the cases raised:
1. Unnamed terminals: small airports data are highly possible to be not maintained well;
2. BRU: Structurally, the terminal consists of 4 connected buildings. It's proper to tag them separately. `aeroway=terminal` on a `building`=* describes the property that the building is used for passengers to transfer between aircraft and ground transport. the connecter building clearly takes part of the responsibility for transferring passengers from Pier A to the main building. As for the 5th one mentioned, I don't think that is a `=terminal` since it not serving passengers.
3. CDG: The liaisons are in the same situation as the BRU connector I think. The separate building of T3 follows "`aeroway=terminal` on a `building`=* describes the property that the building is used for passengers to transfer between aircraft and ground transport."
4. CTS: the connector is in the same situation as the BRU connector. The building is structurally independent.

I don't think an `aeroway=terminal` has to be the whole "terminal" in operational concept, instead, every building used for the purpose of checking in, boarding, baggage stuff or so should have the `aeroway=terminal` tag to specify that the building has such function.

Let me reorg the discussion:
1. Every single building used for boarding purposes should be an `aeroway=terminal` + `buidling`=*, because `aeroway=terminal` on a `buidling`=* describes the property of usage instead of strictly indicating the whole terminal, which is the practice in OSM. All the examples raised by you (Except FPO) are notated as `aeroway=terminal` + `buidling`=*, even the remote gates hall in LAX (way/413226763) are notated as this.
2. From the examples you raised, I see the practice of using `type=multipolygon` + `aeroway=terminal` is quite common. Although I don't think it's a perfect solution, I accept this.
3. I insist that `aeroway=concourse` should not be used on `building`=* independently, it should only be used to describe the concourses under the same roof with other components. Further, there is no document or guide for this tag provided, so it is not understandable to any data parser.
4. HKIA official website map not only puts all T1, NSC, and MFC in one tab, but if you drag the map, you can find they also put SkyPier and 4 car parks in the same tab. The map clearly separates main T1 and MFC as 2 independent parts, as you can find that under T1 it writes "(Gate 1-80, 511-530)" while under T1MFC it writes "(Gate 201-230)", where T1 does not cover MFC. Interestingly, In this map T1 does cover NSC, which makes me believe it's okay to mark T1 and NSC as one building, but that is based on your suggestion of "if Sky Bridge is considered as a `building:part=bridge`". This is not "conflicting with my preferred definition", since main T1, Sky Bridge, and NSC have already been marked as a single continuous building.
5. I totally understand HKIA's current and future situation. HKIA is not the only airport using this structure. For example, LAX Midfield Satellite Concourse (way/831597425) is a satellite concourse only of TBIT; ORD T1 Concourse 3 (relation/13749364) is also a satellite concourse only of T1, they are mapped as separate terminal buildings, while there are also other terminals in the same airport. I believe it is good enough to follow the current practice.

Reply to Kovoschiz:
1. You mentioned the `aeroway=concourse` is "used by a few already", I found 9 in total - 2 nodes at RIC and 7 ways at FLL, and they are all inside a `aeroway=terminal` building, not used as a separate building. (For the word "invalid", You have used it in the first, I was just following you. But please don't dwell on this word choice further)

2. `aeroway=terminal` does not need to include the whole terminal system, it just describes the property of an element, that's like "this building is a terminal" instead of "the whole terminal is just this building". (If you want to have a single element for the whole T1, the jet bridges may also need to be included?) Taking HKU as an example, the Sassoon Road Campus is marked as `amenity=university`, which does not mean the campus is an independent university. You can say that's not perfect, but it is the practice in OSM - most satellite concourses, including the ones in ATL, are marked as separate `aeroway=terminal`s (ATL even using multiple `aeroway=terminal`s for one terminal). So, Marking MFC as a separate `aeroway=terminal` in OSM does not mean it is an independent terminal. Yes from the name we know that MFC and NFC are logically equivalent to the 5 concourses in main T1, but in reality, they are not, MFC and NSC are separate buildings but 5 concourses in main T1 are in the same building. Forcing the use of "consistent" tags will only make the data difficult to understand for the parser, for example, the Carto parser cannot understand the 3 buildings are terminal buildings and not rendered as expected shown in the wiki page. (This is not "tagging for render", it is a manifestation of data being misunderstood.)

3. A `type=site` + `aeroway=terminal` relation best fits your needs. A `type=site` relation is more like a management tool to show the logical relationship between different members in it. You can refer to the discussion https://help.openstreetmap.org/questions/60388/usage-of-typesite-relations for more detail. BTW, if you want to make main T1 and NSC to be one `building`=* with Sky Bridge marked as a `building:part=bridge`, I have no objection, but I still prefer to keep them separate since they are not built at the same time.

4. I agree. But since it is not a standard tag, I would express my objection to using `aeroway=concourse` on buildings independently (i.e. MFC and NSC), the reasons are as above. I think `aeroway=concourse` should only be used within an `aeroway=terminal` building.

5. I apologize for having not discussed this in your changeset first, because the changes made the data unusual so I fixed it at first. By saying ", and it seems to make no sense to me personally.", I mean your changes do not follow any diagram implemented by other airports (JFK does not implement the same diagram as yours) or any guide in wiki, and it made the data parsed unexpectedly, so it makes no sense to me. And I understand the purpose for adding the tags but it did not work as expected, and then replaced with documented tags on wiki. Last, I will "try to contact the author" next time.

6. Regarding your additions. I studied and found that in OSM and main-stream commercial map apps, satellite concourses are mostly mapped as separate terminals and I personally haven't heard anyone complain about this in real or on web. In the current practice, passengers can easily tell from the name which `aeroway=terminal` building is the main one - the main part is always marked as “Terminal X’ or “XX Terminal”, the same as their ticket shows, while the satellite concourses are marked with different names. A multipolygon terminal containing mant separate parts, on the contrary, will increase the understanding cost for passengers.

To sum up, for HKIA, I support to have a relation to put separate parts together logically, but not a split multipolygon, and each satellite concourse (MFC and NSC) should be an `aeroway=terminal` building. Further, I do not oppose to using `aeroway=concourse` for concourses inside an `aeroway=terminal` building. I wonder if a consensus can be reached.

Reply to Kovoschiz: First of all, thank you for the detailed comments. I attached my opinion as follows:
1. `aeroway=concourse` is invalid. The talk topic you provided is not discussed by anyone else, is not accepted, and is not used in JFK. Actually, according to overpass-turbo, this invalid tag is rarely used worldwide (only used in 2 airports)
2. According to [HKIA's official website map](https://www.hongkongairport.com/tc/map/) , T1, T1 MFC, T1 SC, SkyPier, and several car parks are marked as independent buildings with names in the same style. Of course, I can imply from the T1 prefix that MFC and SC are parts of the T1 system, but according to current practice, they could be treated as separate `aeroway=terminal` buildings like most satellite concourses in the world do, for example [LAS T1 - Concourse D](way/143887543). If they are different buildings, they can be separate `aeroway=terminal`s.
3. I understand and support that you are trying to relate these `aeroway=terminal`s to the T1 system, but there is no guide on wiki to create an `aeroway=terminal` but not `buidling`=* multipolygon consisting of multiple terminal buildings, and it seems to make no sense to me personally. To my knowledge, a Site relation is a good choice to describe the relations of several objects which together have a single identity according to [wiki](osm.wiki/Relation:site) , and most values of "site=" are not documented, so I create a non-standard one following the practice. But I realize that `aeroway=terminal` can be directly used on the Site relation, just like `amenity=university` site. Would that be a good choice to change the relation to `type=site` + `aeroway=terminal`? And should the car parks be included?
4. I agree that `building:part=` is not a good choice. `aeroway=concourse` maybe
a choice for the 5 concourses within the T1 main building, but it's not approved or documented. This issue could be explored.
5. Lastly, I was not trying to "remove tags that you don't understand". I fully understood the intention here (as described above) and the tags added, and I removed those tags based on my understanding. Please don't blame and keep calm to discuss.

Open for discussion.

感谢提醒，已修复

提醒阁下注意：您在本changeset中错误地删除了两条东莞境内的镇界路径，导致对应的镇界关系被破坏，此错误已由 Changeset# 147655223 修复，请您在之后的编辑中多加注意

注意到阁下近期在若干条深圳城市快速路出口添加的name标签，但这些name标签的value均为此出口的destination而并非name （详情请参见highway=motorway_junction#Name_and_number）
如若有异议可以在此讨论串提出，若阁下对该意见没有异议，本人将于7日后撤销这些name标签转入匝道的destination标签。

注意到阁下近期在深圳梧桐山片区添加了大量路径，包括道路和水路要素，首先感谢对OSM的贡献，但这些路径绝大多数没有确切来源，且大多数道路要素似乎出现在没有通行条件的区域，同时部分路径添加有无意义的name标签（如“x”、“溪”等），这在通常意义上被认为是不符合OSM规范的，鉴于阁下并未在变更集中种提供来源，若阁下有其他可验证的信息作为佐证欢迎阁下提供，也欢迎阁下对这些编辑做出适当的调整（删除没有可信来源或不符合Wiki描述的数据），若无法提供社区可能对阁下提供的编辑做出撤回

Reverted by [Changeset #140089218](changeset/140089218)
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/139053082

Reverted by [Changeset #138730102](changeset/140088716)
---
#REVIEWED_BAD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/138730102

请问您批量添加的坝光地区地名是否来源？