One way to minimize the impact of the redraw is zoom in to a very large scale where there are no features so the redraw occurs very fast.

But a better way, actually a way better way is to use the “Pause” button on the scroll bar at the bottom of either the Data View or Layout View. (If you don’t see it, it may be that your Scroll Bars are toggled off. Turn them on by selecting from the Main Menu View | Scroll Bars command.)

How does this work? Well, clicking Pause suspends all drawing. And in fact blanks the entire display area while Pause is in effect. There is no ambiguity about when display is Paused. Clicking Pause again toggles display back on.

So when you need to make a number of map configuration changes – say, adding layers, removing layers, changing layer symbology, adding or changing map labels and so forth — your work flow is simple.

1. Click “Pause”
2. Make your changes
3. Click “Pause”
4. Repeat if necessary

Pretty simple. But only if you know about it.

Hope this helps!

The post “Pause” for Map Configuration Performance appeared first on Blair Services.

This is the scenario.

Say your operations department has decided to perform a seasonal load transfer and serve a neighborhood from feeder Magenta102 instead of Green102. This involves moving the location of a tie point between the adjacent feeders. Our starting point situation is illustrated at the right with the tie point near the top of the illustration and upstream switch on Green102 at the bottom.

In practice what operations will do is temporarily close the tie switch and then open the upstream switch. In this way no customers will be without power at any point in the switching operation.

However, mimicking these steps in ArcFM will result in undesirable consequences.

The illustration at the below shows the results of opening the closed tie point as the first step and the opening the upstream switch as the second step. What’s happened is that all segments, and all devices connected to those segments were after the first step fed by both feeders. While after the second step the network as we want the problems with following the sequence are:

1. The first edit will take a long time to complete. Possibly a very long time depending on the number of features present in the two feeders.
2. There will be many edits present in your versioned Geodatabase Adds and Deletes tables, potentially leading to conflicts on reconcile.

If these steps are reversed, so that the upstream switch is opened leaving equipment between the switches temporarily de-energized, we accomplish the same goal though this time the edit operation is much faster and there are fewer features edited and subject to possible reconcile conflicts.

Simple change in work steps, but de-energizing the sections to be changed can make a big difference in editing performance and in the long-term health of your Geodatabase.

The post ArcFM Feeder Manager Switching: De-Energize First appeared first on Blair Services.

The annotation display engine uses a technique that can take into account the presence of other graphic elements already present in the active view. If graphics for geometries such as points, lines or polygons are already rendered at the time annotation display occurs this technique will be applied, otherwise it won’t.

We decided to test this notion with a dataset containing a rich set of annotation classes. In an ArcGIS 10.1 environment we assembled a map with group layer containing point and line features representing land base features and a group layer with 8 annotation classes with a total of approximately 1 million annotation features.

First test was a timed display of all features/annotations, first with the group of annotation layers at the top and second at the bottom. Here were the results.

In this case putting the annotation at the bottom of the TOC saved 391 seconds, or 27% of the display time compared with anno at the top. May be worth considering.

To be thorough we performed the same test in a 10.2.1 environment. In this case performance was not noticeably different with annotation at the top or bottom of the TOC.

The post ArcMap Annotation: Put it on the Bottom appeared first on Blair Services.

Don’t edit the ArcFM DUCTDEFINTION table.  Don’t even try to.  And by that we mean don’t assign AutoUpdaters to it and don’t enable ArcGIS Editor Tracking on it.

The consequences are subtle, but significant.   Especially if you’re using both ArcFM Underground Facility Manager and Conduit Manager.  Let’s just say your edit operations won’t complete as expected.

Why, you ask?

The DUCTDEFINITION table is used only as a template for defining properties of ducts shown in the conduit manager user interface.  It’s not intended to hold actual data.

So, where is the actual data stored?  It’s in the CONFIGURATION Blob field on the ConduitSystem feature.

So that’s it.  Short and sweet.

The post Don’t Edit the ArcFM DUCTDEFINITION Table appeared first on Blair Services.

First a little background

ArcFM Feeder Manager (1.0) dynamically maintains feeder information through the course of editing operations – including switching changes. This is critical information for maintaining integrity of an electric system model. The result of the process is that a value is stored in the FEEDERID field of all features participating in the electric network.

