需要指出，《深圳市国土空间总体规划（2021－2035年）》之附图亦有标注“本图界线不作为权属争议的依据”

For information about underground buildings, please refer to osm.wiki/Buildings#Mentionable_usage .
It's okay to map them or not, and it's easy to be filtered out by simple rules for data users if they do not want

请不要将别墅区内的道路调整为highway=service，这里的道路用于集散住宅区内外交通车流，而非用于连接某一建筑或设施，根据wiki定义，https://wiki.openstreetmap.org/wiki/Tag:应当使用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.