Latest Contributions by GregoryChristakos

Hi @TylerKiehle1 - There's no specific delay setting but there are two options you could consider: 1. Create a staging folder that GeoEvent doesn't look at. Once the file has been written entirely to the staging folder, you can use a script or something similar to move it to the folder that GeoEvent is looking at and will start reading from. 2. You can configure GeoEvent to look for a file of a specific name. Once Pi creates and writes all of its data to this file, use some sort of task/script to change the name to the specific one that GeoEvent is looking for. ... View more

Hi @Moi_Nccncc - Yes you can if you're using a geofence synchronization rule on a feature or stream service and you have a string type field in your data whose literal string values are either true or false. Assuming you've met this criteria, you can configure your geofence sync rule to use that said field as the "active field". Feature records whose active field value are "true" will continue to be used as geofences. Those that are "false" will not be used as geofences for further processing. I've included a screenshot below of what I am talking about in the sync rule settings: If you have all this in place, you can configure a GeoEvent service to process geofence records and use different logic paths to set the active field value to true or false based on your needs. It's worth noting that you can also control whether or not a geofence is active based on time extents as well, but the tried and true method is going to be to use the active field property. ... View more

If I were in your shoes, I would give it a try but obviously there are other details to consider (e.g. what resources are available on the machine, is GeoEvent Server competing for those resources, are other inputs/outputs/GeoEvent services running on your instance of GeoEvent Server, etc). At a glance... 1. 1,500 point geofences doesn't seem alarmingly high. They have simple geometries (x,y) which is a major plus. I'd be more concerned if you had 1,500 complex polygons (i.e. high vertices count). 2. Updating those AVL "geofences" every minute doesn't seem all that bad either. That is within the scope of what a stream service (for a sync rule) could support (but again, this is based on the other factors I mentioned above). 3. This is the biggest question; how many areas are there? Are they complex polygons? How frequently are you looking to check them for truck intersection? If they're simple polygons, there aren't many, and you only need to see their point-in-time status once every minute or so, this could work. If your answer is the opposite (i.e. they are all complex polygons, you have hundreds instead of dozens, and you need them updated every 5 seconds, then that could be an issue where you see performance bog down some and not keep up in real-time). Again, if I were in your shoes I would put together a pseudo proof of concept and see how it works for you. That's really the best way to know for certain (especially because there are other factors that could be at play like I mentioned above that I am personally not aware of). In the event that you find its not what you want, there can be other ways to potentially go about your problem. For example you could track the trucks again and geotag them with the name of the geofence area they intersect with. In another field you could have the name of the area they're assigned to. If the geofence (geotag) name field == the assigned area name, there might be a way to use that condition to affect another GeoEvent Service to update a separate areas dataset to have an area status set to covered. This might require some more tinkering/logic though. ... View more

@Moi_Nccncc - I assume that the areas are (or can be) geofences coming from a feature layer or stream layer? If this is true, you can ingest the areas every "x" seconds or minutes from this feature layer using an input connector (e.g. poll an arcgis server for features). Simultaneously, you have your truck data coming in somehow. You can push those trucks to a stream layer & use said stream layer (via a geofence synchronization rule) to act as point geofences that are updating frequently.  With this setup, you can begin to answer real-time questions such as "when does my area (polygon event), contain a truck (point geofence)?". You can refine this even further; "when does my area (site "xyz"), contain a truck (of type "Alpha")? If the truck is of type "Alpha", consider area xyz fully covered. However, if the truck is of type "Beta", consider area xyz half covered.    To me it sounds like you're not trying to capture the status of the truck, but rather the status of the area based on its interaction with the truck if that makes sense. I hope this helps but let me know if it does not. ... View more

Hi @YObaidat - As an out-of-the-box capability, the answer is no. That's not to say its impossible however. Rather, its likely that you would need to develop a custom transport/adaptor for handling messages via thread in the format/protocol of matter. An alternative solution would be to push these messages to some other endpoint or broker that GeoEvent can then tap into with an out-of-the-box connector (e.g. Kafka). ... View more

Hi@meb323 - It could be that the token error means the service isn't accessible since the credentials to ArcGIS Online (where I presume the service is?) are bad. You'd want to check your GeoEvent data store connections & credentials to see whether or not your connection to ArcGIS Online validates. It could be that the credentials you provided have access to reading the service, but not writing to it. Just something else to consider. Assuming the credentials are good, you own the service, and that you can edit the service, my next suggestion would be to ensure you have your TRACK_ID tags set correctly. You might know that the feature record  for car with plate "ABC321" was updated, and should then be updated in the output feature layer as such, but GeoEvent doesn't necessarily know which field value its supposed to use to uniquely identify and manage each record on output so they're all just "cars" if that makes sense. Make sure your input connector definition has a field set with the TRACK_ID tag set to unique identify and manage records from one another in the pipeline of your GeoEvent Service. If this definition is the same one used for the output connector, you should be good to go. If you somehow have a different definition for the output connector, make sure that output definition has the TRACK_ID tag appropriately set to the correct field too. Putting this back into the context of an example, the correct usage of a TRACK_ID will let GeoEvent know that it needs to update the record whose plate is "ABC321" with the values it processed in the output feature service. For more, check out this doc. I hope this helps and makes sense but please don't hesitate to message me if it doesn't. It could be that the issue is none of what I mentioned in which case I might suggest reaching out to Support Services for further investigation. ... View more

