OSM Deep History is a tool to show tag changes of an OSM object (node, way, relation). But it doesn’t provide too much visualization of history on map.

Base on it I’ve made OSM Visual History. The new tool has several enhancement on UI and features, including:

• Improve map UI and fix issues
• Scrollable table with fixed header and first column
• When mouse hover on table cell, highlight corresponding version of object on map and pan to center
• Base map layer supports both OpenStreetMap and Google Satellite
• Export full data of specific version in Level0L format
• Show way(s) which the node belongs to
• Show history versions of way on map

History of node:

History of way:

OSM的多语言名称使用 name:code=* tag，但是 code 的使用限制在 ISO 639-1/2，对于中文，就只有 zh 这个编码，无法区分简体中文、正体中文，更无法区分不同地区（大陆、香港、台湾等）的命名区别了（例如“珠穆朗玛峰”，“圣母峰”）。

这造成目前中文地名的标准相当混乱，有些地名使用 name=* 这个tag里面同时放进去简体中文、正体中文和英文，有些地名被某些 mapper 根据自己喜好在简体中文、正体中文之间来回更换。

实际上，对于具体一个地图用户而言，他只关心地名在他惯常使用的语言中是什么。本来技术上完全可以解决这个问题，Android、iOS、web 都有技术规范去根据用户设定的 locale（包括语言和地区）去显示。但由于 OSM 的数据标注没有支持中文语言的细分，大家没有共同遵守的标准去编辑。

有 mapper 提出改进的提案，但似乎后来没有进一步行动了。

统计了一下目前中文的 name tag 语言代码使用情况（排除了拼音）：

  | key                  | count  | user |
  | -------------------- | ------ | ---- |
  | name:zh              | 259513 | 6116 |
  | name:zh-yue          | 1145   | 240  |
  | name:zh-hant         | 1061   | 62   |
  | name:zh-min-nan      | 815    | 165  |
  | name:zh-classical    | 522    | 129  |
  | name:zh-traditional  | 377    | 72   |
  | name:zh-simplified   | 183    | 55   |
  | name:zh-CN           | 101    | 17   |
  | name:zh-hans         | 87     | 26   |
  | name:zh-Hant-CN      | 75     | 9    |
  | name:zh-Hans         | 69     | 20   |
  | name:zh-Hant         | 69     | 21   |
  | name:zh-cn           | 65     | 8    |
  | name:zh_trad         | 59     | 8    |
  | name:zh_cn           | 28     | 8    |
  | name:zh-hant-CN      | 17     | 1    |
  | name:zh-TW           | 13     | 12   |
  | name:zh-tw           | 10     | 6    |
  | name:zh-sg           | 8      | 4    |
  | name:zh-hk           | 8      | 4    |
  | name:zh-mo           | 8      | 3    |
  | name:zh_1            | 5      | 3    |
  | name:zh_tw           | 5      | 3    |
  | name:zh_hant         | 3      | 3    |
  | name:zh2             | 3      | 3    |
  | name:zh_TW           | 3      | 3    |
  | name:zh-pinyin       | 2      | 2    |
  | name:zh_tradition    | 2      | 2    |
  | name:zh-Hans-cn      | 2      | 2    |
  | name:zh-Hant-tw      | 2      | 2    |
  | name:zh_arab         | 2      | 2    |
  | name:zh-Hans-CN      | 1      | 1    |
  | name:zh-Hant-TW      | 1      | 1    |
  | name:zh-Hant-hk      | 1      | 1    |
  | name:zh3             | 1      | 1    |
  | name:zh_hk           | 1      | 1    |
  | name:zh:note         | 1      | 1    |
  | name:zh_jyutping     | 1      | 1    |
  | name:zh-simpified    | 1      | 1    |
  | name:zh_hans         | 1      | 1    |
  | name:zh_2            | 1      | 1    |
  | name:zh-min          | 1      | 1    |

使用 OpenStreetMap （简称为OSM）地图数据的手机应用有好些，OsmAnd 是其中比较优秀的一个。OsmAnd的地图数据每月更新一次，延后了半个月到一个多月。作为一个OSM mapper，期望能够马上看到和用到最近做出的修改，等一个月实在太久了。

OSM原始地图数据在 planet.osm 的网站可以下载到，但数据文件是全球的，非常大。从 GeoFabrik 可以下载按国家分割的数据文件。中国区的PBF格式数据是330MB。但每天重新下载一个数据包还是太大了，其实更新的数据不是很多。网站上还提供每天（planet.osm还有每小时）的变更数据包（osc文件），用 osmupdate 工具就能自动下载变更并且生成新的完整数据文件。

有了最新的 osm.pbf 数据文件，就可以使用 OsmAndMapCreator 生成 OsmAnd 可用的 OBF 格式离线地图文件了。生成的过程非常耗内存和CPU，全中国的地图在一台 Core i3-4370 CPU 的电脑上用了90分钟，需要分配 10GB 内存才够用（否则会出现 OutOfMemory 错误）。生成出来的 OBF 文件也有845MB之巨。为了缩短时间，我设置了 osmupdate 的-b参数，过滤出广东中部区域的数据，这样就快很多，几分钟搞定。

处理的流程如下图。实际上安装好软件，修改好配置后，每次更新就执行一个脚本，过程全自动。

Previous full map data (osm.pbf) \
                              [osmupdate] --> Latest full map data (osm.pbf)
            Recent changes (osc) /                      |
                                                        v
[OsmAnd] <------ Latest offline map (obf) <------- [OsmAndMapCreator]

步骤和脚本放在 gist：https://gist.github.com/aleung/42776348d023b689e8c337b82a3c7cd5，适用于 MacOS 和 Linix，需要自行修改文件中的目录路径。工具在Win平台也可以用，但脚本就要重新写了。

现有的人行天桥大部分都是根据卫星图描绘出来，下桥楼梯的走向、位置与真实一致。这样的好处是出来的地图放大后与现实相符。例如：

但是，如果考虑到使用OSM来做步行导航的时候，导航引擎是不会选择这样的天桥的，因为它没有与其它道路相连——也就是说，对于导航引擎而言，这个天桥是一个孤立的存在，不可达的。

另一种做法是放弃地图微观的形态，关注其意，直接将天桥楼梯连接到附近的道路上。这样绘制的地图放大来看是位置不是非常准确，但保证了可导航性。 如下图：

最理想的做法是将人行道(sidewalk)单独描绘出来，天桥楼梯连接到人行道。导航引擎也会优先选择人行道。

但是人行道的描绘的工作量会非常大，在独立人行道未成网之前，可以先在天桥楼梯旁边画出一小段人行道，连入道路保持可导航性，待有时间继续做的时候再分离开来进行延长，最后做好一段路的路边人行道之后，可以把马路的步行属性设为no。

路边人行道不建议在双向两车道的小路上做，这样子图层就不美观了，只需在大路的交汇处与人行横道连接起来并入网络就可以了。

以上为与羊角忠实黑讨论的纪录