Monthly Archives: May 2011

ArcGIS Server 10中的切图/缓存机制深入

  两年前我写过一篇关于ArcGIS地图切图/缓存原理的文章,《ArcGIS Server的切图原理深入》,里面以tiling scheme为主,讲了缓存图片的存储结构以及相关坐标的计算。那时还是ArcGIS 9.3版本,现在ArcGIS 10已经推出快一年多了,地图缓存/切图方面有了很大改进,比如增加了compact缓存格式,增加了import/export map server cache工具,增加了mixed图片模式等。这次就在上篇文章的基础上,以ArcGIS 10为例,看看其中地图切图/缓存制作的工作机制。
  注:本文旨在深入了解ArcGIS目前切图(即制作地图服务的缓存)的机制,以帮助工作中有需要的朋友们提高工作效率,因为切图,尤其是大比例尺,耗时耗资源,实在是一件伤不起的工作。这里已经假设你知道了如何为缓存地图服务配置地图如何检查发布地图服务的地图文档的性能,开始动手前务必进行小范围、全比例尺切图试验等等注意事项,如否,请查阅相关资料。

supertile和bundle

  要深入了解ArcGIS在切图时的工作机制,有两个概念必须明白,就是supertile和bundle。
  假设一个tile(切片)的大小是256*256,在切图时如果按照这个大小直接exportmap,开启了动态标注的地图服务上线图层和面图层就会有很多重复的标注。因为exportmap时,每个tile都会包含一个要素的标注,如果一个要素横跨了多个tile(这在大比例尺下基本是肯定的),那么这些tile上就会出现相同的标注,exportmap时并不知道相邻的tile上已经有了该要素的标注。

image

  为了解决这个问题,ArcGIS在切图时引入了supertile的概念,开启抗锯齿时supertile大小为2048*2048,反之为4096*4096。真正切图时会首先exportmap出一个supertile,然后将它们分割成指定大小的tile。对于每个要素,每个supertile中只包含一次标注,这样保证一个superfile大小的范围内不会出现重复标注。事实上在绘制supertile时,会尽可能多地包含周围的标注,所以在每个supertile的边界周围仍会有重复标注。解决重复标注的根本办法就是使用annotation,而不是label。
  ArcGIS 10中推出了新的compact缓存格式,将原来离散的每个tile图片(exploded格式),保存成连续的二进制文件(.bundle),每个.bundle文件最多可存储128*128个tile。相比以前成千上万的tile文件,这样做有明显的好处:易于缓存迁移,减少占用磁盘空间,减少硬盘i/o等,esri在任何时候都推荐使用compact格式来创建缓存,除非你需要自己读取每个tile(技术上来说这点可以不成立)。ArcGIS 10在切图时,也采用了bundle的概念:对于每一级比例尺,首先从tiling scheme origin开始,将切图范围分成若干个bundle,每个bundle覆盖的范围是128*128个tile大小。比如在1:4096比例尺时,如果tile大小是256*256,DPI为96,那么每个bundle范围的大小是:((4096*2.54/96)/100/1000*256*128)^2=1261.086平方千米。之后,有且仅有(这么做是为了避免多个进程同时读写一个磁盘文件)一个服务实例/一个arcsoc.exe进程(如果是high isolated)来负责此bundle范围的切图,先输出supertile,然后再切成tile。即使选择了exploded缓存格式,ArcGIS 10中也会采用这种机制来切图。

image

  9.3.1及以前版本中,每个服务实例工作的单位是supertile。即一个arcsoc.exe负责生成一个supertile,然后切成tile,再继续生成下一个supertile……相比supertile这种处理单位来说,采用bundle作为处理单位的ArcGIS 10中的服务实例可以将更多精力投入到连续切图中去,而不是频繁切换自己负责的范围。在大比例尺切图中,这种新机制能很大程度上减少切图时间;但在小比例尺切图中,这种新机制有可能反而增加切图时间。因为小比例尺时可能全图范围只有不到一个bundle范围大小,这样只会有一个服务实例来切图,其他实例都处于空闲状态,而9.3.1及以前版本中,所有服务实例都会“蜂拥而上”。

