推荐语
Palantir如何通过地理位置数据重构业务逻辑？深入解析其本体中的空间数据类型与应用场景。核心内容： 1. 地理位置数据在Palantir本体中的核心地位与业务价值 2. 四种基础地理空间数据类型及其典型应用案例 3. Pipeline Builder支持的地理空间处理能力与技术规范
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
在Palantir的产品体系里，本体（Ontology）是把业务世界结构化、语义化的关键层，而地理位置数据（Geo/Geospatial Data）则是本体里非常重要的一类。无论是国防安全、供应链调度，还是城市治理、能源运维，几乎所有核心场景都离不开“东西在哪儿”，“它们之间的空间关系”是什么这两个问题。
在Palantir的Ontology里，每个业务对象（Object）都有一组属性（Properties），其中一类属性就是地理空间属性（Geospatial Properties）。常见的有
从本体角度看，地理位置是直接参与业务语义建模的核心字段。比如
Vehicle对象：currentLocation:Point，plannedRoute:Line
Warehouse对象：location:Point，coverageArea:Polygon
Incident对象：location:Point，affectedArea:Polygon
有了地理位置，在本体层就能表达这是一辆车，这个车现在在这儿，规划路线是这条线，并且在这个仓库覆盖区里，而不是在底层数据库/坐标系里自己去拼接。
Palantir的Pipeline Builder 目前支持以下几种地理空间类型：
GeoPoint： 一个由经度和纬度组成的结构体（struct）。
经度（longitude）：[-180, 180] 范围内的 double
纬度（latitude）：[-90, 90] 范围内的 double GeoPoint 必须是符合 WGS:84 或 EPSG:4326 坐标参考系统（CRS）的有效 (x, y) 坐标。
Geometry： 一个符合 GeoJSON 规范的字符串形式的 JSON 数据块（stringified JSON blob）。 其中每个坐标都应使用与 GeoPoint 类型相同的 WGS:84/EPSG:4326 格式。
H3Index： 表示一个有效 H3 六边形索引的字符串。
LatLonBoundingBox： 表示一个边界框（bounding box），由 minLat, minLon, maxLat, maxLon 组成的结构体。
Ontology GeoPoint： 一种与本体（Ontology）中的 GeoPoint 属性类型兼容的字符串格式，形如：{lat},{lon} 其中 -90 <= lat <= 90 且 -180 <= lon <= 180。
MGRS： 表示一个有效 MGRS（Military Grid Reference System，军事格网参考系统）坐标的字符串。
Pipeline Builder 支持对地理空间数据进行多种不同的转换和表达式操作。
GeoPoint：
构造 GeoPoint 列（Construct GeoPoint column）： 接收一对纬度、经度（lat,lon），校验其是否在前文提到的取值范围内，然后将其转换为 GeoPoint 表示。
从坐标系（CRS）创建 GeoPoint（Create GeoPoint from Coordinate System, CRS）： 接收一对 x,y 坐标和一个坐标参考系统（CRS），先将该 (x,y) 投影转换到 WGS:84，然后构造一个 GeoPoint 表示。支持从 EPSG 数据库中的大多数坐标系进行转换，包括所有 UTM 分区。
Geometry：
解析 Well-Known Text（Parse well-known text, WKT）： 将 WKT 字符串转换为 Geometry 逻辑类型。可选地提供一个源坐标系标识符，如果 WKT 当前不在 WGS:84 下，则会从该源 CRS 转换到 WGS:84。
标准化 Geometry（Normalize Geometry）： 对给定的 WGS:84 格式的 GeoJSON 字符串进行标准化处理，包括：正确的顶点顺序（右手法则）、闭合的环、去重以及点的维度保持一致。
从 Shapefile 中抽取行（Extract rows from Shapefile）： 对一组原始 Shapefile 数据集进行解析，将每个 Shapefile 拆解为多行数据，每一行包含一个要素的几何信息和属性信息。输出数据集中会包含一个 geometry 列，以及对用户指定的每个属性生成对应列。对于非 WGS:84 的数据集，可以指定其坐标参考系统。
从 GeoJSON 中抽取行（Extract rows from GeoJSON）： 对一组原始 GeoJSON 文件进行解析，将每个文件拆解为多行数据，每一行包含一个要素的几何信息和属性信息。输出数据集中会包含一个 geometry 列，以及对用户指定的每个属性生成对应列。对于非 WGS:84 的数据集，可以指定其坐标参考系统。
此外还提供了一些表达式，可以在上述两种类型之间互相转换，也可以将它们转换为 H3 索引、MGRS、边界框（bounding boxes）以及本体中的 GeoPoint 格式。
地理位置属性是如何建模的？首先是属性类型与约束。在Ontology建模时，为对象增加属性时，可以选择Geospatial类型，并进一步限定数据类型为Point/Line/Polygon/MultiPolygon等。坐标系通常使用WGS84（EPSG:4326）经纬度，也支持其他投影；系统负责统一坐标。维度约束包括点（比如经度-180~180，纬度-90~90）、线与面的约束是坐标序列必须合法闭合、无自交（系统会做基本校验）。在对象层面，可以通过约束表达业务逻辑，比如某类对象必须有location（必填）、某类对象可以选填coverageArea、对属性值进行业务校验（如仓库位置必须在某个国家边界内）。
地理位置通常与其他属性的组合，地理位置属性通常不会单独存在，而是与时间、状态、分类等属性组合，形成可直接驱动分析的结构化业务实体。比如设备对象location+status+lastMaintenanceTime，订单对象destination+eta+priority，危险事件对象location+severity+detectedTime+incidentType。这样的组合，后续在Pipeline、Logic或AIP里就可以直接用，比如筛选在某个区域内、状态为Critical、且最近30分钟发生的事件。
地理位置数据是怎么存、怎么连的呢？Palantir在底层会兼容多种存储技术，包括时序、列式、文档、对象存储等。但在Ontology这一层不需要关心具体存在哪个数据库里。作为使用者，可以理解为所有地理属性都以统一的Geo类型暴露在Ontology上。无论源数据来自PostGIS、ES、Parquet、对象存储中的GeoJSON，最终都被标准化为统一的geospatial属性。本体层会处理坐标系转换、基本合法性校验。更关键的是，关系也可以依托地理位置来定义和计算。比如仓库与订单之间的关系：订单destination点落在仓库coverageArea面内→属于该仓库服务范围；传感器与设备：传感器位置与设备位置距离<10米→视为绑定设备；港口与船舶：船舶轨迹在港口区域内停留时间>1小时→到港记录。
在Ontology里，可以通过计算属性（Derived Properties）或在数据管道中，将这些空间关系显式化，写成结构化字段，例如assignedWarehouse,nearbySensorsCount等。
地理空间查询与分析能力依赖于地理位置数据。一旦本体层有了标准的地理属性，后续在Foundry/Gotham/AIP里就可以直接做各种空间分析，而不需要开发者手写复杂的GIS代码。典型能力包括
范围查询（Within/Intersects）：查询某个多边形区域内的对象，例如查出在上海市行政边界内的所有订单目的地。查询与某个区域相交的线或面：例如查出穿过环保敏感区域的管道段。在应用界面中，用户可以直接画一个多边形、圈选一块区域，后台自动执行空间过滤，结果列表立刻联动更新。
距离与缓冲区分析（Buffer/Distance）：计算点与点之间距离：比如计算车与仓库的距离，判断是否在50km内。基于一定半径构建缓冲区（Buffer）：比如沿着输电线路生成500米缓冲区，用于扫描线路风险点、树木、施工工地等。在Ontology中，可以预定义这些计算为派生属性，如distanceToNearestWarehouse,isInRiskBuffer,从而在Logic和AIP里直接使用。
空间Join（Spatial Join）：这是很多业务场景中的关键操作，比如：把实时车位置join到路网，得到所在道路、路段等级。把事故点join到行政区划，本体中直接保存所属省、市、区。把环境监测站join到工业园区边界，监测不同园区的排放情况。在Palantir的Pipeline/Contour/CodeWorkbook中，都可以配置空间Join，然后把结果写回Ontology，形成新的业务属性或新的关系。
时空结合分析（Spatio-temporal）：很多场景本质上是位置+时间的复合问题，例如：某设备在过去24小时的轨迹是否进入过禁区？某段时间内所有卡车经过某个收费站的次数？某舰艇过去一周的在港/离港时间分布？在Palantir的时序能力与地理能力结合下，可以通过用时序属性记录轨迹（时间+Point），用空间函数判断每个轨迹点相对于区域/边界的位置，聚合得到停留时长、访问次数、路线偏差等指标，并将这些分析结果作为新的结构化属性写回本体。
地图可视化与Ontology形成联动。Palantir的前端（Foundry Actions、Gotham、AIP Workshop等）提供了强大的地图组件（Map/Geospatial Widget），这些组件与Ontology深度绑定。
（1）基于对象集（ObjectSet）驱动地图
选择一个对象集（例如Vehicle、Warehouse、Incident），映射地理属性到地图：
点：用经纬度属性画点
面：用Polygon属性画区域
线：用Line属性画路线
再用对象其他属性决定渲染样式：
颜色：按状态/风险等级分色
大小：按数量/流量/重要性调整点大小
透明度：按置信度或权重控制
这些全部是配置而不是硬编码，并且是和Ontology中的对象定义自动同步的。
（2）地图与列表/图表联动
典型的工作界面会是：
左侧：对象列表或表格（所有事件、所有车辆）
中间：地图，展示它们的空间分布
右侧：详情面板、趋势图表、推荐动作
当在列表里选择某一行，对应对象在地图上高亮；在地图上圈选一块区域，列表自动筛选为该区域内对象。这种联动是由Ontology的统一对象模型驱动的，不需要前端写复杂glue code。
（3）在地图上驱动决策与Action
更进一步，地图不只是看图，而是通过地图触发行动，在地图上选中一组受影响的设备或订单，点击侧边的按钮（Apply Action/AIP Action），调用AIP Logic流水线重新规划线路、生成调拨建议、下发任务单。由于Action的输入输出都是Ontology的对象和属性，所以从地图到决策执行是一个闭环：位置→对象→决策逻辑→写回本体→地图更新。
AIP中地理位置数据+LLM结合可以做很多事情。在AIP的场景里，LLM并不是直接操作底层坐标，而是通过Ontology暴露的地理属性来理解和推理。例如：
（1）自然语言查询
帮我找出未来24小时内会经过上海港周边50公里范围、且载货量超过80%的船舶。
LLM解析为：
区域=上海港polygon Buffer(50km)
对象集=Vessels
条件=etainnext24hANDrouteintersectsbufferANDloadFactor>0.8
（2）决策建议
这个事故点附近最近的三家维修站在哪？给出各自预计到达时间和推荐路线。
LLM会：
从事故对象的location出发
查找附近RepairStation的点
调用路网/路径服务（或已有函数）计算ETA
返回结构化建议，并可以通过Action写入派单记录。
因为地理位置已经是Ontology的属性，LLM不需要自己理解坐标系，而是只要会调用查询附近对象过滤某区域内对象等封装好的Geo能力。
我们举一个典型业务例子。
场景：关键零部件缺料+调整建议
（1）Ontology建模
Plant（工厂）：location:Point,coverageArea:Polygon
Warehouse（仓库）：location:Point,stockLevel
Shipment（在途运输）：currentLocation:Point,route:Line,eta
（2）Geospatial用法：
通过空间Join把Shipment的route与各Plant的coverage Area相交，判断在途货车是给哪个工厂的；在地图上展示每个Plant的库存缺口，用颜色反映严重程度。
（3）AIP+LLM：
用户问：某个关键件在华东区域哪些工厂未来三天会缺料？能否从周边仓库和在途货车中调货？
LLM将自然语言转为
过滤华东区域（Polygon内）Plant
基于需求预测+当前库存+到货ETA计算未来三天缺口
在缺料工厂周边一定范围内查找Warehouse和相关Shipment，计算可调拨量与调拨时间
输出建议，并用Action在本体中创建reallocation记录，地图实时更新新的调拨路线。
整个过程中，地理位置数据是贯穿看清局面→分析问题→生成方案→执行闭环的主线。
Palantir本体中的地理位置数据，不是简单的经纬度字段，而是作为Ontology属性的标准Geo类型，被统一建模与管理；与时间、状态、关系等属性组合，表达丰富的业务语义；通过空间过滤、空间Join、距离/缓冲、时空分析等能力，支撑复杂业务逻辑；在地图组件中以对象驱动的方式可视化，并与列表、图表、Action深度联动；在AIP中成为LLM调用和推理的基础，使用自然语言问空间问题和基于空间信息自动决策成为可能。
粤ICP备14082021号
免费POC，
零成本试错
