Select to view content in your preferred language

FC has symbology and labelling permanently stored in GDB?

1107
12
Jump to solution
02-21-2024 07:13 AM
Labels (1)
Bud
by
Honored Contributor

ArcGIS Pro 2.6.8; Oracle 18c 10.7.1 EGDB:

There is a line feature class in our enterprise geodatabase that now seems to have default symbology and labelling defined at the GDB level. The symbology and labelling is a recent development; the FC was created years ago, but the symbology and labelling only started happening in the last 10 days.

If I add the FC to a new project, the lines are automatically symbolized as thick red lines and some of the features are labelled.

Notes:

  1. One of our users is confident that it was them that created the default symbology and labelling in Pro, as part of a recent initiative. But the user isn't sure how they managed to accidently define default labelling and symbology in the GDB for all users.
  2. The default symbology and labelling isn't shown if I add the FC to ArcMap. And it isn't preserved if I copy the FC via to a file geodatabase via Catalog (Pro).
  3. For what it's worth, the FC doesn't have a subtype.
  4. The Oracle table hasn't had any recent DDL changes:
    Bud_0-1708528553369.png
    So I guess the labelling and symbology information must be stored elsewhere, maybe in geodatabase system tables.
  5. The user doesn't think they made any annotations. And they weren't using ArcMap so they wouldn't have made any cartographic representations.

Question:

What mechanism might have been used to store the default labelling and symbology in the FC in the GDB? I want to know how it was done so that I can understand how it works and disable it if it causes issues.

Video:

1 Solution

Accepted Solutions
DrewFlater
Esri Regular Contributor

Hi @Bud was that dataset derived by running a system geoprocessing tool or a custom ModelBuilder model or Python script tool? Has that dataset been used in a ModelBuilder model or Python script tool that applies the thick red line and labeling? 

I am asking, because for a number of system geoprocessing tools and custom ModelBuilder or Python script tools that define the symbology of the output parameter, the geoprocessing framework stores a layer file representing that symbology and other layer properties in the dataset metadata so that if the dataset is added to another map, the symbology and layer properties are consistent to when the tool was originally run. 

This system was put in place early in Pro 2.x. The goal was that the result of an analysis often has a specific symbology and layer properties that are necessary for the result to be interpreted and understood, and when that info was not stored with the dataset, only the layer produced by running the tool would have the full information necessary for the result to make sense. It's been several releases at least since the Geoprocessing framework has done this. I am not familiar with the thick red line with labeling, so that's why I'm asking about custom model or script tools. 

A way to be sure the layer file has been stored in the dataset metadata is by exporting the metadata to an xml file and look for the LayerFile tag. Right click the dataset in Catalog and select View Metadata. In the Catalog ribbon tab, in the Metadata group, click Save As>Save As XML>All Content. Use the browse dialog to select a location and name for the xml file. The xml file will look something like below including the LayerFile tag (I highlighted in Purple - also the XML has been "pretty printed" for easier readability).

DrewFlater_0-1708545232799.png

When this LayerFile is present in the dataset metadata, when the mapping system adds that dataset to a map, the LayerFile properties are automatically applied to the layer. 

If you find the LayerFile and do not to keep this information, you can delete that part of the XML, save the file, then back in the Catalog, select the dataset, and in the Catalog ribbon tab, in the Metadata group, click Import and browse for the XML file that you saved with the cleaned out LayerFile.

If you can find what system or custom processes have been run using that dataset (the XML metadata also contains a useful lineage tag), we can then find out why the LayerFile had been embedded in the dataset metadata in the first place.

View solution in original post

12 Replies
MErikReedAugusta
Occasional Contributor III

Whoah, this could be incredibly useful when on purpose and incredibly annoying when on accident.

If you figure it out, I'd love to know more!

Bud
by
Honored Contributor
DrewFlater
Esri Regular Contributor

Hi @Bud was that dataset derived by running a system geoprocessing tool or a custom ModelBuilder model or Python script tool? Has that dataset been used in a ModelBuilder model or Python script tool that applies the thick red line and labeling? 

I am asking, because for a number of system geoprocessing tools and custom ModelBuilder or Python script tools that define the symbology of the output parameter, the geoprocessing framework stores a layer file representing that symbology and other layer properties in the dataset metadata so that if the dataset is added to another map, the symbology and layer properties are consistent to when the tool was originally run. 

