Select to view content in your preferred language

Buffering a Point Feature

3911
8
05-16-2014 02:54 PM
TomFlahive
New Contributor III
In the GeoEvent Processor, is it possible to take a point feature as an input, buffer it, and then output it as a polygon?  The scenario is this: a user collects a point location in the field along with filling out a buffer distance.  We would then like to buffer that point by the distance specified and output it to a feature layer.

Thanks.

Tom
0 Kudos
8 Replies
RJSunderman
Esri Regular Contributor
Hello Tom -

There are examples of a couple custom processors on the Esri" rel="nofollow" target="_blank">http://links.esri.com/geoevent-gallery]Esri Gallery along with the different connectors and product tutorials. I think the Processor" rel="nofollow" target="_blank">http://www.arcgis.com/home/item.html?id=a2f546a5cbb54e32a3... - Geometry Processors for GeoEvent Processor offering might be what you are looking for.

- RJ
0 Kudos
TomFlahive
New Contributor III
Thanks RJ, the Geometry Processors look like what we need.  But I am having trouble installing these custom processors.  Do I need to go through the whole build and install instructions which are listed on the GitHub site (link), or are those steps only required if you are trying to build the .jar files from the GitHub source files?  The download link you provided me with already has the .jar files available, so I thought that means I could skip the build steps and just use the output .jar files.  But I didn't have any luck doing that.

The requirements for the build and install steps on the GitHub site have a link to another project called "solutions-geoevent-java" (link) that has its own install steps.  These include installing the followng:

    ArcGIS Geoevent Server Software Development Kit (SDK)
    Java Development Kit (JDK) 1.6 or greater
    Apache Maven
Do I need to go through all steps on the "solutions-geoevent-java" project, and then all the steps on the "solutions-geoevent-java" project to use these custom processors?

Thanks.
0 Kudos
RJSunderman
Esri Regular Contributor
Hello Tom -

No, you should not need to build the source from the GitHub site. Not unless you find that the sample is not doing precisely what you want and you want to modify the source to customize the processor sample.

If copying the JAR files extracted from the 10.2.x ZIP archive downloaded from the Gallery into the GeoEvent Processor's ...\deploy folder does not work, you might try explicitly adding them using the Manager:

1)  Launch GeoEvent Processor Manager
2)  Navigate to Site > Components > Processors and click 'Add Local Processor'
3)  Locate the buffer-processor-10.2.0.jar extracted from the 10.2.x ZIP archive downloaded from the Gallery
4)  Click 'Add' to add the selected JAR to the GeoEvent Processor framework

You should see a message at the top of the Manager indicating that the custom processor was loaded successfully. If the BufferProcessor does not display in the Site > Components > Processors list after a few seconds, try refreshing the browser's display.

I had to download and import the GeoEventDefinitions-GeometryProcessors.xml:

5) Browse to https: //github.com/Esri/solutions-geoevent-java/tree/master/data/configurations
6) Copy the GeoEventDefinitions-GeometryProcessors.xml file content to create a local XML file on your system
7) Navigate to Site > GeoEvent Processor > Configuration Store and click 'Import Configuration'
😎 Select the GeoEventDefinitions-GeometryProcessors.xml file and click 'Import'
9) Navigate to Site > GeoEvent Processor > GeoEvent Definitions

You should see event definitions for buffer, ellipses, and rangefans listed.

From there I was able to use the GeoEvent Simulator with a configured TCP/Text inbound connector to simulate events. I designed a simple GeoEvent Service incorporating a Buffer Processor. I mainly kept the default values for the processor. I specified 2500 meters as a constant buffer radius. I accepted the default WKID values for the incoming data (whose coordinates are WGS84), processor WKID (3857 is a spherical Mercator projection popular with web services), and output (project back to WGS84).

I elected to send GeoEvents from the Buffer Processor to a GeoEvent cache, just so that I could review a JSON representation of the processor's output.

[ATTACH=CONFIG]33939[/ATTACH]
0 Kudos
TomFlahive
New Contributor III
OK, good, I'm glad to hear I don't need to build the source files.  I had been able to add the .jar files and they showed up.  I also had added the GeoEventDefinitions-GeometryProcessors.xml file, as you pointed out, and those geoevent definitions showed up as well. 

The part were I got stuck was building the actual GeoEvent Service.  I was doing the example on the GitHub page for the Range Fan Processor, and when I got to the point where I set up the Processor properties, I was not seeing the properties that are prefixed with rangefans: in the drop down lists, e.g. rangefans:range, rangefans:bearing, and rangefans:traversal.  Here is what they look like in the GitHub example:

[ATTACH=CONFIG]33950[/ATTACH]

When I didn't see those values in the dropdown, that's when I thought that maybe I had to install the tools mentioned above.

