|
POST
|
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
02-20-2023
11:29 PM
|
0
|
0
|
1890
|
|
IDEA
|
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
01-28-2023
09:41 AM
|
0
|
0
|
739
|
|
POST
|
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
09-29-2022
01:30 PM
|
0
|
0
|
1265
|
|
POST
|
@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
09-24-2022
02:58 AM
|
0
|
0
|
1282
|
|
POST
|
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
07-12-2022
02:49 PM
|
0
|
0
|
1089
|
|
POST
|
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
06-29-2022
02:46 AM
|
1
|
0
|
7630
|
|
POST
|
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
03-09-2022
01:38 AM
|
0
|
3
|
2993
|
|
POST
|
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
03-04-2022
02:09 PM
|
0
|
0
|
3032
|
|
POST
|
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
02-21-2022
12:02 AM
|
0
|
0
|
4933
|
|
POST
|
I already detected this same issue of disconnection for Query Layers in ArcGIS Pro 2.4... seems nothing changed... For the particular case I had, I worked around the issue by dumping the layer to a Pro layer file (*.lyrx) by saving it out, and editing the JSON directly using the Python 'json' module and "json.load" / "json.dump" methods. Note that this is wholly outside the realm of safe edits that ESRI probably supports, but if you are careful, and understand the CIM and know how to mentally translate it to the respective JSON structure, you can in fact edit the json directly by modifying the hierarchical dictionary structure that "json.load" will give you access to, and then dumping it back to the layer file, and subsequently re-load the layer file in ArcGIS. Note that the *.lyrx layer files are in fact stored in text format, not binary, so you can luckily inspect them and the CIM structure in a text editor, which helps getting it right. I know..., it makes you grind your teeth... knowing you should be able to do this no problem using "layer.getDefinition/setDefinition"...
... View more
02-09-2022
12:37 PM
|
1
|
0
|
3972
|
|
IDEA
|
@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
11-18-2021
04:55 AM
|
0
|
0
|
5298
|
|
IDEA
|
Currently, when a user makes any changes to the viewport, e.g. by zooming in or out on a Map or Layout, almost the entire User Interface is blocked / disabled by default until the drawing of the view is finished. Virtually the entire ribbon will be disabled, even the most used tools related to zooming, panning, or switching the scale of the map. Essentially the user can do nothing until the drawing has finished, and even switching the display off by hitting the "Pause" button doesn't help. This is a huge problem, and very much negatively affects user productivity. This is especially so for complex, high quality maps using extensive Maplex labeling, where it can takes minutes to draw a single view and have the labeling finish. I see absolutely no reason why crucial UI / ribbon elements like the zoom / pan / scale options should become disabled during drawing. It is an absolute nuisance and doesn't make sense: when you are searching for an area to use, you continuously want to be able to make adjustments until you find the right place. Having to wait up to minutes between each move, is a pain. Please review what tools truly must be disabled, and what tools can be left enabled. I appreciate that during some operations, it may be necessary from a technical point of view to disable a few buttons, but the current almost indiscriminate behavior affecting the entire ribbon is a major issue.
... View more
10-10-2021
10:46 PM
|
15
|
3
|
2000
|
|
POST
|
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
08-05-2021
03:40 AM
|
0
|
1
|
1228
|
|
IDEA
|
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
07-30-2021
01:42 PM
|
0
|
0
|
4436
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 01-31-2026 04:45 AM | |
| 1 | 12-08-2025 09:12 AM | |
| 1 | 12-05-2025 12:38 PM | |
| 1 | 12-04-2025 10:08 PM | |
| 1 | 12-04-2025 10:11 AM |
| Online Status |
Offline
|
| Date Last Visited |
03-11-2026
01:10 PM
|