作者归档：贺 利华

关于贺 利华

正在学习编程，享受编程 热爱文学，闲来读读《读库》 有思想，没理想 正在学会专注

再论GIS和云计算

发表评论

本周一，有幸因为团队小组领导即将离职，所以获得了一次不错的机会，可以近距离地听取一次由IBM中国云计算研究中心的三位工程师带来的关于云计算的培训式讲座。鄙人抱着很高的期望前去，和我怀着同样心态前去的人也不少，当时讲座场地是公司总部的一个会议室，不大，能容下30个人不到吧，坐满了。

开篇由一位技术工程师给我们做了一个入门级别的云计算介绍，主要集中在IBM云计算硬件和相关的虚拟化的软件。其中有介绍到云计算的一些优点，主要有以下几点吧（记录得并不是很全面）

  • 给用户提供一个一体化的体验
  • 成本的节约
  • 效率的提高
  • 安全性的提高

我们都知道云计算服务提供商一般可以为中小型企业提供非常廉价但是高性能的硬件和软件环境，企业产品的构建和部署均可以在云端进行，这在很大程度上解决了企业维护硬件和运营的成本，机房的能耗和故障往往会成为小型企业产品研发和运营中的鸡肋，而云计算服务提供商给了我们一个非常完美的Solution。IBM这样的企业又能为我们提供什么呢？IBM面向的一般都是企业级用户，也就是政府和企事业单位，这些组织机构对硬件和软件的要求一般情况下都是很大的，例如IBM在无锡给某个软件园建设的云计算平台，就是软硬件结合，进驻软件园的企业并不需要自己采购大量的服务器产品和相关的软件，而只需使用软件园中的账户登录软件园的云计算平台，根据企业项目的需求申请获取相应的硬件资源，定制操作系统和相关构建的软件等等。这极大地增强了企业的灵活性，节约了众多的维护和运维的成本，企业在项目紧张的时候可以申请更多的资源，而较为闲暇之时使用的资源大大减少，而不像传统软件企业依然需要耗费大量的人力去维护相关的软硬件资源。既然云计算能为我们这些企业级用户带来这么大的优势，为企业大大节约成本，那么云计算在GIS产业中将如何体现其价值呢？

因为目前服务式GIS还主要集中在地图出图和简单的分析上，而地图出图渲染和分析这种功能需求往往有非常强的时刻型需求，也就是说，我们可以会有需求每个小时出一次全国地区的气象云图等等，并做相关的分析得出结果。那么在这个时刻点上，系统所需要的资源就会非常之多，系统的负载就非常大，而其余的时间系统大部分资源都是闲置的。那么我们能通过云计算来解决这个问题吗？我们都知道云计算的主要优势在于海量存储与高计算能力，然而在图形显示上并没有太多的优势。而GIS出图对于系统GDI资源的消耗非常大，而系统的GDI资源往往是非常有限的，那么怎么来解决这个问题呢？IBM的小型机跑的一般都是AIX系统，显卡的性能也很一般，那么这个问题如何解决呢？当然我们可以借鉴一些电信计费和结算系统的原理来进行一个高峰时期错开的处理，由于日常生活中人们的电话通信一般时间在白天，那么白天的计费系统肯定负载非常之大，而晚上计费系统负载相对就会小很多，这个时候就可以将大部分资源调度给结算系统来进行结算。其实我们GIS的这个问题也可以这么解决，假设我们现在的系统中有非常强大的计算能力，图形渲染能力相对较差，那么我们在系统并不需要进行出图的时候，充分利用系统的计算能力生成大量的地图缓存，而在需要出图的时刻调度所有的GDI资源来进行渲染，地图缓存很显然会极大提供地图显示和出图的速度的。

那么应用点仅仅停留在此吗？恐怕不止。目前我们国家的诸多政府部门都在构建自己的系统，而这些系统中都多多少少的能看到GIS的影子，但是这些部门又不像国土局和测绘局对GIS有如此强烈的需求，他们只是在一些特殊的时候需要使用到GIS。例如卫生局，当管辖区域出现传染疾病灾情时，就非常需要依托地图数据和疾病传染的一些模型来计算出可以传染的区域，并及时对这些区域进行处理。那么卫生局愿意每一年向测绘局等等其他的组织机构购买相关数据吗？这些数据可以每年都会发生更新的哦，每年都买吗？我想很多部门是不愿意的，在需要的时候又希望能迅速获取数据，在平日里并不愿意也不需要支付高额的费用，是很多组织机构的共同需求。那么云计算就完全可以插一脚了，政府或者企业通过建立一个大型的平台，包含软硬件资源，数据生产部门可以通过提交数据来获取利润，而消费部门完全可以节省大量的软硬件维护费用，按需索取即可。当然这是一个抛开了所有体制的设想，至于市场的可能性，who knows?

