Categories vs. Category.ByName Discrepancy in 2.13

Hey there Dynamo community. I’m checking my company’s scripts to make sure they work in Revit 2023/Dynamo 2.13 and noticed this issue with specifying Categories using the Category.ByName node. Wondering if anyone has any insight on this.

We specify Categories using the ByName approach for simplicity, ability to be in a code block, etc. We’re trying to grab the four Categories in the code block, but you can see in the Category.ByName preview list that 0 & 2 are actually grabbing the "Analytical Surfaces - " Categories, not the plain ones that I’m wanting (as shown in the separate Categories nodes below). Any ideas on how to specify the plain “Ceilings” and “Roofs” Categories by name?

image

Hello @jpclark - The bad news is that this is a regression that slipped through :frowning: The good news is that this is a known issue that the team is working on :slight_smile:

The node under the hood is here - DynamoRevit/Category.cs at a90305ebc8fe2227d646760233a12f33ccc75046 · DynamoDS/DynamoRevit · GitHub if you are curious to looking.

In the interim, I suggest you either use the Category dropdowns, or a Python Filtered Element Collector. Shoutout to @Konrad_K_Sobon for the base code that was modified below.

import clr
clr.AddReference("RevitServices")
import RevitServices
from RevitServices.Persistence import DocumentManager
doc = DocumentManager.Instance.CurrentDBDocument
clr.AddReference("RevitAPI")
from Autodesk.Revit.DB import BuiltInCategory,ElementMulticategoryFilter,FilteredElementCollector

import System
from System import Array
from System.Collections.Generic import List

try:
    errorReport = None
    
    cat_list = [BuiltInCategory.OST_Rooms, BuiltInCategory.OST_Ceilings, BuiltInCategory.OST_Floors, BuiltInCategory.OST_Roofs, BuiltInCategory.OST_Stairs]
    typed_list = List[BuiltInCategory](cat_list)
    filter = ElementMulticategoryFilter(typed_list)
    output = FilteredElementCollector(doc).WherePasses(filter).ToElements()

except:
    # if error occurs anywhere in the process catch it
    import traceback
    errorReport = traceback.format_exc()

# Assign your output to the OUT variable
if None == errorReport:
    OUT = output
else:
    OUT = errorReport

Thanks for the update and code, @solamour. Very much appreciated!

1 Like

Note: I haven’t tested this between documents a whole lot. But, I believe category ids are reserved and stay standardized.

I would be pretty inclined to use this method rather than python.

6 Likes

Now that drop down’s are static in all supported Dynamo for Revit releases, I’m thinking migrating back to drop downs might be more stable overall; those IDs may change across Revit releases.

Dropdowns still change quite often or wipe out the selection ma dude. I think I trust Jeremy on this one.

2 Likes

Also, monocle update is incoming to help with this regression. I was using the ByName option too, but with this news, that’s a big ol nope.
20220601-categoryById

Id seems to be more stable across languages too:

2 Likes

Annotation Crop Boundaries (-2000549 to -2000547), Crop Boundaries (-2000548 to -2000536), and View References (-2000198 to -2000197) have all had their id values changed at some point in the last 5 versions. Not popular categories for bulk selection, but worth knowing and a good case of “trust but verify,” because with systems of a certain complexity things will usually change at some point.

Personally since nothing is completely static drop downs may be best as they can be resolved by just about any user:

“Oh no a warning. Here’s the first one and it’s the second node in the string. Proceeding node is a blank drop down, and is named “Walls.” Easy enough fix. Yay now it works.”

Admittedly not all users will make such a change, and the development team will continue to strive for better consistency. But we do have to make a choice for one of the 3 or 4 (5?) methods available here. Either way I am in favor of moving past ‘by name’ (for the language issues alone I disliked it before).

PS: Running a full report of the category names and id for Revit versions 2019 to 2023 after dinner; I’ll post here when done and will include the dyn used to mine the info for anyone who’s interested.

1 Like

I think the categories you mentioned are duplicates and not changes…

Maybe? I can confirm differing values between 2019 and 2020. Moving .dyns and and results between systems to post now.

wait… that is a special category?

okay, getting off topic now, but that is interesting. It didn’t change ids, it is just displaying the same name in Dynamo’s dropdowns. (+1 for Dynamo dropdowns I guess? :rofl:)

2 Likes

I would say to post the full OST name then since Dynamo is truncating names for whatever reason resulting in inaccurate results.

2 Likes

Good call… I’ve got another change to make for that reason… and one I can’t make between bites of dinner.

I’m going to ask someone on the Revit dev team about this on this because something is odd, and we can’t really do what’s best for the community if we don’t have all the info… Stay tuned for more. :slight_smile:

2 Likes

@jpclark have you tried using BuiltInCategory names with Category.ByName yet (e.g. OST_Roofs)? That might still work in Revit 23 and also it‘s language neutral.

4 Likes

@Andreas_Dieckmann Using the BuiltInCategory names seems to work well, at least for the handful of categories I’m concerned with.

I’m thinking this is the workaround I’m going to use for now, since my scripts are all locked to specific Revit versions, and then see what develops as a result of all the other posts and ideas here for future best-practices.

Really appreciate all the dialog and ideas!

7 Likes

Hi @jpclark Does this issue happen on R2022 or an earlier version?
I remember “Analytical Surfaces - xxx” categories were added into Revit years ago.

@gina.liu Not that I’ve ever seen. My organization has been supporting these same scripts with these code blocks since R18, and they’ve been fine till now.