Short version: What is the "correct" Esri-based solution to the presumably-common scenario of receiving dynamic asset location data (eg. aircraft), checking to see whether those points are within any of a set of polygons (eg. flight zones), and updating the point record with the identifier of the polygon which contains it (eg. "Aircraft A is within Zone 1")?
Long version: We provide a service which tracks assets and reports whether or not they are inside an area of interest (AOI). We have written our own point-in-polygon code to perform this check, but it's not scaling. We're assuming that a dedicated GIS will be better at it than we can make it.
Currently our system is something like this:
- Asset locations are stored as records in MS SQL Server 2008 with X & Y fields for lon & lat
- AOIs are stored as polygons with geom in a simple geometry-type field, and minX,minY,maxX,maxY coordinates as attributes
- Every few minutes, we check each new record against each of the existing AOI polygons by first checking if the lat/lon is within the bounding coordinates, and if so, we apply our point-in-poly code to determine whether it's really inside the polygon
- If it is, we update the point record with the identifier of the polygon it falls inside.
At the moment we get ~10 point updates per second and check them against ~<100 polygons. In the near future, we need to be able to scale up to checking hundreds of point updates per second against up to 10,000 polygons. Our tests indicate that our current system's not going to be fast enough, and that our point-in-polygon code is the bottleneck.
It's been proposed we use Esri's ArcGIS Server software to perform this check. We have access to the software to do a proof-of-concept run. The thing I'm sticking on is exactly how to integrate it into our workflow. Would we hit the GeometryService using a HTTP request? If so, would we first have to translate our point and polygon geometry to JSON and interpret the response? Would we have to do that for every point, and every polygon? If so, it seems this overhead would likely outweigh any gain in processing speed from using Esri's geometry service (but that's an assumption).
Alternatively, would we set up the server to have full awareness of our existing database and use some kind of map/geoprocessing service perform the query? On the surface, that seems like it would be roughly equivalent to building a tesla coil to kill a fly.
Generally, I've got that "surely it can't be that hard" feeling. I'm assuming this is a bread-and-butter use case for GIS, but I'm having trouble finding implementational details. I suspect there's some obvious thing that I'm missing, but it'd also be useful to hear "you've got the right idea, it's not as overkill as it seems". So, any thoughts would be appreciated.
It's worth making explicit that although we have access to the Esri suite to test, and are somewhat interested in the other functionality it provides, if there's an easier/more efficient non-Esri solution to our immediate need it will win out, so I'd appreciate that advice too.
Best Answer
If you're using SQL Server 2008, you should look into the built-in spatial functionalities - I think you find them quite snappy. Look at the
STIntersects()method in particular. Everything you need to do could be easily wrapped up in a stored procedure - the testing of the geometries against one another (is this point in this polygon) followed by setting the flag on the point record.