使用 Azure 流分析的地理围栏和地理空间聚合方案

借助内置的地理空间函数,可以使用 Azure 流分析来为机群管理、单车共享、联网汽车和资产跟踪等方案构建应用程序。

地理围栏

Azure 流分析支持云中和 IoT Edge 运行时中的低延迟实时地理围栏计算。

地理围栏方案

某家制造公司需要跟踪其建筑物中的资产。 他们在每台设备上装备了 GPS,并希望在设备离开特定的区域时接收通知。

本示例中的参考数据包含建筑物以及允许在每个建筑物中使用的设备的地理围栏信息。 请记住,参考数据可以是静态的,也可以是缓慢变化的。 本方案使用静态参考数据。 数据流持续发出设备 ID 及其当前位置。

在参考数据中定义地理围栏

可以使用 GeoJSON 对象定义地理围栏。 对于兼容性版本 1.2 和更高版本的作业,还可以使用已知文本 (WKT) 将地理围栏定义为 NVARCHAR(MAX)。 WKT 是一个开放地理空间信息联盟 (OGC) 标准,用于以文本格式表示空间数据。

内置地理空间函数可以使用定义的地理围栏来确定某个元素是在特定地理围栏多边形的内部还是外部。

下表列出了可以存储在 Azure Blob 存储或 Azure SQL 表中的地理围栏参考数据示例。 每个场地由地理空间多边形表示,每个设备与允许的场地 ID 相关联。

SiteID SiteName Geofence AllowedDeviceID
1 "Redmond Building 41" "POLYGON((-122.1337357922017 47.63782998329432,-122.13373042778369 47.637634793257305,-122.13346757130023 47.637642022530954,-122.13348902897235 47.637508280806806,-122.13361777500506 47.637508280806806,-122.13361241058703 47.63732393354484,-122.13265754417773 47.63730947490855,-122.13266290859576 47.637519124743164,-122.13302232460376 47.637515510097955,-122.13301696018573 47.63764925180358,-122.13272728161212 47.63764925180358,-122.13274873928424 47.63784082716388,-122.13373579220172 47.63782998329432))" "B"
2 "Redmond Building 40" "POLYGON((-122.1336154507967 47.6366745947009,-122.13361008637867 47.636483015064535,-122.13349206918201 47.636479400347675,-122.13349743360004 47.63636372927573,-122.13372810357532 47.63636372927573,-122.13373346799335 47.63617576323771,-122.13263912671528 47.63616491902258,-122.13264985555134 47.63635649982525,-122.13304682248554 47.636367344000604,-122.13305218690357 47.63650831807564,-122.13276250832996 47.636497473929516,-122.13277323716602 47.63668543881025,-122.1336154507967 47.6366745947009))" "A"
3 "Redmond Building 22" "POLYGON((-122.13611660248233 47.63758544698554,-122.13635263687564 47.6374083293018,-122.13622389084293 47.63733603619712,-122.13622389084293 47.63717699101473,-122.13581619507266 47.63692757827657,-122.13559625393344 47.637046862778135,-122.13569281345798 47.637144458985965,-122.13570890671207 47.637314348246214,-122.13611660248233 47.63758544698554))" "C"

生成地理围栏的警报

设备可以通过名为 DeviceStreamInput 的流每隔一分钟发出其 ID 和位置。 下表列出了一个输入流。

DeviceID GeoPosition
"A" "POINT(-122.13292341559497 47.636318374032726)"
"B" "POINT(-122.13338475554553 47.63743531308874)"
"C" "POINT(-122.13354001095752 47.63627622505007)"

可以编写一个查询,用于将设备流与地理围栏参考数据相联接,并在每次设备离开允许的建筑物时生成警报。

SELECT DeviceStreamInput.DeviceID, SiteReferenceInput.SiteID, SiteReferenceInput.SiteName 
INTO Output
FROM DeviceStreamInput 
JOIN SiteReferenceInput
ON st_within(DeviceStreamInput.GeoPosition, SiteReferenceInput.Geofence) = 0
WHERE DeviceStreamInput.DeviceID = SiteReferenceInput.AllowedDeviceID

下图显示了地理围栏。 可以根据流数据输入查看设备所在的位置。

