7 Replies Latest reply on Dec 12, 2013 7:55 AM by Karyn Peters

    Are ConductorInfo records useful?

    Karyn Peters

      I’m looking for input on how ConductorInfo records are used.  At first glance it appears this data could easily be stored in a single feature record.  Is there software functionality supported by these records in ArcFm, Designer, and/or Responder?  Have you found this table useful for reporting?  Any input would be appreciated.

        • Re: Are ConductorInfo records useful?
          Kevin Leben

          Hi Karen,


          In ArcFM, ConductorInfo records are used to maintain characteristics of the individual wires of a conductor. Attributes such as phase, conductor material, size, insulation can differ for each conductor. ConductorInfo records can be used to maintain this information. This would be difficult to maintain in a single conductor record. By relating ConductorInfo records to a conductor the differing information for each conductor is easily maintained, especially when favorites are created with preset attributes for the conductor and its related ConductorInfo records.


          If you are using Designer, cost and inventory information can be maintained in ConductoInfo compatible units, and used along with conductor CUs in CU favorites to pre-define conductor assets. Cost may differ per conductor due to material differences, and ConductorInfo records can maintain these differences to give a more accurate cost assessment of  a design.


          ConductorInfo records are managed in ArcFM by configuring the correct auto updaters and model names for the conductor and ConductorInfo classes.


          I am also @mentioning GIS Support and ArcFM to widen the audience for responses.

          • Re: Are ConductorInfo records useful?
            Samuel Tregillus

            One thing I would mention is the tools that maintain ConductorInfo records when a line is split (The AUs assigned to the conductor "Save Related Objects", "Split Feeder Object", and "Restore Related Objects") do not work properly with "Simple Edge" lines.  Your lines must be "Complex Edges" in order for you to use ConductorInfo and have those records be maintained on the split lines.  This is documented here.

            1 of 1 people found this helpful
            • Re: Are ConductorInfo records useful?
              Ed Blair

              Karyn -


              This is a great question.   I've often wondered the same thing.  Do we really need to normalize the model to account for the possibility of <three> distinct conductors?  (Or four if you put the neutral in there?)  Wouldn't it simplify life if just have Size and Material for phases A, B and C on the conductor feature?  We wouldn't need to worry about whether the related records are getting duplicated correctly on a split.  We wouldn't need to tip over the conductor feature every time to see size and material info.  We wouldn't need an auto-updater to keep a LabelText field updated if we want size and material information shown in labeling and annotation.


              I'm pretty sure there are companies out there that DO de-normalize the model -- though I'm also pretty sure they have customized some components of Designer, which expects conductor info in the related table for some work function operations.


              When the founding modelers set forth the basic Electric Distribution Data model back in 1999 or so, normalization seemed like the right thing to do. Given that was over a decade ago it certainly seems worthwhile to re-consider this direction.



              1 of 1 people found this helpful
              • Re: Are ConductorInfo records useful?
                David Miller

                I'll preface this by saying that we don't have the ConductorInfo table in our database nor do we use Designer.


                When we set up our GIS system 15 years ago, we did what Ed described: de-normalized the data and just drew one line to represent one, two, and three phase lines.  This works fine for us on overhead because we never mixed conductor sizes.  If a line was 1/0 aluminum, then all the phases were of the same size.  The same basically held true for underground conductor.  And all the lines were installed together at the same time, so the installation dates and records matched for all lines in a trench run  Until recently.


                As our distribution system has aged, I'm now realizing that in a multi phase run of conductor, one phase can be swapped out independent of the other phases.   While the wire size would be the same, the installation date and asset age will be different.  Without the ConductorInfo table, I can't track the different attributes of (for example) the C phase line (installed in 2013) separate from the AB lines(installed in 1975).  That, in turn, limits the analysis I can do on the system in the long run.  Because of that, I'm considering adding the ConductorInfo table back into the model.

                1 of 1 people found this helpful
                • Re: Are ConductorInfo records useful?
                  Matt Francis

                  I also think that's an interesting question.  As a long-time GIS user, for a long time I have puzzled why GIS data remains mostly non-normalized.  We are the only group of people that don't mind updating FIELD_B with values from FIELD_A + "." + FIELD_C.  Is that because of the legacy of GIS software, the perception of the people developing and consuming the data, or the fact that GIS is an animal wholly unique from other database applications?  After many years, I still can't answer that.


                  I am still very new to ArcFM and that suite of tools, but I would like to add that in a multi-user environment where the opportunity exists to have edits conflict, by moving certain aspects of features away from the feature itself, you minimize the risk of conflicts.


                  I had to edit... with a cross-post.

                  Is good database design less important for a spatial database - Geographic Information Systems Stack Exchange

                  1 of 1 people found this helpful
                    • Re: Are ConductorInfo records useful?
                      James Wright

                      I'm not entirely sure about this, but I know there are some 'performance' issues related with 'relationships' and GDB 'versioning' which I think may be part of the answer to your questions. I'm not sure 'versioning' of the nature ESRI provides is really common practice in other database systems... I know for a fact, ESRI highly recommends reducing relationships as much as possible as I believe the queries get quite complex when coupled with the lineage tree.


                      Additionally ESRI comments that 'symbolizing' off related records on features is quite slow... :

                      ArcGIS Help 10.1


                      "With many ArcGIS for Desktop Advanced coverage data models, the Feature Attribute table contains as few items as possible, and many of the attributes for a feature class are contained in a related table. This can be done with geodatabase feature classes; however, navigating a relationship in the geodatabase is a more costly operation than navigating relates in INFO. In the INFO environment, it was common to store the symbology for a feature in an external, related table called a lookup table. This can still be done in the geodatabase using relationship classes and joining the two tables; however, symbolizing large datasets this way will be slow, even with indexes on the primary and foreign keys. Try to keep attributes for symbolization on the feature class's table. For performance considerations, it is recommended that symbology information be stored in the feature class."


                      Lastly, non-geodatabases don't have the same type of  'view' requirements that can be related to the same intensity that exists when viewing an entire map of assets.

                    • Re: Are ConductorInfo records useful?
                      Karyn Peters

                      All of your answers were very helpful, and drove some other discussions & decisions.  Thanks!!


                      FYI, we've left these records in the data model and will re-evaluate their value when we've been operating in the system longer.