nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Controleer op dubbele AssetID-waarden met Arcade

Billy

<\/HEAD>

Hallo, <\/P>

<\/P>

Ik heb een Arcade-regel die een assetid genereert wanneer een punt wordt ingevoegd. Deze code wordt gegenereerd door de afstand, in voet, van het ingevoegde puntobject tot een vaste referentiepunt te meten en af te ronden. Het proces kan herhaalde assetids genereren voor puntobjecten die zich op dezelfde afstand van het referentiepunt bevinden.<\/P>

<\/P>

Daarom probeer ik de nieuwe assetid te vergelijken met de bestaande met behulp van 2 for-lussen, met de onderstaande code.<\/P>

De code probeert de nieuwe assetid te vergelijken met alle bestaande (binnenste lus), als er een duplicaat is dan wordt de nieuwe assetid gewijzigd, opnieuw vergeleken, en als er geen duplicaat is dan wordt de buitenste lus verlaten.<\/P>

<\/P>

De regel werkt niet. Hij komt nooit in de if-verklaring binnen de binnenste lus, zie onderstaande code. Ik heb opzettelijk dubbele assetids gemaakt, zoals je kunt zien in de afbeelding hieronder. Ik heb geprobeerd een punt toe te voegen en de bewerking op te slaan, daarna nog een toe te voegen en opnieuw op te slaan, voor het geval de Arcade-regel het herhaalde assetid pas zag nadat de bewerkingen waren opgeslagen; maar dat werkte niet.<\/P>

<\/P>

Is er iets mis met de code of is er een betere en efficiëntere manier om dit te doen? <\/P>

<\/P>

<\/P><\/BODY><\/HTML>

Vind meer berichten getagd met

Accepted answers

All comments

RobertBorchert

You put the object id into a text field. I was under the assumption you were creating AssetID which is where you would put the objectID. Then add something to distinguish that it belongs to that Feature Class.

And possibly format the number so it is X number of characters long.

example.

New handhole. ObjectID 4824 formatted to HH004824 You would not use the objectID as the unique identifier for that Handhold because as you said when it goes to a different system the objectID's are new, but the unique AssetID would go where ever.

Using objectID as the BASE of the AssetID would prevent you from creating duplicate AssetID's automatically.

JohnAlsup

Objectid is only unique to that database. If you use any type of disconnected capabilities, your objectid's are not maintained and will be different between databases. I would not use ObjectID as a unique ID.

RobertBorchert

It would eliminated the need for this question. ObjectID will be unique for any new feature created in the feature class

Billy

Hi Robert,

What would be the benefit of doing what you propose?

RobertBorchert

Why not switch to generating it from ObjectID

Billy

Good to know. Thanks for the suggestion.

MikeMillerGIS

To help with debugging, use pop ups in ArcGIS Pro. That profile supports a lot of the same functions as attribute rules. This can help track down coding issues.

Billy

Hi Xander,

As you mentioned, we agree that the benefits of the UN worth the effort. At this point, we have created our data dictionary, selected the Tiers, AG/AT (AssetGroup/AssetType), and related tables that we need. Also, we deployed the Electric Utility Network asset package with the sample data (as a testing environment) and deployed the same asset package with the schema only and the special reference changed to our location (our project environment). Since we don't have GIS quality data to import directly to the UN, we have to basically draw the network one pole at a time, with the help of group and preset templates. But we have decided to start by creating all the substations, then the interconnecting lines between them, and finally the distribution circuits and the other assets (transformers, junction box, street lights, etc) Also we're are taking our time to clean and transform the data that will be added to the UN, which will be added to the features using Arcade rules.

Thanks again for your comments and suggestions. Here are my comments:

Your first point is very valid. I'll adjust the script accordingly.
For you second point, the rule is triggered by insertion. The type of assets (poles, junction box and hanholes) that will be using this rule to generate their assetid are not usually moved, so they will have that number until they are removed from the field. In reality, this id is acting more as a location id than an asset id, because the id will survive the asset. If a pole is replace at the same location, the new pole will get the same assetid. We know that this is not ideal from the point of view of asset management, but we will address this with an asset management system link to the GIS. Regarding your blog: Aqui se hable español. Lo leere con detenimiento, sole le di una hojeada.
I'm incrementing the distance, because we want to keep the id length to 6 characters. I was using the postfix as a print to console alternative. If Arcade had a development environment with step-by-step debugging and variables inspection, it would be easier to debug. I thinking something like what MS Office has for VBA.

Regards.

XanderBakker

Hi Billy Guerrero ,

I can imagine that changing from paper maps to the Utility Network is a huge leap in digital transformation and will requiere proper change management for those that will interact with the UN. However, the benefits that you will have as organization are priceless. How far are you in the process of implementing the UN?

I just looked at the 2nd expression you shared and there are a couple of questions and comments I have:

I see that you check at the end if the ID is not already set. You might want to do this at the start to avoid processing when it is not necessary
This also makes me wonder. What trigger did you define fro this attribute rule? If it is also trigger on update, and a point is moved to another area, the code would change, no only the prefix but also the distance. If you update the code based on these new aspects, you might create a hole in the sequence. Update triggers will need a different way of processing and some considerations of what you want to happen. I have a blog (in Spanish, sorry) of how this could be handled here: CRU2020 - Track Servicios Públicos - Arcade y Reglas de Atributos (although it uses database sequences)
I also notice that the format of the id has changed. You seem to increment the distance when a distance is "already in use". Is that correct? I thought that you were creating a postfix that will increment based on the number of id's that are already in use.

When I ignore an updates and changes in distance and the prefix, I would think that the logic could be something like this:

<SPAN class="comment token">// check first if the id is already set</SPAN>

<SPAN class="keyword token">var</SPAN> prefix <SPAN class="operator token">=</SPAN> <SPAN class="string token">"W"</SPAN><SPAN class="punctuation token">;</SPAN> <SPAN class="comment token">// assumably is extracted from a polygon fs</SPAN>
<SPAN class="keyword token">var</SPAN> dist_feet <SPAN class="operator token">=</SPAN> <SPAN class="number token">551</SPAN><SPAN class="punctuation token">;</SPAN> <SPAN class="comment token">// dist_degree(...);</SPAN>

<SPAN class="keyword token">var</SPAN> fsPolesRules <SPAN class="operator token">=</SPAN> <SPAN class="token function">FeatureSetByName</SPAN><SPAN class="punctuation token">(</SPAN><SPAN class="punctuation token">.</SPAN><SPAN class="punctuation token">.</SPAN><SPAN class="punctuation token">.</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
<SPAN class="keyword token">var</SPAN> idcode <SPAN class="operator token">=</SPAN> prefix <SPAN class="operator token">+</SPAN> <SPAN class="token function">Text</SPAN><SPAN class="punctuation token">(</SPAN><SPAN class="token function">Round</SPAN><SPAN class="punctuation token">(</SPAN>dist_feet<SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">,</SPAN> <SPAN class="string token">'00000'</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>

<SPAN class="comment token">// create a sql to query all features withe the same start of the assetid</SPAN>
<SPAN class="keyword token">var</SPAN> sql <SPAN class="operator token">=</SPAN> <SPAN class="string token">"assetid LIKE '"</SPAN> <SPAN class="operator token">+</SPAN> idcode <SPAN class="operator token">+</SPAN> <SPAN class="string token">"%'"</SPAN><SPAN class="punctuation token">;</SPAN>

<SPAN class="comment token">// filter the fs</SPAN>
<SPAN class="keyword token">var</SPAN> fs_filtered <SPAN class="operator token">=</SPAN> <SPAN class="token function">Filter</SPAN><SPAN class="punctuation token">(</SPAN>fsPolesRules<SPAN class="punctuation token">,</SPAN> sql<SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>

<SPAN class="comment token">// use the count to create a new code</SPAN>
<SPAN class="keyword token">var</SPAN> cnt <SPAN class="operator token">=</SPAN> <SPAN class="token function">Count</SPAN><SPAN class="punctuation token">(</SPAN>fs_filtered<SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
idcode <SPAN class="operator token">=</SPAN> prefix <SPAN class="operator token">+</SPAN> <SPAN class="token function">Text</SPAN><SPAN class="punctuation token">(</SPAN><SPAN class="token function">Round</SPAN><SPAN class="punctuation token">(</SPAN>dist_feet<SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">,</SPAN> <SPAN class="string token">'00000'</SPAN><SPAN class="punctuation token">)</SPAN> <SPAN class="operator token">+</SPAN> <SPAN class="string token">"-"</SPAN> <SPAN class="operator token">+</SPAN> <SPAN class="token function">Text</SPAN><SPAN class="punctuation token">(</SPAN>cnt<SPAN class="operator token">+</SPAN><SPAN class="number token">1</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="punctuation token">;</SPAN>
<SPAN class="comment token">// this will gloriously fail when existing points get moved </SPAN>
<SPAN class="comment token">// and the id is adjusted to those changes</SPAN>

<SPAN class="comment token">// return the result</SPAN><SPAN class="line-numbers-rows"><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN></SPAN>

Billy

Hi Xander,

When we were reviewing the different ways to create an assetid we tested the NextSequenceValue option, but we want to have an assetid code that would have some meaning, not just any random number. Our new assetid code has the information about the district where the asset it located and the distance from a reference point. Maybe you would wonder why someone would need that since you can get that information from the map, but when you are jumping from paper maps to digital maps with the utility network, this king of transition is not easy for everybody. Our current assetid system for poles is not database friendly (a lot of duplicate numbers) but it's very intuitive for the people in the field. With our implementation of the utility network we decided to change our current assetid system, but we want to replace it with something that will convey some information for the people in the field when they are not using the digital map.

I share your concern about performance with the nested for-loops and growing data volume, that's why I was wondering if there was another method. Right now we have less than 10K poles, but we don't expect that that number will increase beyond 10K. Yesterday, I came to the same conclusion that you are suggesting and this is the new rule:

The rule performance, in the test environment, with the ~10K poles on the map is almost the same that we experience when the rule was not checking for duplicate values, so it looks like performance won't be an issue. But we still have to test it in the production environment, where we are adding the poles with a group template that includes other features (lines, electric attachment and street lights)

Since the assetid generated by the rule includes a "prefix" (pole district), I'm thinking that maybe filtering the pole class by the "prefix", to reduce the dataset being tested for duplicates, could make the rule more efficient. What do you think? Also, I still wonder why the first rule didn't work, even if it's not very efficient.

Thanks.

XanderBakker

Hi Billy Guerrero ,

Just wondering, but why are you generating an assetid based on the distance in feet from a fixed point? Normally, when automatically creating an assetid, the recommendation is using the NextSequenceValue function in combination with a sequence defined in the database (Create Database Sequence—Data Management toolbox | Documentation ).

You also only showed part of the expression and I did not see any part where you return a value. Also, when the data volume starts growing, looping through the entire data will have an impact on performance. If you do need to use the distance for the assetid, use a filter first to only filter those that start with the same id and use the count to generate the new id and not a for loop. Also when there are 10 or more points at the same distance you will run into duplicate codes again with your code.

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.