This system was put in place early in Pro 2.x. The goal was that the result of an analysis often has a specific symbology and layer properties that are necessary for the result to be interpreted and understood, and when that info was not stored with the dataset, only the layer produced by running the tool would have the full information necessary for the result to make sense. It's been several releases at least since the Geoprocessing framework has done this. I am not familiar with the thick red line with labeling, so that's why I'm asking about custom model or script tools. 

A way to be sure the layer file has been stored in the dataset metadata is by exporting the metadata to an xml file and look for the LayerFile tag. Right click the dataset in Catalog and select View Metadata. In the Catalog ribbon tab, in the Metadata group, click Save As>Save As XML>All Content. Use the browse dialog to select a location and name for the xml file. The xml file will look something like below including the LayerFile tag (I highlighted in Purple - also the XML has been "pretty printed" for easier readability).

DrewFlater_0-1708545232799.png

When this LayerFile is present in the dataset metadata, when the mapping system adds that dataset to a map, the LayerFile properties are automatically applied to the layer. 

If you find the LayerFile and do not to keep this information, you can delete that part of the XML, save the file, then back in the Catalog, select the dataset, and in the Catalog ribbon tab, in the Metadata group, click Import and browse for the XML file that you saved with the cleaned out LayerFile.

If you can find what system or custom processes have been run using that dataset (the XML metadata also contains a useful lineage tag), we can then find out why the LayerFile had been embedded in the dataset metadata in the first place.

Bud
by
Honored Contributor

For our notes, Save As —> Save as XML —> All Content is greyed out.

Bud_0-1708635961916.png

This item has authored FGDC metadata that must be upgraded to ArcGIS metadata format before it can be used in ArcGIS Pro.

View Content


But I can I can click View Content which opens an XML file in Internet Explorer.

Like you mentioned, I can see the labelling and symbology properties in the <LayerFile> tag:

..."whereClause":"RDSEC LIKE 'A%' Or RDSEC LIKE 'B%' Or RDSEC LIKE 'C%' Or RDSEC LIKE 'D%' 
Or RDSEC LIKE 'E%' Or RDSEC LIKE 'F%' Or RDSEC LIKE 'G%' Or RDSEC LIKE 'H%' Or RDSEC LIKE
'J%' Or RDSEC LIKE 'K%' Or RDSEC LIKE 'R%' Or RDSEC LIKE 'S%' OR RDSEC LIKE 'T%' OR RDSEC
LIKE 'W%'","visibility":true,"iD":-1}],"labelVisibility":true,"renderer":
{"type":"CIMSimpleRenderer","patch":"Default","symbol":{"type":"CIMSymbolReference","symbol":
{"type":"CIMLineSymbol","symbolLayers":[{"type":"CIMSolidStroke","enable":true,"capStyle":
"Round","joinStyle":"Round","lineStyle3D":"Strip","miterLimit":10,"width":6,"color":
{"type":"CIMRGBColor","values":[168,0,0,100]}}]}}},"scaleSymbols":true,"snappable":true}]}
</LayerFile>

Bud_2-1708636695141.png

The full XML file seems to have some somewhat sensitive connection information in it. So I won't post it publically. But I can send it to you in a private message. Maybe between the two of us we can figure out what GP tool, model, or script inserted the layer file into the metadata.

I've also asked my colleague if a GP tool, model, or script was used on the FC. Waiting to hear back.

 

0 Kudos
Bud
by
Honored Contributor

For my notes:
The key to getting the XML to be formatted properly in Notepad ++ was to remove line breaks first, then format the XML.

Bud_0-1708711248422.png

 

0 Kudos
MErikReedAugusta
Occasional Contributor III

@DrewFlater Out of curiosity, what happens if you open a Feature Class like this in an older version of ArcPro, or even in ArcDesktop?

I can see some potential uses for this, but there's a significant chunk of our organization that we haven't been able to transition from Desktop 10.8, yet.  The Pro users on my team are all on 3.1.3, and I think the other Pro users in the organization are as well, but there's a non-zero chance someone managed to sneak through on an older version, for all I know.  (That's all pretty far about the pay grade of my team).

The first thing I'd need to make sure before going down this rabbit hole is that it won't brick anything for those users who haven't been fully brought up-to-date.

 

(As an analogous situation: We've noticed that once a Feature Class has Attribute Rules assigned, it can no longer even be opened in ArcGIS Desktop, which is one of the big delays our IT department is facing in the switchover, across the organization.  Even departments ready to make the switch can't do so until other departments sharing the data are also ready to make the switch.  I'd want to make sure this wouldn't be one of those situations.)

BarryNorthey
Occasional Contributor III

