Latest Contributions by ChristopherDufault

I am attempting to update a Feature Service in a 10.7.1 Enterprise, with ArcGIS for Python Api. The Feature Service is backed by a EGDB. When I run with the following code I get an error. I have logged in as an admin. Actually the same admin user that created the feature service. When it gets to line 6 the error is thrown. Everything up to that comes back as expected.  ... 1. search_results = gis.content.search(query='title: "'+<title>+'*" AND type: "Feature Service"') 2. feature_layer_item = search_results[0] 3. featureLayer_collection = FeatureLayerCollection.fromitem(feature_layer_item) 4. update_dict = {"enableZDefaults": True, "allowUpdateWithoutMValues": True} 5. properites = featureLayer_collection.properties 6. featureLayer_collection.manager.update_definition(update_dict) I am using this example as a guide to do this. https://developers.arcgis.com/python/guide/updating-feature-layer-properties/ Anyone encountered this and has a work around or sees my error? Thanks in advance for any help. ... View more

I have a master survey that has 3 different types of users who are supporting the survey. Each user group have different levels of access to the survey based on need to know information for each survey.  We have Portal groups for all 3 types of users giving access to specified fields in the FeatureClass that the survey is feeding and updating to. Each group is only allowed to see a sub set of all fields except for the Admin group. When I populate the survey I can make the JS Query to the feature class knowing what level the user has access to. I then only pull down the fields that user can access and populate the survey with the data they are authorized to see and update. The main question here is this.  When the user submits the survey is there a way for Survey123 to only update the fields that the user has access to? Is there a setting or some other tags we can add to our survey to do this by default for each user type? We are trying to keep it all in 1 survey instead of having to make 3 different surveys to accomplish this one task. I appreciate any help you can send my way. Also if this is in the beta and how to use it in beta would be useful also. Thank you. ... View more

Here are some tips for allocating resources to properly run a world Gazetteer GeoLocator. I started by using these tools created just for this located here Geonames Locator | ArcGIS for Defense . These were a great help but I ran in to some minor issues with this when I modified it to turn on the suggest for the GeoLocator. I found I had to update it to run in the background and install the 64bit background GP processing to my ArcMap. Once I did this I was able to create the GeoLocator with out any issues. When I went to publish it there were System Memory issues that had to be address. I found an old blog post that helped with this so I thought I would post it here for other to find.  ArcGIS locators support a “Run Time Memory Limit” parameter.  For large geocoding jobs working against a large locator such as US streets, or world, you will want to set this limit near the capabilities of the system.  With ArcGIS 10.5.1, geocoding performance continues improving as the cache grows beyond 2GB.   By default, ArcGIS locators are configured to use 1024 MB of system memory. ArcGIS supports use of 2GB memory on a 32-bit system and 3GB of memory on a 64-bit system.  There is a formula for determining out how much memory the system should have to run this kind of locator. When the RuntimeMemoryLimit is set to 2 GB then you should allocate 3 GB per locator instance (there is some additional overhead and then we round up). Additionally, you will want to have a minimum of 4 GB of RAM for ArcGIS Server. (8 instances * 3 GB) + 4 GB for Server = a minimum 28 GB of RAM required. Instructions for increasing the run time memory limit. This step must be done prior to publishing the locator as a service: Open the Gazetteer folder containing the Gazetteer locator. Open the *.loc file in a text editor (e.g. NGAGeonames.loc). Look for the line that starts with RuntimeMemoryLimit = If the value does not exist, create one and change the value to represent the number of bytes of system memory you want to allocate for the locator:  RuntimeMemoryLimit = 2048000000   Save the locator.  Open the *.loc.xml file (e.g. NGAGeonames.loc.xml).   Update each instance of “RuntimeMemoryLimit“ to 2048 MB Lastly use the locator and compare performance and system memory use. I hope you found this useful. If you have any other tuning suggestions I would love to see them in the comments.   ... View more

