Parameter Filter Element node doesn't recognize current project units

[ksobon]

Dynamo version

Dynamo 1.3

Revit version

Revit 2017

Operating system

Windows 10

What did you do?

Entered 100 to create Wall Width filter element, but that get's converted to Feet

What did you expect to see?

values in current project units

What did you see instead?

value was interpreted as if it was in feet while my current settings were millimeters. Instead I had to use the unit conversion node which as we know is not precise and makes using rule like Equals not feasible.

[jnealb]

@ksobon Can you please be more specific about how the unit conversion node is not precise?

[ksobon]

well it's not the node itself per se, but the above workflow will result in a situation where if my wall width parameter is returning values in millimeters; let's say 150. The FilterRule node expects them in feet for comparison, so now we have a situation where 150 is fed through an equation: x * 0.00328084 = 0.492126. That kind of looks all right, but if you compare two doubles against each other without accounting for some significant digit adjustment, it will return false. In the case above the conversion doesn't exactly EQUAL 150 so instead of overriding the existing rule it creates a new one. Kind of sucks.

Makes sense?

[smangarole]

@jnealb says: It does make sense.

@kronz Ping: Is there a better way to do this?

[kronz]

Ok, the real problem here is that FilterRule.ByRuleType isn't using the built in conversion methods that all the Revit nodes should use to respect Project Units, not the internal API units, right? (Conversion node accuracy is a secondary issue here, and can MAYBE be dealt with using the Math.Round that takes numbers of digits as an additional input.) There's a couple of places where this is happening, like some of the Room query nodes. @mjkkirschner @moethu is there a way we can systematically audit the new-ish Revit nodes to verify that they do or do not look at Project units instead of internal API units.