This document describes the following best practices:
- Finding de-energized features, loops, and multi-feeds with Feeder Manager 2.0
- Avoid unnecessary tracing
- Use basemap layers to improve draw times
- Clean your local storage
- Use feeder change events sensibly with your customizations
- Use Feeder Manager 2.0 layer order to maximize efficiency
The user-centered architecture of feeder information in Feeder Manager 2.0 offers easy symbology mapping to visually highlight de-energized features, multi-feeds, and loops. Tie symbology to the Loop field to highlight loops and use the Number of Feeders field to visually locate de-energized and multi-feed features.
Best Practice: Do not leave your symbology layers on. Instead, enable the layers only when your workflow requires them. Having your loop symbology layer on while making edits will slow your processes, so wait to enable the layer until you're actually interested in finding loops.
In general, the use of definition queries on Feeder Manager 2.0 fields is not advised. The reason for this is that specific queries cause a full network trace to come up with the result and the performance of some tools can be negatively impacted. Symbolizing on FM2.0 fields can be used for most use cases and is the recommended approach with FM2.0 as it will only trace the current map extent.
Best Practice: As with symbology, normally have definition query layers turned off (disabled) and ONLY enable once you need the query's results.
Best Practice: Feeder Manager 2.0 is fast because it does not store data. As a result, Feeder Manager 2.0 must perform a trace to answer queries. With this in mind, you will want to build specific queries that will trace only the map extent instead of general ones that will force a full table scan and trace of your entire network. In general, just querying your map extent is a more efficient approach.
Export by Feeder tool
The Export by Feeder geoprocessing tool is provided with Feeder Manager 2.0. The tool traces the feeders you specify and appends the Feeder Manager 2.0 feeder information to the individual features. It also exports all of the other attributes on a feature.
Custom applications can query feeder information from Feeder Manager 2.0.
When it involves features that don't currently belong to your Feeder Manager 2.0 cache, network tracing can take a noticeable amount of time. The amount of time it takes depends on the number of feeders traced—more feeders require more time. To improve performance, you can easily avoid many operations that query the database and cause Feeder Manager 2.0 to trace your network. Employ each of the following practices for a much more efficient experience.
Symbology inspects only the data belonging to the extent. Use this to your advantage! Spend some time considering the levels at which you need to see things in your map.
At large map scales, you should avoid basing your symbology on Feeder Manager 2.0 fields.
If your query includes Feeder Manager 2.0 plug-in fields, this tool scans the entire database for attributes defined in your query.
Again, consider setting up symbology instead. For example, create a new group layer that you can use to symbolize looped, multifed, or de-energized areas of your network.
And don't forget about the Find Feeder tool's Zoom to Extent command.
When you open the attribute table on a layer in this fashion, ArcMap returns the first 2000 features it finds. This usually incurs an unnecessary and time-consuming amount of network tracing:
There's a much more efficient way to do this that doesn't require unnecessary tracing. First, use the Find Feeder tool to select all of the features belonging to a feeder:
Then List By Selection:
Now you can open a table of the selected features:
If you're not interested in Feeder Manager 2.0 data, you can disable the automatic joins, as described in the section below. Doing so restores the performance of the Open Attribute Table command. You can extend this practice by, for example, creating a group layer for the purpose of locating features with attributes that don't include Feeder Manager 2.0 data.
If you have users who don't care about feeder data, there's no sense in expending any computational effort on providing such data. In those cases, when your data are configured for Feeder Manager 2.0, design stored displays that won't automatically join their layers to the plug-in data. Simply uncheck a layer's Join FM2.0 Feeder Info Fields option. Save the stored display with a new name and you're done.
Feeder tracing operations are required when locating features that participate in a network configured for Feeder Manager 2.0. Unchecking this option improves performance:
Additionally, don't use the ArcFM Locator to search based on feeder information fields. Instead, use the Find Feeder tool, which was designed expressly for that purpose.
Note that the Locator displays whatever feeder data currently reside in the Feeder Manager 2.0 cache. If the cache is currently populated with feeder data relevant to the Locate operation you're conducting, you will see data in the Feeder Manager 2.0 fields even when the option to Return FM2.0 Data is turned off.
Because edits that affect the Feeder Manager 2.0 cache cause a refresh of the geography draw phase, we recommend that you take advantage of basemap layers in your stored displays. If you move feature layers you're not editing into a basemap layer, you can take that data out of the map's geography cache, thereby improving draw times while editing.
At the 10.2.1a release there is a configuration option to cleanup local storage files automatically. At 10.2.1, this needs to be done manually or via a script. Because Feeder Manager 2.0 generates an .edb file for each session and version, these files may occupy more space than you'd like. Deleting them in no way damages your data or has any deleterious consequences. You can find them here:
\Users\user\AppData\Roaming\Miner and Miner
The .edb files will look similar to this:
Keep in mind that the performance advantage of Feeder Manager 2.0 is that it minimizes database-write operations. Customizations that use these events extensively will degrade the performance of Feeder Manager 2.0. For example, using the events to update the label text field on conductors could be costly because of the large number of features that might need updating. Check the Resource Center to find out more about the feeder change event.
Beginning with 10.2.1b, you can order the read-only Feeder Manager 2.0 fields similar to the way you can order the list hierarchy of other feature fields. You can place the group of fields at the beginning of the feature field list, the end, or after a specific field you select. The optimum spot will depend on your workflow, but the goal will be to limit the scrolling that your analysts will need to perform to view feeder information for a feature. You can learn more about the field order feature on the Resource Center.