前言

最近几个月，又攒了很多草稿，但是并没有时间去一一写下来，找个时间慢慢还原好了。

Openstreetmap 是什么？

其实看看 https://www.openstreetmap.org/ 就知道了，地图一个，还是万国语。后文中可能会对其进行简称OSM。

入门，第一阶段

这里也没有什么细节，就是关于地图的各种图层啊，边界啊，数据什么的，简而言之就是大杂烩，什么都得接触一些。

具体涉及到哪些内容：

1. Postgis
2. Osm2pgsql
3. Polyline Encode
4. Geojson
5. TopoJSON
6. EPSG:4326
7. Mapnik
8. WikiData
9. ST_***

总的来说，上面的一部分都只是为了获得一个东西，边界和线路数据。Openstreetmap 提供了大量的接口来支持我的设想。设想都是没有问题的，只是数据的大小和整理的难度超乎了我的想想。

一些高级的工作

为了边界数据，需要全球的边界数据

在这个期间，了解到几个网站，起初以为这里有自己想要的一切数据，后来是真的有，只是和自己的预期有所差异罢了。

1. http://gadm.org 这是一个神奇的网站，特意整理了全球行政区域的边界内容，很好的初心，只可惜数据有点落后，只能期待官网的那句：The current version is 2.8 (November 2015). It delimits 294,430 administrative areas. Version 3 is expected to be available by April 2018.
2. https://wambachers-osm.website/boundaries/ 这里的数据可能是已知最详细的了，只可惜是私人整理，数据的导出实在没有保证，而且部分数据和想象中的有所出入，只能可惜了。期间遇上对方升级，随便找了个BUG。
3. http://wikidata.org/ 这是一个神奇的网站，有很多你无法想想的内容，而且结构化。让我惊奇的是，如果我想找到中国每个省会的坐标，简直不要太容易，前提是学习过它相关的查询语句。
4. http://polygons.openstreetmap.fr/ 这里提供了边界数据的下载，针对特定的osm_relation_id，东西很好用，而且同步很及时，只可惜只支持relation_id，我所需要的可不止这些。
5. http://overapi.com/ 这个是一个关于openstreemap的官方接口，提供查询语句和结构化的搜索，同时下载内容也是很便利的。实际上，有了这个polygons.openstreetmap.fr存在的必要性似乎就没那么大了，但这个接口实在太慢。
6. https://overpass-turbo.eu/ overapi的调试工具，可以算复杂查询的必备了
7. https://geojosn.io/ 一个单纯的geojson查看与编辑的网站，只可惜对超大数据的支持不友好，但也没有更好的了。

中间插入了一个wikidata，或许会很困惑，但同属开放性编辑项目，这个这两个内容的关系就特别有意思了，后文详解。

WikiData 在此的重要性

为什么要深入了解它？

我们在地图上的数据，一般都会指定一个数据来源，以验证数据的真实性。相应的地图上也有很多附加属性，比如名称等，名称的学问就大了，各种翻译之类的，不仅英语分为很多个版本，中文的也很过分，如果只是单纯的认为只有简体和繁体，就太天真了，实际分类多得超乎我们的想象，而Wikidata就解决了这个问题，完全结构化的形式，便于程序的引用。

地图与它的关联有多深

除了上面提到的语言问题，其实也没有什么特殊的，就是那些热门但你想查询的数据。

一个不太恰当的例子，给你一个坐标，如何判断它是否在首都国际机场。

1. 简单的方案，打开地图，输入坐标，看一下，搞定。
2. openstreetmap 输入机场，得到边框数据，程序判断之。
3. WikiData搜索机场，得到ID，下载边框，判断

方案二在于大部分时间都得去验证关于搜索结果的准确性，而OSM的搜索结果实在不敢恭维，这个时候基本无法去人工辨认。方案三的问题是，如何从WikiData得到想要的数据，由于是结构化的数据，整个就简单多了，比如得知机场IATA为PEK，搜索得到WikiDataId为Q32190，然后得到OsmRelId为Way-292809708，一切都水到渠成。至于具体怎么处理这个问题，涉及到的东西就挺多了，足够学习好一阵子了，但都是面向API编程。

方案三的三步基本可以拆解得到如下几个地址：

1. https://query.wikidata.org/ 关于如何通过PEK查询到机场WikiData
2. https://overpass-turbo.eu/ 关于如何从WikiData查询得到OSM相关ID
3. https://www.openstreetmap.org/way/292809708 地图上显示

Openstreetmap 的终极折腾

如果说，上面我已经掌握了基本的查询技巧，那么如何面对大量的查询需求才是最终的问题。可以理解，如果只是几百上千的数据，也许有一定的时间进行数据抓取的工作，但数据大到可计算的时间内都让自己觉得无法处理时。会冒出这样一个想法，如果数据全在自己手上，那么肯定是一件不错的事情。
实际上，这个想法也并非那么疯狂，OSM正好提供了这样的一个镜像，不仅是镜像，而且是一个全量的数据包，支持实时同步，那就是 OSM planet，能让你离线拥有完整的地图数据，除了数据量巨大以外，感觉一切都OK。

接下来就需要面对几个问题，这些都是后期遇到的。

1. OSM PBF 文件高达 39GB，如何下载就是个严肃的问题，我选择了VPS中转，直接宽带满速，但也导致警告不断。
2. Osm2pgsql 导入出错的问题，这里就得判断服务器版本和内存等等问题
3. 导入速度太慢问题，你需要SSD。一块够么，不，你需要两块。
4. 容量问题，39GB数据解压后高达400GB，如果包含全部索引，真不确定，毕竟我没有完成。
5. 内存问题，导入的很多操作，都是需要大内存的，12G够么？真的，不够。
6. 时间，你的电脑能抗住一到两个星期的满负荷运行么。
7. 可能对于部分人不是问题，但风扇真的很吵。

折磨

折腾主要体现在OSM planet的导入过程中，下载很让人期待，毕竟速度很慢。导入出错，可以一步一步了解到自动化构建等一堆新东西，原来大家都不在本地编译代码了。导入速度慢，花了近1K买硬盘，但并不够，从此对随机读写的慢有了深刻体会。导入数据，从1G，10G，100G，400G（四个层级）都失败了一次，每一次的时间都很长很长。第一次是导入软件出错，第二次是内存设置太大挂了，第三次是PgSQL设置有问题出错了，第四次我开始用Hyper跑虚拟机，但在第13天，由于Win10扛不住，内存出错挂掉了，直接导致整个虚拟机挂掉。最惨的是我想恢复的时候，由于虚拟机内存设置了10G，而机器内存只有12G，然后彻底崩溃无法恢复。至此，之前忍受的关于一切的一切都结束了，然后开始关掉电脑睡了一个没有风扇吵闹的觉。

终章

虽然折腾了很多次，前前后后持续时间长大一个多月，但最后还是得掏钱，买吧。新设备始终得有得，想买得还是得买，即使有点小贵，略微舍不得，毕竟穷。

起因

起因很简单，最近一年，累计了太多关于POI相关得知识，如果说有所积累那就是有一切数据得来源，但缺乏数据，缺乏标记。或许慢慢得，这些数据会有点小值钱呢。