Latest Contributions by MarcoBoeringa

‎03-09-2022

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.

‎03-04-2022

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.

‎02-21-2022

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'.

‎02-09-2022

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"...

‎11-18-2021

@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.

‎10-10-2021

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.

‎08-19-2021

@ShitijMehta, any ideas what is causing this?

‎08-05-2021

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.

‎07-30-2021

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.

‎07-29-2021

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.

‎07-28-2021

@DylanT_EsriCanada This is unfortunately not really a solution... What is a possible "workaround" is the suggestion / workaround listed with the bug you referenced (BUG-000141015, you need to login to the Technical Support site and search for this bug number to see the full listing of this bug): "Manually copy arcgis\bin\python\envs\arcgispro-py3\Lib\site-packages\arcgisscripting\_arcgisscripting.pyd to the appropriate location in the cloned environment." The unspecified "appropriate location" seems to be simply the equivalent "Lib\site-packages\arcgisscripting" subfolder of the cloned environment (full path "C:\Users\<YOUR_USER_NAME>\AppData\Local\ESRI\conda\envs\arcgispro-py3-clone\Lib\site-packages\arcgisscripting"). There is already an existing "_arcgisscripting.py" file there, overwriting it though, solved my issues with the cloned Python environment in a project not being properly recognized and switching back to default.

‎02-19-2021

I think you will need to use table name aliases for the two join sections to avoid this. I see it is a self-join, but that doesn't make a difference. This will also make your query much more readable, as you don't need to repeat the whole long concatenation of "GISWRKS1.works.INSPECTIONS_HYDRANT_INSPECTION", but can instead refer to the aliases. The error message suggests SQL Server already attempted to add an alias automatically ('a.'), but since it is self joined table, likely used only the 'a' alias, and not a second one, e.g. 'b', for the table to join.

‎01-23-2021

Are you able to connect to this database at all, e.g. by setting up an ODBC connection in Windows and using the connection test option there? Maybe one of the posts in this other thread is of some use: https://community.esri.com/t5/arcgis-enterprise-questions/solved-amazon-postgresql-rds-enable-enterprise-geodatabase/td-p/643107

‎01-20-2021

@TheodoreF wrote: Every ArcGIS Pro user has access to the geocoder installed by default That may be so, but not everybody uses it, so that is why I think it is relevant to explicitely add this information to your support case. @TheodoreF wrote: I've sent my log to my ESRI case, so hopefully that'll help anyway. Don't know if there is any additional info in the log besides the sample entry you showed, but certainly won't hurt to send it to them.

‎01-20-2021

As you now confirmed you are using a geocoding service, and you stated you opened a support case with ESRI, I think it might be useful to add this information about your usage of geocoding to the support case, as it may be relevant to the bug. It might help ESRI finding the source of the problem. Entirely agree your disk shouldn't fill up with so many files, all the more reason to keep ESRI posted with any potential new leads you find.

Online Status	Offline
Date Last Visited	a week ago

My Ideas

Latest Contributions by MarcoBoeringa

Re: Roads Print Incorrectly from Correct PDF

Re: Roads Print Incorrectly from Correct PDF

Re: ArcGIS Pro failed to open gpkg polyline layers

Re: arcpy in ArcGIS Pro 2.9.1 - Setting a CIM definition on a query layer causes the layer to become disconnected

Re: Toolbox format for new projects

Stop indiscriminately blocking the entire ArcGIS Pro User Interface (UI performance) during drawing

Re: ArcGIS Pro 2.8 ModelBuilder showing wrong In Features

Re: Failure / Bugs to upload Tile Cache to ArcGIS Online for cache greater than 1TB

Re: Toggle for converting SQL expressions to Arcade

Re: GeoPackage layer name adds 'main.' prefix

Re: ArcGIS Pro 2.8.1 keeps changing Python environment back to default

Re: SQL error when creating a Query Layer

Re: Connect to RDS AWS Postgres Database from ArcMap.

Re: huge amount of .geodatabase files since ArcGIS Pro 2.7, not clearing

Re: huge amount of .geodatabase files since ArcGIS Pro 2.7, not clearing

Re: Open Street Map showing Transmission Line

Re: How to edit Community post

Re: I'm getting confused by the Esri approach to b...

Re: I'm getting confused by the Esri approach to b...

Re: 999999 Add Spatial Join Doesn't Work on Extern...