Latest Contributions by Bud

@StevenDel_Favero said this in Migrating from Personal GDB to Mobile GDB: The main advantage of the Personal GDB was the ability to query and edit the data in Microsoft Access. This is not an inherent ability for Mobile Geodatabases and ArcGIS is not at all adequate for working with complex relational data. The ability to open a SQLite database in MS Access requires a third party ODBC driver. As a government employee, I do not have the luxury of installing such a driver on my machine, let alone having this driver installed on the Remote Desktop server where my agency does all of its work. Getting approval to have something like this installed may never be possible or will take a very long time (I am starting to petition for it). Is it possible to have this ODBC Driver installed along with ArcGIS Pro in future releases? Otherwise a Mobile Geodatabase does not have much value and is not a valid alternative to a Personal GDB. Not being able to use a Personal GDB in ArcGIS Pro is therefore a serious impediment to my workflow and Esri has still not provided an alternative for me. Could Esri consider installing an ODBC/SQLite driver by default along with Pro to allow viewing/editing complex Mobile GDB relational data in MS Access? That would let us move forward with switching from PGDBs to mobile geodatabases. ... View more

It would be helpful if we could use the ORDER BY clause in definition queries. Like this: That would be useful for scenarios where we want to control sorting in ways that can't be done in the attribute table UI, but can be done in the DB, such as making nulls come last in a column:  https://community.esri.com/t5/arcgis-pro-ideas/sorting-a-field-in-the-attribute-table-specify-how/idi-p/1184709/jump-to/first-unread-message. There are other scenarios too. If it's not possible to do it right in the definition query SQL expression builder textbox, then it could be done in its own ORDER BY expression builder textbox. Using the ORDER BY clause in other enterprise systems, such as IBM Maximo, has been really handy. It would be great if we could do it in ArcGIS Pro too. ... View more

For cases like the following: A slow ST_GEOMETRY query layer that constructs geometries or does spatial operations. A slow linear referencing route event layer. Or, a layer is slow due to a connection to an external database. Could some optional settings be added to a layer's properties to boost performance? Control how often ArcGIS Pro re-queries the underlying data. For example, only re-query the db once every 5 minutes (and only if the map is actively being used). When the layer is used/refreshed in the map, ArcGIS would utilize the data that's cached in RAM, rather than re-querying the DB each time. Similarly, could we use a setting to tell ArcGIS Pro to re-query ahead of time, so that the data is pre-queried for the next time we use/refresh the layer in the map? Kind of like what Google Chrome does? Or only re-query if the underlying data has changed. Similar to Oracle’s result cache mechanism: Making Oracle queries faster: Cache query results using an SQL hint. I wonder if that kind of thing might be useful for cases where a dynamic layer is slow or doesn't need to be real-time (to avoid unnecessary database hits). It would be a lot more convenient to control that sort of thing in the application, instead of setting things up in the back-end via materialized views, triggers, scheduled tasks, etc.. And the user could toggle it on or off as needed, depending on the use case. Whereas if it's done in the back-end, the user doesn't have any control over how the data behaves in their map...in terms of currency, caching, etc.. ... View more

