Select to view content in your preferred language

Geocoding Event Locations

3064
2
05-20-2014 06:18 AM
RobLammle
New Contributor
We are using GeoEvent Processor to monitor the location and operation of our garbage trucks.  If a truck is unable to collect garbage from a resident - for example, the can wasn't out at the curb - the driver creates a point at his location and, using a drop-down menu of common problems, explains why he wasn't able to collect.  This point is recognized by the GeoEvent Processor and an email alert is sent to a few different people.  However, the alert only shows that a point was created and why the garbage was not collected.  If you aren't sitting in front of the map, you have no idea where the garbage was not collected.   

Is there any way to geocode the newly created point, or retrieve the address from our existing parcel layer, and attach that information to the alert?  That way instead of the alert email just saying:

"Garbage was not collected because the can was not at the curb"

it will read:

"Garbage was not collected at 100 N. Main St. because the can was not at the curb".
0 Kudos
2 Replies
MarkBramer
Frequent Contributor
Hi Rob,

Yes, this is possible in one of two ways (at least that I can think of). 

#1.  If your parcel layer's parcel polygons will always contain the location of a garbage truck at any particular time, you could use your parcels as geofences in GeoEvent Processor, and rely on the Geotagger processor to obtain the address.  When each message comes into GeoEvent Processor with an x,y coordinate, the Geotagger processor can obtain the address from the parcel polygon in which the truck's x,y coordinate is located (point-in-polygon).  This depends on some things and may not be feasible: 1: a garbage truck must be inside a parcel polygon when the event is created, 2: your parcel layer must be of a manageable size for GeoEvent Processor to handle the polygons as geofences.  I do not know of any official limits, so you'd have to experiment.  Regarding the trucks always falling within a parcel polygon, this would require your parcel boundaries to extend to the street centerlines, and also depend on the accuracy of the location device in each truck.  If your parcel boundaries end at the curb (which is common), then a truck on the street wouldn't fall in a parcel boundary, which would make this whole method not feasible.  If the parcel boundaries do meet at the street centerlines, but the accuracy of the truck location devices is questionable, then an incorrect parcel polygon may be selected by the point-in-polygon process executed by the Geotagger processor.

#2.  You could call an external reverse geocoding service to retrieve the street address using the x,y coordinate.  This is not out-of-box yet, but I know a lot of people have requested it.  There could be a custom processor on GitHub that does this, and RJ may be able to speak of any plans the GEP team may have to build processors to make external calls and consume the results.

Mark
0 Kudos
RJSunderman
Esri Regular Contributor
Rob -

In the driver's workflow, how is the point getting created which identifies the truck's current location? Mark is correct that if an AVL transponder is feeding vehicle locations to GeoEvent Processor, then it might be difficult to guarantee that the vehicle location being reported would be within a parcel boundary.

However, if the driver were using some sort of in-cab application to select a location on a map, then it would be easy enough to have the driver click the rooftop of the house whose trash can was absent. That should allow a GeoEvent Processor setup which polls the feature service in which the point was created, discover (using a GeoTagger) that the point is inside a GeoFence (imported from a dataset of parcel polygons), enrich the geotagged event with an address retrieved from a String attribute field in the parcel dataset feature service, and then send a notification to identified stakeholders.

The other approach, feeding the vehicle's location to an external reverse geocoding service, is something we have been asked to support. It is in our product backlog, but unfortunately it is not something that we have been able to assign to an upcoming development iteration. The invocation of external services, especially those with significant latency such as geocoding, tends to run afoul of the product vision - providing processors with minimal latency and avoiding bottlenecks which prevent high volume, real-time, event processing.

If it is compatible with your workflow, I think an approach which integrates an application such as the ArcGIS Collector to create point features which GEP can then poll, geotag, and enrich would be better. You can find some additional information on how to do this [url=http://forums.arcgis.com/threads/100211-GeoTagging-several-fields-from-one-geo-fence]here[/url].

Hope this information helps -
RJ
0 Kudos