明白那个用鼠标拖动，图像是怎么动态生成的了。
发现很简单
主要针对于satellite image。map应该有专门的矢量图，可以动态描绘，也可以预先生成。
每次当前显示的卫星图像，都是由一个一个256x256的图片块组成的。拖动时，只要更新需要显示的图象块就够了。如果网速快的时候，我们会感觉拖动的是一整块大图像，还没有尽头。但如果慢的时候，就会发现很多因更新不及导致的大的灰白色块。
总共有20个scale，从1:2:4:8:.....这样的比例排下去。每个scale级别，都有预先生成的256x256图块。
这样由整化零，对数据的检索和查看是特别方便的。不过，若要构建这样的数据库，首先的问题是融合图像，registration？他们的数据源是从哪儿搞的？为什么其他网站提供的图片都不一样？谁负责图像的更新？satellite原始图像是怎么样的？图像的resolution？一个像素对应实际的多少米？
图像块url的模式
看这幅图像，我的家就在这片白房子右下的一栋中间
这个URL有什么规律？发现n=404, v=5似乎是不变的。嗯，发现也可以变，但图像结果不变，可能跟内部服务器索引有关。t后面一长串。规律也很明显，只有qrst四个字符，这个字符串长度是18，恰好等于scale第18层。如果你在后面添加一个q，结果将是这幅图像的左上角，同样，r是右上角，s对应右下，t对应左下。也就是说，一个子块再切分为四个子块，对应图像的scale增加一倍。（试着依次删除这个url的最后一个字符，然后回车，就相当于不断的升向太空鸟瞰地球的感觉了；然后不断点back（或回车键），就是落地了）
基于这个规律，似乎给定字符串可以立马算出对应经度纬度，而给定经度纬度，也可以立即计算出对应字符串索引。
图片数量？
20层。第一层一张图片（只有t,rsq不存在），也就是世界地图。第二层4张，。。。。所以N = 1 + 4 + 4 ^ 2 + ... + 4 ^19 = ?
4^19 = (2x2)^20/4=(2^10)^2^2/4=1000^4/4=250G
每幅图像，存成bmp，18.9K。
若一个硬盘有1000G，那么差不多需要5000块硬盘。
当然，这是最保守估计。因为首先图片可以压缩，第二很多国家和地区并没有高清晰的图片。这样算下来，至少可以减去20多倍甚至上百倍。几百块硬盘，就算不了什么了。嗯。应该还有冗余服务器，那就需要乘以n倍。hoho~
跑题又跑远了。回头再到怎么构建图片库。
由于没有原始图像来源，只能凭猜测了。卫星拍照，一张照片会有多大？图像间肯定会有重叠，也需要根据重叠来合并。图像可能还需要校正，东南西北，上下左右。接下来的问题是如何与矢量图合并？矢量图怎么定义的我还不清楚。由于是二维图像，给定两个对应点，整个图像就可以对应起来了。那么，如果新的图片来了呢？给定四个对应点，从校正到对应，也可以一次性完成。
自动？自动才是proposal要搞的东西。如果是原始图像，自动合并倒很有用，也很容易。但proposal里面要搞的是原始图像到地图的合并。还是纯图片地图。地图里面就都是些街道，公路，街道名之类的东西了。怎么自动合并？老板说要着重考虑scale不同的问题。给两个例子先？
又查了一下，发现map也是预先生成的，
里面又有模式。
从原始图像到地图合并，如果人工作，其实是个很简单很简单的问题，最多点4个点就够了。自动不仅很难而且不必要。若是一定要考虑自动，可作的是imagery到imagery的对应。因为这样图像的基本特征都差不多。而且自动确实也可能提高效率，比如定位。
至于抽取文字，更加不必要，除非是要处理老的图片文档，但是老的文档不都过期了么？有了Google map，其他的地图库还有存在的必要么？若要显示一些环境信息，交通信息，直接集成到Google map不就搞定了么？何必单独绘制图片？Scientific Visualization，嗯，有数据就够了，还可以给你搞出多种花样，任何图片，不过是一个可能的结果而已。
可是，可是，我仍然要写proposal，写那些觉得毫无意义的问题，虚无缥缈的，让人吐血的问题。为什么总是执迷不悟的要寻找“自动”的圣杯？
