Probably completely the wrong term, but I like the word, so I'm sticking with "atomising". Anyways...
Playing a bit with PowerBI today I've been noting holes* in my data and been making a mental note of what to consider for my next round of Template development.
*holes as in not-missing information not-coming out of Revit, but information I could really benefit from if it were coming from Revit
Specifically; when dealing with large-site concept-stage work, the ability to "drill" up, down and all around, all the while querying, a dataset is increasingly attractive. The "issue" (if you could call it one) is how one might populate said properties, and into which, and how many parameters, for best effect.
A lot of this thinking (read: rambling) stems from my love of "reverse-order" and hierarchal systems; where I almost always wish to seperate information, to the point where nothing is (effectively) a "concatenated" (compound?) field of information, i.e.:
<NameFull> = "Mr Snowy Weston"
is actually: (<Title>," ",<NameFirst>," ",<NameSecond>)
where one might use some tricksy little Dynamo to concatenate the bit-parts into said <NameFull> parameter.
Elevated to the "large-site concept-stage work" scenario; doing such requires a (very) top-level-down approach to the notion of taxonomy, i.e.:
>Job
>>Site
>>>Plot
>>>>Block
>>>>>Building
>>>>>>Floor
>>>>>>>Zone
>>>>>>>>Tenure
>>>>>>>>>Tenure (Sub-Type)
>>>>>>>>>>Department
>>>>>>>>>>>Area
>>>>>>>>>>>>Room/Space
>>>>>>>>>>>>>System
>>>>>>>>>>>>>>Element
>>>>>>>>>>>>>>>Sub-Element
>>>>>>>>>>>>>>>>Part
(this is my current, off-the-cuff, list - and I know there are "true" organisational schema for this kind of stuff, but hear me out)
So I've started this thread to "specifically" target the sense in persuing the Nth degree, i.e.:
Take UK Building Use Classes for example.
Many would, and quite fairly, create a Shared Paramter <Use Class>, populate it "A1", "B2" or "C3(b)" and be done with it.
Me? I'm presently toying with having:
<UseClassPart> = "C"
<UseClassType> = "3"
<UseClassVar> = "b"
Then having Dynamo populate:
<UseClass> = as a concatenation of the above (seperate) fields.
Why?
Because I like to have things "atomised" in Revit to allow different levels of data-management and visualisation.
Now (of course) I know we can define view and schedule filters using search terms "Starts with"... but downstream, say in something like PowerBI, Access, or more commonly in Excel, I tend to find it far more helpful having the information as seperate, "nuclear" columnlar data than having to setup multiple COUNTIFs and SUMIFs. Considering also, that certain/many classification "systems" (the UK Building Use Class coding example included) do not follow a logical/consistent/alphanumeric taxonmy, making rule-based queries (of compound fields) becomes increasingly difficult.
So am I crazy? Do any of you have a similar masochistic tendancy to drive things down to the itty bitty as well? I'm really curious if I'm in my own little world here.
Playing a bit with PowerBI today I've been noting holes* in my data and been making a mental note of what to consider for my next round of Template development.
*holes as in not-missing information not-coming out of Revit, but information I could really benefit from if it were coming from Revit
Specifically; when dealing with large-site concept-stage work, the ability to "drill" up, down and all around, all the while querying, a dataset is increasingly attractive. The "issue" (if you could call it one) is how one might populate said properties, and into which, and how many parameters, for best effect.
A lot of this thinking (read: rambling) stems from my love of "reverse-order" and hierarchal systems; where I almost always wish to seperate information, to the point where nothing is (effectively) a "concatenated" (compound?) field of information, i.e.:
<NameFull> = "Mr Snowy Weston"
is actually: (<Title>," ",<NameFirst>," ",<NameSecond>)
where one might use some tricksy little Dynamo to concatenate the bit-parts into said <NameFull> parameter.
Elevated to the "large-site concept-stage work" scenario; doing such requires a (very) top-level-down approach to the notion of taxonomy, i.e.:
>Job
>>Site
>>>Plot
>>>>Block
>>>>>Building
>>>>>>Floor
>>>>>>>Zone
>>>>>>>>Tenure
>>>>>>>>>Tenure (Sub-Type)
>>>>>>>>>>Department
>>>>>>>>>>>Area
>>>>>>>>>>>>Room/Space
>>>>>>>>>>>>>System
>>>>>>>>>>>>>>Element
>>>>>>>>>>>>>>>Sub-Element
>>>>>>>>>>>>>>>>Part
(this is my current, off-the-cuff, list - and I know there are "true" organisational schema for this kind of stuff, but hear me out)
So I've started this thread to "specifically" target the sense in persuing the Nth degree, i.e.:
Take UK Building Use Classes for example.
Many would, and quite fairly, create a Shared Paramter <Use Class>, populate it "A1", "B2" or "C3(b)" and be done with it.
Me? I'm presently toying with having:
<UseClassPart> = "C"
<UseClassType> = "3"
<UseClassVar> = "b"
Then having Dynamo populate:
<UseClass> = as a concatenation of the above (seperate) fields.
Why?
Because I like to have things "atomised" in Revit to allow different levels of data-management and visualisation.
Now (of course) I know we can define view and schedule filters using search terms "Starts with"... but downstream, say in something like PowerBI, Access, or more commonly in Excel, I tend to find it far more helpful having the information as seperate, "nuclear" columnlar data than having to setup multiple COUNTIFs and SUMIFs. Considering also, that certain/many classification "systems" (the UK Building Use Class coding example included) do not follow a logical/consistent/alphanumeric taxonmy, making rule-based queries (of compound fields) becomes increasingly difficult.
So am I crazy? Do any of you have a similar masochistic tendancy to drive things down to the itty bitty as well? I'm really curious if I'm in my own little world here.
Comment