2022年度变更调查数据处理工具箱
Posted 就咬一小口GIS
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了2022年度变更调查数据处理工具箱相关的知识，希望对你有一定的参考价值。
版本20230103
工具模块总览：
数据拆分合并
因项目工期紧张，需要多人、多标段同时作业，数据拆分、合并使用频次较高。（我们不是加班有瘾，是身不由己）
1.1 DLTB拆分
根据需求自行创建分组字段（按乡镇代码、标段、作业区域等）并赋值。该工具以属性为分组条件拆分数据，不会切割图斑，工具执行后以分组字段值将作为所生成GDB名称。
例如以乡镇代码作为分组字段，拆分后数据如下
模型思路：
1.2 单独图层拆分
单独图层采用分割方式拆分（裁剪图层分组字段不要有重复）。若以XZQ作为裁剪图层，输出路径可与工具1.1路径相同，拆分结果写入对应GDB
脚本源码：
1.3 数据合并
待合并gdb数据结构均需与模板相同，图层名称差异会导致无法合并。待合并数据置于“输入路径\\gdb”文件夹内（路径不要有中文名），模板数据置于输入路径根目录下，并命名为muban.gdb，工具执行后，生成合并数据Merge.gdb
脚本源码：
2. 数据质检
2.1提取变化图斑
DLTB增加字段shpchange值为“Y”或tabchange为“Y”即为变化图斑。输出要素可用于后续工具质检、“中地”建库软件增量入库等。（注意：以往测试中发现个别地区的本底数据自身存在精度问题，例如0.0001m精度存在拓扑错误等，提取可能会有误差）
2.2变化图斑属性值域检查
先使用工具2.1提取变化图斑进行检查，检查结果标注于字段SXCWLX，多个错误以“|”隔开。若使用建库软件统一进行属性维护的可忽略该项。质检内容：
（1）ZZSXDM值域错误：耕地种植属性不为LS、FLS、LYFL、WG；非耕地种植属性为LS、FLS、LYFL、WG；非可恢复地类标注恢复属性
（2）GDLX/KCDLBM/KCXS/GDDB冗余：非耕地的耕地专有属性未清空，可用工具3.1处理
（3）耕地类型错误：非1级坡度耕地未标注“PD”或“TT”
（4）20X冗余：交通运输水工建筑用地20X冗余
（5）20X缺失：建设用地（不含④地类）未标注20X
（6）GDDB/GDPDJB缺失：耕地等别与坡度属性未填写
（7）宽度错误：线性地物宽度未填写或≤0；非线性地物宽度冗余；农村道路宽度>8m
（8）TBXHDM错误：非耕地标注河道耕地、林区耕地等；非工矿铁路公路标注“FQ”
（9）KCXS/GDLX缺失：耕地专有属性缺失（建库软件一般都会处理，该项已去除）
2.3狭长角检查
输出点文件为狭长角位置，角度值可调节
2.4耕地恢复属性检查
质检内容：
（1）恢复属性冗余：恢复属性参考图层（基础库为耕地或已标注恢复属性，下同）范围外标注恢复属性且面积大于阈值（默认400㎡，可设置）
（2）恢复属性缺失：恢复属性参考图层范围内园林草塘未标注恢复属性且面积大于阈值，退耕还草、25°坡以上耕地情况需另行扣除
（3）异常变化：地类未发生改变，恢复属性变化，疑问图斑，需自行核实
模型思路：
2.5推土区未按原地类检查
推土区范围内图斑未按原地类调查
2.6 20X更新检查
质检内容：
（1）新增20X非建设用地且面积≥10㎡
（2）变化图斑未更新20X且面积≥30㎡
（3）更新后20X生成新的空洞
模型思路：
3.入库前处理
3.1冗余属性清空
该项针对于“中地”mapgis建库软件增量入库需要，“批量变更范围”导入前清空BZ字段，KCXS统赋为0，耕地GDPDJB统赋为1，非耕地GDPDJB清空，GDLX清空，入库后方便由建库软件重新赋值。
3.2按面积占比赋值坡度级别
耕地坡度字段正常维护，以PDT作为依据图层，按面积占比最大的坡度对耕地转进图斑赋值坡度，输入数据需使用gdb格式。
3.3 KCXS赋值
调取基础库1~4坡度对应KCXS，对增量进行赋值。存在土地整治项目涉及田坎系数调整的请勿使用
为什么用Go语言的普遍喜欢Python？ | Go开发者年度调查报告
本文最初发布于 Go 语言官方博客，由 InfoQ 中文站翻译并分享。
近日，Go 语言社区正式发布 2019 年度调查报告，本次调研共收到 10975 份回复，几乎是 2018 年的两倍，以下是本次报告的重要内容。
本文篇幅较长，希望快速了解结果的可以阅读如下概述：
调查对象的人口统计数据与 Stack Overflow 相似，因此这些结果代表了广泛的 Go 开发者；
大多数受访者每天都使用 Go，而且这个数量每年都在上升；
Go 的使用仍主要集中在科技公司，但也越来越多地出现在金融和媒体等行业；
通过调整方法，我们看到大多数年度同期指标都很稳定，并且高过我们之前的认知；
受访者使用 Go 解决的问题类似，特别是构建 API/RPC 服务和 CLI，而这与所在组织规模无关；
大多数团队都会设法更新当前 Go 语言的版本，当第三方提供商不能支持 Go 的当前版本时，就会妨碍开发人员采用；
在 Go 生态系统中，几乎每个人都在使用 Modules，但在包管理方面仍然存在一些混乱；
具有高优先级的改进项包括改进开发人员的调试体验、Modules 使用体验和云服务使用体验；
VS Code 和 GoLand 使用率持续上升，四分之三的受访者当下首选二者；
泛型依旧被认为是 Go 缺失的关键特性。
2019 年，我们提出了一些新问题，以帮助更好地了解参与调查的人，比如从事编程的经验年限和所服务的组织规模，这些问题参考了 StackOverflow 的年度调查。我们也看到最终结果与 StackOverflow 2019 年的结果非常接近。我们的结论是，本次调查的受访者与 StackOverflow 的受访者经验水平类似，而且不同规模的组织比例也相似（差别是我们的调查对象是 Go 开发人员）。
所在组织规模
根据调查，大部分受访者所在公司的人数规模在 1000 人以下，且其中有 65% 的受访者具备 10 年以下编程经验。
从事编程工作（或编程作为工作的一部分内容）的时间
从结果来看，大多数受访者（56%）都是相对较新的 Go 开发者，他们使用 Go 还不到两年。另外，72% 的受访者在工作时间使用 Go 语言，62% 的受访者在工作之余使用 Go。
如下图所示，2018 年的受访者中有 72% 使用 Go 语言工作，而这一数值并未在过去一年有所增长，在工作中使用其他编程语言的比例也并未因此增长，反而下降了。这种异常也被 Go 语言社区所注意，这可能意味着 2018 年参与调查的受访者与过往几年不同，因为这种异常也发生在其他选项中。
使用 Go 时间最长的受访者与新晋开发人员的背景存在差异。Go 老手对 C/C++ 更加熟悉，但对 JavaScript、TypeScript 和 PHP 熟悉的不多。但有两种编程语言是不同的，Python 和 Java 是相对比较稳定的，各个经验段的受访者对这两种编程语言的熟悉度相差不大，只是大多对 Python 更加熟悉。
过去两年的调查结果显示，科技公司应用 Go 语言的比例最高（2019 年把软件、互联网 /Web 服务等相关选项合并成了技术），但这一比例出现下降，金融服务公司次之，其 2019 年的应用情况有了一定提升。
组织所在行业
Go 是一个成功的开源项目，但这并不意味着使用 Go 的开发人员也在贡献开源。与前几年一样，大多数受访者并不是开源项目的频繁贡献者，75% 的受访者“很少”或“从不”这样做。 随着 Go 社区的扩大，我们看到，从未参与过开源项目的受访者比例在缓慢上升。
我向使用 Go 编写的开源项目做贡献
与前几年一样，绝大多数受访者表示使用的是 Linux 或 macOS 系统，这是与 StackOverflow 2019 年调查结果之间的明显差别：在我们的调查中，只有 20% 的受访者使用 Windows 作为主要开发平台，而在 StackOverflow 的调查中，有 45% 的受访者使用 Windows 作为主要开发平台。
如下图所示，66% 的用户使用 Linux，53% 的用户使用 macOS，这两个数值都比 StackOverflow 的结果高得多，StackOverflow 的这两个数值分别为 25% 和 30%。
编辑器整合的趋势仍在继续。GoLand 和 IntelliJ 的使用量增长最快，从 24% 上升到 34%。虽然 VS Code 的增长有所放缓，但它仍然是受访者中最受欢迎的编辑器，比例为 41%。两者相加占了受访者的四分之三。
此消彼长，其他编辑器均有小幅下降。这并不意味着这些编辑器没有人用，但它们不是受访者更喜欢的编写 Go 语言的工具。
你最喜欢使用哪个编辑器来编写 Go 代码？
2019 年，我们增加了一个关于内部 Go 文档工具的问题，比如 gddo。少数受访者（6%）表示，他们的组织运行着自己的 Go 文档服务器，但当我们查看大型组织（至少有 5000 名员工）的受访者回复时，这一比例几乎翻了一番（达到 11%）。
接下来，我们询问了那些表示停止运行文档服务器的受访者，结果表明，停止的主要原因有两个：一是效益低（23%）；二是初始设置和维护所需的工作量较大（38%）。
你的组织管理自己内部的 Go 文档服务器吗（类似 godoc.org）？
使用感受绝大多数受访者（86%）认为，Go 在团队中使用效果良好，并愿意在下一个项目中使用它（89%），超过一半（59%）的受访者认为，Go 对公司业务的成功至关重要。自 2016 年以来，所有这些指标都保持稳定。
结果标准化改变了前几年的大部分数据。例如，同意“Go 在团队中使用效果良好（Go is working well For my team）”这句话的受访者比例之前在百分之五六十，这种变化是由于参与者减少；当我们剔除那些未看过该问题的参与者时，我们发现，自 2016 年以来，这个问题的数值相当稳定。
你在多大程度上同意或不同意下面这几句话？
对于在 Go 生态系统中解决问题的感受，我们看到了类似的结果。大部分受访者（82%-88%）都同意这些观点，在过去四年中，这些比例基本保持稳定。
你在多大程度上同意或不同意下面的说法？
2019 年，我们对各行业的满意度进行了更细致的调查。总体而言，无论在哪个行业，受访者对在工作中使用 Go 都持积极态度。
在一些领域，我们确实发现了不满情绪的细微变化，最明显的是制造业，我们计划通过后续的研究对其进行调查。同样，我们还调查了 Go 语言开发的各个方面的满意度和重要性。综合来看，有三个主题特别值得关注：调试（包括调试并发性）、使用模块和云服务。对这些主题的评价，大多数受访者都认为“非常”或“极其重要”，但与其他主题相比，这些主题的满意度得分要低得多。
关于对 Go 社区的看法，我们看到了与前几年的一些不同之处。首先，同意“我觉得自己在 Go 社区很受欢迎”这句话的受访者比例从 82% 下降到了 75%。进一步调查发现，“有点”或“中等同意”的受访者比例有所下降，而“既不同意也不反对”和“非常同意”的受访者比例均有所上升（分别上升了 5 个和 7 个百分点）。这种两极分化的现象表明，在 Go 社区中，有两个或两个以上的群体社区体验存在差异，这是另一个我们计划进一步研究的领域。另外一个很大的不同是，同意“Go 项目的主导者理解我的需求”这句话的受访者比例同比也出现了大幅的增长。
所有这些都表明，赞成度的增加与 Go 语言使用经验的增加相关，这大约是从使用 Go 语言两年左右时间开始的。换句话说，受访者使用 Go 的时间越长，他们就越有可能同意这些说法。
这并不奇怪，但那些参与了 Go 开发者调查的人往往是喜欢 Go 语言的。然而，我们也想了解受访者喜欢使用其他哪些语言。与往年相比，这些数字没有明显变化，只有两个例外：TypeScript（增加了 10 个百分点）和 Rust（增加了 7 个百分点）。
当我们将这些结果按照 Go 语言使用经验长短进行细分时，我们发现了与语言知识相同的模式。特别是，Python 是 Go 开发人员最喜欢使用的语言。
将语言按照个人喜好进行排序（选取排名前 5 的语言）
2018 年，我们首先问了一个净推介值（NPS）的问题，就是“你会推荐……吗？”，得分为 61。2019 年，我们的 NPS 结果为 60（67% 的“推广者”减去 7% 的“批评者”），从统计学上来说没什么变化。
Go 语言最常见的应用场景仍然是构建 API/RPC 服务（71%）和 CLI（62%）。 下图显示出了自 2018 年以来的主要变化，但这些变化很可能是选项顺序随机化的结果，过去是按字母顺序排列的：以“A”开头的 4 个选项中有 3 个下降了，而其他选项保持稳定或增加了。因此，对于这个图表，最好的解释是一个更准确的基线（2019 年）加上 2016 到 2018 年的趋势。举例来说，我们认为，自 2016 年以来，构建返回 HTML 的 Web 服务的受访者比例一直在下降，但这很可能是统计的原因，因为这个选项总是位于一长串选项的末尾。我们还对组织规模和行业进行了分析，但未发现显著差异：受访者使用 Go 语言的方式大致相同，无论他们是在小型科技初创企业工作，还是在大型零售企业工作。
在另一个相关问题“受访者在哪些比较大的领域使用 Go 语言”的回答中，最常见的领域是 Web 开发（66%），其他常见领域包括数据库（45%）、网络编程（42%）、系统编程（38%）和 DevOps 任务（37%）。
我在以下场景中使用 Go（可多选）
我在以下领域中使用 Go（可多选）
在开发技术层面，大多数受访者表示他们使用文本日志进行调试（88%），而他们的文本回复表明，这是因为其他工具使用起来比较困难。但是，本地逐步调试（例如使用 Delve）、性能分析和使用竞态检测器进行测试的也不少见，大约 50% 的受访者至少依赖于这些技术中的一种。
我在进行 Go 开发时依赖以下技术（可多选）
在包管理方面，我们发现绝大多数受访者（89%）采用了 Go Modules。对于开发人员来说，这是一个巨大的转变，几乎整个社区都在同一时间经历了这一转变。
我通常使用下面的工具进行 Go 程序包管理（可多选）
此外，75% 的受访者会评估将 Go 的当前版本应用于生产，另有 12% 的人会等待一个发布周期。这表明，大多数的 Go 开发者都在使用（或者至少是在尝试使用）当前或者之前的稳定版本，这说明，PaaS 提供商快速提供对最新一个稳定版本的支持非常重要。
当 Go 语言有新版本发布时，你的团队会在何时开始评估将其应用于生产（如从 1.11 到 1.12 或从 1.12 到 1.13）Go 语言在云中的使用情况
Go 在设计时考虑了现代分布式计算，我们希望继续提升使用 Go 构建云服务的开发体验。2019 年，我们扩展了关于云开发的问题，以便更好地了解受访者如何与云提供商合作，当前开发体验的哪些方面是他们喜欢的，以及哪些方面可以改进。如前文所述，2018 年的部分结果存在异常，比如，自有服务器部署的结果出乎意料地低，而 GCP 部署的结果出乎意料地高。
我们看到了两个明显的趋势：
在本次调查的受访者中，全球三大云服务提供商（AWS、谷歌云平台和 Microsoft Azure）的使用率都呈上升趋势，而其他大多数云服务提供商的使用率都在逐年下降；
部署自有服务器的比例继续减少，但仍是最常见的部署选项，其统计数据（44%）与 AWS 相近（42%）。
通过查看受访者使用的云平台类型，我们可以看到主流提供商之间的差异。部署到 AWS 和 Azure 的受访者最有可能直接使用 VM（分别为 65% 和 51%），而部署到 GCP 的受访者使用托管 Kubernetes 平台（64%）的可能性几乎是使用 VM 的两倍（ 35%）。
我们还发现，部署到 AWS 的受访者使用托管 Kubernetes 平台的可能性（32%）与使用托管无服务器平台的可能性（AWS Lambda, 33%）基本相同。GCP（17%）和 Azure（7%）的受访者使用无服务器平台的比例都比较低，文本回复表明，这主要是因为这些平台对最新 Go 运行时的支持存在延后。
总体而言，大多数受访者对在上文提到的三大云服务商提供的 Go 语言支持感到满意。受访者对在 AWS 上进行 Go 开发的满意度（80%）和 GCP（78%）相似。Azure 的满意度得分较低（57% 的受访者满意），而文本回复表明，这主要是因为人们认为该平台没有为 Go 提供一等支持（25% 的文本回复）。
注：“一等支持”指的是始终与 Go 的最新版本保持同步，并确保新特性在发布时就提供给 Go 开发人员。
这也是使用 GCP 的受访者反馈的最让他们痛苦的地方（14%），并且他们特别关注在无服务器部署中对最新 Go 运行时的支持。相比之下，部署到 AWS 的受访者最有可能说 SDK 可以改进，比如更符合习惯（21%）。改进 SDK 也是 GCP（9%）和 Azure（18%）开发人员的第二大常见需求。
在过去几年，你对云服务商提供的 Go 语言支持满意吗？
受访者表示，他们不能更多地使用 Go 的最主要原因包括：在使用另一种语言开发的项目上继续开发（56%），团队更喜欢使用另一种语言（37%）以及 Go 本身缺少关键特性（25%）。
我们对这个问题的选项进行了随机排序，所以无法进行同期比较，不过，2016 年到 2018 年的趋势是有效的。例如，我们相信，由于团队更喜欢另外一种语言而不能频繁使用 Go 的开发人员数量每年都在减少， 但不确定这种趋势是否在明显加速。
如果不是因为下面这些原因，我会更多地使用 Go
为了更好地理解如何能帮助开发人员增加对 Go 的使用，我们要求受访者提供更多细节。本节剩余部分的图表基于文本回复整理而成，占比不到总回复数 3% 的选项都被归入“其他”类别。单个回复可能会提到多个主题，因此图表的百分数总和不是 100%。
如下图所示，25% 的受访者认为 Go 缺少他们需要的语言特性，79% 的受访者认为泛型是 Go 缺失的关键特性。22% 的受访者提到了（除了 Go 1.13 的变更外）错误处理还需要不断改进，而 13% 的受访者要求更多的函数式编程特性，尤其是内置的 map/filter/reduce 功能。需要说明的是，这些信息来自部分受访者，而不是全部受访者。这些人表示，如果 Go 没有缺少他们需要的一个或多个关键特性，他们就可以更多地使用 Go。
有哪些你需要的关键特性是 Go 语言没有提供的？
有受访者表示，对于他们所从事的工作来说，Go“不是一种合适的语言”，他们的理由和应用场景各种各样。最常见的是从事某种形式的前端开发（22%），例如 Web、桌面或移动应用的 GUI。另一个常见的回复是，他们的工作领域已经有一门占主导地位的语言（9%），因此很难使用不同的语言。受访者提到的另一个主要原因是需要更好的性能（9%），尤其是实时计算。
对于你所从事的工作，为什么 Go 语言不合适？
受访者指出的最大挑战与去年基本一致，缺少泛型和模块 / 包管理器使用仍然名列榜首（分别占回复的 15% 和 12%），强调工具问题的受访者比例有所增加。这些数值与上图不同，因为这个问题面向的是所有受访者，不管他们说采用 Go 的最大障碍是什么。这三个方面都是 2019 年 Go 团队关注的重点。我们希望，在接下来的几个月里，开发体验会有大幅改善，尤其是模块、工具和入门体验。
你个人在使用 Go 时面临的最大挑战是什么？
在任何语言中，诊断故障和性能问题都非常具有挑战性。受访者告诉我们，对于这两个问题，他们面临的最大挑战并不是某些特定于 Go 的实现，而是一个更基本的问题：缺乏知识、经验或最佳实践。
我们希望，在今年晚些时候，这种知识缺口可以通过文档和其他材料得到弥补。其他主要问题涉及工具（特别是学习 / 使用 Go 的调试和分析工具所带来的成本收益平衡问题），以及在各种环境中使用这些工具所面临的挑战（例如，在容器中调试，或者从生产系统中获得性能分析数据）。
如果有的话，是什么妨碍你在 Go 应用程序中高效地诊断 Bug？
如果有的话，是什么妨碍你在 Go 应用程序中高效地诊断性能？
最后，当我们问受访者“在他们的环境中为 Go 支持带来最大改进的是什么？”，最常见的回复（19%）是对语言服务器（gopls）的一般改进或更好的支持。这在意料之中，因为 gopls 取代了大约 80 个现存的工具，并且仍然处于测试阶段。
当我们要求受访者更具体地说下希望看到的改进时，他们回复最多的是调试体验（14%）和更快或更可靠的代码补全（13%）。许多受访者明确提到，在使用 gopls 时需要频繁地重启 VS Code（8%）。自该调查发布以来（2019 年 11 月下旬 12 月初），gopls 的许多改进已经落地，这仍然是该团队的高优先级事项。
如果有的话，什么可以 [在你首选的编辑器中] 最大限度地改进 Go 支持？
对于 Go 相关的问题，大约三分之二的受访者使用 Stack Overflow 来获取答案（64%）。其他排名前列的答案来源分别是 godoc.org（47%）、直接阅读源代码（42%）和 golang.org（33%）。
对于 Go 相关的问题，你都是从哪里获取答案？（最多选三项）
上图说明存在大量不同的答案来源（几乎都是社区驱动）以及受访者在使用 Go 语言开发时赖以克服挑战的模式。事实上，对于许多 Gopher 来说，这可能是他们与更大的社区互动的原因之一：随着社区的不断发展，越来越多的受访者不参加任何与 Go 相关的活动。在 2019 年，这一比例接近受访者的三分之二（62%）。
过去的 12 个月里，我参加了以下哪些活动？（可多选）
由于谷歌隐私准则更新，我们不能询问受访者生活在哪个国家。作为替代，我们问了受访者的首选语言，希望可以基本反映 Go 在全球范围内的使用情况。因为这项调查是用英语进行的，所以本文的调查结果更偏向于说英语的人和以英语为第二或第三语言的地区。
你说话 / 写作时的首选语言或语系是什么？
部分读者可能已经注意到，本次的年度同期数据与我们过去分享的数据并不完全一致。从 2016 年到 2018 年，我们使用参与调查的总人数作为分母，计算每个问题的百分比。虽然这很好，而且前后一致，但它忽略了一个事实：并不是每个参与调查的人都完成了调查，高达 40% 的参与者在完成最后一页之前就停止了，这意味着很多开发者并没有查看报告后半部分的问题，这不利于统计。2019 年，我们使用回答特定问题的人数作为该问题的分母，重新计算了所有结果（包括本文中展示的 2016 到 2018 年的回复）。我们在每个图表中都列出了 2019 年的回复数量，以便读者更好地理解每项调查结果。
类似地，我们还发现，在之前的调查中，答案列表中出现较早的选项容易被选择，尤其是一些多选题。为了解决这个问题，我们在调查中加入了随机因素。一些多项选择题的列表没有逻辑顺序，比如“我在 Go 中编写以下内容：[应用程序类型列表]”。在此之前，这些选项是按字母顺序排列的，但在 2019 年，它们是随机展示给每个参与者的。
第三个变化是改进了对文字回复的开放式问题的分析。去年，我们使用机器学习粗略但快速地对这些回复进行了分类。2019 年，两名研究人员对这些回复进行了手动分析和分类，这让我们可以进行更细致的分析，但无法与去年的数值进行有效比较。
参考链接：
https://blog.golang.org/survey2019-results
你也「在看」吗？ 以上是关于2022年度变更调查数据处理工具箱的主要内容，如果未能解决你的问题，请参考以下文章 为什么用Go语言的普遍喜欢Python？ | Go开发者年度调查报告 机器学习工具榜单Tensorflow最多使用，Python 取代 R 成最受欢迎编程语言 2015年度最流行PHP框架调查结果出炉，Laravel居首 2022全球数商大会顺利举行，合合信息旗下启信宝斩获年度数据产品奖 Java收入排名倒数，TypeScript受欢迎程度超越Python | Stack Overflow年度开发者调查报告