image

网格切图和按featureclass范围切图

  有过大比例尺范围切图经验的朋友肯定会知道,一般切图策略是:小比例尺全图直接切,较小比例尺可能按照某个featureclass范围来切,而大比例尺一般是按照包含网格(grid)的featureclass范围来切。以我国全范围切图为例,小比例尺时全图切没有问题,大比例尺时如果仍然全图范围(包络矩形)切的话,会将周边其他的国家也包含进来,这并不需要的额外工作量在大比例尺时会是一场噩梦。

image

  而之所以不仅要按指定featureclass范围切图,而且featureclass里要包含网格的原因在于,便于细化和跟踪切图进度。切图工具会给你指定的featureclass创建一个新的Cached字段,将已经切好的feature标记为YES,以便在选择Recreate Empty Cache时避免重复切图,从而可以将切图工作分为多次来进行,或者以便在切图失败后排查原因,继续切图工作。
  在指定featureclass范围切图时,是顺序处理该featureclass中的所有feature的。所有的服务实例会首先集体处理一个feature范围,切出该feature范围内所有要求的比例尺级别的结果。此时ArcGIS Server会重启该服务。然后所有服务实例再去切下一个feature范围……所以与每个feature边界相交的supertile可能会被创建两次或多次(多个feature的相交处),这也是为什么在使用featureclass切图前,需要分别对它进行GeneralizeAggregateDissolve的原因。

image

  结合之前bundle的机制我们知道,如果一个feature范围恰好只包含一个bundle,那么就杯具了,因为对该feature切图时,只会有一个服务实例进行工作(一个bundle同时由且仅由一个服务实例处理),其他服务实例全部处于空闲状态。因此,比较理想的情况是,每个feature至少包含比服务实例数更多的bundle时,才能充分利用硬件资源来对其切图。
  这就会引出一个问题,就是如何来确定某个比例尺下一个bundle的大小,从而生成这样的featureclass呢?ArcGIS 10中,给我们提供了一个新的GP工具Map Server Cache Tiling Scheme To Polygons,利用它,我们可以针对某个地图服务,生成每个需要切图比例尺下所有的supertile,进而得到以每个supertile为一个feature的featureclass。以全国地图为例,在1:288,895比例尺(ArcGIS Online Tiling Scheme的第12级)下生成的supertile是这样的:

image

  我们需要的是某个比例尺下bundle的范围,如何根据supertile来确定bundle的大小呢?在N级比例尺时,一个supertile是16*16个tile,第N+1级比例尺时,该supertile会覆盖32*32个tile,第N+2级比例尺时,覆盖64*64个tile,第N+3级比例尺时,这个第N级的supertile会覆盖128*128个tile,眼熟吧,这正是一个bundle的大小。由于supertile和bundle都是从tiling scheme origin往右下角算起的,因此第N级一个supertile的范围正是第N+3级一个bundle的范围。由此如果我们要生成第15级的bundle网格,只需要用Map Server Cache Tiling Scheme To Polygons工具生成第12级supertile的网格即可,如上图。
  以此为例,我们来说明如何有效进行大比例尺切图的问题。假设我们需要对1:36,111(ArcGIS Online Tiling Scheme的第15级)这个比例尺进行切图,我们首先生成该范围的bundle网格,恰好是第12级的supertile网格,如上图。为了简便起见,我们只取其中8个feature来做说明,地图服务的最大实例数是4个(机器是单cpu,4核)。如果每个feature恰好是一个bundle,那么一个feature只能被一个arcsoc.exe处理,而其他3个服务实例均处在空闲状态(占用内存最少的那个arcsoc.exe是用来清空工作目录的,与具体服务无关):

image

  而我们对这个featureclass做一个处理,将4个feature(恰好是一个bundle)合并成一个feature(bundle cluster),这样每个feature就恰好包含了4个bundle,如此我们所开启的4个服务实例就可全速工作了,发挥了机器的最大性能:

image

  ps:Map Server Cache Tiling Scheme To Polygons工具生成的supertile是从tiling scheme origin开始计算的,而不是地图服务的fullextent左上角,因此利用它生成的supertile合并出来的bundle是最合理的,恰好与理想的bundle分界处一致。因此在大比例尺下利用featureclass切图时,应当利用Map Server Cache Tiling Scheme To Polygons来生成网格,而不是fishnet工具。在ArcGIS 10.1中,将会推出新的GP工具,会根据cpu核数来生成合理的包含bundle cluster大小feature的featureclass。
  其他方面还有一些问题,比如切图时最大服务实例数设置多少为好(一般是cpu核数+1),即使所有实例全部工作cpu占用率依然低于90%(有可能是内存不足)等问题,与切图机制无关,就不在此讨论了。
  总之,切图是一个技术活,要求还比较高,需要考虑的问题很多。如果你只把它当一项体力活来看的话,只能说明认识还不够全面,那就不能怪ArcGIS Server不好。毕竟,人家ArcGIS Online全球的19级缓存都7*24小时上线两年了,还有什么理由说产品不好呢?

佛与蜘蛛的故事(转载)

转自网络,出处不明。

  很久很久以前,在一个香火很旺的寺庙里,有一只染上了佛性的蜘蛛。有一天,佛从天上路过,看见了这个香火很旺的寺庙,佛来到了这个寺庙里,看见了那只蜘蛛,佛问:“蜘蛛,你知道什么是这个世界上最值得珍惜的吗?”
  蜘蛛回答:“得不到的和已经失去的。”
  佛说:“好,那我三千年后再来问你这个问题。”
  佛走了。
  蜘蛛仍然生活在这个寺庙,每天都在为前来许愿的人们所祈祷,每天都在为他们的故事所感动。曰子就这样在不知不觉中慢慢的过去。
  三千年后,佛又来到了这个寺庙,他又问这只蜘蛛:“蜘蛛,你知道什麽是这个世界上最值得珍惜的吗?”
  蜘蛛回答:“得不到的和已经失去的。”
  佛说:“好,那我三千年后再来问你这个问题。”
  佛走了。
  蜘蛛仍然生活在这个寺庙里。忽然有一天一阵风刮来了一滴甘露,这滴甘露就落在蜘蛛的网上,蜘蛛很喜欢这滴甘露,它每天都看着它,觉得自己很幸福,觉得时间每天过得很快。但是有一天,那阵风又刮来了,并且把甘露也带走了。蜘蛛失去了甘露,它很伤心。曰子就在蜘蛛的悲伤中慢慢的过去了。
  三千年后,佛再一次来到了这个寺庙,他又问蜘蛛:“蜘蛛,你知道什麽是这个世界上最值得珍惜的吗?”蜘蛛仍然回答:“得不到的和已经失去的。”佛说:“好,那你就和我一同到人间一趟吧。”
  蜘蛛随佛来到了人间,佛帮蜘蛛投胎转世,18年过去了。
  那只蜘蛛投胎成了一个官宦之家的小姐,取名叫珠儿。同年,甘露也投胎转世,成了金科状元。再一次皇宫的大宴上,珠儿和甘露又一次的相遇了。甘露仪表堂堂, 举止文雅,成为了众人瞩目的焦点,自然也得到了皇帝的女儿—长风公主的亲睐。珠儿并不着急,因为她知道,她和甘露的缘分是上天注定的。
  有一天,珠儿去寺庙里烧香,恰巧遇见了陪母亲来烧香的甘露。她走过去,甘露文质彬彬的说:“小姐,您有何贵干吗?”珠儿的脸色顿时变得很苍白:“你难道不 认识我了吗?我是珠儿呀,就是两千多年前那的那只蜘蛛。”甘露不解的回答:“对不起小姐,我想是你认错人了,我并不认识你,也不知道你说的到底是什麽。”
  甘露扶着母亲走了。珠儿进入了无比的悲痛之中。她不明白这份天注定的缘,怎麽这麽难。几天后,当珠儿还沉浸在痛苦中的时候她得到了两个消息:一是皇帝把自己的女儿长风公主许配给了金科状元——甘露;二是皇帝把她许配给了自己的儿子——甘草。
  听到这个消息,珠儿终于坚持不住了,她彻底的崩溃,从此一病不起。在珠儿和甘草的大婚快到的时候,得知珠儿大病不起的甘草很是伤心,他来到珠儿的床边,握着昏迷之中的珠儿的手说:“珠儿,你知道吗,自从在父皇的大宴上看见你的那一刻起,我就已经深深的爱上你了,所以我请求父皇把你许配给我,如果你死了,我这下半生……”
  珠儿已经听不见了,因为她的灵魂已经慢慢的离开了她的躯体,她看着自己身边默默流泪的甘草,感觉像有一把刀在心里狠狠的割了一下。
  正在这时,佛出现了,他问珠儿:“你现在能告诉我什麽是世界上最值得珍惜的吗?”
  珠儿含着眼泪说:“得不到的和已经失去的。”
  佛说:“难道你还不明白吗?甘露在你的生命中只是一个过客,他是被长风带来的,也是被长风带走的,所以他属于长风公主。而在你在寺庙生活的那段曰子里,在你网下的甘草,一直默默的注视着你,爱慕着你,只是他没有勇气告诉你,你也从来没有低下过你那高贵的头颅。”
  这时的珠儿早已是双眼含泪,她点点头,看着自己身边的甘草说:“在这个世界上最值得人们去珍惜的是现在身边所拥有的。”

