Latest Contributions by MarcoBoeringa

Before the upgrade to Pro 3.1, were you using the default 'arcgispro-py3' Python environment, or a customized clone created with the ArcGIS Pro "Package Manager"? If the latter, I guess you may need to update the cloned Python environment for the latest version. Pro will even automatically switch to the default 'arcgispro-py3' environment, if the clone is not up-to-date, and display a warning, so you may be missing vital packages now that you installed in the clone. The "Environment Manager" that is part of the "Package Manager" will show this with a special icon next to the environment that offers the option to upgrade the environment, which seemed to work well in my personal case. Only after upgrading, will you be able switch back to your customized cloned environment and activate it for use in your workflow and scripts. ... View more

Well, exactly as you say: you create a geodesic buffer (which is the only really accurate buffer), and compare the result with a plain circle with radius calculated in what is likely a high distortion projection like Web Mercator. This is the classic "Greenland-is-as-big-as-Africa" in Web Mercator problem, where in reality Greenland is far smaller than the Africa continent. In such situations, at high latitude, the "plain circle" will be much smaller than the geodesic buffer, and severely underestimate / under-represent the real size of the buffer (which, again, can only be properly represented by the geodesic buffer). If you need accurate buffers in a high distortion projection like Web Mercator, only use geodetic buffers. If you have a low distortion local projection (e.g. data within one UTM zone), you can get away with using planar buffer calculation, and it will be relatively accurate (but still not as good as geodetic). ... View more

I think your best bet to accomplish this is to convert the dynamically placed Maplex labels to annotation using the: "Convert labels to annotation" geoprocessing tool in ArcGIS Pro as this will give you a geodatabase table with data about the labels, which should include their text. I know of no other good way to get the data of the displayed labels, e.g. there is no "listVisibleLabels" property on something like a Layer object in ArcPy. ... View more

I actually now managed to workaround this performance issue of the "Apply Symbology From Layer" related to "Query Layers". I have actually been contemplating options for a significant amount of time, but overlooked a relatively straightforward solution that works for my specific case: temporarily rename the original table in the database just before running the "Apply Symbology From Layer" tool, create a database view with only a single record of this renamed table using the original table's name (I use a selection with MAX on the objectid column in the SQL), and subsequently run the "Apply Symbology From Layer" tool against the layer now referencing the single record database view. This is very fast and makes the tool's performance independent of the underlying table size of the original table. After running the tool, I delete the view, and rename the secondary table back to the original table's name. Fortunately, a Query Layer already in the TOC doesn't seem to be affected by temporarily knocking out its datasource, so this rather drastic measure doesn't seem to have negative side effects. It would still be nice though if the original issue is fixed. ... View more

@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