Lead Service Line Solution - "dot" labels suddenly disappeared on service line point features

[JayHodny]

Hi.  I have been working with the LSL ServiceLine layer for some time now.  I then created a feature class on our sde geodatabase of the data.  Symbology and labeling came over from the service layer to the sde feature class.  All was fine for several months.  Today I was working on editing and updating utility- and customer-side fields, and the "dot" labeling disappeared.  I cannot figure out how to restore the "dots."  I had this happen when I first started using the solution, tech support helped, but I cannot remember what we did.  I hope someone has the answer!  Thanks in advance, Jay

[AlexKabak · Accepted solution]

Hi Jay,

Did you update the values in Utility Side Verified and Customer Side Verified to be "Yes"? That would have the dots disappear as intended.

[JayHodny]

Hi Alex,

Yes, I have been updating the verified fields.  The dots have been present for months, disappearing as expected, when I update the verified fields.  The Arcade code is present in the labeling properies pane.  On top of this, I began to have trouble Friday with symbology failing during a join to another layer.  Maybe the two, labeling and symbology, are related?  In addition, to updating my LSL FC with the Survey123 results, I was attempting to bring over water main, curb stop, and lateral line material values from the other sde FCs, to better populate the service line layer.  I started getting the following error message: 

Warning:   
Primary symbology relies on one or more fields that are invalid.

I found a technical bulletin work around which helped me correct the symbology issue, but the dot labelling was never restored.  I really don't know what else to do.  I have updated10,000 records and worry about something being corrupted.  I was close to concluding the historic data search, and now the above starts to happen.

[JayHodny]

Hi Alex,

I believe the dot labeling issue has to do with the join I have in place.  It appears the Arcade labeling code from the original solution gets updated or overwritten based on the newer field names.  In testing in a separate Pro project, if I replace the Arcade code with the code from the original solution the dot labeling returns.

Original Solution Arcade code

if($feature.utilverified != "Yes" && $feature.custverified != "Yes") {return " ●●"}
else if($feature.utilverified != "Yes" && $feature.custverified == "Yes") {return "●"}
else if($feature.custverified != "Yes" && $feature.utilverified == "Yes") {return " ●"}

My feature class Arcade code. I have no clue why the Survey123 L0ServiceLine field names are shown or where this comes from?  wLSLServiceLines is my feature class on sde, created from the ServiceLine layer, and represents our source of truth.  Again, the dot labeling and symbology were working fine for the past several months with this feature class.  I think I can simply replace the current code with the solution's original code and all will be well.  I would like confirmation though.  And thank you for your help!

if($feature['.....wLSLServiceLines.L0ServiceLine.utilverified'] != "Yes" && $feature['.....wLSLServiceLines.L0ServiceLine.custverified'] != "Yes") {return " ●●"}
else if($feature['.....wLSLServiceLines.L0ServiceLine.utilverified'] != "Yes" && $feature['.....wLSLServiceLines.L0ServiceLine.custverified'] == "Yes") {return "●"}
else if($feature['.....GIS.wLSLServiceLines.L0ServiceLine.custverified'] != "Yes" && $feature['.....wLSLServiceLines.L0ServiceLine.utilverified'] == "Yes") {return " ●"}

[JayHodny]

Bingo!  I think I have this resolved.  I modified the script to remove the 'L0ServiceLine' in the field name, and this restored the dots in my wLSL feature class.  I don't know how this happened in the first place, but I know what to do going forward.  Thank you again for your help.

[AlexKabak · Accepted solution]

Hi Jay,

The 'L0ServiceLine.' prefix for the fields were added when the join was created. The system adds the prefix in the event the two layers being joined (in your case a feature class layer and a feature service layer) have the same field name, it is able to differentiate between the 2. The 'L0' is the layer ID of the ServiceLine layer of the ServiceLine feature service, standing for 'Layer 0'.

Glad you were able to find a fix for your issue.