Hi @Moi_Nccncc - It might be worth taking a look at the karaf logs from the system directly. You can find these via C:\Program Files\ArcGIS\Server\GeoEvent\data\log. I am willing to bet there are messages indicating kafka issues with finding various topics and what not. If that is the case, your best bet is going to be doing an admin reset. Make sure you get a backup of your GeoEvent Server configuration first. None of what I suggested above speaks to what caused the issue to begin with, but it should hopefully get you going again.  If the issue persists, I would recommend reaching out to Support Services so that we can take a deeper look at what is amiss. Hope this helps! ... View more

Hi @MANESK - There's a few things you could try here: 1. If you can afford it, try pre-filtering the data so that you're only bringing in the data that matters, thereby shrinking the payload. 2. You could try increasing the polling interval to give GeoEvent Server more time to process the incoming records as events. 3. You could consider increasing the input buffer capacity. By default its 20MB but increasing it might prevent the overflow from happening for a time. This is a setting in GeoEvent Manager > site > settings. Check out this page. 4. It could be worth checking out how much RAM is available on the machine where GeoEvent Server is running and whether or not GeoEvent Server is having to compete with other processes that are also consuming RAM. ... View more

Hi @Moi_Nccncc - I would recommend checking out this blog. ... View more

Hi @Moi_Nccncc - This'll sound odd but you might want to flip this problem on its head. Rather than tracking the trucks, track the areas. If an area (the event) has a truck of type <A> inside of it, mark that area as "fully covered". If the same area (the event) has a truck of type <B> inside of it, mark that areas as "partly covered". The area (the event) can be, by default, not covered until it has a truck reported inside of it. Hope this helps! ... View more

Hi @Nadiia_Matsiuk - At a glance it looks like there's a certificate/trust problem here. When you access GeoEvent Manager on the machine where GeoEvent Server is installed, does the browser present you with certificate errors? If not, can the same be said when accessing GeoEvent Manager from another machine entirely? I often found that a failure to subscribe to a Stream Service is 9 out of 10 times due to SSL/trust and your errors seem to indicate this.  This is likely going to require a deeper dive into your environment to resolve, and so I would definitely recommend reaching out to our Support Services for assistance, but just off the cuff here, here are some things I would look into if I were in your shoes: 1. Ensure you have the latest patch installed for 10.9.1. This would be patch 4. We did some work on stream services as a part of this cumulative patch. None of the issues are directly related to what you're reporting, but this is a good start nonetheless. 2. If you can hit GeoEvent Manager and are getting SSL/certificate errors in the browser, I would look into addressing this. If you have a domain certificate you can work with, that is by far more preferable than using a self signed certificate. I often tell folks that a self signed certificate is analogous to writing your name on a piece of paper and trying to get through airport security with it as a method of identification. Its really only good for you, or to bring this back to GeoEvent Server, its only good for doing anything on the machine/browser where GeoEvent is installed and running. Forcing the browser to "trust" the self signed certificate isn't guaranteed to work either unfortunately. - It'll be telling pretty quick if you can subscribe to the stream service from the browser where GeoEvent is installed/running, but cannot from anywhere else. 3. If you are using a domain level certificate, make sure you have the entire certificate chain imported into the ArcGIS Server admin endpoint. The root, any intermediates, and the cert itself. I've seen issues where just bringing in the cert alone isn't sufficient for establishing the chain of trust. 4. This might be a given, but did you try restarting GeoEvent Server following the certificate import you did on ArcGIS Server? Can you see if GeoEvent Server is presenting the new certificate when navigating to GeoEvent Manager? These are a few things I would look into checking myself, but as I said before it might be best to reach out to Support Services where an analyst can take each of these suggestions further as needed. Hope this helps.   ... View more

@Moi_Nccncc - There isn't a gallery of templated or example GeoEvent Services currently but this is something the Real-Time team can look into offering on the GeoEvent Server Gallery if there's enough interest from the broader community. I suggest posting this idea to our Ideas page if you haven't already! In the short term, I would recommend checking out some of the various recorded GeoEvent Server sessions from past conferences. Our "Applying Real-Time Analytics" line of sessions usually delve into GeoEvent Service design and demonstrations.  ... View more

@Moi_Nccncc - Incidents from the Incident Detector are managed in a separate cache/queue across all GeoEvent Services. The only way these incidents can be lost is by restarting the GeoEvent Server services (Windows services) or by restarting the machine where GeoEvent Server is running. Stopping and starting a GeoEvent Service, or republishing a GeoEvent Service isn't going to purge these incidents. Given this information, you should be able to update your GeoEvent Services per the normal pattern of use. In certain situations where an Incident isn't making logical sense anymore (e.g. an Incident is reported as ongoing from before the change, and you're trying to test/confirm that your latest changes are working and so the incident should be closed), it can be advantageous to restart GeoEvent Server too. ... View more

Hi @Moi_Nccncc - You might want to look into using the Track Idle Detector Processor from the GeoEvent Server Gallery for this scenario. You can easily download and deploy it from the Gallery Add On Manager via GeoEvent Manager, or manually download and install it from here. Track Idle is designed to monitor whether an event has moved or not. You could use this event to then trigger an incident with the incident detector per your criteria (e.g. expire the incident after 5 mins, or close it if the track idle detector passes along an event indicating movement has occurred).  You could apply the logic to your second scenario as well. If the incident is ongoing for more than 5 minutes, pass that along to a buffer processor and create a geofence via a sync rule. These geofences could then be used for the third scenario (i.e. monitor for ongoing incidents). What you're describing is within the realm of doable/possible and I think you're on the right track. All I would add here is that the Track Idle detector might make your life easier when monitoring for movement (or lack thereof). ... View more