PostGIS+SpringBoot：地理难抵点检索的工程化实现

1. “最纵深处”不是地图上目测出来的：先把这个概念想清楚

我第一次接触到“地理难抵点”这个词，是在做一个省域应急物资储备布点项目的时候。需求方提了一个很朴素的诉求：全省范围内，哪些地方是救援力量最难到达的？不要凭感觉，要用数据算出来。

直觉上，大家都会觉得是山区、林场、边境线附近。但真正的难点在于“难抵”这个词怎么量化。如果从一个区域中心出发，离所有外部通道都最远，那这个点就是该区域的“地理难抵点”，地理学上称为Pole of Inaccessibility，国内也有人叫“极难点”或“最纵深处”。欧亚大陆的难抵点在中国新疆附近，这是地理学里很有名的结论。但落到一个省域范围内，问题就复杂了：省界不是光滑的圆，边界线上有大量锯齿状凹凸，真正的“最深处”往往不在几何中心，而是被边界形态推挤到某个意想不到的位置。

举一个很直观的例子：一个狭长形的省份，如果南边界有一个巨大的内凹湾，那么几何中心可能落在这个湾的开口处，反而离北边界不远。而真正的难抵点可能被挤到北部某个被群山环绕的角落。所以，这个点必须通过精确计算得到，任何目测和人工估算都不可靠。

那怎么算？核心思路其实不复杂：在一个封闭多边形内部找一个点，使得该点到多边形边界的最短距离最大。听起来像是一个纯粹的几何优化问题，但落地到工程上有几个绕不开的坎：省域边界数据从哪里来、用什么坐标系算距离才准、几万平方公里的范围怎么高效检索、算出来的点怎么展示给业务方看。

本文就围绕这个完整链路来写：从数据准备、算法选型、PostGIS的SQL实现，到SpringBoot接口封装和前端可视化。项目本身是一个省域尺度的“最深处检索”服务，但其中的思路和坑，放到市域、县域甚至任意自定义多边形区域内都适用。

先说结论：这个需求的本质是一个带约束的空间距离优化问题，而PostGIS加SpringBoot的组合，是这个场景下工程实现成本最低、效果最稳的方案之一。下面逐步拆解。

2. 算法选型对比：为什么最终落在PostGIS方案上

2.1 三种可行路线的优劣对比

“多边形内部到边界最远点”这个问题，业界有几种常见的解法。我先做了一轮对比，避免一上来就闷头写代码。

第一种是纯Java计算，用几何库（比如JTS）读入省界多边形，在内部铺密集格网点，逐个计算到边界的距离，取最大值。优点是部署简单，不依赖额外中间件；缺点是计算量巨大——一个省级边界如果要达到100米级别的精度，需要铺上百万个格网点，每一点都要做一次点到多边形的距离计算，单次请求可能耗时数十秒，完全不具备服务化能力。

第二种是用Python的Shapely库加GeoPandas做离线计算。Shapely里有一个Polygon.representative_point方法，但它只保证返回一个落在多边形内部的点，不保证最远；真正的polylabel算法倒是有Python移植版，计算效果好，但它是一个离线脚本，不适合做成线上接口。

第三种就是PostGIS，这也是我最终选定的方案。核心理由有三点：

• 空间索引和空间算子成熟，数据库原生支持，不需要额外引入计算引擎；
• 数据就存在PostgreSQL里，后续做区域查询、点面关系判断、缓冲区分析都很顺；
• 通过SQL可以把迭代逼近算法写成递归查询或者存储过程，虽然性能不如C++原生实现，但足以支撑省级尺度的准实时查询。

2.2 为什么PostGIS的“生成点+距离查询”思路可行

PostGIS里有一个函数ST_GeneratePoints，可以在一个多边形内部生成指定数量的随机点。配合ST_Distance和ST_Boundary，就能算出一个点到边界的最短距离。于是算法就变得很直接：生成一批内部点，计算每个点到边界的距离，取距离最大的那个点，再围绕这个点缩小范围加密采样，迭代逼近。

这在数学上是蒙特卡洛加局部搜索的思路。它不是数学意义上的全局最优解，但在工程精度要求内（比如500米、200米），完全可以满足需求。省域范围的难抵点，本身就是一个带有模糊性的业务概念，没有人会要求精确到米级。