Storing the value in the FEEDERID field can take some time and also result in version conflicts, so SE built Feeder Manager 2.0 which discovers feeder ID values when needed by the application and uses a separate memory structure to hold feeder ID values. The result is a dramatic improvement in some editing operations and elimination of conflicts resulting from feeder updates. And, there is no need for a FEEDERID field on network classes.

However, while there is a lot to like about FM 2.0, some users need a FEEDERID field – in many cases to support legacy applications such as interfaces to operations or asset management systems. To meet this need SE created a “Feeder Sync” process that stores the FEEDERID value – but does it in a way that doesn’t affect user editing performance and *should* minimize version conflicts.

This is where our post picks up

The question is, “are we in danger of introducing conflicts by using the FM 2.0 Feeder Sync?” And, as in many cases, the answer is, “it depends.”

Here’s why. The FM 2.0 Feeder Sync makes updates to FEEDERID fields directly in the SDE.DEFAULT version and, by configuration, can operate either with AutoUpdaters in effect or not.

Here’s a scenario in which the FM 2.0 Feeder Sync would likely generate conflicts – and probably many of them.

• Implement FM 2.0 Feeder Sync with AutoUpdaters enabled and use the “ArcFM User Name” and “ArcFM Current Date” AU’s. (These are sometimes referred to as “meta-data AutoUpdaters”.)
• Reconcile child version with SDE.DEFAULT – using either row level or field level conflict detection. Conflicts will be detected on LAST_USER and/or DATE_MODIFIED fields in any case where a feature in the child version was changed and the FEEDERID updated in SDE.DEFAULT.

In contrast, the following scenario will only result in conflicts if the same value on the same feature was changed in SDE.DEFAULT and a child version (a “true” conflict):

• Implement FM 2.0 Feeder Sync with AutoUpdaters disabled.
• Reconcile child version with SDE.DEFAULT – using field level conflict detection. Conflicts will result only where the same field was updated in both versions. And since FEEDERID is updated only in SDE.DEFAULT there will be no conflicts on FEEDERID.

In addition, this scenario should also void all but “true” conflicts:

• Implement FM 2.0 Feeder Sync with AutoUpdaters enabled with ArcGIS Editor Tracking used to maintain meta-data information instead of the “ArcFM User Name” and “ArcFM Current Date” AU’s.
• Reconcile child version with SDE.DEFAULT – using field level conflict detection. Conflicts will result only where the same field was updated in both versions, and may include any updates resulting from non-meta data AutoUpdaters.

Summary

Depending on your work flow and requirements the FM 2.0 Sync process could result in many unwanted conflicts. However, if you don’t need AutoUpdaters firing during the sync process or are using ArcGIS Edit Tracking instead of the ArcFM meta-data auto-updaters then these conflicts can be avoided.

The post ArcFM Feeder Manager 2.0 Synchronization and Conflicts appeared first on Blair Services.

If a structure is found, then its primary key value is assigned to the foreign key field on the device and viola you’ve got a relationship. The “designation” of a structure is achieved by assigning the class model name “STRUCTURE.”

And yes, if multiple structures fall within the search tolerance of a new device feature the relationship will be established with the closest one – as we see at the right. If you want the relationship to be defined to the structure farther way, then simply use the attribute editor to make the update.

As an aside, what you call a structure might not be what everyone else calls a structure. See, for example, our recent post on pole-conductor relationships for examples where the structure location and not the structure itself is defined as the “structure.”

Now, when the structure relate AU fires the default search tolerance is 25 map units. Which is fine if your mapping conventions call for devices to fall within 25 feet of a structure. What if they don’t? Then SE has provided an option under the “Editing” tab of the “ArcFM Options” dialog where you can change it!

Here are a few more tidbits on the structure relate auto-updater which apply at least as of version 10.2.1a.

• The target structure class and associated device class must exist within the same feature dataset.
• To be able to assign the “ArcFM Structure Relate” auto-updater to a class there must be, 1) a feature class already present in the feature dataset with the class model name STRUCTURE, and 2) a relationship between the structure class and class to which your assigning the AU. The relationship typically has the cardinality of one-to-many.
• It does work with polygons as the target “structure.” Per the example below, say you assign the STRUCTURE model name to your gas regulator station polygon class and create a relationship from regulator station to valve, then creating a valve that falls within the station boundary will establish the relationship.

