Latest Contributions by Bud

ST_GEOMETRY vertices should be easier to access (Oracle).  Currently, ST_GEOMETRY vertices are obscured in a BLOB/LOB column within the shape object, which makes accessing the vertices difficult. An alternative idea might be: store the vertex ordinates in a more transparent datatype, such as a varray, a nested table column, or some other table collection datatype — as an additional/separate attribute within the existing SHAPE object column (not to be confused with creating an entirely new column in the table). That would make it a lot easier to work with ST_GEOMETRY vertices. We're aware there are workarounds like cross joins and parsing WKT. But they're too clunky & slow. An easier-to-access collection datatype would be better. ... View more

When copy/pasting an object in Catalog: We should  be presented with a window to define the name of the object as part of the pasting process. We shouldn’t need to go looking for the object in Catalog and rename it after-the-fact, which can be a nuisance in GDBs with hundreds of objects. We should also have the option to specify the spatial type as part of the pasting process. For example, ST_GEOMETRY vs. SDO_GEOMETRY, etc. I'm aware those things can be done through GP tools, instead of copy/pasting. But copy/pasting is often the preferred method for duplicating FCs, rather than using GP tools. So it would be nice if that functionality could be added to copy/paste. I think ArcMap had that functionality, at least when copy/pasting in the same GDB when there’d be a name conflict (we can’t have two objects with the same name). If I remember correctly, Pro handles that scenario by automatically adding a “_1” suffix to the name, which isn’t ideal. I’d rather define the new name myself. ... View more

I have multiple connections to two different databases in ArcGIS Pro: DEV and PROD. The objects in the two DBs look identical. So it’s easy to mix up what connection/DB is being used by an object in the map. There are helpful practices we can use, like only using a single DB/connection in a given map. And that does help. But it’s still easy to get your wires crossed and accidentally edit/test in the wrong DB. We can also check an object’s source in the table of contents properties to see what DB the object is in. But that only helps us if we're actually aware that we might not be using the right connection/DB. There are still cases rare where we unknowingly do stuff using the wrong connection. Could Esri make it more obvious what connection is being used by a given object in Pro? For example, put the connection or DB name in brackets or greyed-out text — after the object name in the table-of-contents or in the attribute window. Something like that? Thoughts? We have that kind of functionality in SQL clients like Toad and SQL Developer. Tabs/queries have the DB name right in the tab title. We can also color-code connections & tabs, such as green for DEV and red for PROD. So those kinds of things help avoid confusion about what connection/DB we’re using. Whereas with ArcGIS Pro, it’s less obvious and easier to make mistakes. ... View more

Does anybody else get this error from the Esri Community website in Chrome? This page isn't working community.esri.com redirected you too many times. Try clearing your cookies. ERR_TOO_MANY_REDIRECTS It happens about once per week for me. Clearing cookies solves it. So it's not a huge deal, just inconvenient. Does anyone else get that error? I don't get it for any other websites. Just the Esri Community. Chrome Version 103.0.5060.53 (Official Build) (64-bit). Windows 10.   ... View more

Oracle 18c 10.7.1 GDB: I noticed that our SDE.GDB_ITEMS table has a row that is mostly null values. I discovered that row using this technique: Find problem rows in GDB_ITEMS_VW. That null row causes problems when extracting data from the XML DEFINITION clob column in GDB_ITEMS_VW. For example, these two queries would error-out if I selected ALL rows using CTRL+END in SQL Developer (originally, the queries didn't have WHERE clauses): Select domain codes/descriptions using XMLTABLE instead of EXTRACTVALUE Select subtype and a subtype field/domain names using SQL ORA-31011: XML parsing failed ORA-19202: Error occurred in XML processing LPX-00007: unexpected end-of-file encountered ORA-06512: at "SYS.XMLTYPE", line 272 ORA-06512: at line 1 31011. 00000 - "XML parsing failed" *Cause: XML parser returned an error while trying to parse the document. *Action: Check if the document to be parsed is valid. Now that I know what row is causing the problem, it's easy workaround the issue by adding a WHERE clause to the queries: where     i.name is not null With that said, I'm still curious how that junk row got created. I doubt anyone meddled with the system tables through the back-end using SQL. My best guess is that the row was somehow created via an ArcGIS bug. I looked at some old backups, and it would seem that row has been there for years — since the 10.3.1 GDB days. It wasn't created recently. Questions: Has anyone else had that issue? Does the query below find any null rows in your Oracle GDB? select * from sde.gdb_items where name is null OBJECTID UUID TYPE NAME PHYSICALNAME PATH URL PROPERTIES DEFAULTS DATASETSUBTYPE1 DATASETSUBTYPE2 DATASETINFO1 DATASETINFO2 DEFINITION DOCUMENTATION ITEMINFO SHAPE CONTINGENTVALUES -------- ------------ ------------ ------ ------------ ---- ------ ---------- -------- --------------- --------------- ------------ ------------ ---------- ------------- -------- ------ ---------------- 3367 {39F456FC... {F3783E6F... (null) (null) \ (null) 1 (null) (null) (null) (null) (null) (null) (null) (null) (null) (null)   ... View more

Oracle enterprise GDBs: The enterprise GDB system table docs tell us to use the Oracle EXTRACTVALUE function when extracting GDB system table data via SQL. But it looks like EXTRACTVALUE has been deprecated: Oracle 11g R2 docs:  The EXTRACTVALUE function is deprecated. It is still supported for backward compatibility. However, Oracle recommends that you use the XMLTABLE function, or the XMLCAST and XMLQUERY functions instead.  11g R2 release date: 2009 EXTRACTVALUE vs XMLTABLE Speed comparison: (Oracle 18c) Select domain codes/descriptions using EXTRACTVALUE (the old way): --Source: https://desktop.arcgis.com/en/arcmap/latest/manage-data/using-sql-with-gdbs/example-resolving-domain-codes-to-description-values.htm select extractvalue(codedvalues.column_value,'CodedValue/Code') as domain_code, extractvalue(codedvalues.column_value,'CodedValue/Name') as domain_description from sde.gdb_items_vw items cross join xmlsequence(xmltype(definition).extract('/GPCodedValueDomain2/CodedValues/CodedValue')) codedvalues where items.name is not null Time: 10 seconds.    Select domain codes/descriptions using XMLTABLE (the new way): select i.name as domain_name, x.code, x.description from sde.gdb_items_vw i cross apply xmltable( '/GPCodedValueDomain2/CodedValues/CodedValue' passing xmltype(i.definition) columns code varchar2(255) path './Code', description varchar2(255) path './Name' ) x where i.name is not null Time: 5 seconds (twice as fast).  Idea: Since EXTRACTVALUE was deprecated in ~2009, and since XMLTABLE is twice as fast, could the docs be updated to use XMLTABLE?   Related: Oracle Database XMLTable vs ExtractValue performance "...The SQL execution time was 4.5 times faster after switching to XMLTABLE." ... View more

When using the Feature Vertices To Points geoprocessing tool to get the midpoints of lines: Currently, the tool produces midpoints for each part of a multi-part line. That's not always what we want. We often want a single midpoint placed at along the line — with all parts of the line still considered as a single feature. Similar to how it would work if the line were a linear referencing line, placing the point halfway along the length of the entire multi-part line. Could an optional setting be added to that tool that would honor multipart features? (create just one point per feature, instead of points for each part) ... View more