2.3 一个容易踩的坑：距离计算必须用投影坐标系

这是我第一轮实验就踩到的坑。PostGIS的ST_Distance如果直接传入经纬度坐标（SRID 4326），返回的单位是度而不是米。在省域尺度上，纬度跨度可能有十几度，用度当距离比较会完全失真。正确的做法是先把数据转换成适合本区域的投影坐标系，比如Web Mercator（3857）用于大范围展示，或者按省份所在经度带选择对应的CGCS2000高斯投影带。对于省域尺度的距离计算，我更推荐用3857做初算，虽然它有面积变形，但在求“最远点”这种相对比较的场景下，误差可以接受；如果项目要求更高精度，可以改用省域对应的Albers等积投影或高斯投影。这个后面在SQL部分会给出具体写法。

3. 省域边界数据的获取与清洗：算法再好也怕烂数据

3.1 边界数据从哪来

省域边界数据是这个项目的地基。我的选择优先级是：

• 基础地理信息中心的公开省界数据（精度最高，但申请流程繁琐）；
• DataV.GeoAtlas的省级边界GeoJSON（阿里云提供，拿到了可以用于绝大多数项目，免费，坐标是GCJ02偏移过的，需要纠偏）；
• Natural Earth的国家级边界（全球数据，省界精度一般，适合粗糙演示）。

我实际项目中用的是DataV的省级边界GeoJSON，原因是省界数据准确度够用，而且可以按需加载单个省的边界，不用处理全国数据。

3.2 数据清洗：去除岛屿、简化边界、确保拓扑正确

拿到GeoJSON之后，有几个脏数据问题必须处理干净：

第一，边界多边形里会有大量岛屿。省域边界数据通常包含一个大的主多边形，再加上近海岛屿。如果直接把整个MultiPolygon拿去算难抵点，那些岛屿会严重干扰距离计算——某个岛上的点到主边界的最短距离可能很小，但它会拉低整体分布的极值。我的处理策略是：只保留面积最大的那个多边形作为主区域，或者把沿海岛屿单独剔除。实际SQL里可以用ST_Area排序后过滤。

第二，边界线段过于密集。高分遥感解译出的边界可能有几十万个顶点，每次算距离都要消耗大量CPU。PostGIS的ST_Simplify可以对边界做简化，保留容差范围内的主要形态。对于省域尺度的难抵点计算，我一般把容差设为500米到1000米，这样既能保证边界形态不严重失真，又能让计算速度快5到10倍。

第三，拓扑错误。GeoJSON转进PostGIS之后，最好检查一下ST_IsValid，常见的错误是自相交多边形、重复闭合点、孔洞出现在岛外。ST_MakeValid可以修复大部分问题，但修复后要再验证一次。

数据清洗完成后，存表结构很简单：

sql复制CREATE TABLE province_boundary (
    id integer PRIMARY KEY,
    name text NOT NULL,
    geom geometry(MultiPolygon, 4326) NOT NULL
);

CREATE INDEX idx_province_boundary_geom ON province_boundary USING GIST (geom);

这里我直接存4326坐标系，计算时用ST_Transform转换到目标投影。这样设计的好处是展示时不用再转换，算距离时临时转一次即可。

4. 核心算法落地：基于ST_GeneratePoints的迭代逼近SQL实现

4.1 第一版：一次性网格采样

最朴素的写法是这样：对省界多边形生成上万随机点，计算所有点到边界的最短距离，取最大值。

sql复制WITH boundary AS (
    SELECT ST_Transform(geom, 3857) AS geom_3857,
           ST_Transform(geom, 3857)::geography AS geom_geog
    FROM province_boundary
    WHERE id = 1
),
points AS (
    SELECT (ST_Dump(ST_GeneratePoints(geom_3857, 20000))).geom AS pt
    FROM boundary
),
distances AS (
    SELECT pt,
           ST_Distance(pt, (SELECT geom_3857 FROM boundary)) AS dist
    FROM points
)
SELECT ST_Transform(pt, 4326) AS geom, dist
FROM distances
ORDER BY dist DESC
LIMIT 1;

注意这里ST_Distance计算的是点到多边形的距离，因为边界几何对象是一个闭合面，ST_Distance会自动求点到面边界线的最短距离，不需要手动取ST_Boundary。不过我建议实际代码里显式用ST_Boundary，语义更清晰，性能也不差：