Building geofences

设备“C”位于建筑物 ID 2 的内部,根据参考数据,这是不允许的。 此设备应位于建筑物 ID 3 的内部。 运行此作业会针对此特定违规生成警报。

包含多个允许的设备的场地

如果某个场地允许多个设备,则可以在 AllowedDeviceID 中定义设备 ID 的数组,并在 WHERE 子句中使用用户定义的函数,来验证流设备 ID 是否与该列表中的任何设备 ID 相匹配。 有关详细信息,请参阅有关云作业的 Javascript UDF 教程。

地理空间聚合

Azure 流分析支持云中和 IoT Edge 运行时中的低延迟实时地理空间聚合。

地理空间聚合方案

某家出租车公司想要构建一个实时应用程序,以引导其出租车司机在租车需求旺盛的城市区域找到活计。

该公司将城市的逻辑区域存储为参考数据。 每个区域由 RegionID、RegionName 和 Geofence 定义。

定义地理围栏

下表列出了可以存储在 Azure Blob 存储或 Azure SQL 表中的地理围栏参考数据示例。 每个区域由地理空间多边形表示,该多边形用于将来自流数据的请求相关联。

这些多边形仅用于参考,而不表示实际城市的逻辑或物理划分。

RegionID RegionName Geofence
1 "SoHo" "POLYGON((-74.00279525078275 40.72833625216264,-74.00547745979765 40.721929158663244,-74.00125029839018 40.71893680218994,-73.9957785919998 40.72521409075776,-73.9972377137039 40.72557184584898,-74.00279525078275 40.72833625216264))"
2 "Chinatown" "POLYGON((-73.99712367114876 40.71281582267133,-73.9901070123658 40.71336881907936,-73.99023575839851 40.71452359088633,-73.98976368961189 40.71554823078944,-73.99551434573982 40.717337246783735,-73.99480624255989 40.718491949759304,-73.99652285632942 40.719109951574,-73.99776740131233 40.7168005470334,-73.99903340396736 40.71727219249899,-74.00193018970344 40.71938642421256,-74.00409741458748 40.71688186545551,-74.00051398334358 40.71517415773184,-74.0004281526551 40.714377212470005,-73.99849696216438 40.713450141693166,-73.99748845157478 40.71405192594819,-73.99712367114876 40.71281582267133))"
3 "Tribeca" "POLYGON((-74.01091641815208 40.72583120006787,-74.01338405044578 40.71436586362705,-74.01370591552757 40.713617702123415,-74.00862044723533 40.711308107057235,-74.00194711120628 40.7194238654018,-74.01091641815208 40.72583120006787))"

根据时间范围聚合数据

下表包含“乘车”流数据。

UserID FromLocation ToLocation TripRequestedTime
"A" "POINT(-74.00726861389182 40.71610611981975)" "POINT(-73.98615095917779 40.703107386025835)" "2019-03-12T07:00:00Z"
"B" "POINT(-74.00249841021645 40.723827238895666)" "POINT(-74.01160699942085 40.71378884930115)" "2019-03-12T07:01:00Z"
"C" "POINT(-73.99680120565864 40.716439898624024)" "POINT(-73.98289663412544 40.72582343969828)" "2019-03-12T07:02:00Z"
"D" "POINT(-74.00741090068288 40.71615626755086)" "POINT(-73.97999843120539 40.73477895807408)" "2019-03-12T07:03:00Z"

以下查询将设备流与地理围栏参考数据相联接,并每隔一分钟计算 15 分钟时间范围内每个区域的请求数。

SELECT count(*) as NumberOfRequests, RegionsRefDataInput.RegionName 
FROM UserRequestStreamDataInput
JOIN RegionsRefDataInput 
ON st_within(UserRequestStreamDataInput.FromLocation, RegionsRefDataInput.Geofence) = 1
GROUP BY RegionsRefDataInput.RegionName, hoppingwindow(minute, 1, 15)

此查询每隔一分钟输出该城市中每个区域在过去 15 分钟的请求计数。 可以通过与 Azure 函数等服务的集成,以短信的形式将其广播给所有司机。

下图演示了该查询在 Power BI 仪表板中的输出。

Result output on Power BI dashboard

后续步骤