Open liujiusheng opened 2 years ago
传统GIS概念较多，而实际，如今大众GIS方面用到的知识只是九牛一毛，所以在新的软件产品设计过程中要剔除掉一些不常用的GIS概念，让GIS技术大众化，为大众服务。
ArcGIS占据主要国内市场，其GDB格式甚至成为了如今工作的标准数据格式，但这一格式属于闭源性格式，虽然开放了二进制的Esri File GDB的dll文件和demo，但这远远不够。其它国内商业公司也都自建了自有的闭源格式，这种闭源格式对软件市场规模的扩大很不友好。虽然Esri shape file作为另一种常用格式属于开源格式，Esri shape file最大的问题是无法提供中文字段别名，导致国内使用很被动。
目前国家推行CGCS2000国家大地坐标系，如果只在国内使用的话，软件地理坐标只需要支持CGCS2000坐标就可以了。平面投影上直接采用WEB 默卡托，三维里面直接采用10进制经纬度就可以了。
不得不说，从事这么多年GIS相关工作的我也没有太搞懂每一种坐标系具体是怎么一回事。我想那些非专业人员可能就更不懂了吧，很多人非专业的人通过我的文章来咨询我。
要脱离ArcGIS体系可以借助PG数据库+POSTGIS插件，但使用数据库需要导入导出，迁移也极易失败，所以采用PG的方案是个可用的方案但不是最优方案。
按GIS行业日常工作逻辑，成果的分发和汇交都以拷备为主，并且成果内通常还带有PDF、EXCEL、JPEG等多种其它格式的附件资料，所以文件系统是最有效的数据管理方式，服务最好也能直接依托于文件系统式管理的数据，可避免数据导入导出的麻烦。
粗略对比了一圈，发现SQlite是一个较符合以上设想的软件。
一方面它以.db文件的形式存放单个数据库数据便于拷备，另一方面SQLite本身开源并且具备优秀的跨平台能力，最后它本身是一个数据库文件可以很容易检索。
sqlite不支持字段和表别名，这是硬伤，对非英语母语国家来说别名非常重要。
GIS方面的日常工作以Windows操作系统为主，但如今信息化快速推进，绝大多数工作成果还会共享到Linux系统上发布为服务。
现在的国产化也是一个大趋势，几乎所有国产化的桌面操作系统都基于Linux二次开发。
所以新的产品应该具备跨平台能力。
数据量增大是必然趋势，提供一种简单的分布式方案也势在必行。
目前分布式方面以GO实现最为方便快捷而且高性能，而且天然跨平台。
Docker、K8S、Minio等多种性能要求较高的核心应用软件都基于GO进行开发，GO是未来的主流语言之一。
未来肯定是三维的时代，但大量存量的二维数据是目前的主流，所以应有一套很好的二三维融合方案。
计算距离、分析路线、计算相交、数据裁剪、可视分析、挖填方分析等都是很常用的分析需求，软件中应考虑提供相关支持接口。
大屏展示需求较多，可视化展示能力需要更高。
大展展示需求较多，需要提供更多动效支持。
采用分级抽稀计算方法，力争做到一个点数据只传输一次，前端的数据根据层级逐级累加，大思路是使用算力换流量。
HTTP/2在数据传输效率上得到了较大提升，虽然之前我有专门对比研究过HTTP/2在WEB GIS上的应用，结果是性能无明显提升。但在高分辨率下由于请求的瓦片数量大幅度增加，多瓦片的同步传输就能有较明显的优势了。况且，若服务对外向海量用户提供服务，单张瓦片节省的0.1kb流量累计下来依然是个庞大的数值。
众所周知，OGC定义了整套WEB GIS的服务标准，但实际上我们99%的场景上只用到了WMTS这一个服务，而且它的GetInfo等配套的方法几乎从未使用过。
如今常规的WMTS瓦片输出有png、jpeg、MVT等格式，需要统一到一种方法让用户只需要配一次图就能发布多种格式的服务。
一次图都不配直接从ArcGIS中导入是不太现实的，毕竟这是一种闭源的格式，ArcGIS也未开放任何接口。
以Mapbox的MVT矢量瓦片格式为代表的新型数据服务格式，虽然性能优异，压缩效率较高，但其操作图层需要按单个图层进行操作在某些特定场景中较不合理，因为部分“图层”实际是由多个图层组合而呈现的视觉效果。所以应提供按组操作的功能。
标准规范需要开放，利于部分有实力的企业基于标准自研，繁荣市场。
源数据可以是不加密的，但共享到Web前端的数据必须采用一定方法加密，防止居心不良的企业或个人根据开源的格式逆向数据。
可以较低价格出售源代码。
传统GIS引擎动则几十万的购买费用让中小企业很难消费，开源产品质量又太差。急需一款售价足够低，发展C端用户为主的产品。
弱化传统GIS概念
传统GIS概念较多，而实际，如今大众GIS方面用到的知识只是九牛一毛，所以在新的软件产品设计过程中要剔除掉一些不常用的GIS概念，让GIS技术大众化，为大众服务。
去ArcGIS化
ArcGIS占据主要国内市场，其GDB格式甚至成为了如今工作的标准数据格式，但这一格式属于闭源性格式，虽然开放了二进制的Esri File GDB的dll文件和demo，但这远远不够。其它国内商业公司也都自建了自有的闭源格式，这种闭源格式对软件市场规模的扩大很不友好。虽然Esri shape file作为另一种常用格式属于开源格式，Esri shape file最大的问题是无法提供中文字段别名，导致国内使用很被动。
坐标系概念简化
目前国家推行CGCS2000国家大地坐标系，如果只在国内使用的话，软件地理坐标只需要支持CGCS2000坐标就可以了。平面投影上直接采用WEB 默卡托，三维里面直接采用10进制经纬度就可以了。
不得不说，从事这么多年GIS相关工作的我也没有太搞懂每一种坐标系具体是怎么一回事。我想那些非专业人员可能就更不懂了吧，很多人非专业的人通过我的文章来咨询我。
文件系统即服务
要脱离ArcGIS体系可以借助PG数据库+POSTGIS插件，但使用数据库需要导入导出，迁移也极易失败，所以采用PG的方案是个可用的方案但不是最优方案。
按GIS行业日常工作逻辑，成果的分发和汇交都以拷备为主，并且成果内通常还带有PDF、EXCEL、JPEG等多种其它格式的附件资料，所以文件系统是最有效的数据管理方式，服务最好也能直接依托于文件系统式管理的数据，可避免数据导入导出的麻烦。
粗略对比了一圈，发现SQlite是一个较符合以上设想的软件。
一方面它以.db文件的形式存放单个数据库数据便于拷备，另一方面SQLite本身开源并且具备优秀的跨平台能力，最后它本身是一个数据库文件可以很容易检索。
sqlite不支持字段和表别名，这是硬伤，对非英语母语国家来说别名非常重要。
跨平台
GIS方面的日常工作以Windows操作系统为主，但如今信息化快速推进，绝大多数工作成果还会共享到Linux系统上发布为服务。
现在的国产化也是一个大趋势，几乎所有国产化的桌面操作系统都基于Linux二次开发。
所以新的产品应该具备跨平台能力。
自动分布式
数据量增大是必然趋势，提供一种简单的分布式方案也势在必行。
目前分布式方面以GO实现最为方便快捷而且高性能，而且天然跨平台。
Docker、K8S、Minio等多种性能要求较高的核心应用软件都基于GO进行开发，GO是未来的主流语言之一。
二/三维一体化支持
未来肯定是三维的时代，但大量存量的二维数据是目前的主流，所以应有一套很好的二三维融合方案。
空间分析支持
计算距离、分析路线、计算相交、数据裁剪、可视分析、挖填方分析等都是很常用的分析需求，软件中应考虑提供相关支持接口。
前端可视化支持
大屏展示需求较多，可视化展示能力需要更高。
前端动效支持
大展展示需求较多，需要提供更多动效支持。
基于三维的革命性LOD算法
采用分级抽稀计算方法，力争做到一个点数据只传输一次，前端的数据根据层级逐级累加，大思路是使用算力换流量。
HTTP/2支持
HTTP/2在数据传输效率上得到了较大提升，虽然之前我有专门对比研究过HTTP/2在WEB GIS上的应用，结果是性能无明显提升。但在高分辨率下由于请求的瓦片数量大幅度增加，多瓦片的同步传输就能有较明显的优势了。况且，若服务对外向海量用户提供服务，单张瓦片节省的0.1kb流量累计下来依然是个庞大的数值。
不完全实现OGC标准
众所周知，OGC定义了整套WEB GIS的服务标准，但实际上我们99%的场景上只用到了WMTS这一个服务，而且它的GetInfo等配套的方法几乎从未使用过。
一次配图多种服务格式输出
如今常规的WMTS瓦片输出有png、jpeg、MVT等格式，需要统一到一种方法让用户只需要配一次图就能发布多种格式的服务。
一次图都不配直接从ArcGIS中导入是不太现实的，毕竟这是一种闭源的格式，ArcGIS也未开放任何接口。
图层组概念
以Mapbox的MVT矢量瓦片格式为代表的新型数据服务格式，虽然性能优异，压缩效率较高，但其操作图层需要按单个图层进行操作在某些特定场景中较不合理，因为部分“图层”实际是由多个图层组合而呈现的视觉效果。所以应提供按组操作的功能。
格式开源
标准规范需要开放，利于部分有实力的企业基于标准自研，繁荣市场。
Web端数据加密
源数据可以是不加密的，但共享到Web前端的数据必须采用一定方法加密，防止居心不良的企业或个人根据开源的格式逆向数据。
代码有条件开放
可以较低价格出售源代码。
产品低价
传统GIS引擎动则几十万的购买费用让中小企业很难消费，开源产品质量又太差。急需一款售价足够低，发展C端用户为主的产品。