GeoEvent Server:  Geofence Best Practices Over the course of the last six months I have been configuring and managing a GeoEvent Server, specifically Geofences. I have learned a lot of about configuring them and how and when to use them efficiently. I felt compelled to share this with the community, to help others who are new to working with Geofences to get started. Here are the best practices I use to manage and work with Geofences effectively.   What are Geofences A “geofence” is a geometry that GeoEvent Server uses to identify a geometry of interest. Configurable filters and processors added to GeoEvent Services use geofences to determine if geometry associated with an event record shares a spatial relationship with one or more secondary geometries or “geofences”. Geofences are organized in categories; within each category every geofence must have a unique name. It is natural to think of geofences as areas modeled using polygon features, but geofences do not have to represent polygonal areas. GeoFences can, in fact, model any of the basic types of geometry exposed through a feature service: point, multipoint, polyline, or polygon. Event records received for processing typically have an associated geometry. When designing and publishing a GeoEvent Service, the filters and/or processors you configure can test to see if a particular spatial relationship returns ‘true’ or ‘false’. For example, assuming you have imported a set of geofences from polygon feature records, you can use a filter to retain (allow to pass) any event record whose associated geometry (a point) is INSIDE, OUTSIDE, ENTERING, EXITING a specified set of geofences. You can also buffer an event record’s point geometry and test to see if the area surrounding the point INTERSECTS, OVERLAPS, or is DISJOINT from a specified set of geofences. Importing Geofences When importing feature records as new geofences only the feature record’s geometry is imported along with a single attribute which is used as a unique name for the geofence. You must select an attribute, usually a String field, the import can use to uniquely name each geofence being imported. If no other suitable attribute field exists, you can use the OBJECTID to uniquely identify geofences. When specifying the category into which geofences should be imported you can select an attribute field or manually key in a string value to “hard code” the category name. The category name is technically not part of the geofence – it is used to organize geofences into groups. It is important to recognize that the general attributes associated with a feature record are not included with a GeoEvent Server geofence. Geofences only have a name and a geometry. This is by design; geofences are intentionally very lightweight. A feature record may include a rich set of attributes describing its features, but maintaining all this attribute information in-memory along with the geofence geometry would impact event record processing and throughput. When importing geofences from feature records, work to make the feature record geometries as simple as possible. Complex, multipart geometries with many thousands of vertices tend to negatively impact event record processing and throughput. Also, because geofences are maintained in-memory, you should avoid importing thousands of geofences with complex geometries (many thousands of vertices) because the complex geometry will consume more RAM. This is often the case with features whose boundaries include river or ocean coastlines. Geofence Spatial Reference When importing geofences from feature records, GeoEvent Server must establish a common spatial reference for all imported geofences. This simplifies the in-memory organization and allows geofence retrieval to be optimized. GeoEvent Server retains the spatial reference of the first geofence loaded until the product’s configuration is reset and the GeoEvent Server Service is restarted. When importing geofences you’ll notice the Import Geofences panel defaults a property WKID to 4326, the well-known identifier of the WGS 1984 geographic coordinate system. This can be changed – and should be changed – if the feature record geometries you are importing use a projected coordinate system and you expect coordinates or geometries associated with event records you will receive to be expressed in same projected coordinate system. If the default is left unchanged, GeoEvent Server will have to perform on-the-fly projections to place received event records and geofences in the same spatial reference before evaluating a spatial condition or relationship. Geofence Identification Filters and processors can be configured with a spatial expression (INTERSECTS, DISJOINT, ENTER, EXIT, etc.) which consider one or more geofences. The specification of a set of geofences to consider is done using a pair of regular expressions. The first expression refers to the geofence category and selects any category name by matching any character ‘.’ any number of times ‘*’. The second expression refers to the geofence names within a category and selects any named geofence by again matching any character ‘.’ any number of times ‘*’. .*/.* considers every geofence in every category CategoryName / .* considers every geofence in the category ‘Arizona’ (Arizona/.*) CategoryName /GeoFenceName considers only the geofence ‘Maricopa’ in the category ‘Arizona’ (Arizona/Maricopa) Geofence Synchronization Using Feature Services In addition to a one-time import used to establish geofences in GeoEvent Server’s in-memory catalog, you can periodically synchronize GeoEvent Server’s geofences by configuring a synchronization rule to point to a feature service. You should not both conduct a one-time import and configure a synchronization rule to update the same set of geofences in a specified geofence category. The geofences you explicitly import (one-time) will take precedence and will never be updated by the synchronization. If you want to switch to begin synchronizing geofences, first select all the geofences in the target category and explicitly delete them. The synchronization rules you configure will periodically query a feature service for feature records and use the feature records from the query to update the in-memory geofences. Each synchronization rule should have a unique name. Synchronization rules run asynchronously and are independent of the rate or frequency of event record ingest. You should consider geofence synchronization only when you know that feature records you want to use to model geofences are dynamic and synchronize as infrequently as possible. Keep in mind that querying a feature service for feature records and applying those feature records to add and update geofences does not happen instantaneously. If your GeoEvent inputs and services are busy ingesting and processing event data during the time a synchronization is occurring, spatial relationships may be evaluated incorrectly. Geofence Synchronization Using Stream Services The best way to handle highly dynamic feature records to use a stream service to broadcast the feature data and configure your synchronization rule to subscribe to the stream service (rather than to periodically poll a feature service). This tends to minimize the latency between discovery that a feature record has changed and the need to update the corresponding geofence. Geofence Properties:  Active Field When importing geofences, either one-time or using a synchronization rule, there are a few properties you can use to control whether a geofence will be considered by a filter or processor. When importing (or synchronizing) geofences, use the ‘Active Field’ property to select an appropriate String attribute whose value will specify whether an individual geofence is Active/True or Active/False. You can also accept the property’s default ‘Always Active’ which will import every geofence as “active”. String values "true", "y", "yes", "on", and "1" evaluate as Active/True. String values "false", "n", "no", "off", and "0" evaluate as Active/False. The string comparisons are case insensitive. Geofences are not often set Active/False, but the setting can be useful for some real-time analytics. When a geofence is Active/False it will not be considered by a filter or processor. This is important because if a spatial expression cannot be proven true, it will evaluate as false. For example, if none of the known geofences are set to Active/True, a DISJOINT evaluation will return FALSE even if an event record’s geometry does not intersect any known geofence. There is no active geofence to provide a geometry against which the event’s geometry can be compared, so the spatial relationship cannot be proven true. Geofence Properties:  Time Extent Start, Time Extent End When importing geofences, either one-time or using a synchronization rule, it is possible to establish a temporal extent during which a geofence will be considered by a filter or processor. When importing (or synchronizing) geofences, use the ‘Time Extent Start’ and ‘Time Extent End’ properties to select an appropriate Date attribute whose value will specify the date/time a geofence is “effective from” and the date/time the geofence is “effective until”. If no suitable Date attribute field exists, you can use a long integer attribute whose value represents epoch milliseconds (GMT). When an event record arrives at a filter or processor, geofences whose “effective from” date/time is greater than the date/time associated with the event record are excluded from spatial relationship tests performed by the filter/processor. Likewise, geofences whose “effective until” date/time is less than an event record’s associated date/time are excluded from spatial evaluations. The date/time associated with an event record is determined by the attribute field tagged TIME_START. If no event record attribute field has been tagged TIME_START (or TIME_END) an internal property (the time the event was created by an input’s adapter) may be used to associate a date/time with the event record to determine if the event falls within a geofence’s temporal extent. If no known geofence shares a temporal intersection with an event record no spatial relationship will be considered – and if a spatial relationship cannot be proven true the filter or processor evaluating the relationship will assume the relationship is FALSE. When setting geofence ‘Time Extent Start’ and ‘Time Extent End’ property values, it is important to know when geofences and event records being received temporally intersect with one another. Another reason to be aware of the ‘Time Extent Start’ and ‘Time Extent End’ properties of geofences is that GeoEvent Server, by default, is actively considering the geofences in its in-memory catalog and deleting those geofences whose ‘Time Extent End’ is sometime in the past relative to the server’s clock. When importing geofences, either one-time or via synchronization, only features whose date/time is less than the specified ‘Time Extent End’ (according to the server’s clock) are included in the in-memory catalog. This prevents geofences which have already “expired” from taking up unnecessary memory. Geofence Properties:  GeoSync Filter Field When configuring geofence synchronization, it is possible to limit which feature records are returned by the synchronization rule’s query. Use the ‘GeoSync Filter Field’ to select an appropriate Date attribute (or other integer) whose value can be incorporated into a WHERE clause by the synchronization rule. The synchronization rule will consider feature records returned by its query, caching the greatest value from the set of returned features, so that when the next query is executed only feature records whose attribute value is greater-than or equal-to the cached value from the last synchronization cycle are used to update geofences in the in-memory catalog. You should only use the ‘GeoSync Filter Field’ when many thousands of feature records could potentially be considered for geofence update – and the majority of those feature records have not actually changed since the last synchronization. This property is one way to optimize geofence synchronization and is not appropriate in all workflows. Key Takeaways Every geofence must have a unique name. Every geofence is associated with a category (used to group geofences). Geofences only consist of a name and a geometry; attributes associated with a feature record used as the source of a geofence are not imported along with the geofence. Before importing geofences from feature records: Simplify the feature record geometries to minimize RAM consumption and allow spatial relationships to be more efficiently evaluated. Project your feature record geometries to match the spatial reference of the event records you plan to ingest. Choose to either establish geofences using a one-time import or synchronize your geofences using a synchronization rule – never both. A pair of regular expressions are used to specify which geofences a filter or processor will consider when determining if a spatial relationship exists. When a spatial condition cannot be proven true, it is assumed to be false. Set geofence “active”, “effective from”, and “effective until” values with care. Avoid inadvertently excluding geofences from spatial relationship evaluations. Geofence synchronization is not instantaneous. Real-time analytics run as geofences are being updated may return unexpected results. Consider using stream services to “push” geofence updates to the in-memory catalog to reduce the number of feature records and the latency associated with catalog updates. Use the ‘GeoSync Filter Field’ to limit the number of feature records returned when a synchronization rule is used to poll a large feature service. ... View more