你看好GIS Cloud吗？我不看好。路漫漫其修远兮，吾将上下而求索。

《读库0906》观感

发表评论

年前一直盼着《读库》大礼包能及时赶到，到时候上火车的时候就背着一大包的书回南方的家，我喜欢旅行途中阅读的感觉，火车是一个选择出游旅行的绝佳交通工具，以前我非常喜欢坐大巴，而且也总是坐大巴，因为当时大学离家里比较近，大巴的交通便利性远远高于火车。当我第三次乘坐长途火车的时候（此处指超过12小时），我发现其实乘坐火车出行，快乐非常简单。我不是一个能跟火车上坐在相邻的旅客轻易聊上的人，我比较寡言，被动发言居多。乘坐火车的痛苦在于我一般在行进的列车硬座席上无法入睡，即使深夜依然如此，幸运的是我总是有非常不错的书能陪伴着我的旅程。记得一次下杭州时，带了《读库0903》在车上一路相随，当列车上诸多人开始聊天的时候，我完全沉浸在书本的世界中，当大家安静地入睡时，我开始能有时间静静地回味书中的些许精彩。

那么此次春运期间返乡过年是否也能幸运地再次背着《读库》一同前行呢？等得心中实在是搔痒难耐，给小六短信，询问了关于订单的事情，小六的答复是等年后吧。

返京后的当天就收到了读库礼包，《读库0906》作为2009年的收宫之作自然是排在了阅读的前列。时至今日，差《沿着西湖看历史》一章，已经通读一遍了。开篇姬炤华老师关于儿童图画书的讲述和见解，让我这山里娃彻底地开眼了，原来艺术真的是这么无私的，儿童也应该得到尊重。《老师》中流露出来的年代味道以及对老师的敬爱，着实让刚刚离开学校的我有了一股莫名的忧伤，曾经在求学路上陪伴我们十余年的诸位老师，你们近来好吗？碰到的学生还跟当前的我们一样顽皮捣蛋，让您们头疼吗？张铁志先生延续之前歌手系列的讲述，又一次给我这个美国音乐盲着实扫盲了一把。此期读库，最让我着迷的一部分当属瓦当的《穿越而来》，通篇从尼古拉·特斯拉的童年一直到老去，讲述了特斯拉一生中的传奇事迹，从一个无名的电话公司员工，到交流电之父，直至孤独地终老于纽约人旅馆。特斯拉用了一个几近传奇的一生也我们诠释了人类可以如此出众，可以如此卓越，但是我们珍惜过这位天才吗？苗炜的《声音》是我个人比较喜欢的一种文体，仅仅采用便签式的杂记体，从平日媒体上，阅读书籍中，网路交流中等等撷取诸多精辟而不失为典型的一些言论，附加自我简短的讲述，客观而精妙地阐述了2009年。

下面是《读库0906》我个人最喜欢的两段文字：

我不明白，一名收银员怎么能因一点三欧元遭解雇，而那些丢掉数以十亿计欧元的银行高管却能保住工作。——德国一名工龄超过三十年的超市收银员因为涉嫌偷窃一点三欧元遭超市解雇，基督教社会联盟主席霍斯特·泽霍费尔说，这一事例更加剧人们对资本主义制度的怀疑。

政治不会比我现在从事的行业更肮脏。——色情演员丹尼尔斯在竞选美国路易斯安那州参议员

对于一个囚犯来说，真正的监狱是在他出监狱的这一天才开始的。——阿兰牧师

年底贺岁

发表评论

己丑年的尾巴真的就要隐去了，庚寅年就要来了。

在这个不知年味的城市中，待了快一年了，终于还是要离开，回家。

祝所有的人新年快乐，希望在新的一年里，世界和平，万家灯火！

LineNumberReader和FileWriter同时使用碰到的问题

发表评论

今天上班有个任务就是将之前产品中的示范代码有一些不规范的地方进行修改，使得能在多平台顺利运行，主要是文件名大小写的问题。由于之前示范代码编写者在跨平台上编码经验相对不足，所以编写者在写代码的时候并没有严格的大小写意识(主要原因还是因为Windows不区分大小写，而代码的测试均是在Windows下进行的)，造成很多遗留问题。产品中有示范代码64个，大小写问题几乎无处不在，还有一个就是跨平台产品支持的数据引擎与Windows不一致，之前的Windows版本中有不少的示范代码使用了Windows平台特定的引擎类型，也需要进行修改。

