Select to view content in your preferred language

Dashboard with 100+ Feature Layers

216
4
Jump to solution
11-21-2024 07:34 AM
sfritkin
Emerging Contributor

I've been using Survey123 Connect for the last ~6 months and feel pretty comfortable with it, but I just recently started dabbling with the Dashboard.  I currently have 125 surveys created for calibrating different tools and devices and they all have the same "Status" field with the choices of Review and Finalize, and the same "Job ID" field that is a text type element.

I was hoping to use the Dashboard to track the status of specific jobs by showing how many of the surveys for a specific job are in the review step vs how many are finalized.  What I have so far is a Sidebar that lists all my Job IDs, and I've figured out how to connect the selection on the side bar to a gauge element in the Body of my dashboard.  I also have a gauge for each (I've made 3 of my 125 so far) survey that shows the data I wish to show.  When a job is selected on the sidebar, it will show how many of that particular item has been submitted for that particular job as well as how many of those items have been reviewed vs. finalized.  Currently, if the gauge is for an item that was not calibrated for that particular job, it will just show "No data".

The big issue I see is if I were to continue down this path, there would be a ton of useless information on the page as most jobs only calibrate ~10 different item types at most, meaning there would be over 100 gauges on the screen that will all be empty, showing "No data".

Is there a way to make Dashboard elements dynamic?  I would like to make it so when a job is selected on the side bar, if there were zero items with that Job ID for a particular survey, it hides the element completely.

0 Kudos
1 Solution

Accepted Solutions
jcarlson
MVP Esteemed Contributor

https://www.esri.com/arcgis-blog/products/ops-dashboard/announcements/introducing-data-expressions-i...

For yours, you mention that there are shared fields between them, Job ID and status. Is the category field shared between them as well?

Here's what the expression could look like:

// for single-layer services, the layer index is almost always 0, but we will explicitly state the index for each, in case you have other values. the index number corresponds to the URL, /FeatureServer/X, X being the index

// list out all layers to add to dashboard
var layers = [
  {id: 'itemid of layer', idx: 0},
  {id: 'itemid of second layer', idx: 0},
  // and so on
]

// establish output schema
var out_dict = {
  fields: [
    {name: 'jobID', type: 'esriFieldTypeString', alias: 'Job ID'},
    {name: 'status', type: 'esriFieldTypeString', alias: 'Status'},
    {name: 'category', type: 'esriFieldTypeString', alias: 'Category'}
  ],
  geometryType: '',
  features: []
}

// loop through our layers and push features into dict
for (var l in layers) {
  // get featureset
  var fs = FeatureSetByPortalItem(
    Portal('your portal URL'),
    layers[l]['id'],
    layers[l]['idx'],
    ['job_id', 'status', 'category'],
    false
  )

  // push features into dict
  for (var f in fs) {
    Push(
      out_dict['features'],
      { attributes: {
        job_id: f['job_id'],
        status: f['status'],
        category: f['category']
      }}
    )
  }
}

return FeatureSet(Text(out_dict))

 With so many layers, this is likely to be a long-running expression. I would pause and test it every few layers as you build the layers array, to see if the performance becomes an issue for you.

- Josh Carlson
Kendall County GIS

View solution in original post

4 Replies
jcarlson
MVP Esteemed Contributor

Have you looked at Data Expressions? It would be one heck of an expression, but you could merge all the data together into a single ad-hoc source, then drive all your widgets from one thing. That way you minimize the number of widgets to configure, and the category selector can act across all items.

- Josh Carlson
Kendall County GIS
0 Kudos
sfritkin
Emerging Contributor

Thanks for the suggestion; sounds like that might be the best option.  Do you mind sharing a link to where I might find more information on Data Expressions?

0 Kudos
jcarlson
MVP Esteemed Contributor

https://www.esri.com/arcgis-blog/products/ops-dashboard/announcements/introducing-data-expressions-i...

For yours, you mention that there are shared fields between them, Job ID and status. Is the category field shared between them as well?

Here's what the expression could look like:

// for single-layer services, the layer index is almost always 0, but we will explicitly state the index for each, in case you have other values. the index number corresponds to the URL, /FeatureServer/X, X being the index

// list out all layers to add to dashboard
var layers = [
  {id: 'itemid of layer', idx: 0},
  {id: 'itemid of second layer', idx: 0},
  // and so on
]

// establish output schema
var out_dict = {
  fields: [
    {name: 'jobID', type: 'esriFieldTypeString', alias: 'Job ID'},
    {name: 'status', type: 'esriFieldTypeString', alias: 'Status'},
    {name: 'category', type: 'esriFieldTypeString', alias: 'Category'}
  ],
  geometryType: '',
  features: []
}

// loop through our layers and push features into dict
for (var l in layers) {
  // get featureset
  var fs = FeatureSetByPortalItem(
    Portal('your portal URL'),
    layers[l]['id'],
    layers[l]['idx'],
    ['job_id', 'status', 'category'],
    false
  )

  // push features into dict
  for (var f in fs) {
    Push(
      out_dict['features'],
      { attributes: {
        job_id: f['job_id'],
        status: f['status'],
        category: f['category']
      }}
    )
  }
}

return FeatureSet(Text(out_dict))

 With so many layers, this is likely to be a long-running expression. I would pause and test it every few layers as you build the layers array, to see if the performance becomes an issue for you.

- Josh Carlson
Kendall County GIS
sfritkin
Emerging Contributor

For anyone who is looking at this in the future:

I have used a slightly modified version of the code Josh sent and it works great.  As he pointed out, performance could be an issue; it currently takes just under 2 minutes for the dashboard to load currently with 125 different feature layers and ~4000 surveys split among those layers.  I'm not sure how much worse it will get as more surveys get turned in, but I'll keep an eye out.  If the dashboard takes > 5 minutes to load, I may need to come up with a different solution.

sfritkin_0-1732302879972.png

0 Kudos