Add a filter widget to ArcGIS Field Maps
Hi @Anonymous User , see below. A lot of our example is for work orders as that's our immediate business need, and appreciating that you are looking to integrate the Esri Workforce capability into field maps. While we could consider this, the need for filtering remains valid for non-works related information, so using workforce might be relevant but wouldn't remove the driver for this..
Also noting we're a state water/wastewater/stormwater utility (Melbourne Water, Australia), so this is very 'asset-centric' / 'works-centric'.
1. Should the mobile worker have the ability to create a filter using any field? Some products allow the map author to configure pre-defined filters/selectors where the user either enables/disables the filter or the user only selects the value (not the field). For us, these would be fine if predefined per layer by the webmap/field maps author and field, and then user could choose to use one or more filters on a given layer. No expectation end users can define this 'on the fly'.
2. We are looking for specific examples of the layer you would use, and the filter you would like to use. For example "I would like to filter a trees layer by the age of tree and specie of the tree." We're trying to understand the complexity of the filters that are needed. How many conditions are expected?
If we had to constrain it, 5 fields max, but 3 would make a huge difference (so 3-5). Expectation is user could apply 0-n of these and they would combine (i.e. 'AND' join). Use cases for us are 2:
A. 'Activities' we have represented spatially (e.g. 'stuff happening on ground'). These are usually generated from EAM/CRM type systems. purpose of exposing to field users is so they can understand other on ground works occurring at site. e.g.
- Maintenance Work Orders (from our Maximo EAM; it has complex appland a non-spatial mobile app, so looking to use it in a complementary fashion. Further details below on an example workflow.
- CRM activities. This could be construction work near our asset, call centre enquiries/complaints
- Capital projects. New greenfield works, ours or from externals
- Operational activities, e.g. water valve testing, routine site inspections
As these all come from different systems, intent is to be able to use GIS to provide the overlay of all this information. This means it's a high volume of data, so for field works to filter what they can see they can cut through the noise depending on the activity they are performing at site.
B. Assets. We have a large # of assets (~300k) across 14000km2 area, plus there are another 1 million of other agencies assets. While have used definition queries, subtypes to provide a tiered list of assets, if they are at a complex site like a treatment plant, there's a lot of data on the screen for them to drill into. Having filters we could apply to asset layers means uses can self-service to identify information not be represented by symbology and layer structure alone. e.g.
- layers are used to separate out asset ownership and top level asset type (pipes, valves)
- symbology is used to further delineate asset types (aqueducts, scour valves) and asset status.
- so if user wants to see all pipes of x diameter, then the currently need to use the info tool repeatedly, or if they want to just show a subset of asset classes within a layer they have no way to do that.
Generally, our field maps are designed for one business use, e.g. Work Order execution for maintenance crew - they're focused on work orders; Customer Response - they're focused on their CRM cases (e.g. a field inspection of a CRM case to ensure a building permit has been completed without damaging our asset); Asset Managers - undertaking a site inspection to plan a new capital project; focused on the asset data. So in each case there's really a single 'primary' layer they'd want to filter by, having the ability to filter on multiple layers would be fantastic, but appreciate that could become quite unwieldy.
3. Why do you need to filter a layer? Is it reduce the visual complexity of the map to find nearby features? Is it to reduce search results for searching for specific features?
Yes for both:
- to reduce visual clutter
- to narrow search results
one of the issues with Field Maps is that search doesn't constrain to the visible map area (that would also be amazing), so applying a 'filter' on a work area (geographic zone) that is populated as an attribute is one way we see to allow users to only see that relevant context. Or to filter to work orders assigned to a given user, as also the issue is that only one search term can be entered (so user can't use a layer attribute search to find 'all work orders assigned to me scheduled for today).
4. Should filters be persisted/saved so they can easily be turned on/off for a layer?
This would be ideal and would be great to save PER USER, as if users are searching for work orders 'assigned to me', then they would want to return to this same filter. Reason for this is we haven't worked out an OOTB method to pass a logged in user as a filter criteria to a definition query, so we can't create e.g. a view or a map service that has a layer that shows 'work orders where ASSIGNED = '<logged in username>'. maybe this is something we could address with a SOI or something but haven't explored that yet.
Further context:
re: work orders as an example workflow for maintenance crew
- One week to one month of work is scheduled assigned at a time to a field member (depending on site/provider). These will be allocated to the nearest day, not to a specific time within a day due to volumes of work.
- The field worker then has autonomy on which jobs to complete ‘first’ from their backlog – they just need to ensure all work is completed by end of day/week
- Subsequently, the field worker is looking to use filters in the Field Apps to:
- Use a filter to only view work orders assigned to them
- Further filter down that ‘list’ of assigned work orders to determine which job to undertake first, based on location and closeness, priority, or type of work
OR
- View work orders assigned to another user. e.g. if they have 3 hours left in the work day, and no work orders within drivetime with suitable duration, they can self-service identifying another work order by:
- viewing spatially to find a close work order
- filter where activity type matches (e.g. grass crew can find other grass cutting jobs). They can then ‘pick up’ that work instead of relying on a central dispatch to coordinate this work.
As mentioned, we have an existing non-spatial work order mobile app for Maximo that is used to execute workflows for in the field (status changes, booking time to job, updating comments). These have complex backend interaction to application/database so we are currently using Field Maps as a complementary product to provide the 'GIS view', and then have set up launch in context via URLs in popups to<>from to our other dedicated enterprise apps to complete workflows.
Two options we’ve considered:
- Option 1 - Using a group layer, and then a set of sublayers under that with various definition queries applied e.g.:
- Work Orders
- Work Orders In Progress (def query status = ‘In Progress’)
- Work Orders Scheduled (def query status = ‘Scheduled’)
- …
- Users can then ‘turn on’ the group layer to see all records, or individual sublayers to see filtered subsets
- However, this has two limitations:
- def queries have to be predefined and published, so doesn’t work where requirement is a changing free text list like ‘work order lead’ as a person name
- this only allows for one attribute to be set as the filter, and we can’t have that cascading/nested/shopping cart type filter experience
- Work Orders
- Option 2 – use an SOI as described earlier in this post to to address the lack of capability in Esri OOTB products to have a ‘dynamic’ definition query that can use the logged in user as an input to that query. Our proposed design is have two services defined in the map:
- All work orders (no def query)
- ‘My’ work orders (same dataset on a different service, with an SOI that applies a definition query where logged in user = lead)
- However this also has limitations:
- Only one query could be defined in this way, and it would be predefined
- Cascading filters couldn’t be used (show work orders where lead is me and priority is 1 and activity type is repair)
Here’s a WAB webapp with the OOTB filter widget we have been using to provide this type of functionality for equivalent desktop flows for field crew supervisors and leading hands when they’re in the office (disregard the word Operational Dashboard title, it’s a WAB webapp).
Similar equivalent filters have been really useful in ArcGIS Dashboards, but issue with both of these are they only work online as webapps.
We also have been using a non-Esri mobile GIS product that we're looking to transition away from that has this functionality implemented in a mature fashion that works really well - not sure on forum policy on publishing screenshots and content for other vendors' products, but happy to share via DM/email.
this is great! Thanks for starting the process.
1. Should the mobile worker have the ability to create a filter using any field? Some products allow the map author to configure pre-defined filters/selectors where the user either enables/disables the filter or the user only selects the value (not the field).
Yes, being able to create a filter using any field would be very helpful for us. We conduct interviews with rural Alaskans on their subsistence harvests. We would need to be able to filter by our assigned Community and Household identifiers.
We work in areas without wifi and would therefore need it to be something that can be done in the field offline. Dropdown menus would be ideal. I don't think predefined filters would work for us.
2. We are looking for specific examples of the layer you would use, and the filter you would like to use. For example "I would like to filter a trees layer by the age of tree and specie of the tree." We're trying to understand the complexity of the filters that are needed. How many conditions are expected?
We conduct interviews in which we gather information about rural Alaskans subsistence activities and harvests. We aim to interview an adult from each household within the community, and each household has a number assigned to it as an identifier. We would need to filter by the community number first, and then household number so that only the data from that household is showing up on the map. We would need to filter it as we are collecting the data so that no other household's data shows up.
For the most part, filtering by two fields (Community ID, Household ID) is absolutely required. If there was an ability to filter by more than that, such as resource (the plant or animal harvested), it would be helpful. If we needed to search for the moose harvest for household 5 in community 56, being able to do that would make the field worker's job much easier.
3. Why do you need to filter a layer? Is it reduce the visual complexity of the map to find nearby features? Is it to reduce search results for searching for specific features?
There are several reasons we require a filter. First and foremost is that by state statute, the data we collect is confidential. By not being able to filter the data, we as a state agency are in violation of state law. Obviously, this is not acceptable. What I've done for a work around is to make a separate map for each household in each community so that only one household's data shows on the map during an interview. This gets very clunky and overwhelming for my field workers, and it is a lot of extra work for me. But it is the only way we can collect our data without violating state law.
Second reason is that seeing the responses from other households is likely to introduce bias into an interviewee's responses. While there is always some bias when collecting data from interviews, we have developed questions to try to limit it. But we can't limit bias when we show them where other people hunt, fish and gather resources.
Third reason is that our field workers go into remote communities without access to wifi, and sometimes they go from one community to another without coming into the office in between. Each community can result in hundreds of overlapping polygons (see attached photo). It ends up being a mess, and impossible to collect new data or edit existing data. Often the data is cleaned up after an interview is completed, so being able to find the correct polygon is essential, and this is where being able to filter by more than one attribute would be helpful.
This is an example of a subset of overlapping polygons from one community (with location and identifying attributes not shown)
4. Should filters be persisted/saved so they can easily be turned on/off for a layer?
I don't think this is necessary for us but could be useful. A dropdown for the filter field and then another either dropdown or box for the specific household ID being interviewed/edited is really all we require.
This is our main attribute table.
Let me know if you need any further explanation, or more information.
Thanks,
Gayle Neufeld
Alaska Department of Fish and Game
Yes for us just a drop down of coded values that filters on equal would be great for now. But they also tell me if could have a unique values drop down based off a string field that would be slick. Some of our trip planning fields are added by the crew weekly so we cannot domain it. They add say Trip6 to pick out where they are going this week. Then they can filter for the 5 points out of 1,000 and only see those. That was the big ask but I know that is harder than domains for you to code. Unless you can do a local lookup in the replica to get the list? Eventually being able to have another sort field that cascades the choices. Project A only has Trips 1-5 for example. And then from there a spatial filter maybe.
Just a simple drop down like Ops dashboard would be a great start.
Thanks!