ArcGIS API for Windows Phone开发实例(7):利用Geoprocessing分析超市的营业状况

  本文内容:Geoprocessing
  前几节中,我们利用GIS这个工具,对连锁超市店面的营业状况做了充分的展示。这一节中,我们利用GIS特有的Geoprocessing功能,结合超市的营业数据统计,对超市的营业状况做一个比较合理的判断,从而有助于经营者及时调整策略,适应市场的变化。
  我们的大致分析思路是这样的:对于每个超市来说,会有固定的消费群体,一般通常是距离该超市一定范围内的常驻居民,这部分占绝大多数(一次性路过的消费者人数较少,可以忽略不计);首先我们利用GIS这个工具,设法得到每个超市周围一定范围内的常驻人口数,做为该超市的潜在消费群体;然后根据过去一定时间内,这个品牌所有超市的营业额统计,计算出所有超市店面潜在消费群体每人每天的大约消费额度是多少,做为该品牌超市的一个平均竞争力(每人/天购买力是多少);这样就能利用这个平均竞争力数值和某个超市潜在消费人口数,预估出该超市一定时期内大约的营业额收入。如果实际营业额与这个预估相差不大,我们认为该超市营业状况正常;如果营业额统计明显小于这个预估值,则有可能是该超市营业范围内新增了竞争对手的店面,或竞争对手采取了促销措施等手段分流了购买力,从而提醒经营者及时对营业策略做出调整,避免进一步的损失。
  超市店面的营业额统计我们有了,下一步就需要获得每个超市潜在的消费人群数量。我们分两步来完成这项工作:第一步计算出距离某个超市店面一定时间车程的地理范围,作为该超市潜在消费群体的居住区域;第二部查询出该区域内的常驻人口数。
  GIS正是用于处理所有与地理分布相关任务的一个有力工具,Geoprocessing则是它的核心所在。上面的两个步骤我们就可以利用Geoprocessing轻松完成。ArcGIS Server中,将具有一定逻辑相关的一组任务封装成一个处理流程,发布成Geoprocessing Service(简称GP服务),通过Task的形式供客户端调用。客户端只需提供相关的参数后,就可直接得到处理结果,而不需要理会服务器端复杂的处理流程。ArcGIS Online为我们提供了两个现成的Geoprocessing Service:CreateDriveTimePolygonsPopulationSummary。前者用来获得距某点一定时间的车程范围,后者用来获得某范围的常驻人口,刚好符合我们的需求。因此只需调用这两个GP服务,即可得到我们想要的数据,从而完成相关计算工作。
  注:CreateDriveTimePolygons适用于美国境内,在此仅作说明之用;由于数据原因,程序内所使用的北京市内的对应GP服务无法公开。PopulationSummary适用于全世界范围,但结果精度不做保证。关于两个服务的使用限制,请查看相关页面。
  我们依然创建一个工具类,取名Analysis,该类包含两个GeoProcessing Task(Geoprocessor):_gpDriveTime和_gpPopulation,分别用于获取某超市的营业范围和该范围内的常驻人口数。

   1: private Geoprocessor _gpDriveTime = new Geoprocessor(App.Current.Resources["GPDriveTime"] as string);

   2: private Geoprocessor _gpPopulation = new Geoprocessor(App.Current.Resources["GPPopulation"] as string);

   3: Time.ExecuteCompleted += gpDriveTime_ExecuteCompleted;

   4:                 _gpDriveTime.Failed += (s, a) =>

   5:                 {

   6:                     MessageBox.Show("ServiceArea"+a.Error.Message + "n" + a.UserState);

   7:                 };

   8:                 _gpPopulation.ExecuteCompleted += gpPopulation_ExecuteCompleted;

   9:                 _gpPopulation.Failed += (s, a) =>

  10:                 {

  11:                     ChangeMapOpacity(-1);

  12:                     MessageBox.Show("Population"+a.Error.Message + "n" + a.UserState);

  13:                 };

  GP Task是ArcGIS API for Windows Phone提供给我们用来调用Geoprocessing Service的类,与Query Task,Identify Task等相同,使用分为三个步骤:准备参数,提交请求,处理结果。我们首先来看一下CreateDriveTimePolygons这个GP服务所需的参数:

