OpenStreetMap logo OpenStreetMap

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

Discussion

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

就同一个问题的修改,用大范围的变更集并非没有先例,如( https://www.openstreetmap.org/changeset/115447422 ),且在评论中进行了细致的说明进行如何的变动。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 (https://www.openstreetmap.org/changeset/115447422), 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

而hanchao先生所言的“无现场调查”,我倒是认为这次并不适用。因为这并非新增对象,而属于对众所周知的品牌的规范化,虽然是否应移除这个alt_name仍有争议,但Thregren移除alt_name的这个理由,“NSI数据(name-suggestion-index)中,中国大陆及港澳的版本,已不存在alt_name”,我想是站得住脚的,因为NSI确实不能对过往编辑做出回溯性修改。且若是有争议,这份争议应当被送到ideditor/NSI社区,而非中国编辑者社区,因为这是一个技术问题。

举个例子(按照时间顺序):

  • 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: http://127.0.0.1:8111/import?url=https://www.openstreetmap.org/api/0.6/changeset/115788704/download. 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.

這種無中生有的東西,你再說一遍……識得唔識得噶?

Log in to leave a comment