During one of my experiments with
GeoEvent Server GeoEvent Extension for Server, I needed to test out real-time streaming. Having only dabbled with JSON before, it was time for me to get real. To Python!
I’d like to point out that even though I only wrote this script 4 months ago, I’ve learned enough in the meantime to want to rewrite this script. I’d still like to walk it through it though, because the tweaks I would like to make to it are more optimisations/best practice than fixing any bugs.
IIRC, this was my first dalliance with the delightful requests module. In Line 22, I used the url provided by GeoEvent after setting up a “Receive Features on a REST Endpoint” input connector. In Line 23, I manually entered an extent I had determined using a technique I like to call “looking at it in ArcMap”. This extent is used in the Create Random Points geoprocessing tool to constrain the area in which random points would be created.
(I’ve been moving away from using geoprocessing tools available in arcpy, in favour of pure Python. Instead of calling the Create Random Points tool, I would rather use the random tool to generate the coordinates and then physically build the point geometries.)
In the search cursor, after processing every row as JSON and assigning a random label, the JSON is POSTed. What this does mean is that the REST service is going to get hammered with those points one after the other. For testing purposes, only a small set of points were generated, and the server can easily handle the load.
What if, in some future scenario, I have (hundreds of) thousands of points trying to get through at the same time? I can’t easily think of such a scenario, but since I’ve been moving more and more into development, I’d like to keep these things in mind.