I stumbled across the layer file embedded in metadata scenario while working in ModelBuilder in AGP 3.2.2. For test purposes, I ran 3 GP tools as single processes in ModelBuilder: Buffer, Export Features and XY Table To Point with Single Symbol and Unique Values symbology and got consistent embedded layer files in the output's metadata when using this workflow:

  • Add the target feature class (stored in the Project's Home fGDB) to a Map --> symbolize.
  • Start a Model
    • The Model's current and scratch workspace environments are the Project's Home fGDB.
    • On the Model canvas --> insert the GP tool such as Buffer.
    • Set the tool input to the layer in the Contents pane and other necessary parameters.
    • Double click on the output element --> click on Properties. The Template (.lyrx) should be blank.
    • Use the pulldown and set the Template to the symbolized input layer in the Contents pane --> OK.
    • Validate and Save the model.
    • Run the Model

Before you do anything else, locate the newly created layer file in the Project's Home folder and delete it.

Check the results as follows:

  • Add the new output feature class to the current Map or any Map in the Project to see if the symbology came across.
  • Copy the feature class to another location and add the copy to a Map in this or another Project to confirm that the Symbology is coming with it.
  • From a Catalog View, save the new feature classes metadata to an XML file.
    • Open the XML file and search for (tag) layerfile to see the embedded info in the metadata. 

Might have something to do with this:

BarryNorthey_0-1712683153398.png

Other workflows and data types might or might not work.

 

Bud
by
Honored Contributor

@DrewFlater's comments about the full XML file:

Here are the processes run on that dataset from the Lineage, from oldest (2011, basically when the very original source data was created) to very recent (few days ago)

  • FeatureClassToFeatureClass_conversion
  • CreateRoutes_lr
  • MigrateStorage_management
  • CalculateField_management
  • Append_management
  • AddRelate_management
  • CalculateField_management

Nothing in this list has a defined symbology for the output that the GP tool/GP framework would be applying into the metadata. But it seems like the symbology got burned into the metadata when the layer was named INFRASTR.STRLN_ROUTE. This feature was installed in Pro 2.3. From that release until 2.7, it is possible that running even simple tools like Copy Features or Feature Class To Feature Class would store the input symbology into the new output dataset metadata. This was an error that was corrected at 2.8. But the Feature Class To Feature Class record in the metadata lineage is from way back in 2011, so that timeline doesn't really make sense for how the symbology/LayerFile came to be embedded in the dataset metadata recently. 

0 Kudos
Bud
by
Honored Contributor

ArcGIS Pro 2.6.8; Oracle 18c 10.7.1 EGDB:

It looks like the Add Relate tool is the culprit (I didn't test Calculate Field). I'll send you a video in a private message.

Steps:

I'm working in a different environment --  a dev environment.

  1. Create a new ArcGIS Pro session/project.
  2. Add FC to map.
  3. Apply symbology using a default symbol from the gallery.
  4. Apply the SQL expression from the XML file (from the prod FC).
    RDSEC LIKE 'A%' Or RDSEC LIKE 'B%' Or RDSEC LIKE 'C%' Or RDSEC LIKE 'D%' Or RDSEC LIKE 'E%' Or RDSEC LIKE 'F%' Or RDSEC LIKE 'G%' Or RDSEC LIKE 'H%' Or RDSEC LIKE 'J%' Or RDSEC LIKE 'K%' Or RDSEC LIKE 'R%' Or RDSEC LIKE 'S%' OR RDSEC LIKE 'T%' OR RDSEC LIKE 'W%'
  5. Enable labelling via right-clicking the layer in Contents.
  6. Rotate the map to -19 degrees.
  7. Add a standalone table to the map that will be related to the FC.
  8. Use the Add Relate tool to relate the FC to the standalone table.
    Bud_1-1708973271455.png
  9. Point to related records: FC —> standalone table.
  10. Add FC to the map (again).
  11. The symbology and labelling persist in the new feature layer.
  12. Close ArcGIS Pro and re-open; create a new project.
  13. Add FC.
  14. The symbology and labelling still persist in a new project/session.


The steps only seem to "work" (permanently apply symbology and labelling) about one in every three times. I’m not sure why it only works sometimes.

I’m not sure if all of those steps are necessary. Likely not. It was kind of fiddly to test, so I ended up just finding a set of steps that worked and sticking with them.

The steps can also be used to remove the permanent symbology and labelling if it already exists.

It’s pretty strange behavior. But if I'm understanding your comments above correctly, it sounds like it’s been removed in newer versions of Pro.

0 Kudos