I've been trying to do something that's either possible in a way I haven't found or not possible at all.
I'm putting together a dashboard that looks at bird banding data. There's an "Incidents" layer that includes all of the locations where each of the birds was originally banded, plus locations where some of those birds were later encountered.
I created a "Links" layer that has lines between each banding location and the location(s) any later encounter(s), in date order. The two layers have the BandNumber attribute in common. So there may be one, two, or more Incident entries with the same BandNumber. If there are two or more Incidents with the same BandNumber, there's a corresponding line feature in the Links layer.
I created a hosted feature layer on AGOL with those two layers, created a map with that hosted feature layer, and then created a dashboard from that map, with selectors that filter the Incidents layer based on various attributes in that layer.
What I'd like is for the user to be able to apply one or more of the selectors to the Incidents layer, turn the Links layer on, and see *only* the links related to the shown Incidents.
It seems like when setting up a selector, one of the available actions should be to also filter a separate layer with a matching attribute value. (In this case, BandNumber.) But if there's a way to do that, I'm not seeing how.
If any of you smart folks know how to do this, or can think of a different approach that'll let me set up this capability, I'd be much obliged!
Have you tried setting the data as a related table. In regards to related tables, it is possible to create filters so that when one layer is filtered it will filter the layer in the related table as well.
I tried that, but will give it another shot and see if I missed anything.
Am I correct that the filtering of the second layer would happen via an action in each selector, with a connection between Incidents and Links based on BandNumber? Or Link Object Id to OBJECTID?
Or would the fact that the two layers have already been related take care of the connection?
EDITED TO ADD: Uh-oh. Do the two layers specifically need to be in a relationship class in the hosted feature layer? A relationship class that - as far as I know - can only be created in ArcGIS Pro, and specifically in ArcGIS Pro but only if it's licensed to a higher level than I have it? Because that would be ... frustrating.
It shouldn't, especially if you are doing this in a local geodatabase. Both ArcMap and ArcPro local gdbs can create relationships. The relationship does need a relationship class, which can easily by created in any local gdb. That would allow for specific records in the main layer to be filtered, which in turn, will auto-filter the other layer specifically by the records in which they are related to.
Here is some documentation to help with this. Create Relationships
Well, unfortunately, I only have a GIS Professional Basic license, which I discovered doesn't include the Create Relationships tool. So I guess I need to figure out some other way of doing this, or come up with $2,750 for a GIS Professional Standard license.
But seriously, thank you for your help.
So I've given your circumstance some more consideration and there is an other option. Since you only have a basic license, which limits you but doesn't eliminate all options, you can try adding all of the links that you want filtered by adding them to the feature class to corresponding attribute so you can set up the filter widget to create a subfilter based on that attribute.
If I understand correctly what you're suggesting, I don't think that'd work. Some of the Incident point feature attributes I want the end user to be able to filter for have different values along the shared Link feature. And while most Links have only one Banding Incident and zero, one, or two later Encounter Incidents, some of them have as many as 20 associated Encounter Incidents. (Hence wanting to use a relate.)
The other thing I've considered but need to research more is the similar possibility of using attributes at each of the Link feature vertices. But my first read is that those are specific attributes used for specific purposes, like routing (m-values) and elevation (z-values).
So when it comes to editing vertices, you would be correct. Editing vertices attributes is only for routing and elevation. You won't be able to add attributes to the vertex attributes.