sql复制ST_Distance(pt, (SELECT ST_Boundary(ST_Transform(geom, 3857)) FROM boundary))

这一版能跑通，但精度不高。20000个随机点在几万平方公里的范围里平均密度可能只有几公里一个，算出来的“最远点”误差可能超过10公里。所以必须迭代。

4.2 第二版：局部加密迭代逼近

思路是这样的：第一轮全局采样找到最优点的近似位置之后，以这个点为中心，画一个半径逐步缩小的搜索圆，在圆内继续生成高密度点，重复计算。每次迭代半径缩小一半，点的密度翻倍，迭代10次左右就能把误差缩小到百米级别。

我用PL/pgSQL写了一个存储过程来实现这个逻辑：

sql复制CREATE OR REPLACE FUNCTION find_farthest_point(
    province_id integer,
    initial_points integer DEFAULT 20000,
    iterations integer DEFAULT 8,
    target_srid integer DEFAULT 3857
)
RETURNS TABLE (geom geometry, distance_m double precision) AS $$
DECLARE
    boundary_geom geometry;
    boundary_proj geometry;
    search_center geometry;
    search_radius double precision;
    best_pt geometry;
    best_dist double precision := 0;
    i integer;
BEGIN
    SELECT ST_Transform(geom, target_srid) INTO boundary_proj
    FROM province_boundary WHERE id = province_id;

    boundary_geom := ST_Boundary(boundary_proj);

    -- 第一轮全局搜索
    WITH pts AS (
        SELECT (ST_Dump(ST_GeneratePoints(boundary_proj, initial_points))).geom AS pt
    )
    SELECT pt, ST_Distance(pt, boundary_geom) INTO best_pt, best_dist
    FROM pts
    ORDER BY ST_Distance(pt, boundary_geom) DESC
    LIMIT 1;

    search_center := best_pt;
    search_radius := ST_MaxDistance(search_center, boundary_geom) * 0.3;

    FOR i IN 1..iterations LOOP
        -- 在当前搜索范围内生成高密度点
        WITH search_area AS (
            SELECT ST_Buffer(search_center, search_radius) AS area
        ),
        pts AS (
            SELECT (ST_Dump(ST_GeneratePoints(area, 2000))).geom AS pt
            FROM search_area
        )
        SELECT pt, ST_Distance(pt, boundary_geom) INTO best_pt, best_dist
        FROM pts
        WHERE ST_Distance(pt, boundary_geom) > best_dist
        ORDER BY ST_Distance(pt, boundary_geom) DESC
        LIMIT 1;

        -- 收缩搜索半径
        search_radius := search_radius * 0.5;
    END LOOP;

    RETURN QUERY SELECT ST_Transform(best_pt, 4326), best_dist;
END;
$$ LANGUAGE plpgsql;

这个存储过程的核心逻辑是：每次迭代不是全图重新采样，而是在已知最优点附近做一个局部搜索窗。因为难抵点是一个连续函数的极大值点，局部加密收敛得很快。

实测下来，一个普通的省级区域，20000个初始点加8轮迭代，总耗时约10到15秒。对非实时的检索类需求来说完全够用。如果你需要更快的响应，可以把全局采样点降到5000，再把迭代次数控制在6次，精度大概在1公里左右，耗时能压到5秒以内。

4.3 为什么要保留最大内接圆的思想：从算法到业务理解

讲到这里，我需要解释清楚一个容易被忽略的点：难抵点本质上对应的是该点作为圆心、以到边界最短距离为半径的最大内接圆。这个圆如果在业务上叠加出来，很有说服力——它就是“从这个点出发，方圆多少公里内没有任何边界出口”的可视化表达。所以在算法落地时，我不只返回难抵点坐标，还返回了这个半径值。后面做可视化时，直接画一个以难抵点为圆心、对应距离为半径的圆，业务方一眼就能看懂。这个设计在需求评审时非常加分，因为决策者不需要理解几何算法，只要看到那个圆就知道“这个点有多远”。

4.4 计算效率的进一步优化：简化边界是关键中的关键

