Latest Contributions by MarcoBoeringa

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 ... View more

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

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. ... View more

As the log clearly states, this is the log from the setting up of the SQLite "Mobile Geodatabase", with the ArcSDE repository and geodatabase system tables being created. The initialization apparently succeeds, as the log shows no errors, so no problem there. One thing that is mildly interesting though, is the creation of the LOCATORS table being visible. This seems to be created in all these Mobile Geodatabases, and must be associated with the geocoding facilities in ArcGIS Pro and the "Locators" option in the Pro Catalog. Are you using any of the geocoding stuff in Pro? Note though that these geodatabase system tables, as said, seem to be created by default, so this is not out of the ordinary and not necessarily related to the geocoding stuff in Pro. ... View more

You are not by any chance an ESRI "Production Mapping" or "Defense Mapping" user? I have never used these products myself, but recently noticed in the documentation Help pages that some of the cartographic product specifications for these extensions are defined in Excel and used as input for tools. Maybe this process is related... ... View more

Actually, I think you already answered most of the questions yourself... As you state, the .geodatabase files are ESRI's new Mobile Geodatabases based on SQLite that ESRI introduced at 2.7. I have seen similarly uniquely numbered files in TEMP in older releases, and these are likely related to some form of local caches, either for imagery or vector (tile) based services you are using in one of your projects, or alternatively, as you stated, the ArcGIS Indexing Service may be involved in the creation of these, although I doubt it would create this much of crud. I guess ESRI substituted some other file based caches for the new format. Of course, if these caches do eat up your entire drive, I think it is time to report this to ESRI as a potential bug. That shouldn't happen. Anything in TEMP is by definition "scratch", and can be safely removed. If not, it is a bug in the software. Do note though, that some of these files may still be in use and locked, e.g. by the Indexing Service or whatever is using them, and thus not removable. ... View more

The Pairwise Dissolve tool is actually just running on a modest 4C/8T Core i7 desktop (32GB RAM though). And I only set the geoprocessing environment to allow 75% 3C/6T usage of the processor, so as to not completely consume this limited CPU. The database is running on a HP Z840 workstation though, a refurbished one that I recently acquired, and has dual Xeon E5-2680 v4 with 14C/28T each, so 28C/56T total. This is some custom Python multi-threaded code I developed (unrelated to the SQLite stuff), that goes flat out at 100% usage on the database server generalizing geometries in PostGIS:           ... View more

Thought you might like this as well, ArcGIS Pro's Pairwise Dissolve tool dissolving a 379 M(!) record dataset of building geometries...   ... View more

Hi Kirk, As you yourself already found out, the Mobile Geodatabase uses ESRI's own ST_Geometry implementation (the link and all sublinks you found in the ArcMap Help that hasn't yet been ported to the Pro Help: https://desktop.arcgis.com/en/arcmap/latest/manage-data/using-sql-with-gdbs/what-is-the-st-geometry-storage-type.htm) I have recently been experimenting with SQLite and ArcGIS Pro too, but using a different path. I use Python and arcpy to write out geometries to a SQLite database created with the Create SQLite Database geoprocessing tool (also see this link). The data involved is coming from OpenStreetMap, and is stored in a PostgreSQL / PostGIS database, that is NOT ESRI Enterprise Geodatabase enabled, just an ordinary spatial (PostGIS) database. Note that the process described below DOES NOT work for the Mobile Geodatabase, just a plain SQLite database as created with the geoprocessing tool mentioned above, there appear to be additional dependencies that regulate data type validation that I haven't been able to figure out yet. In order for the SQLite INSERT to work, I need to: - Create a SQLite database using the Create SQLite Database geoprocessing tool. - Load the stgeometry_sqlite.dll library that ESRI created and made available as a separate download on the My ESRI website (unfortunately, this library appears not part of the standard Pro installation) in Python using the sqlite3 Python package that is part of the default install of Pro's Python environment (you need to use enable_load_extension and load_extension for that in the sqlite3 Python module). - Create a table with CREATE TABLE using a sqlite3 connection/cursor - Add a geometry column to this table using the ESRI ST_Geometry library's AddGeometryColumn function and sqlite3 cursor. - To use PostGIS ST_AsBinary with a psycopg2 cursor to read the PostGIS database and extract the features as WKB. - Insert the geometries using a sqlite3 database connection / cursor using ST_GeomFromWKB. Note that ESRI's ST_Geometry library supports other options like ST_MPolyFromWKB as well for dedicated geometry types, but I haven't succeeded in using these properly, and the ST_GeomFromWKB "just works". - Add a spatial index using the Add Spatial Index geoprocessing tool. Note that implementing all of this was particular tough, this is certainly not for the faint of heart! It took me the better part of two weeks to get it running. However, on the bright side, I am now capable of exporting geometries to a SQLite database at a rate of just over 100M records / hour! (yes, my current OpenStreetMap database is that big...). This is probably about 5x the speed or more of using an arcpy.da.SearchCursor and arcpy.da.InsertCursor that could do the same thing. This speed difference was crucial for me. This database can subsequently be read by ArcGIS Pro again. By the way, as alternative to psycopg2, there is pyodbc, which supports a far wider range of databases besides PostgreSQL (e.g. SQL Server, Oracle), but lacks for example server side cursors. Both Python DB API adapters have their strengths and weaknesses...   ... View more

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/ ... View more

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... ... View more

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

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. ... View more

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

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. ... View more