Where do the rangefans drop down values come from, and would you know why I am not seeing them?  I don't have the Geoevent Server SDK installed.  Is that required?

Thanks.

Tom
0 Kudos
RJSunderman
Esri Regular Contributor
Hey Tom -

Sorry for the delay in getting back with you.


Where do the rangefans drop down values come from, and would you know why I am not seeing them? I don't have the Geoevent Server SDK installed. Is that required? 


I believe the drop down values in the screenshot you provided are coming from the rangefans GeoEvent Definition.
[ATTACH=CONFIG]34049[/ATTACH]

When selecting 'Event' rather than 'Constant' for the 'Range Source' ... the 'Range Fan Field' should display a list of event fields for available GeoEvent Definitions. At least that is the behavior I see with my 10.2.2 instance of GeoEvent Processor. The list items you are referring to - rangefans:range, rangefans:bearing, rangefans:traversal, etc. - are different fields in the rangefans GeoEvent Definition. You should not need the GeoEvent Processor or ArcGIS for Server SDK installed to exercise the custom processors example.

I initally thought that the screenshot in your message was one from your system, not a snip from the GitHub example page, so I prepared an instance of GeoEvent Processor 10.2.0, loaded the rangefan-processor-10.2.0.jar into the GEP framework and imported the GeoEventDefinitions-GeometryProcessors.xml configuration. I confirmed that the rangefans event definition was loaded, but when I tried to configure a 'Range Fan' processor in the Service Designer I did not see items in the event fields list for the rangefans event definition ... the only items in the list appeared to map to the incident event definition which gets installed with GEP.

What release of GeoEvent Processor are you running?

If you browse to the product's admin page for the installed processors ... what do you see for the RangeFanProcessor?

1) Browse to: https: //<host>:6143/geoevent/manager/version.txt to verify your version of GEP.
2) Browse to: https: //<host>:6143/geoevent/admin/processors
3) Click the JSON link at the top of the page and search for "name": "RangeFanProcessor"

I've highlighted code in the following block you should look for:

