Latest Contributions by Bud

Use this WHERE clause in a definition query or the Select By Attributes window: sde.st_numgeometries(shape) > 1   There is a known bug in versioned Oracle SDE.ST_GEOMETRY FCs. The above WHERE clause will throw an error: ORA-00904 Invalid Identifier "SHAPE". Defect #: BUG-000150273 "ST_GEOMETRY functions used in Select By Attributes tool on Shape field generate error "ORA-00904 Invalid Identifier "SHAPE"" Esri Canada case #: 03080875   Workaround: Use a subquery. objectid in (select objectid from my_owner.my_fc where sde.st_numgeometries(shape) > 1)   That bug only happens for SDE.ST_GEOMETRY. Whereas if the FC was SDO_GEOMETRY, then spatial functions would work fine — even if the FC was versioned. sdo_util.getnumelem(shape) > 1   ... View more

@DanLee  The multiparts were created manually in an existing FC.  Here's an explanation from a related post: Multipart features were created manually...by accident. The person who digitized the roads merged two lines together, but didn't realize that a multipart feature was created.  We want to prevent our users from manually creating multipart features. ... View more

Thanks Dan. Regarding your question, "Why are the roads multipart to begin with?" Answer: Some of the roads are multi-part due to situations like this: The road's "Exclusive Right Turn Lane" was deemed to be too short to be it's own asset. So it was merged into it's parent asset as a multipart feature:  (Here's an example photo, although not the same one from the screenshot above: https://i.stack.imgur.com/aiL7W.png) That decision was made years ago by people other than me and is beyond my control. (It's not possible to change things at this point...there are too many existing dependencies. Splitting the multipart into two single parts would compromise any records that are related. Including an already-integrated work order management system.)   The other scenario is: Multipart features were created by accident. The person who digitized the roads merged two lines together, but didn't realize that a multipart feature was created.  In that case, it might be possible to go back and convert the multiparts to single parts. But it would take a lot of work to review/fix any linear referencing events that are tied to the geometry/M-values of those roads.   I've submitted an idea about multiparts here: Prevent multi-part features.   Does that answer your first question? I'll answer your second question about "Why you need to know the closest Ward polygons to each midpoint of the longest part?" in a separate comment. Cheers.     ... View more

The reason I ask: I'm trying to figure out why sorting is so slow in this workaround: Question: Sorting a field in the attribute table: Specify how nulls are handled (nulls first or last) Workaround:  1. Create a query layer with a NULL_FLAG field: select objectid, last_edited_date, case when last_edited_date is not null then 1 else 0 end as null_flag --Source: https://modern-sql.com/concept/null#order-by from events 2. In the Attribute Table, join from the table to the query layer via the OBJECTID. 3. Do an advanced sort using the fields from the query layer:  - NULL_FLAG descending.  - LAST_EDITED_DATE descending.   Now, the latest dates are at the top and the nulls are at the bottom. Which is what I want. Unfortunately, it's far too slow to use. It takes roughly a minute to do the sorting, whereas sorting was instantaneous without the workaround (and sorting was instantaneous when I tested the query in SQL Developer too). So, something about sorting on the query layer in the attribute table is going awry. ... View more

Test #4: I did a fourth test, this time on my work computer. I emailed the FGDB from my home computer to my work computer. And tested the script on the FGDB on my work computer. The script ran without errors. (Although it still doesn't catch the invalid value. But as mentioned, that's expected, since the script wasn't designed for subtypes.) So that test confirms that the subtype isn't causing the error on my work computer. It also confirms that the older version of ArcGIS Pro (2.6.8) isn't causing the problem either. So I think the issue must be something to do with my enterprise GDB environment (or the table).   I googled the error message: "AttributeError: 'NoneType' object has no attribute 'keys'" I'll review those results and see if I can figure out what's happening. ... View more

Test #3: I did a third test (again, on my home computer) where I tested a subtype. The script ran without errors, but it didn't catch the invalid domain value. But that's totally reasonable, since I forgot to mention in my original post that the data uses a subtype...the script likely wasn't designed with subtypes in mind. So, to me, that suggests that the error I got in my first test (work computer) might not be caused by the subtype, since the script ran without errors on my home computer where a subtype was present. ... View more

Test #2: I did a test using ArcGIS Pro on my home computer: ArcGIS Pro 2.9.2 FGDB Created a non-spatial table from scratch No subtypes The script worked fine using the specs mentioned above. So I guess there's something in my work environment that is causing a problem. I'll do some more tests...   ... View more

Thanks Johannes! That's great! I would have struggled with this for a week or more if I'd done it all on my own, lol. Here's where I'm at: Test #1: (using my work computer; enterprise GDB) I tried running the script, but got an error: Error: Traceback (most recent call last): File "<string>", line 41, in <module> File "<string>", line 15, in check_domain_values File "<string>", line 15, in <dictcomp> AttributeError: 'NoneType' object has no attribute 'keys'   The table (non-spatial) has a subtype. Not sure if that's relevant or not.   ... View more

@Scott_Harris Thanks. As you might have guessed, I was looking at the Attributes Table (incorrect), not the Attributes Pane (correct). For what it's worth, that technique worked fine on a feature class, but I couldn't get it to work for a non-spatial table. I'm not sure why. I deliberately entered an invalid domain value (via the field calculator), but the "Select Only Invalid Objects" functionality didn't select that record (or any other invalid domain records).  Does it work for you when used on a non-spatial table in a newer version of Pro? ... View more