I have a process that is triggered by a Lidar file being written to a folder. I want to write a custom processor that will read the spatial footprint of the file then use the abilities of Geo Event Processor to operate on that footprint and possibly do some additional automation on the file. From what I can see, GeoEvent Processor is not designed for working with the large lidar files and the file transport will immediately start reading the file into a buffer. As an alternative, I am thinking of writing a custom transport to just read the file name. From there custom process tasks can use JNI to call into C++ libraries for manipulating the large files.
Am I trying too hard to make a tool do something it isn't meant to do?
Can anyone point me toward an example of a customized file watching transport that I can build upon?
My backup plan is to write a separate service that monitors a folder and does the initial Lidar file manipulation, then calls into GeoEvent server and passes the file path and footprint data. The down side is that then I loose many benefits of GeoEvent Server including tracking and logging the full workflow and I end up with multiple points of failure.
Thank you for any help or feedback you can provide.
My quest continues. I now have a working file name transport. The next step is to create a processor to generate a footprint polygon and use that to pull a list of features from a feature service.
I made it to the point of trying to use a custom processor to call into C++ native functions using JNI. I could make that work on stand alone java applications, but I couldn't figure out how to get the server to allow me to link to my native library.
I spent several days digging into how this is done in Karaf and other OSGI servers and was able to find that placing my linked DLL in <serverpath>/lib seemed to allow me to construct a static class with the native functions, but then calling a native function always resulted in a java linking exception.I am guessing I need to add <Bundle-NativeCode> to the instructions on the felix plugin in the POM.XML file so that they end up in the manifest used during object construction, but I never was able to compile with this in place. It may have been something as simple as needing to include a reference somehow. I can provide more details if anyone is interested in helping troubleshoot further.
In the end, I've run out of time for this experiment so I am setting GeoEvent Processor aside and building this Lidar workflow entirely in a C++ executable. If this project continues to advance I'll probably pick it back up in a few weeks when the workflow hits a point of needing more real-time processing and data flow management.