Latest Contributions by MarcoBoeringa

@HannesZiegler and @Kimberly-Saballett  Just to clarify a bit more: regarding the detected issue with Python "concurrent.futures.ThreadPoolExecutor" hanging when run in the ArcGIS Pro 3.6 Foreground Thread, when I say "hangs" I literally mean hangs, the application does not crash nor does it throw open the ArcGIS Pro error reporter, but it simply becomes unresponsive at the end of the ThreadPoolExecutor execution, and doesn't continue processing. I need to kill Pro from the Windows Task Manager to stop the application. ... View more

Hi @HannesZiegler , I unfortunately have identified two other issues in Pro 3.6: 1) - The Get Count  geoprocessing tool now fails with a non(!) enterprise geodatabase enabled ordinary PostgreSQL enterprise database feature class. This used to work in Pro 3.5 and below. According to the "What's new in Pro 3.6", the Get Count tool had changes applied for Pro 3.6, that seems to break this option. See the images entirely below. 2) - Using a Python "concurrent.futures.ThreadPoolExecutor" seems to make the geoprocessing in Pro 3.6 hang at the end of the thread pool processing if the processing is run in the Pro Foreground Thread. I do not see these hangs if Pro 3.6 is set to run in the background Geoprocessing Thread, which is the default. ... View more

@HannesZiegler  I ran into a highly confusing issue with one of my main custom build Python scripts after the ArcGIS Pro 3.6 / Python 3.13 upgrade. When I attempted to run the script, which runs perfectly fine in Pro 3.5 / Python 3.11, the script immediately errored out with an "indentation error". However, there are none. Visual Studio Code, and PyScripter show the code as fine with their internal syntax checks. One thing I finally noticed, was that the error seemed related to a commented out code section: for renderRule in renderRulesInit: renderRules.append(renderRule.split('|')[0].rstrip(' ')) ## for layeredRenderRule in layeredRenderRulesInit: ## layeredRenderRules.append(layeredRenderRule.split('|')[0].rstrip(' ')) This code section lived directly under an: if __name__ == '__main__': styleFolder = arcpy.GetParameterAsText(0) styleName = arcpy.GetParameterAsText(1)  code section. Having such commented out section there, was never a problem with Pro <3.6 and Python <3.13. As a test, I changed the code with comment to this, so with comment lined out with the rest of the code: for renderRule in renderRulesInit: renderRules.append(renderRule.split('|')[0].rstrip(' ')) #for layeredRenderRule in layeredRenderRulesInit: # layeredRenderRules.append(layeredRenderRule.split('|')[0].rstrip(' ')) and then the script ran! Note that having similar comments lined out to the entire left of a code line in other functions is *no* problem, it is just those sections directly under '__main__' that now in Python 3.13 seem to cause these false "indentation errors", blocking execution of the script in Pro. Not sure if this is a bug in Pro 3.6, or more likely in Python 3.13. Can you confirm this? At least it would be good to document this behavioral change in the Pro Help if this is a deliberate and intended change in e.g. Python 3.13. Marco ... View more

I have never used it, and are also not much of an AGOL user, so can't comment on whether it would work there, but it sounds to me you may wish to use ArcGIS Dictionary Symbology:   https://pro.arcgis.com/en/pro-app/latest/help/mapping/layer-properties/dictionary-renderer.htm https://github.com/Esri/dictionary-renderer-toolkit   Although a lot of the documentation and the initial usage was geared to military mapping and symbology, you can actually use it for custom symbology as well in more recent versions of Pro. Here's a blog post documenting how to create a "custom" dictionary: https://www.esri.com/arcgis-blog/products/arcgis-pro/mapping/create-custom-dictionary-styles-for-arcgis ... View more

@JesseCloutier . The editing isssue is resolved for me. Thanks! ... View more

