在2020年底，当osm2pgsql发布flex输出时，我急切地加入了这个潮流。osm2pgsql 弹性输出启用了我一直希望从 osm2pgsql 中获得的数据结构和清理功能的类型。到 2021 年 1 月，PgOSM Flex 项目已启动并运行，我正在逐步淘汰我遗留的开放街道地图流程。从那时起，我写了十几篇文章，探索通过PgOSM Flex加载的开放街道地图数据的不同改进和用例。这篇文章着眼于0.6.0版本与先前版本相比的一些显着改进，将主要分为以下两个部分：
- 数据质量
- 可用性
数据质量改进
为我提供这篇文章的想法的一系列改进是在PgOSM Flex版本0.5.1和0.6.0中进行的。版本 0.5.1 利用了期待已久的对 osm2pgsql 的多行字符串支持。在osm2pgsql中添加该特征允许以与多边形关系相同的方式添加线的关系。如果没有multilinestring支持，PgOSM Flex 导入将跳过13642053（如以下屏幕截图所示）等关系。这一改进针对道路、水道和公共交通图层。
当我进行更改以添加multilinestring支持时，我意识到我没有向其他一些多边形图层添加关系。这些改进没有被任何东西阻止，除了我还没有注意到这个问题。PgOSM Flex osm.water_polygon表中缺失数据的一个相当突出的例子是狄龙水库。以下查询从使用 PgOSM Flex 0.5.0 导入的科罗拉多州数据集中选择数据。我们得到一个关于旧狄龙水库的结果，这是一个小型水库，旁边就是我们今天所知道的狄龙水库。
SELECT osm_id, osm_type, osm_subtype, name,
ST_Area(ST_Transform(geom, 2773)) AS area_m,
geom
FROM osm_0_5_0.water_polygon
WHERE name ILIKE '%Dillon Reservoir%'
;
┌──────────┬──────────┬─────────────┬──────────────────────┬──────────┐
│ osm_id │ osm_type │ osm_subtype │ name │ area_m │
╞══════════╪══════════╪═════════════╪══════════════════════╪══════════╡
│ 39410606 │ natural │ water │ Old Dillon Reservoir │ 58278.22 │
└──────────┴──────────┴─────────────┴──────────────────────┴──────────┘
复制
查询 PgOSM Flex 0.6.0 加载的数据显示，主油藏现在包含在结果中。计算出的area_m列显示了大小的明显差异！
SELECT osm_id, osm_type, osm_subtype, name,
ST_Area(ST_Transform(geom, 2773)) AS area_m,
geom
FROM osm.water_polygon
WHERE name ILIKE '%Dillon Reservoir%'
;
┌──────────┬──────────┬─────────────┬──────────────────────┬─────────────┐
│ osm_id │ osm_type │ osm_subtype │ name │ area_m │
╞══════════╪══════════╪═════════════╪══════════════════════╪═════════════╡
│ -1954708 │ natural │ water │ Dillon Reservoir │ 13060398.62 │
│ 39410606 │ natural │ water │ Old Dillon Reservoir │ 58278.22 │
└──────────┴──────────┴─────────────┴──────────────────────┴─────────────┘
复制后续改进和重大更改
PgOSM 0.5.1 中引入了上述改进。当然，在0.5.1版本发布后不久，我发现了错误和其他需要解决的长期问题。这些错误是由于我的快速实现，并且很容易解决。其他长期问题围绕着我最初决定使用实例化视图（osm.vplace_polygon）来删除父关系包含的子几何图形。重新考虑这种方法导致了一个⚠️重大的变化⚠️，因此上升到0.6.0而不是0.5.2。
osm.vplace_polygon与 osm.places_in_relations实例化的视图不是在 PgOSM Flex 0.6.0 中创建的。重复数据消除现在通过在导入期间从源表中删除多余的行来处理。
当我开始对 osm.road_line和 osm.water_line表使用相同的方法时，物化视图方法的麻烦变得很明显。创建实例化视图会将数据写入磁盘，从而生成大部分数据的两个副本。此外，实例化视图需要额外的索引，这会占用更多的磁盘空间。
以下查询显示了为什么我之前并不介意place_polygon表上的开销，以及为什么它开始对water_line和road_line表很重要。
SELECT t_name, size_pretty, rows
FROM dd.tables
WHERE s_name = 'osm'
AND t_name IN ('road_line', 'water_line', 'place_polygon')
ORDER BY rows
;
┌───────────────┬─────────────┬────────┐
│ t_name │ size_pretty │ rows │
╞═══════════════╪═════════════╪════════╡
│ place_polygon │ 9448 kB │ 3987 │
│ water_line │ 187 MB │ 443561 │
│ road_line │ 260 MB │ 901777 │
└───────────────┴─────────────┴────────┘
复制对于科罗拉多州，地点数据仅为 10MB，而道路线数据为 260 MB。随着该地区面积的增长（例如北美，欧洲，地球），这些规模变得相当大。继续使用此方法将显著增加磁盘消耗，并为加载和刷新 OpenStreetMap 数据的过程增加不可忽略的时间。没有人想要这样！
易用性
使 PgOSM Flex 易于使用一直是一个大焦点。易于使用是一个很棒的功能，我认为PgOSM Flex在这方面是成功的。这是我维护的一个项目，我认为使用Docker是易用性和可靠性的最佳方法，改进的组合使基于Docker的方法十分实用。
主要改进
关键的改进是 posm2pgsql 内存使用量是可预测的。在osm2pgsql 1.5.0之前，处理需要过多的RAM，并且无法真正预测多少。有了可用于 RAM 消耗的公式，osm2pgsql 调谐器项目成为现实，以确定与 osm2pgsql 一起使用的最佳参数。
PgOSM Flex Docker 映像使用来自osm2pgsql-tuner的逻辑以及–ram.osm.pbf输入和下载文件的文件大小来确定要运行的命令。这使得 Docker 映像易于用于各种区域大小和硬件组合。
osm2pgsql-tuner项目有一个免费的网站和API。您也可以使用 pip install osm2pgsql-tuner 直接从 Python 使用它。
易于定制
通过 Docker 轻松自定义 PgOSM 弹性的使用方式。您可以指定–input-file而不是使用从 Geofabrik 下载的文件。您可以使用 --layerset 和 --layerset-path 来定义自定义图层集，以修改内置样式，或将其完全替换为您自己的样式和后处理 SQL。
如果您不想使用 Docker 映像，则不必使用。手动导入步骤涵盖了这些详细信息。
有关使用和自定义 PgOSM Flex 的更多有用信息，请参阅可用的降价文档列表。
总结
PgOSM Flex 0.6.0提供的数据质量是迄今为止最好的，并且还将继续变得更好。现在我的书已经出版了，我希望有一些时间来研究osm2pgsql 1.7.0中对几何处理的改进。
原文标题：Better OpenStreetMap data using PgOSM Flex 0.6.0
原文作者：Ryan Lambert
原文地址：https://blog.rustprooflabs.com/2022/10/pgosm-flex-improvements-0-6-0
