Update CN-faults.gmt from the official data

[liuzhumei]

提交文件的时候总是提示"LF will be replaced by CRLF" 应该怎么处理？

Fixes #40.

[liuzhumei]

related to #40

[core-man]

LF will be replaced by CRLF

参考阮一峰的博客了解回车和换行

参考解决方案:

• LF will be replaced by CRLF in git
• 关于git提示“warning: LF will be replaced by CRLF”终极解答

# 提交时转换为 LF，检出时转换为 CRLF
$ git config --global core.autocrlf true

[core-man]

@liuzhumei 当前你是从 forked 的仓库提交。如果把你设置为 contributors，就具有读写 GMT-china 仓库的权限。这样做的好处是你可以直接提交 PR 至 GMT-china 的仓库，特别是中文手册可以预览提交的 PR 实际网页效果，如 gmt-china/GMT_docs#444 (comment). 是否可以把你加入 contributors 团队，方便你常常提交 PR 至社区仓库？

[liuzhumei]

@liuzhumei 当前你是从 forked 的仓库提交。如果把你设置为 contributors，就具有读写 GMT-china 仓库的权限。这样做的好处是你可以直接提交 PR 至 GMT-china 的仓库，特别是中文手册可以预览提交的 PR 实际网页效果，如 gmt-china/GMT_docs#444 (comment). 是否可以把你加入 contributors 团队，方便你常常提交 PR 至社区仓库？

那太好了，我最头疼没法预览了。那我在本地的提交步骤并没有区别吧，还是git push origin --> PR的过程？ origin和upstream就是同一个仓库了。

[liuzhumei]

在这个PR中我上传的是以CRLF为行尾的GB2312编码文件，是windows用户需要的。编译的时候再生成一个LF结尾的UTF-8文件就行了吧？

[core-man]

在这个PR中我上传的是以CRLF为行尾的GB2312编码文件，是windows用户需要的。编译的时候再生成一个LF结尾的UTF-8文件就行了吧？

最好是传 LF 结尾的文件。参考这个 #48 (comment).

那我在本地的提交步骤并没有区别吧，还是git push origin --> PR的过程？

yes. 那时候，origin 是 gmt-china 的仓库.

origin和upstream就是同一个仓库了。

当前 #493 还是原先的模式，使用的是你自己 forked 的仓库。

下次可以直接提交修改至 gmt-china 的仓库：

• clone gmt-china 的手册等仓库到本地
• 进入clone的仓库新建分支
• 然后修改、提交
• push 至 origin

跟修改自己的仓库一样，也没有所谓的 upstream 远程了。

---

已经邀请了，请接受：https://github.com/orgs/gmt-china/people/pending_invitations

[seisman]

在这个PR中我上传的是以CRLF为行尾的GB2312编码文件，是windows用户需要的。编译的时候再生成一个LF结尾的UTF-8文件就行了吧？

本仓库里的文件都是Linux/macOS用户所使用的，所以是LF结尾、UTF8编码。在发布新版本时，会有workflow自动将其转换为Windows可以使用的GB2312编码。

[seisman]

还有一个问题，这个PR里的数据看上去是比master分支里已经有的数据要少不少行的，是数据采样率不同？还是数据处理过程中数据被阶段了？我之前用某个命令转换的时候会遇到某个字符编码出错，导致转换失败进而数据被截断。如何确认数据完整性呢？

[liuzhumei]

还有一个问题，这个PR里的数据看上去是比master分支里已经有的数据要少不少行的，是数据采样率不同？还是数据处理过程中数据被阶段了？我之前用某个命令转换的时候会遇到某个字符编码出错，导致转换失败进而数据被截断。如何确认数据完整性呢？

首先，PR数据来源是官方版本，master数据来源是私传版本。前者经纬度精度达到小数点后10位以上，后者精度是小数点后5位。这两个版本数据在小数点后2位都是一致的，展布到空间图上，1：400万比例尺下完全重叠，只有放大到5000比例尺，才能看出存在一点误差。但为了数据的可溯源性，我提交的PR是官方版本（红线是私传版本，蓝线是官方版本）：

其次，shp格式用 ogr2ogr 转为 gmt 后，的确会存在数据截断的情况。但据我测试的结果，这里的截断指的是属于同一断层的多段线条在shp格式中为1条记录，而转为gmt格式后，截为多条记录，同时属性信息仅保留在第一段中。这样导致的结果是，原shp数据共1948条记录，转为gmt格式后变为2181条记录。比如下图蓝线和黄线在shp中是同一个要素，而在gmt中是两个要素：

关于数据完整性问题，我统计了官方版本的总长度（单位 km) ，与PR数据转回shp格式后的总长度，结果是完全一样的（下图的后两个），所以可以认为数据是完整的。至于PR数据和master数据行数的不同（下图的前两个数据源转的gmt格式），可能是采样精度误差导致的。这两个数据源虽然都是1948条记录，但全国断层总长度相差了4km左右，其他统计参数也有略微的不同。

[seisman]

