Latest Contributions by MarcoBoeringa

@ZihanSong  Is there any news to share about development around this tool? This tool is absolutely vital for a custom written geoprocessing toolbox that I have, that extensively uses Python scripting. Unfortunately, I have seen deplorable performance with this tool when using ArcGIS Query Layers using ultra large datasets (>100M records!) stored in an ordinary PostgreSQL / PostGIS database (non-enterprise geodatabase enabled!). E.g. I have seen it take >48 hours(!) to update symbology for a singly Query Layer using this tool. This totally wrecks the performance of my tools. I have absolutely no idea why this tool is so slow in these situations (note the underlying database and table is fully indexed), other then a hunch it is doing some very inefficient full table scan involving terribly slow cursors and inappropriate cursor handling for this size and type of data set. Very unfortunately, despite extensive reviewing of arcpy options, I haven't found any realistic alternative for my custom tool and workflow. E.g. due to the specific processing and highly dynamic processing flow, I absolutely cannot use something like a script tool output parameter's "Symbology" option, because my tool generates a large number of dynamically generated layers, not a fixed set of output parameter feature layers that could have symbology set via the tool parameter's "Symbology" option. There is also a large difference in the performance when having different type of input layers for the tool. E.g., using a 390M record dataset: - It takes 2 minutes to run the "Apply Symbology From Layer" tool when the data source of the feature layer in Pro is a SQLite based ESRI "Mobile Geodatabase" feature class - It takes about 3 hours to run the "Apply Symbology From Layer" tool when the feature layer in Pro is a Query Layer using a SQL statement referencing a dedicated table stored in PostgreSQL / PostGIS containing only those records used in the Query Layer, and the SQL statement is therefor of the type "SELECT * FROM <TABLE_NAME>" without a WHERE clause. - It takes >48 hours to run the "Apply Symbology From Layer" tool when the feature layer in Pro is a Query Layer using a SQL statement referencing a generic table stored in PostgreSQL / PostGIS containing those records used in the Query Layer but also others, and the SQL statement is therefor of the type "SELECT * FROM <TABLE_NAME> WHERE x=y", so including a WHERE clause. In all of the above cases, the data is actually the same (buildings from OpenStreetMap), just stored differently. As said, I don't understand why this tool needs to take so much time. It just needs to swap some symbols for the layer's symbology (note that I am explicitly using the 'update_symbology="MAINTAIN"' option in my arcpy code), and I would expect this to be near instantaneous. ... View more

I have been maintaining a good old "ArcMap" style *.tbx toolbox + python scripts compatible with ArcMap, ArcGIS Pro 1.x, 2.x, 3x for the past five years since Pro 1.x came out. I adapted the toolbox to be compatible with Python 2.x and 3.x, and thus ArcMap and ArcGIS Pro, according to the instructions ESRI provided in the Pro Help, and using e.g. the from __future__ import Python 2.x/3.x compatibility functions. Overall, I've found this pretty well manageable, especially using the ArcPy arcpy.GetInstallInfo() function to get product name and version, so as to be able to distinguish it in code and adapt code flow depending on the capabilities of a version of a product. So if you're reasonably well versed in python and arcpy, I wouldn't worry to much about it. And regarding the specific upgrade from Pro 2.x to 3.x: this was essentially without any issues. Tools just run, at least for my code base. The previous 1.x to 2.x upgrade did represent issues. ... View more

Note that you don't have to install the full .NET 6 SDK unless you intend to do development using ESRI's Pro SDK's. Pro 3.0 runs fine with just the .NET 6 Desktop Runtime: https://dotnet.microsoft.com/en-us/download/dotnet/6.0   ... View more

Hi Tierney, Somehow my brain managed to miss those red major road errors through optical illusion ;-)... I probably got distracted by seeing that major difference in the display of the white minor roads. One last suggestion I have for you is to increase the "Vector resolution" in DPI that you can set upon exporting a layout. I have seen some weird issues happening, e.g. entire layers missing upon export to PDF, when I had low values set for vector resolution. This was especially a problem though with ArcMap, that uses a rather different display engine than Pro, so I don't know if this will make a difference in Pro. Of course, since the display is fine in Adobe, but it fails in print, ultimately this seems to be more of an Adobe or printer driver issue, not so much related to ArcGIS itself. ... View more