修改的方法可以有很多，最为简单和直接的方法，应该是一个个程序运行，一个个文件检查，逐个进行修改。我想作为程序员的我们，肯定是不愿意做这么无聊而重复的工作的。那么搞定这个无聊而重复的工作呢？首先分析一下已有的示范代码的特征，虽然之前的代码存在诸多不规范的地方，但是在一些方面还是存在很多共性的，大小写出现错误的肯定是在设置数据路径的时候出现的，设置引擎类型的代码更是固定的，之需要使用几个非常简单的正则表达式就可以将其完全正确替换了。所以我们选择了读写文件的方法来完成这个任务。

在实现这个功能的时候，使用到了LineNumberReader和FileWriter两个类，每读取一行，使用replaceAll(String regx,String str)方法对该行进行替换，之后再使用FileWriter将替换后的文本写入文件：

File file = new File(sourcePath);

try {
lineNumberReader = new LineNumberReader(new FileReader(file));
String line = lineNumberReader.readLine();
fileWriter = new FileWriter(file);
while (line != null) {
line = line.replaceAll("\\.xxx", ".XXX");
fileWriter.write(line+"\r\n");
line = lineNumberReader.readLine();
fileWriter.flush();
}
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
lineNumberReader.close();
fileWriter.close();
} catch (IOException e) {
e.printStackTrace();
}
}

执行的结果是，64个示范代码中，总会有几个会出现一些很奇怪的问题，那就是修改后的文件丢失了很多文本，导致编译不通过。那么问题在哪儿呢？经过多次分析和调试，最终发现当LineNumberReader和FileWriter指向同一个文件的时候会出现该问题，如果将源文件处理后的结果写入到一个新的文件中便不会存在这样的问题。那么究竟是哪里出了问题呢？来看一张图

在这张图中我们能看到一些信息，LineNumberReader对象中有一个cb字符数组，大小为8192=1024*8.

在我整个的调试过程中，我一直关注着最后一个字符，在整个过程中，这个位置的字符一直没有发生改变，而最终写入到文件中的最后一个字符就是该字符，这难道只是一个巧合吗？

现在让我们更换一下代码将原本使用同一个File对象的代码，改成使用另一个新文件对象的代码来重新调试一下。

先执行代码，查看结果发现，文本的内容完全被写入到新文件中，并没有出现丢失文本这样的情况，那么我们再来调试一下，我们再次来监视cb[8191]处的值，这次我们可以发现在LineNumberReader对象lineNumber==319的时候，该值发生改变。

====我是分割线======

综合上面的两种情况，我们可以得出一个结论，当LineNumberReader和FileWriter同时指向一个文件的时候，系统在写入文件的时候并不是逐行逐行写入，而是先记录下来逐行的内容，并且是记录到LineNumberReader的cb字符数组中。该数组的大小固定为内存最小单位8K，也就是大小为8192的数组，该数组将保存初次初始化FileWriter对象时读取的文件内容，在之后的每次FileWriter写入操作均是改变该数组中存储的字符值。这样导致的结果就是，如果当前的读取的文件较大，就会存在丢失内容的问题(最多保存8192个字符,含空格和换行)。而使用一个新的文件来进行修改后内容的写入就不存在这样的问题，当FileWriter需要使用到flush()方法来将当前缓冲区中的所有内容写入文件之后，LineNumberReader中的cb数组内容也将发生改变，指针下移，读取下一个块大小为8192的内容，直到文件末尾。

所以在使用LineNumberReader和FileWriter的时候需要注意这一点，如果实在不愿意多生成一堆新文件的话，可以在写入完成之后，将原始文件删除，而将新文件更名一下就好了。

SuperMap Objects 碎碎念

发表评论

SuperMap Objects是SuperMap Software Co., Ltd. 成长的关键，最早公司创建之初公司便同时启动了两个项目，一个便是传统GIS中最为突出的桌面产品，另一个就是组件产品。

