• New “geography” type for managing geodetic (lat/lon) data
• Performance-enhanced distance calculations
• GML and KML format readers
• Improved shape loading GUI
• And more!

RELEASE NOTES
Important Changes

• =~ operator now indicates bounding box equality, not feature equality
• GEOS 3.1 is now the minimum accepted version of GEOS
• GEOS 3.2 is needed if you want to use enhanced buffering features and ST_HausdorffDistance
• GEOS, LibXML2, and Proj4 are now mandatory dependencies
• New Features
• Added Hausdorff distance calculations (#209) (Vincent Picavet)
• Added parameters argument to ST_Buffer operation to support one-sided buffering and other buffering styles (Sandro Santilli)
• Performance improvements to ST_Distance (Nicklas Avén)
• Addition of other Distance related visualization and analysis functions (Nicklas Avén)
• ST_ClosestPoint
• ST_DFullyWithin
• ST_LongestLine
• ST_MaxDistance
• ST_ShortestLine
• KML, GML input via ST_GeomFromGML and ST_GeomFromKML (Olivier Courtin)
• Extract homogeneous collection with ST_CollectionExtract (Paul Ramsey)
• Add measure values to existing linestring with ST_AddMeasure (Paul Ramsey)
• History table implementation in utils (George Silva)
• Win32 support and improvement of core shp2pgsql-gui (Mark Cave-Ayland)
• In place ‘make check’ support (Paul Ramsey)
• Geography type and supporting functions
• Spherical algorithms from Dave Skea
• Object/index implementation from Paul Ramsey
• Selectivitiy implementation from Mark Cave-Ayland
• Serializations (KML, GML, JSON) from Olivier Courtin
• ST_Area, ST_Distance, ST_DWithin, ST_GeogFromText, ST_GeogFromWKB, ST_Intersects, ST_Covers, ST_Buffer
• Documentation updates and improvements (Regina Obe, Kevin Neufeld)
• Testing and quality control (Regina Obe)
• PostGIS 1.5 support PostgreSQL 8.5 trunk (Guillaume Lelarge)
• Many, many other changes

关于1.3.4令人振奋的消息是关于GeoJSON的支持，我现在还在陶醉于1.3.0呵呵，而且习惯于在服务器端先AsText()然后在自己根据字符串进行解析。。有了GeoJSON的支持可以省去这个步骤，在客户端可以用Jquery直接$.getJSON，不过我觉得可能在服务器端得到GeoJSON数据后仍需要进一步解析，因为PostGIS是以对象组织空间数据的，而不是以整个文件，所以要输出整个查询结果，仍需要将结果再次组织。

同往常的更新一样，1.3.4增加了一些新的功能并fix了不少错误，Paul Ramsey依然出了不少力。Sol Katz  GFOSS被你拿到真是实至名归。1.3.5 主要是是fixmapserver配合的一个严重问题。

PS：我真的不能不佩服Paul Ramsey了。。改日我要去加拿大拜会你。。。。

References:

Well organized quick tutorial of PostGIS

PostGIS 1.3.4 released

Postgres Journal

routing (来自Cartoweb)

pgRouting示例 (来自GeoSalon的stinjia)

相关代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

-- 构建拓扑关系--
ALTER TABLE road ADD COLUMN source_id int;
ALTER TABLE road ADD COLUMN target_id int;
ALTER TABLE road ADD COLUMN edge_id int;
-- next line is to work around a pgRouting bug in update_cost_from_distance (fixed in latest CVS)
ALTER TABLE road RENAME id TO id_old;
 
SELECT assign_vertex_id('road', 0.001);
 
-- 重复检查--
SELECT * FROM (SELECT source_id, target_id, COUNT(*) AS c FROM road GROUP BY
source_id, target_id ORDER BY c)
AS foo WHERE foo.c = 2;
 
-- 删除重复的列--
CREATE TABLE doublons AS SELECT * FROM road WHERE gid  IN
(SELECT gid FROM (SELECT DISTINCT ON (source_id, target_id) source_id, gid
FROM road) AS doublon);
DELETE FROM road;
INSERT INTO road (SELECT * FROM doublons);
DROP TABLE doublons;
 
-- 构建视图--
SELECT create_graph_tables('road', 'int4');
 
--用距离赋予权重 --
SELECT update_cost_from_distance('road');
 
-- 执行shortest_path命令--
SELECT * FROM shortest_path('
SELECT gid as id,
source_id::integer as source,
target_id::integer as target,
length(the_geom) as cost
FROM road',
1, 15, TRUE, FALSE);

• 1 the first section of Mapserver Tutorials
• 2 the last chapter of introduction to postgis
• 3 Examples of Openlayers Package

* Adding Analytic Muscle to Spinning Globes: Bulking Up Google Earth and Virtual Earth With PostGIS.
* Upgrade to Grid Service with Web Processing Service
* Pleiades: Building a RESTful, Open Source GIS for the Humanities
* Geoserver and Open Standards: A Success Story
* IBM DB2 Express-C: A Free Database for Open Source Spatial and XML Development
* Google Earth Powered by MapGuide
* A Web-Based Open Source Image Server
* A year in the life of OpenStreetMap: How OSM is mapping the world.
* Transitioning Low Earth Orbit Satellite Archive Data from Informix (Geodetic DataBlade) to PostgreSQL (PostGIS)
* Security Considerations for Geospatial Applications in Web 2.0

The final FOSS4G program will include 110 more presentations, for a grand total to 120 30-minute presentations, 16 90-minute labs, 12 3-hour workshops, one code sprint, and thousands and thousands of beers!
PS：the bold tilted ones is what i concerned. Especially the first and the last ones.

I needed some test data to do some performance investigations, and had to load 235 shape files, all of identical schema. Here’s what I did.
First, get the table schema into the database, by loading a small file, and then deleting the data. We delete the data so we can loop through all the files later without worrying about duplicating the data from the initial file.

shp2pgsql -s 3005 -i -D lwssvict.shp lwss | psql mydatabase
psql -c “delete from lwss” mydatabase

Then use the shell to loop through all the shape files and append them into the table.

foreach f (*.shp)
foreach? shp2pgsql -s 3005 -i -D $f -a lwss | psql mydatabase
end

Note the “-a” switch to tell shp2pgsql we are in append mode, rather than the default create mode. Add a spatial index, and we’re done.

psql -c “create index lwss_gix on lwss using gist (the_geom)” mydatabase

Seven hundred thousand line segments, ready to play!

psql -c “select count(*) from lwss” mydatabase
count
——–
755373
(1 row)

PS:前一段时间用PersonalGeodatabase比较多，现在觉得，可能postgis和ArcGIS的personalgeodatabase其实是没有太大理念上差异的，可能关键是Postgis对栅格数据没有一整套很好的处理方法。

1. R-Tree indexes in PostgreSQL cannot handle features which are larger than 8K in size. GiST indexes can, using the “lossy” trick of substituting the bounding box for the feature itself.
2. R-Tree indexes in PostgreSQL are not “null safe”, so building an index on a geometry column which contains null geometries will fail.

CartoWeb is a comprehensive and ready-to-use Web-GIS (Geographical Information System) as well as a convenient framework for building advanced and customized applications.

Developed by Camptocamp SA, it is based on the UMN MapServer engine and is released under the GNU General Public License (GPL).

Written using innovative language PHP5, CartoWeb is highly modular and customizable thanks to its object-oriented architecture. It runs evenly on Windows or Unix-like platforms and shows its real power when associated to PostgreSQL/PostGIS.

Last but not least, CartoWeb may be set up as a SOAP Web Service enabling to have front-end server on one machine and data and map generation on an other.

当然，我们能够对所有 GIS 数据进行编辑，而且必须经常编辑这些数据，训练有素的 GIS 专家可以处理接收到的大多数数据集格式。许多（若非全部）数据格式都遵守开放标准，GIS 空间中的所有操作都可以使用运行于 Linux、主要的 Berkeley Software Design (BSD) 和一些 UNIX 变体上的开源应用程序来执行。最重要的是，GIS 软件套件还可以在 Mac OS X 上运行。

Quantum GIS：开源 GIS 数据查看器
近年来，Linux 上运行的 GIS 应用程序迅速增加。20 世纪 80 年代，编程人员开发了地理资源分析支持系统（Geographic Resources Analysis Support System，GRASS）。在 20 世纪 90 年代后期经过修改后，任何具有 GIS 知识和一些 Linux 专业知识的人员都可以利用 GRASS 从 Linux 命令行或图形用户界面 (GUI) 运行完整的 GIS 系统。遗憾的是，GRASS 极其复杂，为在 Linux 上运行 GIS 的初学者造成了一些不便。GUI 显示大量的功能和命令行标识，其目标用户是 GIS 专家，而非尝试创建网络地图的新手。

2002 年 5 月，开发人员开发了 GPLed Quantum GIS (QGIS)，该项目面向需要访问、显示和可能编辑 GIS 数据集的初学者和中间用户。GIS 用户可以将 QGIS 部署为单独的 GIS 数据查看器和编辑器，或者部署为 GIS 工具链的一部分。GIS 工具链可包括 QGIS、GRASS 软件套件、一个三维 PostGIS 数据库和一个向通过 Internet 访问地图网站的用户提供数据集和地图的地图服务器。

QGIS 开发人员决定使用基于 C++ 的 Qt 工具包来构建 QGIS 界面，这是不同于以前实践的主要方案（编程人员主要使用 Tcl/Tk 创建了 GRASS，Tcl/Tk 建立于 20 世纪 80 年代后期）。尽管 QGIS 是在 GPLed Qt 工具包的基础上开发的，但它可以在多数 Linux 和 UNIX 变体、Microsoft® Windows® 和 Mac OS X 上运行。

栅格数据
应用程序使用两种不同的数据结构存储 GIS 数据：栅格数据 和矢量数据。您可以添加三维数据格式的数据库存储，该格式针对 PostgreSQL 处理而优化 —— 即 PostGIS 数据格式。我们将 PostGIS 数据归类为矢量数据，其原因将在下文介绍。

QGIS 处理所有三种数据 —— 栅格数据、矢量数据和数据库，这也是编写 GIS 数据编程库的程序员的重要努力方向。通过想像正方形网格或六边形单元，可以方便地可视化数据结构（实践中，应用程序在多数情况下采用正方形网格）。这些网格覆盖一个像矩阵一样的地理区域，并在一个名为 map algebra 的字段中使用数学表示形式。GIS 专家可以向每个网格中添加数据，如降水量值或经济数据，但描述复杂的不规则地理形状较为困难。该软件通常必须依赖于相似性和网格中值的位置来对特征分类（如街道或海岸），而非基于封装在元数据中的特征描述。另一种可能的解释依赖于使用与个别网格相关联的颜色值将栅格网格组归类为某些特征。

网格按行或按列排列，它反映硬盘存储数据的方式。许多基于栅格的格式都有基本的图像格式：常见的基于栅格的图像格式是位图 (.bmp)。带标记的图像文件格式 (.tiff) 是另一种常用的基于栅格的图像格式，GIS 专家为适应地理学者的需要将其重命名为 GeoTIFF。基于栅格的数据格式更类似于图像。其准确性依赖于描述尽可能少的特征的网格数量。

在栅格数据模型中，地图的准确性还依赖于地图的比例。因此，地图的分辨率和准确性依赖于每个网格代表的实际区域。该数据模型可比较的简单性有助于对 GPS 设备和卫星成像捕获的数据进行建模。有些数据格式可以很好地适用于栅格模型。例如，数字高程模型（Digital Elevation Model，DEM）数据点在网格图形中均匀排列。DEM 格式编码高程数据来创建高清晰地形。前几年，美国地质调查局 (USGS) 向公共领域发布了一个非常受欢迎的全球 DEM 数据集。

矢量数据
基于矢量的数据格式的出现改变了 GIS 专家的生活。新数据查看器和编辑器，如 Thuban 和 QGIS 不必再费力地表示复杂的基于矢量的格式，因为它一开始就内置了编辑和添加基于矢量的数据层的能力。GRASS 已有 20 多年的历史，但最近才获得此能力。

简言之，矢量数据利用最简单的拓扑实体 — 点、线和多边形，并在二维笛卡尔坐标系统中固定它们来描述地理特征。连接线称为弧，笛卡尔坐标系统中的点称为节点。数据结构与图形关联，并以图形理论做为其数学基础。所谓的弧节点列表 包含弧和节点。列表定义多边形，并可以相互层叠，来表示方向完全相反但描述相同地理区域的数据集，从而形成数据详细的地图。

QGIS 和其他较为简单的数据查看器用于探测各种数据格式和覆盖此行星系统的所有数据集。与某些商业产品、甚至 GRASS 不同，您可以容易地安装这些查看器，并且几乎可以在所有主要操作系统上使用。里程可能稍有偏差，但几乎可以始终保证成功。

数据格式
QGIS 支持许多矢量数据格式，如 Shapefile、MapInfo 图层和 ArcInfo coverage。矢量数据要求的存储要比栅格数据少得多，因为弧节点列表简化并减少了表示地图中包含的特征所需的数据。这些数据还非常便于搜索地图或用矢量表示的各种图层。在 20 世纪 90 年代初，商业软件套件 ArcInfo GIS 进入市场以后，促进了对 Shapefile 的使用。后来出现了其他文件和数据格式，但是，没有免费的开源编程社区，这些成果仍局限于地理学者的理论研究和军事规划。

GRASS
最近推出了 GRASS 6.01 版，该版本支持大约 40 种数据格式。它突破了二维栅格格式，可包括体元（voxel） 或三维栅格格式。大量的成像和成图模块大大方便了 GIS 专家以新的方法分析数据。这使得长期模拟和完善的地图制作成为可能。

不过，用户仍需要解决的问题是，由于该版本针对的是 UNIX 和 Linux 专家，其界面相当杂乱而且安装过程也比较复杂。进一步说，导致这一复杂性的原因是随 GRASS 提供了大量的库和工具。所幸的是，各个 GIS 技术级别的学生编写了许多有关 GRASS 的文档，因此使 Linux 和 UNIX 新手能够对付 GRASS 安装时的复杂要求。

GDAL 和 OGR
在谈到 GIS 数据格式时，必然会考虑到要支持的大量格式，以使每个数据查看器和 GIS 应用程序可以广泛适用。开源 GIS 应用程序必须包括从 ArcInfo 到 X 窗口系统的大多数开放数据格式标准。诸如 GeoTIFF 的格式是通常由多数应用程序支持的开放标准的常见示例。

在开源范围中，GRASS、QGIS、Thuban 和许多其他 GIS 应用程序使用基本库，即 Geospatial Data Abstraction Library (GDAL)。GDAL 用 C 和 C++ 编写，只能包括一种栅格格式。另一个库叫做 OGR Simple Features Library（以前称为 OpenGIS Simple Features Reference Implementation），尽管是为了适应 GDAL 源树中存在的矢量格式而构建的，但 OGR 依赖于 GDAL。事实上，如果没有开源许可的 GDAL，多数现代地理空间数据查看器将是不可思议的。该库为编程人员提供了通用的数据模型，包括所有栅格数据格式和矢量数据格式（通过 OGR）。GDAL 还可让编程人员在世界地理坐标（即地理参考坐标）上设计栅格数据。

PostGIS 和 OpenGIS
在没有相当完善的数据存储机制的情况下，公共领域 GIS 数据不可能存在。然而，存储可能不像栅格数据那样重要，其空间构成可能包含相当简单的数字数据。编程人员只须知道一些较高级别的结构，但是多数编程人员认为栅格数据较为复杂并且占用大量的存储。

OpenGIS 标准通过生成矢量数据解决了这些问题，矢量数据也指几何对象，如点、线、多边形及其组合，可以在启用三维数据库的 PostgreSQL 中存取（PostgreSQL 的 OpenGIS 实现标准称为 PostGIS）。存储在 PostgreSQL 数据库中的 GIS 数据完全可以使用 SQL-92 搜索。

目前，编程人员能够访问整个开源 GIS 应用程序在很大程度上依赖于 UNIX 和 Linux 系统。这些成果得益于通常的开放标准，而且多数 Internet 地图制作领域正在趋向于依赖这些标准。以任何形式处理地理数据的所有编程人员都会遇到与 Linux 系统编程人员在 glibc 上遇到的相同的基础库问题。GIS 编程人员即使只是想利用键盘编写数据过滤器的脚本或删改工具链，也无法判断要使用哪些数据格式和基础库。

结束语
在谈到有关开源和全球环境现象时，很难让人联想到地理数据集和 GIS 应用程序领域。但是，开源应用程序，如 GRASS 和 QGIS 在尝试使公共领域 GIS 数据集可用于编程人员和技术用户，以便他们不必使用商业产品。GDAL 和 OGR 之类的库可以将 GIS 数据放在通用开源基础上处理，而不会影响开放 GIS 数据标准的完整性。