image

  总共有三个参数。Direction为Input的参数,即输入参数,有两个:Input_Location和Drive_Times。因此我们只需准备好这两个参数,即可调用该服务。最后结果中,会包含Direction为Output的参数,即就是我们的结果了(esriGeometryPolygon)。

   1: void _FLayer_MouseLeftButtonDown(object sender, GraphicMouseButtonEventArgs e)

   2: {

   3:     //……

   4:     //prepare parameters for GP Service

   5:     GraphicCollection gc = new GraphicCollection();

   6:     gc.Add(e.Graphic);

   7:     CalculateServiceArea(gc);

   8:     //……

   9: }

  10: mary>

  11: /// find the service area of a given supermarket

  12: /// </summary>

  13: /// <param name="gc">the graphic collection contains the supermarket</param>

  14: private void CalculateServiceArea(GraphicCollection gc)

  15: {

  16:     ESRI.ArcGIS.Client.Projection.WebMercator wm = new ESRI.ArcGIS.Client.Projection.WebMercator();

  17:     GraphicCollection graphicCollection = new GraphicCollection();//using new gc to remain point(121000) stay on map

  18:     foreach (Graphic g in gc)

  19:     {

  20:         Graphic graphic = new Graphic()

  21:         {

  22:             Geometry=wm.ToGeographic(g.Geometry)

  23:         };

  24:         graphicCollection.Add(graphic);

  25:     };

  26:  

  27:     FeatureSet fs = new FeatureSet(graphicCollection);

  28:     List<GPParameter> parameters = new List<GPParameter>();

  29:     parameters.Add(new GPFeatureRecordSetLayer("Input_Facilities", fs));

  30:     parameters.Add(new GPString("Drive_Time_Values", "20 40"));

  31:     //execute the GP Task

  32:     _gpDriveTime.ExecuteAsync(parameters);

  33: }

  34:  

  35: riveTime_ExecuteCompleted(object sender, GPExecuteCompleteEventArgs e)

  36: {

  37:     ESRI.ArcGIS.Client.Projection.WebMercator wm = new ESRI.ArcGIS.Client.Projection.WebMercator();

  38:     foreach (GPParameter parameter in e.Results.OutParameters)

  39:     {

  40:         if (parameter is GPFeatureRecordSetLayer)

  41:         {

  42:             GPFeatureRecordSetLayer gpLayer = parameter as GPFeatureRecordSetLayer;

  43:             //40 min

  44:             gpLayer.FeatureSet.Features[0].Symbol = new SimpleFillSymbol()

  45:             {

  46:                 Fill=new SolidColorBrush(Color.FromArgb(119,153,255,153)),

  47:                 BorderBrush=new SolidColorBrush(Color.FromArgb(255,153,255,153)),

  48:                 BorderThickness=2

  49:             };

  50:             gpLayer.FeatureSet.Features[0].Geometry = wm.FromGeographic(gpLayer.FeatureSet.Features[0].Geometry);

  51:             _GLayer.Graphics.Add(gpLayer.FeatureSet.Features[0]);

  52:             //20 min

  53:             gpLayer.FeatureSet.Features[1].Symbol = new SimpleFillSymbol()

  54:             {

  55:                 Fill = new SolidColorBrush(Color.FromArgb(119, 153, 153, 255)),

  56:                 BorderBrush = new SolidColorBrush(Color.FromArgb(255, 153, 153, 255)),

  57:                 BorderThickness = 2

  58:             };

  59:             gpLayer.FeatureSet.Features[1].Geometry = wm.FromGeographic(gpLayer.FeatureSet.Features[1].Geometry);

  60:             _GLayer.Graphics.Add(gpLayer.FeatureSet.Features[1]);

  61:  

  62:             map1.ZoomTo(gpLayer.FeatureSet.Features[0].Geometry);

  63:             

  64:             //……

  65:             (_BusyIndicator.Child as TextBlock).Text = "查询服务区内人口数......";

  66:             //继续查询该范围人口数

  67:             //……

  68:         }

  69:     }

  70: }

