Latest Contributions by MarcoBoeringa

This mess is causing me to become incredibly defensive in my code and type guarding basically everything and finding alternative ways to access data (I have a whole class that wraps mapping objects and has fallbacks for when attribute access fails). I understand, but ESRI should really sort out the underlying technical problems... we shouldn't be forced to worry about differences between Foreground or Geoprocessing Thread processing... at least that is what all ESRI documentation about the new feature suggests: simply compatible with all workflows (and that is how I think they intended it to actually be). ... View more

By the way, the reason I am not simply using the 'symbologyLayer' input variable of my 'updateSymbology' function as in the code section below as input to the "Apply Symbology From Layer" geoprocessing tool - but instead a reference to a layer file ('symbologyLayerFile') that was originally used to create the 'symbologyLayer' in the TOC - is that when in the past I switched from ArcMap to ArcGIS Pro, I discovered the original code would not update the symbology if fed the layer object, but that it would if I switched to the layer file as input, if I remember it all well. I have now also tested if switching back to layer object 'symbologyLayer' makes any difference for the Foreground Thread processing, but to no avail, the updating of the symbology still fails on the Foreground Thread, while succeeding on the Geoprocessing Thread. if len(inputSymbologyFields) > 0: symbolizedLayer = arcpy.ApplySymbologyFromLayer_management(featureLayer,symbologyLayerFile,inputSymbologyFields,update_symbology="MAINTAIN")[0] else: symbolizedLayer = arcpy.ApplySymbologyFromLayer_management(featureLayer,symbologyLayerFile,update_symbology="MAINTAIN")[0]   ... View more

@JeffBarrette  This is the full code of the 'updateSymbology' function. Note that I call it with 'aprxMap=None', see in the debugger.  Also note that in the particular example shown in the screenshots above, the 'len(inputSymbologyFields)=0' because it is a single symbol legend type. Lastly, note that it is actually a string file path to the layer file stored on disk that is input to the actual call to the "Apply Symbology From Layer" tool, NOT the 'symbologyLayer' (which is however based on it, and was added to the TOC for technical reasons), which is in this function just used to check for symbology fields. def updateSymbology(featureLayer,symbologyLayer,symbologyLayerFile,aprxMap): try: inputSymbologyFields = [] symb = symbologyLayer.symbology if hasattr(symb, 'renderer'): for fieldNamePrefix in ['osm_','tgc_']: if symb.renderer.type in ['UniqueValueRenderer']: # Loop through all value fields, there can be multiple in case of a unique value renderer for valF in symb.renderer.fields: if valF is not None and valF.find(fieldNamePrefix) != -1: inputSymbologyFields.append(['VALUE_FIELD',valF,valF]) elif symb.renderer.type in ['GraduatedColorsRenderer','GraduatedSymbolsRenderer']: valF = symb.renderer.classificationField for symF in [valF]: if symF is not None and symF.find(fieldNamePrefix) != -1: inputSymbologyFields.append(['VALUE_FIELD',symF,symF]) norF = symb.renderer.normalizationField for symF in [norF]: if symF is not None and symF.find(fieldNamePrefix) != -1: inputSymbologyFields.append(['NORMALIZATION_FIELD',symF,symF]) if len(inputSymbologyFields) > 0: symbolizedLayer = arcpy.ApplySymbologyFromLayer_management(featureLayer,symbologyLayerFile,inputSymbologyFields,update_symbology="MAINTAIN")[0] else: symbolizedLayer = arcpy.ApplySymbologyFromLayer_management(featureLayer,symbologyLayerFile,update_symbology="MAINTAIN")[0] if StyleSupportingFunctions.getCanSetLayerVisibility(symbolizedLayer) == True: try: symbolizedLayer.visible = False except: pass if aprxMap is not None: aprxMap.addLayer(symbolizedLayer, "AUTO_ARRANGE") symbolizedLayer = aprxMap.listLayers(symbolizedLayer.name)[0] return [True,symbolizedLayer] except Exception as e: # If an error occurred, print line number and error message import sys tb = sys.exc_info()[2] errorMsg = "Line %i" % tb.tb_lineno errorMsg += '\n' + e.args[0] if len(e.args) > 1: errorMsg += '\n' + e.args[1] if len(e.args) > 2: errorMsg += '\n' + e.args[2] return [False,errorMsg]   ... View more

@JeffBarrette and @HannesZiegler , More important observations, see screenshots including debugger:   ... View more

@JeffBarrette , Few more observations that also exclude other stuff: - I have now realized the entire updating of the symbology fails. I should have noticed before, but due to a mix of issues (e.g. the full hangs caused by 'gc.collect'), I never really got to the point where the final output layers are added in their symbolized form on Foreground Thread. - The fact the symbology of the layer is not applied, also likely means the transfer of label classes fails, hence the default symbology and generic "Class 1" label class name. - I have checked that the "Apply Symbology From Layer" tool runs fine on the Foreground Thread when run as stand alone tool simply from Pro interface. It applies the symbology OK. - So somehow it fails in my current coding using it on the Foreground Thread, even though it succeeds on the Geoprocessing Thread. Still baffles me. I need to do more testing to see if can pinpoint a culprit in my coding that might point to a Pro issue (or just some weird Python related thing, or the way my Python code in these particular modules involved is setup that causes the issue). ... View more

