Have you ever wanted to identify the perfect location for an event, say for a wedding, a meeting, or a workshop?
Quartic worked with a client that identifies ideal event locations based on a customer's specific event needs and then coordinates with local jurisdictions to obtain any of the required permits for the chosen location.
Quartic was able to configure the tools to quickly answer questions from the client’s customers such as “Where can I have a gathering for 50 people on a Thursday afternoon in a suburban neighborhood within 200 feet of a park?”
Utilizing GIS, Quartic was able to configure the tools to quickly answer questions from the client’s customers such as “Where can I have a gathering for 50 people on a Thursday afternoon in a suburban neighborhood within 200 feet of a park?” Relying on outdated and slow technology, and a manual process to find ideal locations was replaced by a GIS based web application that identifies ideal event locations based on complex search criteria.
There were 3 primary goals that Quartic needed to address when configuring a GIS Enterprise environment:
The client was already using the Cloud, so Quartic architected a GeoSpatial Cloud solution using the ArcGIS Enterprise Platform. Google Cloud was used for the underlying infrastructure. ArcGIS Server and Portal were installed, along with a PostgreSQL geodatabase to enable the client to both edit their own GIS data, and publish it to the web. Utilizing Esri’s out of the box Web AppBuilder for Portal, Quartic designed a web application that could search through many GIS layers to identify event locations based on the specific needs. In addition, the client also needed to be able to filter all of the data in the map by date and time as well as location. To address the date/time component of the filtering, Quartic designed a custom widget to be used in the application that could filter multiple layers in the map by date range and time range. To satisfy the need for data editing, a second application using Web AppBuilder was configured that takes advantage of Esri’s existing editing widgets. By utilizing a combination of COTS solutions and minor enhancements with code, all public and internal requirements were successfully met.
Separate CentOS virtual servers used for the installation of ArcGIS Server and Portal. Another CentOS server was used to host a PostgreSQL geodatabase. Once the software was installed and configured ArcGIS Server was federated with Portal. Portal was then configured to use the client's SAML identity provider for a single sign on experience. Since the identity provider is hosted in an Azure cloud it allowed safe, secure sign in not just for on premise users but remote workers as well. A Google file share was added to the VPC to allow for regular backups. Native PostgreSQL tools were used to schedule regular database backups. The ArcGIS Enterprise webgisdr utility was configured to create regular backups of Portal and ArcGIS Server.
Web AppBuilder was chosen for the creation of the application because of the ease of use of setting up and maintaining the application. Using Web AppBuilder meant that the application was hosted in Portal and could easily utilize both public GIS services and any client data that was hosted in Portal. The screening widget was the main component of the application widget. This widget allowed the user to search by either entering an address, or drawing a point, line or polygon on the map. They could then add a buffer to search results within that radius. The screening widget would then search all layers turned on in the map to find locations within the search area. The output could then be printed as a PDF map, or exported to a CSV file. This enabled the client to keep a record of the results at the time which they performed the search.
The custom widget was customized by using the "Filter" widget as a template. The Filter widget already had a method to allow user input for a date range, so the modifications could be made to the internal query to allow a date search. These modifications included customized field names, data format considerations, and Boolean logic changes (from AND to OR as needed). Additionally, the modified query could then be looped through a list of layers to accomplish the multi-layer requirement. The custom list of layers and their associated field names were contained in the configuration JSON, just as the normal widget configurations are kept.
The time portion of the filter was more complex. Time values needed to be entered by a user as a string in format "HH:MM". This was needed to separate the date values for time values so that users could see when features overlap only a time range (such as during a sunset). Applying this filter to a date/time field required significant parsing of the original query to allow the custom variables to be fitted. Adding to the complexity was that this data for time did not exist yet, so the initial prototype was using an assumed time structure. Once this was added to the source data, adjustments had to be made. A requirement for a "time buffer" component to allow users to assume late projects also became complicated when approaching midnight (either as a pre-buffer or post-buffer of the range). Complicated conditional logic was written to account for day-crossing buffers.
In addition to an application to search for event locations, the customer requested an application for their Community Outreach team to be able to edit their own data through the web. These users would not have any GIS experience and needed an easy and intuitive way to edit the data. Using database roles and groups in Portal, Quartic was able to publish the two community outreach layers to Portal while only allowing those Community Outreach staff the ability to edit the data. Once published as a service, those layers were used in the Smart Editor widget in Web Appbuilder, where they could easily be edited with minimal training by the Community Outreach staff.
There was some initial apprehension amongst the staff who would be the ones using the application. Although trained IT staff would maintain the GIS architecture, the users of the application and those maintaining the data were not technical staff and were hesitant to have to learn unfamiliar and new technology. After completing the initial application, Quartic provided a demonstration and training session, as well as written documentation to all of the staff who would be using it. When the training was completed and the staff could see how robust and easy to use the application was especially compared to their old environment, there was overwhelming excitement for a new application that would make their job easier.
