...

This was an exercise to show that the decision of how to represent a data set can greatly affect the performance of its service. In this instance, using the simpler polygons of the Real Property data may be as appropriate as using an intersection with flood waters. Creating a related points layer to use at small scales would allow users to find affected properties visually. While being unsure of the goals of the layer, showing only the current floodwater, or setting a target time value, may also simplify the data shown.

Feature Collections

The Emergency Management Group has a number of Feature Collection layers, including some for Alberta Fire data. In the Alberta Fire case, each layer is published per year. Feature collections appear to offer good performance for publishing a small amount of feature data.

In the Alberta Fire case, these yearly collections could be the intermediate step in gathering a data set published only as yearly summaries, with the intent of publishing a complete data set. But, these layers could be the result of a user searching to fix the poor performance a larger, more comprehensive layer.

Seeing a number of repeated layers that are only differentiated by some attribute is a sign that some guidance may be needed.

Suggestions

• Best practices for publishing and symbolizing data must be followed regardless of our hardware.

  • Create map caches where possible

  • Data that can’t be cached should be stored and displayed in the fewest and simplest features possible

  • Follow ESRI’s Performance tips for uncached maps

• Re-project all data to WGS84 Web Mercator

  • Avoid all re-projection on the fly

  • Debate?

• Test performance on all layers?

  • Web hooks, test new layers?

...