In the error I see reference to PostgreSQL's 'public' user schema. As of PG15, working with public schema to store user data has been strongly discouraged by the the PostgreSQL developers and community due to security concerns, and default access rights revoked. This may be causing you issues. I recommend you to create a new user with its own dedicated user schema and not grant it superuser rights but just leave it at its ordinary limited rights. ... View more

@JesseCloutier I am running into the same issue: no problem posting new posts, but no longer the ability to edit my own posts. Can you fix this? Honestly, I think ESRI should do an overall review of all users that lost their editing rights here in the community by whatever hickup that may have caused it. ... View more

About the life cycle: to me, any(!) bug and a fix for it that is detected in any of the current "general availability" major versions (which is generally the last three major releases, e.g. 3.3, 3.4 and 3.5) should be automatically applied and / or backported to all the other major releases in "general availability" if it is also applicable to those other major versions (there maybe cases where it is not, e.g. if the issue is only related to new functionality not available in lower versions). Currently, this is not the case, and ESRI seems to apply a highly opaque "vetting" system for backporting fixes that feels essentially random to Pro users, and only true security issues seem to automatically make their way to lower versions. ... View more

What happens if you make the path a raw string? So: arcpy.Exists(r"<YOUR_PATH>") ... View more

@RTPL_AU wrote: How valid is it to think that the release model should change to a mix of Long Term Stable + New Feature Releases Short Term Unstable? Introducing such Long Term Stable releases would only be a viable approach if the LTS release is actually actively maintained and being worked on with additional (backported) bugfixes. If it is just another unmaintained essentially dead release cycle nobody cares about, it would solve nothing. ... View more

I totally agree this approach of only "fixing" issues in new releases is highly problematic. In my opinion, a bug is only truly "fixed" if the fix is backported to the release cycle where the issue / bug was first introduced. Fixing issues only in new releases is "addressing" the issue, not fixing it. A fix for an issue / bug introduced into e.g. 3.4.0, should not require upgrading to 3.5 or 3.6, but should be addressed in a 3.4.x minor bugfix release. ... View more

Since this other thread about ArcGIS Monitor suggests the Datastore and associated database is just a regular PostgreSQL installation, the logical option to monitor your Datastore health would be any of the available (commercial) software packages for monitoring PostgreSQL database health. E.g. pgAdmin would be a logical choice. DBeaver is another option, and there others out there if you do a bit of searching. Although both of these suggested options are more about database management, and not so much about alerting or warning you when something catastrophic is about to happen. There are other options out there though, that do more of a kind of monitoring job if you do a bit of internet searching. ... View more

@TanuHoque  Thanks, I overlooked the setting, and hadn't really expected it to reside in the "Map and Scene" section of the Options. I expected this somewhere in "General"/"Geoprocessing" or maybe "User Interface". But at least I am glad to see it implemented! Now I need to get a horrid bug in Pro 3.4+ fixed that has plagued and totally blocked my workflow ever since the Pro 3.4 upgrade, and forced me to stick to Pro 3.3 to get anything done, so I will unfortunately not be able to take advantage of it anytime soon... ... View more

Honestly, that hardly sound like anything needing "special configuration". It is a tiny database by all measures nowadays. As said, I have run a PostgreSQL database with >2.5 B records on a single server. Secondly, any PostgreSQL configuration is also tightly coupled with the actual hardware specs. E.g. something like the 'shared_buffers' setting is almost always recommended to set as a percentage of your RAM, so unless you already know or share your configuration here, there is no sensible recommendation. That said, the three things that really will make a difference: - Do no run from HDD, use NVMe attached PCIe SSDs. It is hardly a question nowadays, but up to maybe five years ago, I still regularily read about people putting their database on HDD, which kills performance compared to modern NVMe SSDs. - Switch off 'synchronous_commit' in the postgresql.conf file. This is probably the single most effective configuration you can make if you do not need it (no replication to standby servers) to enhance performance on writes / UPDATEs. - Set an appropriate 'shared_buffers' setting to give PostgreSQL breathing room in RAM. All other settings are likely to only contribute minor, especially in a minor use case like yours. ... View more