The post ArcFM Structure Relate Search Tolerance appeared first on Blair Services.

Of course my good friend is right.  And that is why the ArcFM valve isolation traces expect pressure information at sources and on pipe themselves.

However, the thing is, all companies don’t know the inlet and outlet pressures of all pumps and regulators in the water and/or gas networks.  At least this information is not always present in their GIS.  And in some cases the effort to obtain that information can be a daunting task.

Luckily, ArcFM provides an option for performing traces without pressure information, in which case it simply looks for valves bounding the point of inquiry.  On the “ArcFM Water Traces” toolbar just click “Options.” The “Use Pressure” check box option is available on the “Water Traces” tab.

Below is an example.  We’ve initiated a water valve isolation trace just beyond a water booster pump station and our trace has identified valves to be operated.  Though there are not additional sources beyond the station the non-pressure trace identifies valves (indicated by arrows) not actually required to isolate the location.

In summary, the non-pressure valve isolation trace can be convenient since it doesn’t require pressure values. Just beware that the results will possibly include more valves than really need to be operated.

The post No Pressure ArcFM Water Tracing appeared first on Blair Services.

However, in our experience there is one scenario where they are not so fast.  And that’s when you need to make extensive use of “join layers”.  Here’s an example.

• Feature Class: 51,000 polyline features
• Related Table: ~50,000 with 1 to 1 relationship with polyline features
• ArcMap map join keeping only matched records
• Symbolize ArcMap layer based on field in the related table

Add a definition query to the joined layer based on a character field in the joined table and we get these results.

Finally, as a measure of analysis function performance we opened the layer’s attribute and performed a “Summarize” to get a count of unique values for a character field in the related table.  Here are the results.

The absolute numbers we report above clearly aren’t that large, but on a percentage basis operations on the join layer in MS-Access are about 5 times faster than the same operation in the File Geodatabase.

Don’t get us wrong, we still love file Geodatabases.  And if you’re comparing them with PGDB’s remember the 2DB MS-Access limitation.  However, if what you need is fast performance for feature classes joined to related tables, consider the good old MS-Access Personal Geodatabase.

The post ArcMap Joins and File Geodatabases appeared first on Blair Services.

As we know in our ArcGIS/ArcFM solution stack there are two ways to perform QA, ArcFM “Run QA/QC” and ArcMap “Validate Features.” Both operate on a selected set of features. The ArcFM QA gives us a progress dialog, a list of errors we can inspect or write to a file, and most importantly, returns *all* errors found for a feature and any related records. The ArcMap “Validate Features” runs silently and removes valid features from the selection set leaving only invalid features selected.

In general, we like to use the ArcFM QA to get benefit from its completeness – but the price is performance. Here’s an example comparison of QA times for a sample set of approximately 45,000 complex edge features that we’ve found to be pretty representative:

That’s 15 minutes difference.

Knowing the performance difference and the results returned one strategy to consider is this:

1. Execute ArcMap “Validate Features” on your large selection set
2. Execute ArcFM “Run QA/QC All” on the remaining features in the selection set known to have at least one error

The following table offers a breakdown of times for an example of 26,000 simple junction features:

In this case our strategy saved us about 10 minutes for a QA run. If this is a task you run repeatedly, it might represent an opportunity.

Of course, if all or a large majority of your feature have QA errors this strategy won’t save but cost you time. Nonetheless, in our experience cases where *all* features in a class have QA errors is relatively rare.

In the end, we hope this strategy might be able to save you some time in your QA processing going forward.

The post Quality Assurance and Performance appeared first on Blair Services.

So, the point is this. When naming fields, do so with the end environment in mind. And if the end environment forces names to upper case, consider separating distinct words in field names with something like an underscore, so the thing you hoped would appear as “SerialNumber” but actually appears as “SERIALNUMBER” will in fact appear as “SERIAL_NUMBER”.

The post CamelCase != ORACLE_CASE appeared first on Blair Services.