从模型的组成来看，不外乎input，model，output。

Input：

对于GIS模型，Input有矢量数据，栅格数据，以及属性表数据。

a）矢量数据可以用shapely和OGR的python API进行处理。shapely也有完善的进行GIS空间分析的方法。

b）栅格数据可以用GDAL的python API进行处理。同时，通过矢量生成栅格，也可以用该类库。如果GDAL python API还不能解决问题，就要动用NumPy和SciPy。

c）而属性表数据则可以用NumPy和SciPy处理。

我觉得，对于数据处理的关键

model：

model的设计和实现过程，无非是以上数据处理的叠合。

output:

a）如果是矢量数据的输出，可以直接从postgreSQL中调取，话说回来，GeoDjango有一套很好的对矢量空间数据进行crud的解决方案，或者也可以直接从数据库调取GeoJson或者WFS发送给前台。

b） 而对于栅格数据的输出，则可能会使用GeoServer，当然我更倾向于Mapnik，用其中之一来制作底图，同时其他一些栅格数据，也可以用它们来制作。

c）在数据发布之前，我们要对数据进行缓存，Tilecache提供了很好的地图缓存功能，建议使用。

d）用OWSLib和OgcService这两个类库实现地图数据的WMS，WFS发布，如果今后要对数据、服务进行grid分布，那么还可能使用pyWPS。

e）最后数据用GeoDJango和Openlayers发布。

就先说这么多，现在要一步一步的实现和整合。

1. mapnik（被openstreetmap使用来制作地图的渲染类库）
2. tilecache（网络地图缓存器）
3. OgcServer (The python-based OGC Server with WMS 1.1 and 1.3 support. )
4. OwsLib （OWSLib works with WMS version 1.1.1 and WFS 1.0.0 Other versions are not supported at this time.）
5. pyWPS（基于python的Web Process Service的实现，如果今后要做grid，这个类库是很必要使用的）
6. Shapely (Geos的wrapper)
7. python for GDAL (GDAL，也包括OGR的wrapper)
8. pyproj （Pyrex generated python interface to PROJ.4 library）
9. NumPy，SciPy（科学计算所用的类库）
10. GeoDjango（整合了主要的空间数据类库，包括GDAL，GEOS，PROJ.4等）
11. subprocess (用来替换os.system,更加稳定，健壮。)

因为最近正在研究如何利用python制作climate change方面的model，所以我主要看了shapely，python for GDAL，NumPy，SciPy（SciPy 0.7的win32 binary for python 2.5还有问题，无法正常使用）。

1）现在有点puzzle的问题，其实很多时候，都可以用os.system来实现对GDAL_grid.exe的调用。所以，如何使用这些类库需要很好的整合，并不是整合到python里面就是最好。

2）其次，我不是很愿意整合R Staticstics，毕竟又要用到基于另一个语言的软件平台，虽然它在空间分析方面有很多比较好用的类库，不过我觉得，如果使用NumPy和SciPy，完全可以实现科学计算类库。所以，我会更加focus on NumPy和SciPy。同时，对于需要大量处理的raster数据，关键还是要搞清楚使用python for GDAL。因为大量的处理是基于栅格的。如果需要，可以使用NumPy和SciPy来进行空间数据的计算。

3）用python做model关键是要在服务器端来处理数据并显示这些数据，那么GeoDjango平台对于crud的强大处理定时非常吸引人的，并且，在crud之外，用python做的model是很好的实现方法。当然，用ArcGIS 9.3 推出的的model design tool（不好意思，我忘了这个工具的确切名称）或者ArcEngine来实现会更加高效方便，但是问题是，价格过高，并且网络实现将花更多labor和精力。

Finally， I will fly to USA to continue my study career.

[umap id="3959" size="s" alignment="none"]

在美国，俺要刻苦攻读博士，要当大厨做饭，也要做个好司机学着开车。呵呵，身兼数职，憧憬这样的生活。而更让新欣喜的，是自己的努力和汗水终于得到实打实的回报，最让人快乐。这段时间，准备着出国，走走亲戚，同时向大家透露，我和阿简合作的FlexCarto也在有条不紊的开发中，而在flash环境下进行坐标投影转换的FlexProj代码编写已经完成，目前是书写API文档和测试阶段，FlexProj第一个版本有望很快和大家见面。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</meta><meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<script src="lib/OLprototype.js"></script>
<script src="lib/proj4js/proj4js-combined.js"></script>
<script type="text/javascript">
Proj4js.defs["EPSG:4326"] = "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs ";
Proj4js.defs["EPSG:900913"] = "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs";
var sourceProj = new Proj4js.Proj("WGS84");
var destProj = new Proj4js.Proj("EPSG:900913");
var p = new Proj4js.Point(108.80,32.08);
Proj4js.transform(sourceProj,destProj,p);
alert(p);
</script>
</meta>

PS：请到Proj4js的主页上下载Proj4js最新的脚本文件。

It would be a little interesting, everybody just look at “900913”， which looks like “google”. these two words are so similar in their forms.

那么都市圈和E都市用的是什么投影呢？

我起初思考，可能用的是方位投影，我们两极都是用的方位投影，而且一些面积比较小的国家也是用的方位投影。而且，对于2.5 D WebGIS针对的研究区域也是一个主城区而已，所以，极有可能会是方位投影。但是后来我用ArcGIS定义了 Azimuth Projection，发现在边缘范围畸变是很大的，因为方位投影的视点为一个点，这样她的投影范围是一个圆形，所以她在不同区域的畸变是不相同的。

后来我仔细琢磨，像都市圈或者E都市的投影应该使用来自无穷远的平行光源照射，然后给一个照射的角度，所以从理论上可知应该使用正射投影（orthographic projection）。然后经过实验也是可以行的。要注意的是，在设置斜射投影时需要设置两个参数，分别为经度中心和纬度中心，需要根据实际情况设置。同时，我有产生了新的想法，完全可以给都市圈以不同的投影，然后on-the-fly进行变化，也就可以让我们在观察时不仅仅用一个视角，而是有不同的视角。这是一个很关键的问题，也是2.5->3的一个便捷转换的过程。下面给出我自己设置的都市圈的投影：

PROJCS["orth_dsq",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",

SPHEROID["WGS_1984",6378137.0,298.257223563]],

PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],

PROJECTION["Orthographic"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],

PARAMETER["Longitude_Of_Center",80.0],PARAMETER["Latitude_Of_Center",-8.0],UNIT["Meter",1.0]]

PS：如果要实现远小近大的效果，可以考虑透视投影（perpective projection），它会给光源加一个高度。