There is a Chinese account that has normalized the KFC tag that its changeset boundary is so big recently, which included Taiwan in it. The changeset boundary is so big that makes QA tools like OSMCha not function as expected, probably Overpass API limitation. The reviewer has to manully review the changeset if there is anything wrong. As a Taiwanese mapper I check if he change something inside the Taiwan boundary, and foundout he does what he said. The mapper stated in his changeset comment said he did not touch KFC in the “Taiwan area”, which in my humble option is not quite necessary.

I will recommend that even though the cause is QA tools problems, that can not check edit in a country if it is problem changeset, might be a good idea to avoid such a big changeset boundary. Split the big changeset into a much smaller, much checkable changeset that lets QA tools like OSMCha to function normally. This could avoid potiental disruption. Heavy mappeers could focus on mapping, not changeset comment discussion.

Even though Taiwan is a small place, there are many hard-working mappers that contribute to OpenStreetMap, following the truth to map stuff that exists in front of them, that can be observed by their own eyes. But sometimes we have to deal with people who do not follow the on-the-ground truth, forcing Taiwanese to accept things not observabe on the ground.

The OpenSteetMap project is just like its sister project Wikipedia, everyone can contribute. So if there is something quite strange, then anyone who spots the strange stuff could edit it and make it alright. And in some extreme cases, you could delete stuff that does not exist. You do not have to have a special privilege to change someone else edit, and in some cases, you have to revert the whole changeset to fix stuff. If you have knowledge of reverter, and support by community members, you could just be a regular account and do the revert. That is no problem at all. OpenStreetMap is a project that everyone is equal, not judged by seniority, anyone who has reason could do things under the rules.

Location: 24.767, 119.866

Comment from hanchao on 14 January 2022 at 16:54


Comment from mmd on 14 January 2022 at 19:07

The comments seem to be correct, I don’t see any changes affecting the area of Taiwan: achavi (experimental fork), changeset map (experimental fork).

Comment from 快乐的老鼠宝宝 on 15 January 2022 at 05:13

就同一个问题的修改,用大范围的变更集并非没有先例,如( ),且在评论中进行了细致的说明进行如何的变动。Thregren特别备注“没有编辑台湾地区”,我想就是因为知道bbox可能包含台湾西部而特别声明的。若是想如您所说,专注于绘图而不必为修改集评论区困扰,那最好的方法显然是信任其他编辑者的comment。

甚至连Overpass Turbo代码都留下来了,在代码中明确点明了”{{geocodeArea:China}}->.searchArea;”

–[zh-Hans ↑][en ↓]–

It is not unprecedented to use large changesets for the same particular issue, such as (, and there is a detailed comment of what changes made in this changeset. The user, Thregren, specifically notes “No edits to Taiwan area”, I think because he knew that the bbox might include western Taiwan and to avoid arguing between 2 community. If you want to “focus on mapping, not changeset comment discussion” as you said, then the best way is obviously to trust the comments of other editors.

Even the Overpass Turbo code was given, with a clear “{{geocodeArea:China}}->.searchArea;” in the code.

Comment from 快乐的老鼠宝宝 on 15 January 2022 at 05:47



  • A品牌在2020年的NSI数据中不包含alt_name,因此2020年编辑者在用ideditor时就不会向改品牌的POI上添加alt_name。
  • 而在2021年NSI数据中包含了alt_name,那么在2021年使用ideditor完善过的A品牌就会包含alt_name。
  • 但若2022年,NSI数据中这个alt_name被移除了,之前2021年的编辑者编辑过的POI中包含的alt_name并不会随着NSI数据的变化而移除,而需要编辑者手动维护OSM数据,删掉POI上的alt_name。

–[zh-Hans ↑][en ↓]–

As for hanchao’s reference to “no survey” accusation, I don’t think it applies to this issue. Although it is still debatable whether the [alt_name] should be removed. Thregren’s reason for removing it, “The alt_name for KFC in Mainland of China, Hong Kong and Macau no longer exists in NSI(name-suggestion-index) data”, is a valid one, at least can be discussed. Since the NSI really cannot handle old version edits. And if there is a dispute, this dispute should be sent to the ideditor/NSI community, not the Chinese mapper community, because it is essentially a technical issue

As an example (in chronological order).

  • Brand “A” does not contain [alt_name] in the 2020 NSI data, so mapper will not add [alt_name] to the POI when they use ideditor in 2020.
  • And the NSI data added [alt_name] in 2021, then Brand “A”, when been refined using ideditor in 2021, will contain the [alt_name].
  • But if this [alt_name] is removed from the NSI data in 2022, the [alt_name] stored in the POI previously edited by mapper in 2021, will not be removed with the changing NSI data. It require the mapper to manually maintain the OSM data and delete the [alt_name] on the POI in 2022.

Comment from Jyunhou on 16 January 2022 at 05:13

It seems that Mr Supaplex is criticizing non-existent bad political change. Via JOSM, everyone can find out any map feature which has been changed: Obviously, no one really did vandalism. I hope Mr Supaplex doesn’t really suffer from Delusions of Persecution.

In this diary titled On the gound rule, Mr Supaplex spends half the space making malicious inferences out of something that doesn’t exist, I think this goes against the idea of the on the gound rule: according to the facts.


Login to leave a comment