GIS空间数据存储的新尝试

qiang

1、主流商业方案还是开源方案
实验室有ArcGIS系列全套，面对豪华的主流软件配备，不少小组都在频繁地使用ESRI的ArcSDE、ArcEngine、ArcIMS、ArcGIS Server等产品。并且听说有时候仅仅为了方便读取空间数据就使用SDE，仅仅为了同SDE建立连接就使用AO，于是一直在想，有些时候，这样做到底合不合适。如果打算使用ESRI的客户端，那SDE等产品绝对是首选，他们有着几乎无缝的集成和完整的功能体系。但如果为了简单地数据显示而动用代价昂贵的天兵天将，很难说清是对是错。值得理解的是，大多数情况，项目投资方用的起这些天兵天将，没错，这样很好，大家都满意。但是不是该研究下第二选择呢，我不敢肯定，但确是值得考虑。开源世界有许多值得研究的东西，将可学习、可扩展的开源软件应用到实际工作中，这一直都是被我们忽略的一片土地。不必为了使用开源软件而使用，只是它有用，能承担重任，就不应该排斥它。
2、数据存储

最先吸引我注意的是空间数据存储。尤其是Oracle、MS SQLServer和DB2，甚至开源领域的MySQL和PostgreSQL都相继扩展原有数据存储能力，将空间数据作为其基本存储类型，这些实现都相对一致。用专门的geometry字段来存储空间数据，扩展空间操作和空间索引。SDE将空间数据作为二进制格式存储起来，当然，它也支持直接读取Oracle等常用DBMS的Spatial扩展的空间数据类型，并且也表现地很好，并为其提供了良好的长事务处理和版本管理等Spatial扩展通常难以提供的特性。
很容易产生的疑问是：随着各种Spatial的壮大，如果空间数据作为Geometry存储在Spatial中能够满足要求，并且如果应用中不需要很强大的长事务处理和版本管理，为什么非要使用SDE？我们是不是可以寻找到一个合适的方案或是几个方案的整合，从而越过中间件来进行部署？或者能否提供其他的足够健壮的中间件方案？很多论坛和使用者从效率、成本及具体方案等角度做了比较和讨论。其中不乏争论，有了争论，就难下定论，于是需要实践一下。以前显然不值得一试，现在未必，以后更难说。
目前我可以获得的软件中，DB2的Express-C版本在这方面作了删减，暂不可重用。MS SQLServer刚涉及此领域。MySQL的数据库功能不完整，虽然没有亲手做过测试，但网上关于存储海量数据时性能下降太快的抱怨此起彼伏，暂不用。
3、PostgreSQL（利用PostGIS）
于是先尝试PostgreSQL。PostgreSQL功能非常丰富，和当初想象的状况不是一个数量级。PostGIS扩展为PostgreSQL注入了 GIS的活力，令其在GIS领域的应用远远超越MySQL。PostgreSQL8.x版本开始默认集成了PostGIS。

下面是PostgreSQL官网上列出的数据：
Maximum Database Size Unlimited
Maximum Table Size 32 TB
Maximum Row Size 1.6 TB
Maximum Field Size 1 GB
Maximum Rows per Table Unlimited
Maximum Columns per Table 250 - 1600 depending on column types
Maximum Indexes per Table Unlimited
尝试往PostgreSQL导入Shapefile文件时，很开心地看到它提供了shp2pgsql这个命令行工具，可以方便地读取shapefile并写出相应导入功能的sql文件。执行命令类似于：
shp2pgsql 4326 shapefilename schema.tablename>target.sql
其中：4326是WGS84对应的EPSG参考系sid，不同数据有不同的参考坐标系；schema和tablename对应于PostgreSQL数据库的模式和拟建的数据表名； roads.sql为输出的sql文件。
导出数据也许很容易成功，但执行sql注入数据时很容易遇到讨厌的encoding问题。为了适应大多数需求，安装PostgreSQL时选取的字符集也许是UNICODE（utf-8），但数据源可能是任意的字符集。shp2pgsql给出转换字符集的命令行参数-W<encoding>，但尝试了很多次都失败，出现提示：utf8: iconv_open: Invalid argument。如果不进行转换，在导入数据集时数据库又会报错。抱着一试的心态尝试了一下利用notepad另存sql数据为unicode，然后导入sql到数据库，但是20000多条数据记录导到9000多条时就出错回滚。试了很多次，回滚时的记录数有过变化，都没有能全部导入，也没能找到最终解决办法。但没有中文的数据就完全没有问题。这方面还需继续研究。眼下还有一条可能的途径是用命令行psql导入sql文件，如果它有字符集转换功能的话（未尝试），设定转换参数。
ogr2ogr是另一个开源数据转换工具，支持格式颇多，可惜并没有字符编码转换功能。除非放弃中文，或者修改源代码重新编译，否则必然问题一堆。
4、Oracle Spatial
不愧是大型商业软件，Oracle提供的从shapefile到空间数据对象的转换工具（shp2sdo）显然健壮地多。转换步骤也体现地较为完整。命令类似如下：
shp2sdo roads roads -g geom -d -x \(118.338981,119.22857\) -y
\(31.231102,32.613331\) -s 4326 -t 0.5 -v
这个命令将生成两个文件：sql文件和一个ctl控制文件。sql文件用来创建符合这个shapefile字段要求的数据表；ctl文件针对字段插入数据（必须使用SQLLoader）。导入数据成功后还需要根据实际情况为数据建立索引。
Spatial的自定义数据类型有很多中，都在MDSYS方案下。经常使用的是SDO_GEOMETRY，表示一个几何对象，可以是点、线、面、多点、多线、多面或混合对象，还实现了R树空间索引和四叉树空间索引，以SQL函数的方式形式实现了多种空间分析功能。提供了java API访问单个字段的geometry字段，也就使访问单条地理坐标记录变为了现实，这也是使用ArcSDE很容易令人头疼的地方。
5、下一步：需要提供地图服务的服务器端软件
局域网环境下，利用uDig访问Oracle数据库并现实数据集（它很好地支持了这个功能）颇耗时间和资源，毕竟是直接获取数据集至前台绘制，数据量庞大。因此服务器端地图服务处理仍然必不可少。

wwxx

进来看看 学习学习