@liuzhumei 我对文件的准确性没有什么疑问了。目前依然存在的几个问题：

1. 编码：目前是 GB2312 编码，需要改成 UTF8 编码
2. 换行符：看上去目前是 LF 换行，也就是 Linux/macOS 下的标准换行符，似乎是没问题的。你为何说是 CRLF 换行？
3. 关于破折号: 为示例“标注断层名”生成正确的图片 GMT_docs#434

[liuzhumei]

@liuzhumei 我对文件的准确性没有什么疑问了。目前依然存在的几个问题：

1. 编码：目前是 GB2312 编码，需要改成 UTF8 编码
2. 换行符：看上去目前是 LF 换行，也就是 Linux/macOS 下的标准换行符，似乎是没问题的。你为何说是 CRLF 换行？
3. 关于破折号: 为示例“标注断层名”生成正确的图片 GMT_docs#434

• 已改编码为utf8。
• 可能我git默认就是autocrlf了，所以本地文件还是crlf结尾，但push上去自动转为LF了。
• 我windows环境下连字符在中文中可以识别并标注，若 GMT_docs#434 “ 这里的情况在Mac上普遍存在，我再改符号。这个中文标注真是复杂啊。

[seisman]

很奇怪，我可以看到是 UTF8 编码，但是我打开文件依然是乱码。

[seisman]

Looks good.

[seisman]

@core-man OK to merge?

[core-man]

其次，shp格式用 ogr2ogr 转为 gmt 后，的确会存在数据截断的情况。但据我测试的结果，这里的截断指的是属于同一断层的多段线条在shp格式中为1条记录，而转为gmt格式后，截为多条记录，同时属性信息仅保留在第一段中。

shp格式的 白泥-沙湾断裂 是一段，但是 gmt 格式就是以下两段且只有第一段有属性信息，是这个意思吗？

>
# @D1929|EF22|F22|22|白泥-沙湾断裂|120|330|SW|50-80|正断|Q4|错断Q4以来地层|||||||0.39,0.5|1.14和1.5以来|||0|||控制珠江三角洲盆地|中国地震局地质所,2000
113.03088568277 23.4884142297647
113.081086731444 23.430242509036
113.117587385483 23.3584204644317
113.157588165589 23.2971286924631
113.202489070511 23.2364869231283
113.251890002807 23.152544514314
113.288090703153 23.095842878841
113.325191428791 23.0399912637616
113.365492252786 22.9892997776269
113.385292635012 22.9581988812863
>
113.423093425231 22.9156176210591
113.487594716308 22.8273850533911
113.517495309625 22.7851538277702
113.58139667697 22.722661953531

因此，目前 PR 的 gmt 格式数据跟官方 shp 格式数据的唯一差异就是数据段数以及多段数据的头段信息的位置，原因是使用 ogr2ogr 将 shp 格式转换为 gmt 格式？

[liuzhumei]

其次，shp格式用 ogr2ogr 转为 gmt 后，的确会存在数据截断的情况。但据我测试的结果，这里的截断指的是属于同一断层的多段线条在shp格式中为1条记录，而转为gmt格式后，截为多条记录，同时属性信息仅保留在第一段中。

shp格式的 白泥-沙湾断裂 是一段，但是 gmt 格式就是以下两段且只有第一段有属性信息，是这个意思吗？

是的。

因此，目前 PR 的 gmt 格式数据跟官方 shp 格式数据的唯一差异就是数据段数以及多段数据的头段信息的位置，原因是使用 ogr2ogr 将 shp 格式转换为 gmt 格式？

如果不算对官方数据属性字段名称的纠错以外（“分段魂龄” 改为 “分段年龄”， "地震地_"改为 “地震地表破裂带时间” 等等。 官方数据应该是从tab格式转成的shp，所以本身就有错误）， 数据分段是PR数据的唯一差异了。

[core-man]

如果不算对官方数据属性字段名称的纠错以外（“分段魂龄” 改为 “分段年龄”， "地震地_"改为 “地震地表破裂带时间” 等等。 官方数据应该是从tab格式转成的shp，所以本身就有错误）， 数据分段是PR数据的唯一差异了。

所以此 PR 里全部数据处理流程？

• 下载官方数据
• shp 转 gmt 格式
• 数据属性字段名称的纠错

[liuzhumei]

如果不算对官方数据属性字段名称的纠错以外（“分段魂龄” 改为 “分段年龄”， "地震地_"改为 “地震地表破裂带时间” 等等。 官方数据应该是从tab格式转成的shp，所以本身就有错误）， 数据分段是PR数据的唯一差异了。

所以此 PR 里全部数据处理流程？

• 下载官方数据
• shp 转 gmt 格式
• 数据属性字段名称的纠错

是的，原则上这三个步骤就够了。实际上，第二个步骤shp转gmt后，我生成的实际是ANSI编码的数据，所以第一次commit后， @seisman 看到的是乱码。我后来手工转成utf编码并最后一次commit的。 我再研究研究ogr2ogr命令，应该可以在脚本中解决，并更新到 GMT_docs#493 中。