Latest Contributions by MarcoBoeringa

‎12-22-2020

I think this will have to wait for WPF (Windows Presentation Foundation) to be ported to ARM by Microsoft. Afaik, ArcGIS Pro is build based on that, and unless it becomes available on ARM, won't be able to run on that. There seems to be some promise though: https://mspoweruser.com/microsoft-wpf-support-windows-10-on-arm/ https://mspoweruser.com/windows-forms-apps-support-windows-10-arm/

‎12-11-2020

Definitely report this to ESRI if you have a reproducable case. I unfortunately have had to report a couple of major bugs in Maplex in the last releases after some big changes in ArcMap 10.3 to the Maplex label engine (addition of new functionality), that only finally got sorted out in 10.6 or so...

‎10-29-2020

Nice you got it to work. Haven't had a look at the rotation properties myself, so missed the obvious.

‎10-28-2020

It may be a bug in the CIM access. The one time I tried it, and used CIM access to change label properties for a Query Layer, I discovered it resulted in the loss of the datasource as soon as I set the CIM definition using lyr.setDefinition. This made CIM access unusable for me. In my particular case, it was possible to workaround the issue by saving the layer to disk first as *.lyrx layer file using lyr.saveACopy, then do a json edit using the ordinary Python json.load and json.dump methods, and finally reload the layer in the project. This requires good knowledge and understanding of the structure of the CIM though, and how it translates to the dictionary structure that json.load creates. It took me a couple of rounds and thought to get it right. Also, ESRI definitely, and probably rightly so, discourages direct json editing of layer files, but it can be done if you are careful.

‎10-28-2020

Definitely one to report to ESRI, seems like a clear bug as you concluded based on your description.

‎10-25-2020

The error message itself refers to Unicode and ascii. It suggest you may have some non-ascii text characters in some of your data, that subsequently cause an issue when part of the processing pipeline you are using tries to handle this. E.g. you can't represent a Chinese character in ascii. So, are there any special language specific characters in your data? If so, maybe replacing them by safer ascii text characters only solves the issue.

‎10-18-2020

Note: I am not working for ESRI Full compatibility may be some time away, but there are some positive developments. There have been recent blog posts from ESRI regarding vector symbols in webservices and efforts for incorporating the full CIM (Cartographic Information Model) in the ArcGIS API for JavaScript, which means that the full potential of cartographic display in ArcGIS Pro, may become available in (vector symbology based) webservices as well. Since ArcGIS Pro can import almost all symbology from ArcMap, I guess this might mean that at some point in the future, you will be able to even have legacy ArcMap TTF fonts symbology fully displayable across the board. Use Published 2D Symbols in ArcGIS Online What’s New in ArcGIS API for JavaScript (October 2020) Create points, lines, and polygons using CIMSymbols

‎10-16-2020

Currently, when you use the Add Incrementing ID Field geoprocessing tool to add an OBJECTID field to a non-geodatabase maintained spatial table, the associated unique index created by the tool ends up in whatever the database sees as the default tablespace. At least in PostgreSQL that I am using, I see the index ending up in the pg_default tablespace. It would be useful to be able to optionally specify the tablespace where the index will be created, so as to be able to avoid the use of the default tablespace.

‎10-05-2020

I also wonder if this issue is actually being worked on? This is a quite hideous issue, causing significant problems for arcpy / Python development. I have reported a similar issue to the Dutch branch of ESRI based on a custom arcpy Python geoprocessing tool of mine that suddenly started failing going from Pro 2.4.3 to Pro 2.5, and the issue was also caused by left over *.lock files in a File Geodatabase folder, that weren't being cleaned up in Pro 2.5, while not an issue and being cleared properly in Pro 2.4.3. It is registered as: BUG-000131154 Fgdb locking behavior is different in ArcGIS Pro 2.5 to ArcGIS Pro 2.4.3 for copying styles

‎10-05-2020

Cooper Logan‌, I am confused. This issue is about File Geodatabases being kept locked. The workaround you suggested shouldn't work according to this Help page, as arcpy.ClearWorkspaceCache_management() is only supposed to do anything for Enterprise Geodatabases, not File Geodatabases. The Help is quite adamant on that aspect: "This tool only works with enterprise geodatabase workspaces."

Online Status	Offline
Date Last Visited	yesterday

My Ideas

Latest Contributions by MarcoBoeringa

Re: ARM processor compatible Pro

Re: Labels Suddenly Overlapping Annotations in All MXDs

Re: Python CIM Accessing Label Properties

Re: Python CIM Accessing Label Properties

Re: ArcGIS API 4.17 client side feature layer rendering issues

Re: Add GTFS to Network Dataset keeps producing Error 999999 Topo-Engine

Re: Have the same symbology across ArcGIS Pro, ArcMap, Portal for ArcGIS, and ArcGIS online.

"Add Incrementing ID Field" tool should allow setting tablespace for unique index

Re: arcpro 2.6 arcpy fgdb lock files not clearing

Re: arcpro 2.6 arcpy fgdb lock files not clearing