如何处理openstreetmap.org的原始OSM数据

谁能提供有关www.openstreetmap.org如何处理或呈现OSM数据的见解？

一个具体的示例...我从最近的planet.osm PostGIS数据集中提取了密苏里州某个区域的数据。OSM数据需要大量清理，然后才能使用正确的样式呈现。许多水体被存储为不能正确关闭的线串，因此我必须使用FME进行捕捉，然后再进行多边形构建，这样我才能拥有充满蓝色的河流/湖泊。

如果我在这里查看相同的数据，水体将按预期方式渲染。

我在确定所有需要捕捉的情况时遇到了麻烦（例如，哪些“自然”类型需要捕捉，以及应具有的公差）。另外，我怀疑在与整个北美地区打交道时，还有许多其他数据问题我将永远不会看到。

下载和使用OSM数据的每个人都会经过自己的清理过程吗？有人知道www.openstreetmap.org如何处理此清理吗？看来他们的过程将是最有见识和最受考验的。

任何见解非常感谢。

编辑：这是有关我的工作流程的更多信息

使用Osmosis将planet.osm文件下载并加载到PostGIS中，并加载到pgsql模式中。然后，我再次使用Osmosis从PostGIS中提取OSM xml的许多小区域。然后，使用FME及其广泛的功能类别将每个这些小型xml文件转换为Shapefile。我希望正是在这一阶段（通过FME通过OSM xml-> Shp）将线转换为多边形并对数据执行其他清理。

这些Shapefile通过GeoServer提供服务（并使用GWC进行缓存）。

好的，对此有一些不同的角度，并且由于尚不清楚您最初如何处理数据，我想我只是概述一下。

消耗OSM数据的主要方法有两种：使用osm2pgsql（一种较旧的工具，支持“样式表”和差异更新），以及使用Imposm（一种较新的基于Python的系统，该系统支持基于Python的样式表转换）。当人们进行处理时，很多都是以这种脚本编写的。例如，这是osm-bright的imposm映射，即MapBox Streets（披露/雇员）所基于的样式表。

为了更具体地了解所遇到的情况，很可能是您没有正确正确地处理osm关系，在数据模型中，osm关系允许多个线串形成多边形。Imposm和osm2​​pgsql之类的工具通常可以为您处理这种数据转换。

就OSM.org本身的工作方式而言：编辑位于“语义”的Postgres数据库中，并通过渗透将其连续导入到PostGIS数据库中，并使用Mapnik进行渲染。在数据库和地图渲染之间没有手动清理步骤，因为两者之间高度耦合，并且地图的目标是保持最新状态。

通常，您不需要这样的“捕捉”，因为原始OSM数据是按拓扑结构组织的-例如，多边形（= OSM方式）是通过节点索引列表（而不是直接通过其坐标）定义的-因此，如果起始索引和结束索引相同，则将其视为封闭多边形。否则，它是一条折线（如道路）。

较大的物体（如您的情况中的Osage河）通常是通过OSM多边形定义的，该多边形由一系列OSM方式（线串）组成，这些方式定义了形状和孔（如果有）。OSM多边形存在多个潜在问题：

1. 定义它们的方法不止一种（只需看一下规格）。不同的人使用不同的规则。
2. 规则是隐式的-您需要通读OSM Wiki文档以尝试了解如何处理它们。
3. 如果使用OSM数据提取，则可能缺少多面体的某些部分（因为它们不在地理上位于密苏里州内）。因此，您需要找到一种关闭水体多边形的方法（通过使用状态边界对其进行裁剪或使用某些GUI工具手动将其关闭）。

是的，还有其他数据问题。它们主要来自OSM映射的本质：不同的人以不同的方式映射事物，并且没有关于如何执行映射的固定规则。它或多或少是一个自组织的无政府状态；）

我本人从未使用过由osm2pgsql生成的扁平化OSM数据-我总是以OSM XML格式的原始拓扑数据开始，然后编写代码以将其处理为所需的格式。但是话又说回来，我不使用Mapnik进行渲染，因此我可能只占少数。

如果使用osm2pgsql的原始数据库方案，则将相关的osm数据模型“封闭方式”和“ multipolygon-relation”转换为多边形，并将其放置在名为“ planet_polygon”的表中。方式和节点位于“ planet_line”和“ planet_point”中。您可以通过Quantum GIS访问这些表，并将它们直接导出到shapefile。您也可以从Quantum GIS内部进行SQL查询以过滤数据。

我不会为此使用渗透。它不像osm2pgsql那样具有多边形处理。渗透以与贡献者处理数据相同的方式（节点，方式和关系）存储数据。它不是适合呈现的数据库方案。