前面提到过ST_Simplify，但这里需要强调它的作用比想象中大得多。一个未简化的省级边界可能有几十万个顶点，ST_Distance每次都要遍历全部线段，20000个点就是几十亿次线段距离计算，性能直接爆炸。简化到500米容差后，顶点数可能降到几千个，计算量下降几个数量级。

我在项目中加了一张简化边界表，专门用于算法计算：

sql复制CREATE TABLE province_boundary_simplified AS
SELECT id, name,
       ST_SimplifyPreserveTopology(geom, 0.005) AS geom
FROM province_boundary;

0.005在这里是经纬度单位，约等于500米。ST_SimplifyPreserveTopology比ST_Simplify更稳，它保证简化后不会出现多边形自相交或岛和主区域粘连的问题。这一点极其重要，否则ST_GeneratePoints可能生成落在自相交区域内的坏点，导致计算结果发散。

5. SpringBoot接口层设计：把PostGIS能力封装成可用的检索服务

5.1 工程骨架与依赖

后端我用的是SpringBoot 2.7.x，搭配MyBatis-Plus和PostgreSQL驱动。这里不引入复杂的ORM映射，因为核心查询就是调用上面那个存储过程，MyBatis直接写SQL即可。

pom.xml里的关键依赖如下：

xml复制<dependency>
    <groupId>org.postgresql</groupId>
    <artifactId>postgresql</artifactId>
    <version>42.6.0</version>
</dependency>
<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>2.3.1</version>
</dependency>
<dependency>
    <groupId>org.postgis</groupId>
    <artifactId>postgis-jdbc</artifactId>
    <version>2.5.1</version>
</dependency>

补充一下，postgis-jdbc这个库已经比较老了，但它能处理PGgeometry类型到Java对象的映射。如果你不想引入这个依赖，也可以把查询结果里的geometry字段在SQL层直接转成GeoJSON文本：

sql复制SELECT ST_AsGeoJSON(ST_Transform(best_pt, 4326)) AS geom_geojson, distance_m
FROM find_farthest_point(1, 20000, 8, 3857);

这种方式更简洁，Java端只需要接收一个String类型的JSON即可。我个人更推荐这种做法，因为跨部门协作时，接口返回GeoJSON文本比返回二进制几何对象更通用。

5.2 Mapper与接口封装

Mapper接口定义如下：

java复制@Mapper
public interface FarthestPointMapper {

    @Select("SELECT ST_AsGeoJSON(ST_Transform(geom, 4326)) AS geom_geojson, " +
            "distance_m FROM find_farthest_point(#{provinceId}, #{initialPoints}, #{iterations}, 3857)")
    FarthestPointResult findFarthestPoint(@Param("provinceId") Integer provinceId,
                                          @Param("initialPoints") Integer initialPoints,
                                          @Param("iterations") Integer iterations);
}

返回对象简单粗暴：

java复制public class FarthestPointResult {
    private String geomGeojson;
    private Double distanceM;
    // getter/setter
}

Service层做校验和编排，比如判断省份是否存在、参数范围是否合理。Controller就一个接口：

java复制@RestController
@RequestMapping("/api/farthest-point")
public class FarthestPointController {

    @GetMapping("/province/{provinceId}")
    public Result<FarthestPointResult> getFarthestPoint(@PathVariable Integer provinceId,
                                                        @RequestParam(defaultValue = "20000") Integer points,
                                                        @RequestParam(defaultValue = "8") Integer iterations) {
        return Result.success(farthestPointService.find(provinceId, points, iterations));
    }
}

到这里，后端接口的核心链路就通了。但实际项目里我不会止步于此——因为业务方通常不只要一个省的全境难抵点，还可能想看“如果排除某个自然保护区后，最深处在哪”“如果以乡镇政府驻地作为可达点，哪些地方离最近乡镇最远”。这些变体需求，会逐步把检索从“全境单点查询”推向“约束条件下多区域检索”。

5.3 进阶变体：带约束条件的难抵点检索

这里展开讲一个常用的变体：排除禁入区域后的难抵点检索。比如要算“全省除自然保护地核心区外的最深处”，SQL需要把边界从省界换成省界差集禁入区：

