按坐标查找时区和国家/地区

这是一系列文章的第三部分，描述了 KI18n 中处理国家、国家/地区细分和时区的潜在新 API，遵循之前的国家/地区到时区映射，涵盖我们如何通过地理坐标查询时区和国家/地区或国家/地区细分信息.用于此的 API 相当简单，传入地理坐标，然后返回该位置的相应特征：这不需要过于精确的坐标，即使是基于 GeoIP 的精确度为几公里的位置，在大多数情况下也能提供有用的结果领域。用于此的数据源与我们在上一篇文章中已经使用的相同：但是源数据庞大且处理缓慢，我们需要将其转换为紧凑的形式以实现高效存储。为此，我们重用了 KItinerary 的先前工作，其中包含基于 z 顺序曲线的坐标到时区索引。不过，对原始代码有一些改进和扩展。最值得注意的是，我们现在可以表示每个位置的多个特征，同时利用实际发生的只有一小组特征组合的事实。这使我们不仅可以查找时区，还可以查找国家或按位置细分的国家/地区，而不会显着增加所需的存储大小。进行处理的QGIS Python脚本也进行了大量优化，KItinerary的原始版本需要大约8个小时，新版本只需要大约15分钟即可产生更详细的结果。这使得尝试调整各种参数以获得最佳结果变得更加可行。

显然我们不能在不交易空间分辨率的情况下神奇地将数百兆字节的源数据减少两个数量级，多少取决于索引生成脚本的参数。对于地球表面的多少，我们返回了错误的结果？要了解我们如何影响这些，快速查看索引生成在概念上的作用是有用的。将地球表面分割成矩形瓷砖（当前：2¹¹ x 2¹¹）。切断无人居住的极地地区，为有人居住的地区提供更多瓷砖（目前：80°N 和 60°S）。对于我们当前的参数，导致赤道大约 10x20 公里处的瓦片，并且朝着两极越来越小。这控制了我们可以覆盖多少表面积，以及为了完全可见，特征必须有多大。对于每个图块，检查该图块中的哪些特征实际上存在冲突。例如，与法国/德国边界重叠的图块将看到两个时区欧洲/柏林和欧洲/巴黎。这两个（至少在现在和不久的将来）是等价的，所以我们只选择其中一个并且没有实际冲突。对于国家来说，我们显然不能这样做，所以我们将无法返回结果。对于每个特征冲突，丢弃那些仅覆盖图块一小部分的特征（当前：2%）。这种在边界数百米内的正确性换取更大的覆盖区域。有了上面提到的参数，我们得到了大约 950kB 的索引大小，覆盖了 99% 的非极地地区的时区和国家，以及 98% 的（一级）国家细分，我们应该不会出错距离边界至少 300 米时的结果。

对于许多用例来说，这是一个不错的权衡，进一步减小图块大小会导致索引大小快速增长，从而降低精度。当然有办法打破这个，内陆和形状反对瓷砖方向的微型国家，如列支敦士登，可以完全从裂缝中掉下来，更何况他们的细分。同样，也可能会遗漏非常细粒度的国家/地区细分，但在这些位置，我们往往至少会获得正确的国家/地区信息。人类可读和翻译的时区名称。与国家不同，对此没有规范形式，应用程序倾向于使用不同的方法来表示时区。目前尚不清楚 KI18n 可以为此提供哪些构建块。查找国家或国家/地区细分的语言，以及人类可读和翻译的语言名称。这也需要多加考虑，因为引用语言的代码通常更期望区域设置（特定区域中使用的区域和/或脚本变体） )，以及系统上可用的翻译目录。非常欢迎对所有这些提供反馈，包括实施以及您在应用程序中的用例和要求。检查相应的 Phabricator 任务和 Gitlab 分支，或者在 Matrix 上的 #kde-devel 频道、每周 KF6 会议（UTC 星期一 15:00）或 kde-frameworks-devel 邮件列表中找到我。