There are cases where we want to store spatial information in a table's non-spatial fields and create dynamic event layers on that information. We currently use the existing event layer types with great success: XY event layers and linear referencing route event layers. Those existing event layers are very powerful tools...and we want more! Polyline event layers WKT example: (30 10, 10 30, 40 40) Polygon event layers WKT example: ((30 10, 40 40, 20 40, 10 20, 30 10)) Multi-part point event layers WKT example: (10 40, 40 30, 20 20, 30 10) Use cases: Use a multipoint WKT field in a non-spatial table to create an event layer — for scenarios we don't have the option of converting the table to a FC, such as an external database.  Or, a WKT field (polyline, polygon, or multipoint) in an existing FC. We can't have multiple geometry columns in a FC, so we'd store the information in a non-spatial text field instead, and create an event layer on it. Lots more... Performance:  My experience has been that event layers are surprisingly fast: Why are XY event layers so fast? The XY event layer is generated on the client-side after all required library/data has been downloaded on the client machine, therefore there is no client-server connection required. It is also fast because it is generated from the Computer's RAM. In contrast, if you are querying geometry from DB, a client-server connection is required and a query is performed on the DB server which causes the latency. So, if XY event layers are fast (linear referencing route event layers are reasonably fast too), then hopefully that high performance would translate to line/polygon/multipoints as well. Alternatives: We're aware that there are other ways to calculate geometries, but they have downsides: ST_GEOMETRY views: The ST_GEOEMTRY constructor/function is far too slow for generating geometries on-the-fly. In a test, an XY event layer on 10,000 rows loaded in the map instantly, whereas an ST_GEOMETRY point view took 10-20 seconds using the same data. So ST_GEOMETRY isn't a realistic option. Attribute rules to populate a separate FC: That would likely work, but would require extra FCs to manage. Our EGDB is already quite big/complicated, so we want to avoid that extra complexity if we can help it.  Also, attribute rules wouldn't be applicable if the table was in an external database. So, something like dynamic event layers would be preferred. Database triggers to populate a separate FC: Similar to the attribute rule option, triggers might work, but would require extra FCs to manage, aren't applicable if the table is in an external DB, and aren't really supported by Esri either. Not to mention the fact that versioning makes things extra complicated/risky/unsupported. As far as I know, there aren't any geoprocessing tools that can create a FC from WKT. And even if there were, the FC wouldn't be dynamic, so that's not what we're looking for...and scheduled jobs to recreate FCs aren't quite what we want either. The same limitations apply to Python scripts. Limitations/Tradeoffs: We're aware that there could be limitations for the proposed event layer types, such as: The event layers would be more complicated than a basic XY event layer. So, for large datasets, or features with lots of points, performance might be slower than we'd like. But users are aware that event layers have their limits by nature of being dynamic, and would plan accordingly.  It's also worth mentioning that linear referencing event layers are reasonably fast. They're based on lines, so maybe other complex geometry types like lines/polygons/multipoints would perform well too. We would need to populate the WKT field with spatial information...one way or another...which would require custom code. But we could live with that. There are lots of different ways of calculating a field in ArcGIS...so one of the options should work. And, in some cases, the field might even come pre-populated if the table comes from an external system. Summary: Having event layer functionality for lines, polygons, and multi-part points could be very handy. We already have event layers for points and linear referencing lines, why not give us event layers for the other geometry types too? ... View more

When sorting a field in the attribute table, it would be helpful if we could specify how nulls are handled (NULLS FIRST vs. NULLS LAST). For example (Oracle), I want to sort a date field descending so that the latest dates are at the top. But when I do that, 1) nulls are at the top, then 2) the latest dates are shown next, then 3) the first dates.  That's a nuisance when dealing with large tables. I need to painstakingly scroll down through nulls to get to the first instance of a non-null date in the list. (In my case, I had to scroll through 10,000 nulls...and then look for where the nulls stop and the dates start) Sorting in ascending order doesn't help either. It would be better if I could specify that I want the nulls to be last in the list, even though I'm sorting descending. Maybe something like this: Would something like that be possible?   Related: Allow using the ORDER BY clause in definition queries (SQL) ... View more

It would help if there were a geoprocessing tool for creating and managing entries in Oracle's user_sdo_geom_metadata table/view. I find it clunky to manually create those records through SQL. Every once and a while I make a mistake when writing the SQL, and it ends up being a headache. I'd be less likely to make a mistake if I used an OOTB GP tool. Also, an OOTB tool would be more convenient for deleting entries. ... View more

Regarding technical article #000011333: Bug: Unable to define a query layer in ArcGIS where the data source uses an st_geometry subtype in Oracle Workaround: Convert the geometry attribute field from the subtype (for example, st_point) to the supertype st_geometry. The docs say we should convert the ST_POINT subtype to ST_GEOMETRY supertype. But they don't say how to make the conversion. The only way I've found so far is to convert to WKB or WKT and then back to ST_GEOMETRY: --This works, but is clunky and slow: sde.st_geomfromwkb(sde.st_asbinary(...)). Is that how Esri recommends we make the conversion? It would help if Esri could explicitly tell us what is meant there. Thanks. Note: I've tried using the TREAT() function too. But that didn't seem to work properly: Stack Overflow: Convert UDT subtype to supertype Related: Convert MDSYS.ST_LINESTRING subtype value to MDSYS.ST_GEOMETRY supertype ... View more