sql复制WITH area AS (
    SELECT ST_Difference(
        ST_Transform(p.geom, 3857),
        ST_Union(ST_Transform(r.geom, 3857))
    ) AS geom_3857
    FROM province_boundary p,
         restricted_zone r
    WHERE p.id = #{provinceId}
)
SELECT ST_AsGeoJSON(ST_Transform(pt, 4326)), dist
FROM (
    -- 在这个area内走同样的迭代逻辑
) t;

这个场景在应急选址、自然保护区巡查点布设中很实用。PostGIS的空间关系算子在这种复合分析上的表达能力，是纯Java方案难以企及的。

6. 从坐标到地图：难抵点的可视化设计与交互

6.1 响应数据结构的约定

接口返回的数据不能只有一个点和半径，我最终设计成了这样的结构：

json复制{
  "provinceId": 1,
  "provinceName": "某省",
  "farthestPoint": {
    "type": "Feature",
    "geometry": {
      "type": "Point",
      "coordinates": [111.23, 30.45]
    },
    "properties": {
      "distanceM": 45600,
      "distanceKm": 45.6
    }
  },
  "maxInscribedCircle": {
    "type": "Feature",
    "geometry": {
      "type": "Polygon",
      "coordinates": [...]
    },
    "properties": {
      "radiusKm": 45.6,
      "center": [111.23, 30.45]
    }
  }
}

前端拿到这个结构后，可以直接用GeoJSON渲染，不需要额外拼接。maxInscribedCircle是后端生成的圆形面，对应2.3节提到的最大内接圆。后端生成这个圆很简单：

sql复制SELECT ST_AsGeoJSON(ST_Buffer(ST_Transform(best_pt, 3857), radius_m));

注意这里的半径单位是米，在3857坐标系下buffer的单位也是米，所以直接用ST_Buffer就可以生成一个圆形面。这个圆在前端展示时，业务方看到的是一个覆盖范围的可视化边界，比单纯的点加提示框直观得多。

6.2 前端渲染：Leaflet就够了

可视化这块我没有引入重型框架，用的是Leaflet加GeoJSON图层，代码量小、上手快、稳定。核心渲染逻辑就二三十行：

javascript复制const map = L.map('map').setView([30.45, 111.23], 6);

L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
    maxZoom: 18
}).addTo(map);

function loadFarthestPoint(provinceId) {
    fetch(`/api/farthest-point/province/${provinceId}`)
        .then(res => res.json())
        .then(data => {
            // 清空旧的图层
            if (window.farthestLayer) {
                map.removeLayer(window.farthestLayer);
            }

            const features = [
                data.farthestPoint,
                data.maxInscribedCircle
            ];

            window.farthestLayer = L.geoJSON(features, {
                style: function(feature) {
                    return feature.geometry.type === 'Point'
                        ? { color: '#ff0000', radius: 8 }
                        : { color: '#3388ff', dashArray: '5,5', fillOpacity: 0.1 };
                },
                pointToLayer: function(geoJsonPoint, latlng) {
                    return L.circleMarker(latlng, { radius: 8, color: '#d7191c', fillColor: '#d7191c', fillOpacity: 0.9 });
                }
            }).addTo(map);

            map.fitBounds(window.farthestLayer.getBounds(), { padding: [50, 50] });
        });
}

实际部署时，如果要用于政务内网，底图可以换成内网发布的瓦片服务，前端代码基本不用动。这是Leaflet的另一个好处——不绑死具体的底图提供商。

6.3 可视化增强：等距圈层辅助理解

除了最大内接圆，我还会额外生成几个等距圈层（比如半径的50%、75%、90%），用来展示从难抵点向外扩展的空间衰减过程。实现方式同样是ST_Buffer。这些圈层叠加在底图上，可以让人直观看到难抵点周围的缓冲范围如何穿越不同的地貌区。比如有的省份，难抵点周围75%半径范围内全是山区，说明这个点的“难抵”主要是地形因素导致的；另一些省份，难抵点靠近大湖或者河流，说明边界的不规则形状是主导因素。这个分析对业务方的决策非常有价值。

7. 性能调优和边界情况：这些坑比想象中多

7.1 性能瓶颈卡在哪

整个链路的性能瓶颈几乎都在PostGIS计算环节，也就是ST_GeneratePoints和ST_Distance的组合。我踩过的优化手段排序如下：

第一，边界简化一定是最有效的。这一步做不好，后面所有优化都是白搭。边界顶点数从十万级降到千级，计算量直接掉三个数量级。

