1. 需求描述
最近正在开发的一个项目，涉及到这样一个需求：在一个页面的主体中央区域，需要展示一个城市分布于不同地理位置的硬件设备站点的实时数据信息和对应站点的统计信息。
2. 选择之路
需求大意很明确，那么，选择什么方式来完成呢？由于是一个展示页面，首先想到的是Echarts。如下图所示：
从官网的demo，点击进入进去，就可以看到如下所示的源码及效果：
尝试了几个小时，发现存在几方面的问题：（1）指定区域的json矢量数据不容易找到；（2）在设置效果的时候，Echarts地图的api文档是5.x的；而用5.x版本的时候，与页面中同时使用的DataV存在兼容性的问题，于是选择了Echarts4.9版本，解决了兼容性的问题，但api接口官网没有找到4.9的。于是，几个小时的一地鸡毛，得想新的办法。
其次，想到了一年前，当时尝试做过的一个Demo，使用openlayer做的，效果如下图所示：
当时，仅实现了加载不同的数据源，谷歌数据源【现已禁用】、OSM数据数据源，以及简单的缩放平移，鹰眼，显示指定点坐标，加载本地文件，等功能。
于是，试着把这个Demo修改一下，把百度地图添加进去，但是，在添加过程中，发现坐标系统不一致的问题。虽然百度上已经有不少方案，但涉及到的代码繁杂，vue类型的代码，没有找到一个合适的版本，逐行调整，工作量巨大。就这样，又是几个小时，但思维从未停止，在这期间，还发现了vue-openlayer编写的一些开源的项目，下载下来运行了一个，如下图所示：
看着挺漂亮的，该项目使用vue对openlayer进行了简单的封装，同时实现了添加绘制点、线、面的功能。看着中间的照片，挺酷炫的感觉。但现在最重要的是解决问题。一段时间没有接触openlayer，里面的概念有些陌生。看到百度地图坐标的变换代码，虽然看着熟悉，但里面的各种参数，不是我关注的重点。于是，先放下openlayer的选择。思考问题的本质。
为什么最开始没有想到直接用百度地图的API来开发一个展示的地图呢？当然，这个方案估计可行，查阅了相关资料，如下图所示：
从文档的友好程度看，确实，该示例要友好很多。于是，打算尝试用该方案，先尽快解决项目上遇到的问题。与此同时，也对事情本身进行了思考。
3. 思考起点
有句古话说的好，万事开头难。那么，万事开头难，难在哪里呢，是的，就难在开头。一年前，当时自己花费了一定的精力，写了上面的那个demo，不到一年时间，再看代码的时候，记忆已经模糊了，对openlayer的概念也模糊了，为什么会模糊呢，因为遗忘，因为后面没有时间用上该demo，但同时，当时也没有写博客，没有记录下当时学习的思维过程。
与此同时，在网络上，出现了一些vue+openlayer的开源代码及资料，丰富了openlayer的学习资源。
上面先放下openlayer，直接选择百度地图API，并不是因为前者解决不了问题，而是，成本比较高，短时间无法达到想要的效果，与此同时，当然选择百度地图，或者高德地图，或者腾讯地图，完成需要的目标都会快很多。
那么，在什么情况下，应该选择什么产品或平台呢，这个问题，是需要进一步深入思考的。下面，引用一篇博客中的介绍：
GIS前端渲染库除了OpenLayers还有LeafLet和ESRI公司的ArcGIS
API，同样能支持地图的前端库还有百度api，高德api，谷歌api等，还有Echarts，D3.js等，初学者常常不能理解他们之间的关系。常常听人说，路径分析我就用高德API不就可以了吗？展示数据我用下Echarts不可以吗？仍然是一句话，选择什么样的工具，完全是依据实际业务需求而定的。当前和地图相关的库大概分类如下：在线地图lbs服务：这类库的代表是百度api，高德api，谷歌api，主要特点是：公网环境，开发者需要申请key，key的地图请求服务有次数限制。地图数据和服务都是百度高德提供的，开发者常常是将业务有限的点（几个点，几十个点，几百个点等）定到地图上定个位置。开发中使用它们主要是如招聘网站上公司位置的一个定位，互联网应用中的lbs服务，如各种快递，外卖等app中附近的餐馆影院等。在企业和政府应用中，业务非常复杂，在线地图服务提供的数据不是我们要的，提供的服务不能满足我们的应用，所以实际上基本不会在企业开发中使用。LBS！=GIS。
数据可视化库：Echarts，D3.js主要作用是web端实现数据可视化的，提供丰富的图表等展示和交互，由于地图的使用越来越普及，所以不可避免的他们也会支持数据在地图上的展示。但主要定位仍然是数据可视化，在开发中，常常指定某个div，用来展示和交互下数据，属于页面的一小部分业务。而一般的综合指挥调度系统的地图是一个应用，加载非常多的图层，可以随时通过地图向地图单元发送指挥命令。page！=application。
GIS地图库:ol,LeafLet,arcgis api等都属于企业级地图应用开发库，彼此之间大同小异。稍微的差异是arcgis
api需要arcserver提供服务，离开了server基本没任何优势。leaflet主要优势还是在开发的第三方控件比较多，但是兼容性比较差。且以“体积小，对移动端友好”为著称，在ol2的年代的确如此，但个人认为API的结构不如ol好，且ol3之后版本支持自定义打包，也支持移动端应用，ol4版本实现es6的import语法，实现按需加载，足以胜任开发大型GIS应用的要求。综述：OpenLayers是GIS地图库，定位于开发GIS应用，而非地图页面，用于复杂的展示和交互用户数据。
从引用文字中可以看出，各类产品适用的场景。当然，实际使用的时候，常常根据需求而定。后期如果有适合openlayer的应用场景，还是会选择openlayer来实现的，展示方面，地图api应该是足够的，后续需要调整，再调整吧，先解决问题。