引用部分均为笔者思考.
地图在抽象概括表达中使用两种观点:
场的视角一般面对非对象模型,如一些"自然现象",即它们没有对象这个概念,或者对象粒度太小.但传统数据库的粒度一般是对象语义的,场的存储可能不适合直接存放于传统数据库.
- 有必要为场数据专门设计数据库吗?
- 或者说为场数据在现有数据库中专门设计容器,让其操作起来像场,但实际是对象?
场模型主要有以下3种:
- 理论上是精度最高的,但如何找到/划分合适联通域,找到合适的数学函数表达式则很难
- 因为值都是实时计算出来,所以参与其他计算时会比较麻烦
可以看做对象模型,但需要区分两种划分对象的方式(以等值线为例):
- 层形:生成大于/小于某个高程的一整张面
- 环形:生成大于某个高程值且小于某个高程值的环
两种划分方式适用于不同的使用场景
选样模型不容易参与矢量运算,比较适合参与栅格计算
对象观点是我们更加容易接触到的,也天生适合放入数据库管理.
- 一般来说,通过业务设计而非底层支持已经能满足很多时间维度的需求
- 相比空间需求,时间维度的需求可能即少,又不同,因此不适宜做成通用功能,因此传统空间数据库底层设计为带时间维度的较少.
- 地理数据随着时间变化的一般随其复杂度/尺度下降而上升:
- 人抽象化为一个点,则不断在变
- 更加复杂的房子,道路则一般不变
一般来说,小于厘米级的尺度已经不能算是传统的地理信息尺度了,但随着传感器的性能上升,会出现单个尺度极小但整体空间范围在地理尺度的地物.比如高精点云.这又与场类似了,但场一般只要求地理级别的精度.
海量性特征具有深刻的现实意义:个人往往无法掌握海量的空间数据,但拥有海量空间数据的组织往往具有独特的需求,他们的海量数据可能是场形式或者对象形式,或者拥有庞大的时间维度,不一而足.传统的空间数据库需要变得越来越复杂,才能更好的应对不同用户的需求,但这也意味着:
- 就算空间数据库变得越来越复杂,也往往是诸多需求的交集,难以满足更精细/定制化的需求
- 对于用户来说,定制数据库远比定制自己的业务更难,但空间数据中的数据又最适合在库内计算.因此无法实现成本效率的最优
- 软件的分发是低成本的,对用户/厂商来说开关某个功能的成本很低,但如果是带硬件加速的功能呢?对于非定制化的空间数据库,采购无用的功能的成本就让用户支付了.
以上这些没有发生可能因为用户的需求还没有真正的被释放出来