Latest Contributions by MarcoBoeringa

Can someone from ESRI please have a good look at this. @Kory Kramer, @George Thompson, @Vince Angelo For some background: - ArcGIS Pro 2.1.3 on Windows 10 - PostgreSQL 9.6 on Ubuntu 18.04 running on a Virtualbox VM executed on the Windows host Situation: A line layer with a valid Definition Query set present in the TOC. The layer is an ArcGIS Query Layer (so a spatial database but not an enterprise geodatabase) and references a huge Europe OpenStreetMap extract containing +/- 65M records in the line table. This line table has both valid spatial index (GIST) and attribute indexes. The display performance of the layers in Pro's Map window is adequate, and actually surprisingly fast given the huge data source. The Definition Query set on the layer, see image, references an indexed field, osm_piste_58_type:   If I insert the Definition Query in DBeaver IDE, and prepend it with the necessary SELECT...FROM... that is missing in the Definition Query itself, and run an execution plan, the query runs in less than 3 seconds (2163ms) and returns 38697 rows, so just under 40k records. The execution plan shows the database correctly using the available index ("Index Scan"): The problem: When I attempt to open the Attribute Table in Pro by right clicking the layer and choosing "Attribute Table", Pro, instead of showing the records near instantly as it should based on the 3 seconds execution plan, instead takes > half an hour to open the Attribute Table. This is the time needed for a full table scan. When it is finished, it does show the proper 40k records, so the final selection was made. When I enable logging in PostgreSQL and check the created log, I can see the SQL generated the moment I open the attribute table. Much to my surprise, even though the Query Layer had a Definition Query set, this Definition Query is not set on the SQL send to the database to restrict the binary cursor being created, as a consequence, the entire table seems subsequently to start being scanned in chunks of 1000 records, see the FETCH FORWARD 1000 statements in the log. This seems to go on the entire half hour, until a full table scan of all the millions of records is done, and the final table is created. As I wrote above, the final result in the Attribute Table, does correspond to the Definition Query, and is only the 38697 rows. To inspect this better, I copied both the cursor statement that is initially used to create the layer (which is fast!), and compared it with the above statement representing the opening of the Attribute Table in an OpenOffice document, see the below screenshots. Notice how the first screenshot, which represent the moment the layer is created when the Pro Map document is opened and the TOC layer generated, does contain the Definition Query in the WHERE statement. This WHERE statement is omitted though, in the second screenshot that represents the opening of the Attribute Table: - Creation of Query Layer: - Opening Attribute Table: Am I missing something here, or fundamentally misunderstanding what is going on and misinterpreting this data? Why is there no WHERE statement submitted to the database when opening the Attribute Table of a (Query) Layer? ... View more

Currently, the ArcGIS Pro Help only shows the data for the most recent version of ArcGIS Pro. Yet, there have been breaking changes between different versions of Pro. This issue affects especially arcpy development. Some arcpy classes have had breaking changes, that unfortunately cannot be looked up in the Help, since the Help only shows the most recent version. For those developers seeking to maintain backward compatibility, it would be really helpful if the Pro Help showed version numbers like for ArcMap, and allowed selection of a previous version: ... View more

It would be really helpful if the CreateDatabaseView_management tool was enhanced with the option to create MATERIALIZED views instead of ordinary ones.   In many cases, ArcGIS Query Layers may reference a view that has poor performance due to complex SQL. The only real solution for that is to materialize the view.   However, once a view is created and referenced by a certain view name, it is no longer possible to modify the view by inserting the MATERIALIZE keyword in e.g. pgadmin in case of PostgreSQL, and save the view with the same name. PostgreSQL does not allow you to simply overwrite an existing view (you must DELETE first), even if you are the owner and exclusive user of the view or table.   Thus, instead, a new view must be created with a different name. The consequence of this is that any Query Layers referencing the original view needs updating of its data source.   For automation workflows using arcpy, it would therefor be very useful to have the ability to create a materialized view upon calling the CreateDatabaseView_management tool, e.g. via a new optional parameter setting, instead of having to reset data sources, or do a complex replacement including multiple DELETE and CREATE statements on the database side.   ... View more

Currently, label classes in multiple dialogs / interface elements of both ArcMap and Pro are totally unsorted and listed in the order in which they have been created. This is problematic for layers having large numbers of label classes, and makes management of the label classes difficult. It would be really helpful if there was an option to (automatically or manually) sort the label classes, and have this sorting persisted when an map document or layer is saved. If full automatic alphabetic sorting is used, then persistence is probably not necessary and likely easier to implement for ESRI, although I can imagine some people would like to have custom manual sorting as well. ... View more