组件产品又作为桌面产品的基础，为桌面应用提供相应的功能。从SuperMap Deskpro 2000到现在的SuperMap Deskpro 6R，一直都是这么一个模式,SFC组件为SuperMap Deskpro系列产品保驾护航多年，不过近几年SFC组件逐渐进入后期维护阶段，SuperMap Deskpro也进入维护阶段，主要对功能的集成和细化进行深入挖掘，更多的是从软件可用性提升以及功能正确性，分析高效性上来提升Deskpro产品的市场认知度和用户体验。基于SFC(SuperMap Foundation Class)组件有一系列的产品，有为我们所熟知的SuperMap Deskpro、SuperMap IS .NET和eSuperMap，从桌面到服务器，再到嵌入式，甚至还有国土行业的一些深度行业应用等等。SFC已经为SuperMap带来了十年的收益，更是为SuperMap品牌提供了前期非常坚实的基础沉淀。那么为什么不继续深入SFC组件产品的研发，而是转而进入了一个后期维护阶段，目前的工作主要集中在后期缺陷的维护呢？主要原因有：

  1. SFC组件式基于COM技术的，称为SuperMap Objects COM，现在依然有很多的产品和项目的基础。但是COM技术毕竟不再是如今软件开发中的主流，存在着诸多的不足，作为平台厂商，固守一方市场固然有利可图，可是此计并非长久之计啊。为用户以及二次开发商创造价值才是平台厂商应该做的，如今的软件开发中(特别是项目实施中)Java/.NET无疑已经是十足的宠儿了，那么尝试转型已成必然之势。
  2. SuperMap Objects Java/.NET是基于UGC(Universual GIS Core)共相式GIS内核封装的组件产品，内核采用标准C++(此为号称，到底标准程度多高，各位看官且看且猜就行了)，与平台相关性降至最低，依托Java/.NET快速而高效的二次开发能力，已经逐渐成为了用户和二次开发商首选的项目实施和开发组件。
  3. 服务器产品需求的激增，由于服务式软件SOA/SaaS等概念的逐渐成熟，催生了服务式GIS，GIS领域顿时服务器产品的需求指数上扬。国家基础地理数据中心，各大城市共享数据平台的建设，国家技术设施的信息化项目，都能看到服务器端产品的身影。服务器端产品对效率和跨平台的要求更高，而COM组件明显在跨平台和效率上不及UGC系列产品，由此SuperMap Objects Java/.NET走上了大舞台。
  4. 云计算概念的成长和应用，诸多厂商开始宣称自己站在了云端，依托云计算的优势能为他们的客户带来更多的价值，节约更多的成本。云计算中最为美妙的就是，任何硬件、软件、服务资源均不以实际形态暴露，而以统一的接口提供给用户，所有的资源均以组件式形态存在于服务端，客户端只需处理请求与响应。那么组件式GIS无疑是GIS云计算中非常重要的一个环节，插件式可定制化的服务，跨平台多地域服务的共享，无疑将为更多的用户带来更多的价值，而成本会更低。

SuperMap Objects Java/.NET

上图是SuperMap Objects Java/.NET产品的实现原理，至于细节，相信众位看官稍微了解一些关于封装机制的都一目了然了。功能性的代码完全由UGC完成，而接口的设计与实现完全由组件层来完成，组件层可以再更具自身语言平台的需求增加一些控件和相关产品的设计开发。例如.NET组件在C/S架构中应用广泛，用于对于桌面应用场景的需求较多，那么易用性高、定制性强、可设计的控件无疑会为客户带来更多的价值空间；而Java组件的优势应用在服务端，B/S架构的产品也不少，在服务端的表现可以交由iServer系列产品(基于SuperMap Objects Java开发的服务器产品)，那么客户端呢？新近稍热一点的 JavaFX是Sun公司首推的RIA解决方案，也许用户的应用场景也会随着产品的升级而出现这一方面的需求。

其实组件产品分两大语言体系是一个比较科学的分类

  • .NET技术依托微软强大的技术后盾，在桌面应用上日益成熟早已是桌面明星了，SuperMap Deskpro .NET就是基于SuperMap Objects .NET使用Ribbon界面库开发的新一代GIS桌面GIS产品，从产品易用性和体验上作出了很大的提高，不过性能目前还存在一定的问题(组件产品的瓶颈问题导致)。
  • Java跨平台的特性无疑是最让人津津乐道的，类似于政府和大型服务企业均采用的Unix和类Unix(各种Linux发行版)系统和硬件，对跨平台的要求显而易见，SuperMap Objects Java基于标准C++，完全可以摆脱平台限制，在多平台上表现得游刃有余，填补市场上很大一块空白(其他厂商也有类似的产品和解决方案，但是均是采用中间件方式完成，效率和易用性上相对较差，对用户和二次开发商的开发成本要求过高)。
  • 两种语言技术体系产品，保持同一份设计同时开发测试，接口文档高度一致，二次开发用户选择开发平台的决策成本大大降低。无疑将会让更多的二次开发商，在低成本的情况下可以尝试更多项目的投标生产，为其带来更多的价值。
  • 两个产品由一个领导带领设计开发，更能突出其特点的一致性和延续性，降低用户和市场对该产品和品牌的认知成本，大大增强了组件产品的产品化和标准化。

================我是分割线==================

来到公司已经快半年了，对项目产品和架构上曾经都颇有微词，迄今依然有些怨言，以上就是我对目前SuperMap Objects Java/.NET系列产品的一些碎碎念，其中均是纯个人想法和行为，有一些猜想更多的是臆断。不过猜想也好臆断也罢，终究是我自己思考的一些沉淀，摆出来，凉一凉，晒一晒，淋雨发霉也好招来板砖也罢，纯属博主个人呓语，众看官且听且过是也。