<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Additional asset information in Utility Network 2.0 in Gas and Pipeline Questions</title>
    <link>https://community.esri.com/t5/gas-and-pipeline-questions/additional-asset-information-in-utility-network-2/m-p/701683#M563</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;For medium and large sized utilities a lot of this detail is stored and maintained inside external asset management systems (Cityworks, SAP, Maximo, and WAM are the ones I've seen the most).&amp;nbsp;&amp;nbsp;Related data you're going to be using in things like collector is going to be captured in related tables (the example packages have inspections done this way).&amp;nbsp; Other misc related data can be stored in flat tables and then either related or joined to the source data&amp;nbsp;as needed.&amp;nbsp; I wouldn't recommend having these joins and relates in your day-to-day editing displays since they'll impact performance, but having specific views that pull in several aspects of this data at a time is pretty typical.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Tue, 31 Jul 2018 00:26:47 GMT</pubDate>
    <dc:creator>RobertKrisher</dc:creator>
    <dc:date>2018-07-31T00:26:47Z</dc:date>
    <item>
      <title>Additional asset information in Utility Network 2.0</title>
      <link>https://community.esri.com/t5/gas-and-pipeline-questions/additional-asset-information-in-utility-network-2/m-p/701682#M562</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I don't see anywhere for additional asset information to stored in the new Utility Network 2.0.&amp;nbsp; Manufacturer information, service dates... additional information that could be useful to a worker in the field.&amp;nbsp; ESRI recommends against using joins with this data.&amp;nbsp; Is that what Notes is for?&amp;nbsp; Are we supposed to add a lot of additional fields?&amp;nbsp; Does anyone have a strategy for this type of information?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 30 Jul 2018 18:53:19 GMT</pubDate>
      <guid>https://community.esri.com/t5/gas-and-pipeline-questions/additional-asset-information-in-utility-network-2/m-p/701682#M562</guid>
      <dc:creator>StevenBell2</dc:creator>
      <dc:date>2018-07-30T18:53:19Z</dc:date>
    </item>
    <item>
      <title>Re: Additional asset information in Utility Network 2.0</title>
      <link>https://community.esri.com/t5/gas-and-pipeline-questions/additional-asset-information-in-utility-network-2/m-p/701683#M563</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;For medium and large sized utilities a lot of this detail is stored and maintained inside external asset management systems (Cityworks, SAP, Maximo, and WAM are the ones I've seen the most).&amp;nbsp;&amp;nbsp;Related data you're going to be using in things like collector is going to be captured in related tables (the example packages have inspections done this way).&amp;nbsp; Other misc related data can be stored in flat tables and then either related or joined to the source data&amp;nbsp;as needed.&amp;nbsp; I wouldn't recommend having these joins and relates in your day-to-day editing displays since they'll impact performance, but having specific views that pull in several aspects of this data at a time is pretty typical.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 31 Jul 2018 00:26:47 GMT</pubDate>
      <guid>https://community.esri.com/t5/gas-and-pipeline-questions/additional-asset-information-in-utility-network-2/m-p/701683#M563</guid>
      <dc:creator>RobertKrisher</dc:creator>
      <dc:date>2018-07-31T00:26:47Z</dc:date>
    </item>
  </channel>
</rss>

