请不要将别墅区内的道路调整为highway=service，这里的道路用于集散住宅区内外交通车流，而非用于连接某一建筑或设施，根据wiki定义，应当使用highway=residential

请不要将未开通的铁路站点标记为已建成开通，请妥善使用 [Lifecycle prefix](osm.wiki/Lifecycle_prefix)

提醒阁下注意：情侣中路情侣南路作为国道G228的城市路段，按照相关指引（osm.wiki/Zh-hans:中国标注指南）应标注为trunk

请阁下在修改道路等级前参阅 osm.wiki/Zh-hans:中国标注指南 ，熟悉道路等级相关指引，再对道路等级进行变更。提醒阁下注意：所有国道均应标注为trunk等级，不受道路技术等级限制。

你好，注意到阁下近日调整南坪快速为trunk等级，提醒阁下注意一下若干问题：
1. 城市快速路若作为trunk应配合使用motorroad=yes标签；
2. 立交匝道等级应以交汇道路等级高者为准，即西端南头立交匝道应为motorway_link而非trunk_link；
3. 所有出入口匝道应同步调整，包括但不限于：南坪快速星河丹堤出口，南坪东大道红棉立交、宝平出口、锦龙立交、马峦立交、绿梓出口、田头立交的部分或全部匝道。
以上。

请注意：公立学校的运营者可以是其自身并非其所属的教育局，且operator:type应为public而非government。请参考operator:type=*

[UPDATE] Fixed in changeset #159542791

感谢阁下做出的编辑；
注意到阁下在此修改集中将深圳地铁11及14号线由地铁(railway=subway)修改为铁路(railway=rail)，能够理解阁下希望将此两条市域快线与其他普速线路做出区分的意图，但事实上它们均为按照地铁标准和制式建设运营的线路，亦在当地被普遍认为是地铁系统的组成部分。依照OSM Wiki和实践，它们应该标注为地铁而非铁路，OSM的标注体系并不明确单列市域线路，快线的属性可以通过添加全程用时、运行速度或备注的形式体现。烦请阁下修正此问题，若一周后仍未修复本人将代劳做出调整。再次感谢阁下的编辑贡献，若有疑问欢迎沟通交流。

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.