{
    "name": "RangeFanProcessor",
    "label": "Range Fan Processor",
    "contact": "geoeventprocessor@esri.com",
    "description": "Returns range fan derived from event center, range, bearing, and traversal angle",
    "version": "10.2.0",
    "domain": "com.esri.geoevent.solutions.processor.geometry",
    "lastModified": "1393882661559",
    "propertyDefinitions": [
        {
            "propertyName": "rangeSource",
            "label": "Range Source",
            "description": "Source of range Value",
            "propertyType": "String",
            "defaultValue": "",
            "mandatory": true,
            "readOnly": false,
            "displayOption": "",
            "dependsOn": "",
            "allowedValues": [
                "Constant",
                "Event"
            ]
        },
        {
            "propertyName": "range",
            "label": "Range",
            "description": "Maximum distance from event for analysis",
            "propertyType": "Double",
            "defaultValue": "1000.0",
            "mandatory": true,
            "readOnly": false,
            "displayOption": "",
            "dependsOn": "rangeSource=Constant"
        },
        {
            "propertyName": "rangeEvent",
            "label": "Range Event Field",
            "description": "Geoevent field containing range data",
            "propertyType": "String",
            "defaultValue": "",
            "mandatory": true,
            "readOnly": false,
            "displayOption": "",
            "dependsOn": "rangeSource=Event",
            "allowedValues": [
                "rangefans:event_id",
                "rangefans:x",
                "rangefans:y",
                "rangefans:z",
                "rangefans:geo",
                "rangefans:range",
                "rangefans:bearing",
                "rangefans:traversal",
                "rangefans:date",
                "rangefans:geodef",
                "buffer:eventid",
                "buffer:x",
                "buffer:y",
                "buffer:z",
                "buffer:radius",
                "buffer:date",
                "buffer:geodef",
                "TrackGap:trackId",
                "TrackGap:gap",
                "TrackGap:lastReceived",
                "TrackGap:geometry",
                "Flights-TcpText:FlightNumber",
                "Flights-TcpText:StartTime",
                "Flights-TcpText:OriginAirportCode",
                "Flights-TcpText:DestinationAirportCode",
                "Flights-TcpText:AircraftType",
                "Flights-TcpText:Altitude",
                "Flights-TcpText:Longitude",
                "Flights-TcpText:Latitude",
                "Flights-TcpText:geometry",
                "Flights:FlightNumber",
                "Flights:StartTime",
                "Flights:OriginAirportCode",
                "Flights:DestinationAirportCode",
                "Flights:AircraftType",
                "Flights:Altitude",
                "Flights:geometry",
                "ellipses:eventid",
                "ellipses:x",
                "ellipses:y",
                "ellipses:z",
                "ellipses:geo",
                "ellipses:major_axis",
                "ellipses:minor_axis",
                "ellipses:rotation",
                "ellipses:date",
                "ellipses:geodef"
            ]
        },
...


Notice beneath the rangeEvent property that a full set of the GeoEvent Defintions known to GeoEvent Processor are displayed along with all of their event fields. To confirm this I stopped my 10.2.2 instance and spun back up my 10.2.0 instance ... and there they were. When I re-launched Service Designer I was able to see them when configuring a Range Fan processor.

[ATTACH=CONFIG]34048[/ATTACH]

Long story short ... try stopping and restarting your GeoEvent Processor then rechecking the admin page to review the processor's JSON definition. If the JSON lists the rangefans event fields as allowed values, you should see them when configuring a Range Fan processor.

- RJ
0 Kudos
TomFlahive
New Contributor III
RJ,

Stopping and starting the GeoEvent Processor did the trick!  I checked the /admin/processors code before stopping the service and the needed allowedValues were missing.  But after stopping and restarting the GEP, the allowedValues showed up.  I was able to complete the rangefans test from the GitHub site successfully!  Thanks for working through that problem and figuring out the issue.  I appreciate that.

I am 90% of the way there with one more hurtle to jump.  My original post was asking about buffering a point.  So I would assume I set up the buffer processor very similar to the rangefan processor example.  If I change the Radius Source to Event, do I then pick the buffer:radius for the Major Axis Event Field?  If so, how does the processor know what distance to buffer the point by?

Here is my current set-up:

[ATTACH=CONFIG]34054[/ATTACH]

Thanks.

Tom
0 Kudos
RJSunderman
Esri Regular Contributor
Tom -

If I understand the idea behind the sample, rather than restricting the Buffer processor to a static distance when creating a buffer about received events, the implementation allows a distance value to be retrieved from the incoming event. I'm assuming that the buffer GeoEvent Definition is something used internally by the custom Buffer processor ... so no, I would not specify 'buffer:radius' for the buffer distance I wanted the processor to use.

Based on the user interface's behavior, it appears that specifying 'Constant' for the 'Radius Source' parameter allows you to specify a constant buffer distance; the processor then uses that static distance to buffer every received event. Specifying 'Event' for the 'Radius Source' parameter causes the UI to change such that an event field - presumably from the event being processed - is specified; the processor should then obtain the buffer distance from the specified event field. (I'm not sure why the label on the processor's property configuration page changes from Radius to Major Axis Event Field when toggling between 'Constant' and 'Event'...)

If, for example, I have a GeoEvent Definition Flights-TcpText with event attributes FlightNumber, Origin Airport, Altitude, and BufferDist ... rather than buffering all flight positions by a fixed value (e.g. '1500' and 'Meters') ... I can allow each event to specify the desired buffer distance by specifying 'Flights-TcpText:BufferDist' as the field from which a more dynamic buffering distance can be retrieved. It appears that only the numeric value can be retrieved from the event however; you still have to select a unit of measure such as 'Meters' when configuring the processor.

By the way - I had some trouble getting this to work. I had to stop/restart GeoEvent Processor to get the Buffer processor to recognize that I had updated my GeoEvent Definition to include a BufferDist with each incoming event. Then, at first, specifying 'Flights-TcpText:BufferDist' didn't seem to be working to retrieve the desired buffer distance from each event ... only specifying constant buffer distances worked. Later, after I had tried several things including changing the GeoEvent Definition's data type for BufferDist from Long to Double ... it started working. I'm not sure if changing the event's data type was the key to get it working however...

Please be aware that we are working with a sample custom processor here. This was something prepared by one of the industry solution teams within Esri, not the GeoEvent Processor team, so I'm not working directly with the developer who implemented the processor. The GeoEvent Processor team is working to develop several new spatial processors for the core GeoEvent Product. These should be available with the upcoming 10.3 product release. Perhaps if we cannot get the sample custom processor to do what you need it to do, the processor being developed for the core product will work better for you.

- RJ
0 Kudos
TomFlahive
New Contributor III
Thanks for another thorough reply RJ.  Like you, I was able to get the buffer working by supplying a constant value.  Like you, I also had problems with the GeoEvent definitions not showing up at first.  But starting and stopping the GeoEvent Processor caused the correct defections to show up.  And also like you, the GEP did not seem to be interpreting the buffer distance value correctly from the field I specified, even though it was of type Double.  Buffer features were being created, but with no area.  I tried several things hoping it would magically start working as it did for you, but no luck.

Since it sounds like there might be an official buffer tool coming out with the 10.3 release, I think I will just wait for that and create the buffers manually for now.

Thanks again.

Tom
0 Kudos