topic Re: Documentation Motion Calculator in ArcGIS GeoEvent Server Questions

Documentation Motion Calculator

DriesHerzeel — Wed, 20 Jan 2016 13:43:09 GMT

Hi,

using ESRI's sample processor 'Motion Calculator', we see unexpected results in the outcome data. I guess this is due to misconfigurations. However, no documentation or explanation is available (or I can't find it).

Could the configuration parameters be documented or briefly explained?

In what unit is speed defined?

Thx in advance!

Best regards,

Dries

Re: Documentation Motion Calculator

XanderBakker — Wed, 20 Jan 2016 15:38:39 GMT

indeed the documentation is lacking on this topic, no hits when searching for "motion". The documentation included on the server where you have installed GeoEvent Extension does not include it in the Processors help page:

http://YourServerName:6080/arcgis/help/en/index.html#/Processors/02sq0000003r000000/

The online help does not include it either.

Processors—Real-time Data Feeds and Sensors (10.3 and 10.3.1) | ArcGIS for Server

I added some feedback on that page to ask for Esri to include it in the help:

Hopefully it will be included soon.

Re: Documentation Motion Calculator

XanderBakker — Wed, 20 Jan 2016 15:42:48 GMT

Maybe Adam Mollenkopf has a moment to shed some light on the configuration of this processor?

Re: Documentation Motion Calculator

DriesHerzeel — Thu, 21 Jan 2016 10:43:53 GMT

Or maybe RJ Sunderman has a moment, he provided lots of helpful answers before?

Re: Documentation Motion Calculator

MorakotPilouk — Fri, 22 Jan 2016 19:06:45 GMT

The speed unit is the same as the selected distance unit per hour, e.g. Kilometers/hour, Miles/hour. The calculation relies on the temporal order of the incoming messages. It may provide strange results in case of store-and-forward messages where message timestamps were in the past. Small time span may also results in very large number.

Please note that these calculations don't work well if the incoming messages are from the GeoEvent Simulator with overridden timestamp at the data rate not matching the real world rate during data capture because the calculated timespan between two consecutive messages won't reflect the actual timespan.