image

  可以看到,我们在parameters集合中添加了GP服务所要求的所有输入参数,然后执行;而结果中,我们也取得了GP服务中的输出参数。这里说明一点,GP服务的参数GPParameter比较灵活,新建参数时的名称,类型一定要保持与Service Directory服务列表中一致,否则可能导致调用失败。另外由于GP服务的空间参考(4326)与我们的底图(102100)不一致,所以做了坐标转换。
  此外我们还注意到一点,CreateDriveTimePolygons服务的执行方式是“esriExecutionTypeSynchronous”即同步调用。这种方式一般用于执行过程时间较短的GP服务,缺点是客户端需要在返回结果之前等待。具体可参考这里
  获得了超市的服务范围之后,需要用第二个GP服务,PopulationSummary来获得该范围内的人口总数;之后就可按照前面的分析思路,来计算出该超市的营业额预期,与实际营业状况比较后,可得出相应的结论。

image

参考资料:
Geoprocessing概念:http://help.arcgis.com/en/arcgisdesktop/10.0/help/002s/002s00000001000000.htm

ArcGIS Server中的Geoprocessing Service:http://help.arcgis.com/en/arcgisserver/10.0/help/arcgis_server_dotnet_help/index.html#//009300000028000000.htm

ArcGIS API for Windows Phone中调用Geoprocessing Service:http://help.arcgis.com/en/arcgismobile/10.0/apis/windowsphone/help/011v/011v0000001m000000.htm

  至此,《ArcGIS API for Windows Phone开发实例》已经结束,希望大家能通过这几篇文章对ArcGIS API for Windows Phone有所了解。目前API的版本是2.2 beta,这仅仅是一个开始,随着以后大家对移动GIS的关注越来越多,相信esri也会在API中逐步推出更多的功能来满足我们更多的应用需求。
  在前不久召开的MIX11大会上,微软展示了新的Windows Phone Mongo,该版本的SDK中不仅WP的性能有了很大提升,而且有着全面支持真正的多任务,Silverlight 4,内嵌全功能IE9浏览器,支持socket通信,允许同时使用Silverlight和XNA编程模型(SL中就会有原生3D功能支持)等令人兴奋的新特性。伴随着市场占有率不断提升的这一事实,有着真正硬实力的Windows Phone有理由让我们相信不仅对于开发者,同样对于用户而言,它能给我们带来更多机会。