第二，ST_GeneratePoints本身是随机采样，在边界凹度大的区域容易出现点分布不均。可以通过增加初始点数、或者把区域用ST_Subdivide分成多个子区域分别采样后合并，覆盖面会均匀很多。

第三，局部迭代时，搜索半径的初始值很关键。我是用所有采样点里第二大的距离作为初始半径的，避免第一轮就直接收敛到局部极值。

第四，把半径缩小系数从0.5改成0.4或0.6，会影响收敛速度和稳定性。经过实测，0.5是一个折中值，配合8轮迭代效果最好。

7.2 多岛屿省份怎么处理

像浙江、福建、广东这种沿海省份，MultiPolygon里的大量离岸岛屿对难抵点计算干扰极大。如果不剔除岛屿，ST_GeneratePoints可能生成很多岛上的点，距离计算会引入大量的“近边界短距离”，最终的最远点会被拉到主岛内部。虽然最终取的是距离最大的点，但迭代搜索时局部加密落在岛屿区域会导致收敛点偏到近岸，明显不符合业务直觉。

我的处理策略是：用窗口函数按面积排序，只保留每个省最大的多边形作为主区域；但如果业务方明确要求“包含岛屿”，那就把岛屿合并到主区域内再计算，不合并也可以，只是需要对每个岛单独算一次难抵点。同一省域两种口径的结果可能相差很大，接口设计时要支持参数切换。

7.3 参数校验和并发控制

SpringBoot接口暴露后，如果有人恶意传一个很大的points参数，比如100万，PostGIS会直接卡到超时。所以我加了参数上限校验：

• initialPoints：最大50000；
• iterations：最大12；
• 当并发量高时，对同一省份的请求做内存级互斥，避免两个大查询同时怼数据库。

实际部署中，这个接口的典型场景是后台分析，不是高并发C端接口，所以简单互斥就够用了。如果后续要做成在线服务，建议把计算结果的缓存落到Redis，按“省ID+口径+参数”做key，因为同一个省的结果短期内不会变，没必要求一次算一次。

7.4 一个隐藏较深的结果验证方法

算完之后怎么验证结果对不对？这是个很实际的问题。我的做法是：把算出来的最远点，用ArcGIS或者QGIS手动量测到边界最近点的距离，看是否和SQL结果吻合。另外可以做一个反向校验：取边界线上离难抵点最近的那个点，做一条连线，看这条连线是否大致垂直于最近的边界线段。如果不垂直，说明大概率算错了——因为空间距离最优解必然落在边界点的法线方向上。这个校验技巧在实际项目中帮我抓出来过一次坐标系转换错误。

8. 项目扩展思路：从“最深处检索”到更通用的空间分析服务

这个项目做完之后，我最大的感触是：难抵点检索只是一个切入点，PostGIS加SpringBoot的能力远不止于此。

最直接的一个扩展是“领域可达性分析”。难抵点关注的是到边界的最大距离，而可达性分析关注的是从一组设施点出发，覆盖整个省域需要多大半径。PostGIS里ST_Union加ST_Buffer就能算出任意设施点的覆盖范围，再配合ST_Difference求覆盖盲区。这个和难抵点场景高度互补。

另一个扩展是“多约束条件下的最优点选址”。比如要在全省建若干个应急物资库，要求每个库到边界的最小距离都不小于某个阈值，同时库与库之间的间距不小于某个值。这类问题的精确解法是设施选址模型，但PostGIS加迭代逼近可以给出一个工程可用的近似解。

再一个方向是把难抵点的计算从省域下沉到县域甚至乡镇。数据量更大的时候，可以考虑把简化边界表和计算结果做预计算，用定时任务把各省难抵点算好存入结果表，接口只做查表返回。这样响应时间能从秒级降到毫秒级，可以支撑Web端频繁交互。

最后说一个个人体会：这类地理计算项目，最容易翻车的不是算法本身，而是数据坐标系、边界拓扑这些看起来不起眼的底层问题。如果你照着本文的思路做，建议第一个小目标先跑通“单省难抵点计算+展示”，验证数据链路没问题，再考虑扩展成多省并行、多约束条件下的服务化能力。PostGIS的好处是这些能力都是内置的，不需要额外引入计算框架，项目演进起来平滑得多。