Changing polygon 'status'

[JeroenOomkens]

Hi All!

Recently I successfully completed the tutorial of the GEP, and started my own little project. The situation is as followed:

I have a stationary feature, and I want to change its status (Lets say like a traffic light - red, orange and green). This feature contains a field that supposedly is able to update. 

What do I got so far:
1. I got a CSV file that contains data without spatial reference.
2. I published one polygon that I want to change status according to the fed data.
3. In the service designer I created the TCP input, made 3 filters for the status red, orange and green. (These work when I connect them to file-out). And added an updatefeature output to each of them.

And now it becomes a bit messy, or better said, I get confused. I there some kind of tutorial or example that handles static features?

Thanks!

[RJSunderman]

Hello -

Since you only want to update the "status"�, not the geometry of the stationary polygon feature, I"?d recommend taking a more generic approach than the one presented in the Introduction tutorial.

Most of the exercises in the tutorial use exactly one GeoEvent definition. This works when the input has the same fields, with the same data types, in the same order as the output. This is done so that an exercise can focus on a particular bit of functionality without complicating the exercise with multiple event definitions.

However, using a single GeoEvent Definition is not as common a case as you might think. In your case, you don"?t need to update the geometry, just the status. So we"?ll prepare one GeoEvent Definition for the schema of the input and a second GeoEvent Definition for the target "? the feature layer you want to update.

The first GED we"?ll call EventStatus-Input. The CSV file I"?m using to simulate events looks something like:

• Alpha,8/25/2012 13:21:36 PM,1


• Bravo,8/25/2012 13:23:52 PM,1


• Charlie,8/25/2012 13:26:11 PM,1


• Delta,8/25/2012 13:29:15 PM,1


• Echo,8/25/2012 13:31:30 PM,1


• "�

So I need a GeoEvent Definition with three fields:  TrackId, DateTime, CodedValue

The second GED is imported from a published feature layer named "?UpdatePolyStatus"?. The feature layer only has two attributes:  Name, and StatusCode. Of course when I import the GED a get a third field named "?shape"?.  In your case we don"?t want to use GEP to update the shape/geometry, so we edit the imported GED and delete that field.

Now, we have two event definitions which don"?t look much like one another, so when we design our GeoEvent Service we will need to include a Field Mapper (see illustration below):
[ATTACH=CONFIG]29512[/ATTACH]

It is important to recognize that the target feature layer has an attribute field which uniquely identifies each feature/record. In this example the received "TrackId"� value "? "?Alpha"?, "?Bravo"?, "?Charlie"?, etc. "? maps to the 'Name' field specified as the Unique Feature Identifier Field when configuring the Output connector. GeoEvent Processor will look for features (polygons in this case) whose "?Name"? matches a received "?TrackId"? and will then update that record"?s "?StatusCode"? with the received "?CodedValue"?.

My target feature layer"?s symbology was configured to use StatusCode to select a color for each polygon. I verified that as data received by GeoEvent Processor was used to update a polygon"?s attribute value, refreshing the map display would update the map to display the polygon using the color which corresponded to the StatusCode for that feature. If my data feed had the coordinate values for each polygon's vertex correctly formatted within a Geometry, I could use GeoEvent Processor to update the position and/or shape of each polygon, but for this example we wanted to leave the polygon's static and only update their status attribute.

Hope this helps "?
RJ

[JeroenOomkens]

Thank RJ

This helped quiet a bit. However I still have one uncertainty about creating the feature. So what you say, you will create a feature within arcmap with the two attributes 'Name, StatusCode'. Also you have to add symbology accordingly to the 'StatusCode', than publish this service. But why delete the shape, where is the information stored about the shape that is in this service?

[RJSunderman]

...you will create a feature within arcmap with the two attributes 'Name, StatusCode'. Also you have to add symbology accordingly to the 'StatusCode' ...

I was assuming that the location of the static/stationary polygon(s) are well-known. The event data being received in my example does not contain any location or geographic information, just attribute values to use to update a target. So I was using ArcMap to author a map document which contained the well-known polygon(s). I was publishing a feature service because we need the feature access capability enabled in order to use GeoEvent Processor to update the attribute values of the named feature(s). Configuring the display to render/stylize the polygon based on the 'StatusCode' is completely optional. It was just an easy, visual way of quickly determining that the polygon's status was being updated as I fed events into GeoEvent Processor.

But why delete the shape, where is the information stored about the shape that is in this service?

Keep in mind that whatever fields exist in the GeoEvent Definition received by the Output connector responsible for updating the feature service - in my example this would be the fs-out connector - will be used to update the targeted feature service. So if my input events had fields 'Name' and 'StatusCode' ... I wouldn't need a field mapper. If the input had a field named 'shape' this would be bad; I don't want the event to drive updates to the static/stationary geometry. In my example the only attribute data I had to work with was a name, a date/time, and a status. Since the output target has a name, a status, and a shape ... if I use a field mapper with the feature service's full schema, I would have a destination field 'shape' with no corresponding source field. So I elected to delete 'shape' from the imported GeoEvent Definition to make the field mapping cleaner and make clear that the GeoEvent Service is only updating the attribute values specified in the field mapper processor.

- RJ