Latest Contributions by Bud

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

Scenario: Moving FC to feature dataset fails, despite spatial references appearing to be the same. Example: The XY Resolution and/or XY Tolerance is different between the FC and the FD. But ArcGIS Pro's error message says, "Move failed. The Spatial references do not match.", which is misleading/not specific enough.  Idea: Improve the error messaging by telling the user what criteria failed instead of the very general "spatial reference" error message. ... View more