If you refer to the very thin nature of the white roads in the print version of your PDF map, then I am almost certain this is not an issue in ArcGIS, but a mis-configuration in Adobe Reader's settings. Adobe, in its eternal wisdom, decided to make the "Enhance thin lines" option, which "thickens" thin lines upon display in Adobe Reader, default to ON. This means that thin lines show up wider than they are in the actual document (and in your ArcGIS settings). Many graphic designers have lamented this choice, as it falsely suggests a width that is not actually set in the document, and can ruin a good design. In your case, you should first disable the "Enhance thin lines" option in Adobe Reader's "Preferences" setting: - Go to Edit/Preferences, and then under "Page Display", disable "Enhance thin lines" You will now likely notice the lines display much thinner in Adobe Reader, similar to the print, and as you in fact set them in ArcGIS! So to correct that: - Go back to ArcGIS and set a wider width for your road lines, re-export the document to PDF and check if the widths are now satisfactory. ... View more

This is wild speculation, but searching for 'gdal*.dll' in the ArcGIS Pro installation folder, turns up a 'gdal_e.dll' instead of 'gdal203e.dll'. There is no 'gdal203e.dll' in my installation folder. If, like Dan suggests, the GDAL version of Pro is ESRI specific, they may have attempted to rename the DLL to a "version-less" name, but forgotten to update the name in some of the code using it. That would be a bug to report. Other option is that they failed to include this file in the installation, and it is a different one than the 'gdal_e.dll', and both should be on the system. As an experiment and proof, you might attempt to temporarily rename this DLL to 'gdal203e.dll' as in the error message, although it is likely this will cause many other issues where ESRI did properly change its name in the code base, or if the DLL is a different one than the missing 'gdal203e.dll'.     ... View more

@DanPatterson  you beat me to this idea! I spotted today when you create a new project from start or save a project that did not start from a template the default toolbox format is tbx. It would make sense that ArcPro creates the new atbx format as it appears to be a better future proofed format. Maybe ESRI is still "testing the waters" a bit with this brand new toolbox format, and didn't consider it wise yet to switch the default format. Frankly, considering ESRI's track record with "new" stuff, I can't blame them for that. ... View more

@ShitijMehta, any ideas what is causing this? ... View more

This thread may also have some relevance to the issue: https://community.esri.com/t5/arcgis-runtime-sdk-for-net-questions/limitations-on-exporting-map-tiles/td-p/1076466 Are these vector tiles? I don't know what the current status is, but historically it used to be that vector tiles were only generated at up to Z14 or Z17 so by default (e.g. just see this  "historic" Mapbox thread https://github.com/mapbox/vector-tile-spec/issues/53, with Mapbox being the designer of the original vector tile specification), and that the highest zoomlevel (Z14-17) was "supposed" to contain all detail necessary to display any of the higher zoom levels via "overzoom". Of course, that is quite a bold assumption, but allows to ditch a whole set of tiles and thus make huge savings on disk space and data transport. I think you can nowadays also generate tiles for higher zoomlevels, but it might need to be specially enabled somewhere. ... View more

Arcade and SQL are quite different languages. Arcade is more like a programming language, e.g. Python, not a SQL dialect. Therefor I don't think that there are that many options for converting one in another, it wouldn't be straightforward at least. It would be more logical to have a "Python-to-Arcade" conversion option for e.g. labeling expressions. ... View more

I don't think so, this is a SQLite feature (Geopackages are based on SQLite). SQLite supports the ability to "attach" other databases to a single database connection. The first database opened before you attach other databases, is called "main" (there is also "temp" for temporary stuff) by default: https://www.sqlite.org/lang_attach.html  The database names ("main" or another "<YOUR_ATTACHED_DATABASE_NAME>") are essentially treated as database "schema" names by SQLite. ArcGIS seems to inherit this structure (and I think for good reasons). Since SQLite databases are here to stay in ArcGIS, especially now ESRI also introduced the SQLite based "Mobile Geodatabase" data format, I suggest you start adjusting your arcpy scripts to handle this, rather than trying to avoid this. This will likely be the only viable option in the long run.     ... View more