Cross reference from my experiences: https://community.esri.com/t5/python-documents/python-in-arcgis-pro-3-6-faq/tac-p/1665790/highlight/true#M669 ... View more

@JeffBarrette : Issues with Editors using the new threading options for running GP tools  ... View more

@JeffBarrette  Please note I do appreciate your efforts to try to reproduce it. I just think it needs a bit more digging and effort from the ESRI side. As I already explained to @HannesZiegler , this particular piece of code is part of larger toolbox with some 20k lines of Python code, with a few dozen Python modules. I honestly cannot transfer the whole thing. And that is what I mean with "there is a *lot* more going on". However, I am almost 100% sure we can safely ignore that fact in relation to this is issue. Why?: What it basically does is implement a sophisticated generalization workflow that generates a 150+ feature classes in PostgreSQL database. At the end of that processing, so when all the true geoprocessing work is done, the script from which I extracted the snippets, is called. It loads layer files from a custom style I developed (just an ordinary folder with *.lyrx files managed by the code, nothing special), and uses the symbology of those style layers in combination with the  symbolizedLayer = arcpy.ApplySymbologyFromLayer_management(featureLayer,symbologyLayerFile,inputSymbologyFields,update_symbology="MAINTAIN")[0] tool to update the symbology of Query Layers that were created during the previous generalization geoprocessing workflow and that point to the feature classes in the PostgreSQL database. It also transfers any label classes from the style layer to the Query Layers. Granted, the transfer of all of theses attributes / settings of one layer to another I think has become easier in Pro 3.6 with new options if I remember it well from the release notes, but my current code is based on what was possible in the past. That said, as you may now understand, by far the majority of "there is a *lot* more going on", is really unrelated to anything to do with actual feature layer objects in the TOC. It is database work and processing. Only a fraction of the code touches upon the parts that might be relevant to this issue. By the way, if by now you are wondering what the output of this whole workflow is, it is the below: topographic maps based on OpenStreetMap data... ArcGIS Renderer for OpenStreetMap - The Netherlands - Valkenburg 1:25k - UTM31N ArcGIS Renderer for OpenStreetMap - The Netherlands - Schiermonnikoog 1:50k - UTM31N ... View more

@JeffBarrette , One other thing that may be highly relevant to the issue and that I didn't mention yet, is that my tool does NOT use layers from the ArcGIS TOC, but first loads them from ArcGIS *.lyrx files stored on disk, modifies the Maplex settings per e.g. the code I showed you (in reality there is a *lot* more going on), and then finally adds them to the TOC. Maybe this is part of the issue why you can't reproduce. ... View more

Part of the CIM layer object properties:     ... View more

@JeffBarrette , I now ran the workflow with ArcGIS Pro attached to the Visual Studio Code debugger using the ESRI debugger extension. I don't think it turns up much new information, but as you can see, it is not just the label class name that got reset to 'Class 1', but all label class properties seem to have been reset to defaults in the CIM object.     ... View more

@JeffBarrette  I can talk with the labeling team to see if the smoking gun you suggest could have been caused by changes made during 3.6 development. Yes, I think you should. ... View more

@JeffBarrette Another thing I intend to do is to try to run ArcGIS Pro attached to the ESRI Visual Studio Code debugger. Maybe that will give some new insights. There is not much more I can and will do. Honestly, I do not want to sound to cynical here and I understand your frustration regarding the reproducibility, but I as an ESRI client, am not the one getting paid for debugging Pro, and believe me, there is a bug lurking here. After 25 years in IT and working with ESRI software, I can smell them from a mile's distance. And remember, my code runs perfectly fine on the Geoprocessing Thread... ... View more

@JeffBarrette , Although you say you tried to reproduce my workflow based on my script sample, your script is missing the setting of the disabling of ligatures in case Maplex spread characters is set on a label class, that I included in my last code snippets. (Background for this: these settings in Maplex are incompatible from a cartographic point of view, and cause garbled incorrectly rendered labels with two ligature characters in Latin grouped together, while the rest spread, e.g. "a...bc...d...e...f" instead of cartographically correct "a...b...c...d...e...f", unfortunately, ArcGIS Pro by default activates ligatures since it introduced support for them in Maplex).   # Change the 'ligatures' label class text symbol setting to false if gType in ['Line','Polygon']: for cimLabelClass in cimLyr.labelClasses: # Double check we got a label class if type(cimLabelClass).__name__ == "CIMLabelClass": try: if cimLabelClass.maplexLabelPlacementProperties.spreadCharacters == True: cimLabelClass.textSymbol.symbol.ligatures = False except Exception: arcpy.AddWarning("*** WARNING ***: Failed to set the label class text symbol's 'ligatures' setting to 'false' for layer '{}'!".format(lyrToAdd.name)) pass   ... View more

The layer that failed in the screenshot examples I showed, was of type Polygon by the way. ... View more