Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Filter based on instance parameter being greater than a type parameter?

  1.    #11
    Member Bjorn_K's Avatar
    Join Date
    April 8, 2011
    Location
    Rotterdam, Netherlands
    Posts
    459
    Current Local Time
    10:14 PM

    Not allowed! Not allowed!
    Quote Originally Posted by Robin Deurloo View Post
    Will have to look at it some more as I believe you should be able to link any custom parameter to any IFC parameter with custom mapping.
    This should work for most parameters, the mapping will just push it to whatever you set up in the .txt file. Just be carefull about declaring for what type of elements the mapping is used.

  2.    #12
    Moderator Robin Deurloo's Avatar
    Join Date
    July 7, 2011
    Location
    Rotterdam, Holland
    Posts
    1,938
    Current Local Time
    10:14 PM

    Not allowed! Not allowed!
    Never really looked into that before, so that is on my list of things to figure out, so far have not managed to get a custom Revit parameter into the standard IFC parameter for Fire Rating.

  3.    #13
    Junior Member
    Join Date
    June 2, 2015
    Posts
    30
    Current Local Time
    09:14 PM

    Not allowed! Not allowed!
    Quote Originally Posted by Twiceroadsfool View Post
    One thing i was wrong about: BOTH of these Parameters (RATING POTENTIAL and RATING ASSIGNED) are Text Types. The Filters still work fine.

    The ASSIGNED is looking for an exact entry, since someone would be saying "its a one hour wall" but POTENTIAL can be ANYTHING greater than a 1 hour potential, or equal to a 1 hour potential. Works perfectly.

    EDIT: BTW, "Post Grenfell fire" (again) doesnt matter. Its irrelevant. Its a complete misdirection tactic. Someone declaring "Fire is extra important" doesnt lend any bearing to one method over the other, at all. It could/would only do that if there was a solid rubric for how to gauge the two methods, and one of them was clearly the winner. In that case, saying "fire is extra important" and pointing at the certifiably better method, would make sense. But (whether its them OR you) simply pointing out the importance of "fire in life safety" literally changes nothing about the debate.

    BTW, there are like... ten solid reasons why Type Parameters only, suck. But there is a crazy long thread on this in the forum already. I would start there, if someone in the org really has trouble understanding it. But its pretty basic, in terms of how it works. And the logic is pretty simple.

    I can build a 4-7/8" partition with metal studs and type X GWB, and it can have the "potential" to be 1 hour rated (hence thats a type parameter). But that doesnt mean everywhere i build a 4-7/8" wall with those materials it WILL be 1 hour rated. It may be unrated, smoke only rated, 30 minutes, or an hour. There is ZERO added "intelligence, smartness, data, BIMness, control, or whatever" simply because they are made in to different wall types. Anyone saying otherwise has a pretty entry level understanding of how Revit works with data.
    ahh just one thing to add. you can do greater/less/equal etc conditions to the out of the box fire parameter for wall type. So you don't need to add a new type parameter or worry about IFC mapping the type parameter correctly for fire. just if you add FR as a prefix to your rating then you need to do it for the instance parameter as well for the condition to work. potential for typos. so just use a number IMO. rather than type FR a million times.

    Click image for larger version. 

Name:	instancepara.PNG 
Views:	15 
Size:	256.7 KB 
ID:	40378

  4.    #14
    Administrator Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    11,691
    Current Local Time
    03:14 PM

    Not allowed! Not allowed!
    Then do it that way.

    There are other reasons we dont use the default Fire Rating parameter. And a number doesnt suffice, for us. Needs numbers and letters, and works great.

    Im not concerned about someone typing incorrectly. I mean, whats to say they suddenly type better when its a number, instead of a letter? Its another of those "factors" that isnt a real difference. It doesnt make sense.

  5.    #15
    Junior Member
    Join Date
    June 2, 2015
    Posts
    30
    Current Local Time
    09:14 PM

    Not allowed! Not allowed!
    Another thought. I wonder if the same concept could work one wall heights. eg every wall type has a maximum height it can be built to. can a filter be made to check if the instance parameter of continuous height if ever heigher than the a new type parameter for walls "Maximum Height Possible". Just putting my thoughts down here. looking into it myself later but if anyone has figured this out feel free to put a reply here for others to see.

  6.    #16
    Administrator Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    11,691
    Current Local Time
    03:14 PM

    Not allowed! Not allowed!
    Yep, you can. We have Filters for the wall heights as well.

  7.    #17
    Junior Member
    Join Date
    June 2, 2015
    Posts
    30
    Current Local Time
    09:14 PM

    Not allowed! Not allowed!
    Quote Originally Posted by Twiceroadsfool View Post
    Yep, you can. We have Filters for the wall heights as well.
    How'd you get the wall filters to work? Unconstrained height isnt a parameter in the drop down lists of parameters available for filters in plan views (in rvt2019 anyway).

    Hit a brick wall with making it do the same as fire in plan views so ended up making a schedule that will only show interior walls. Added a wall type parameter called "max.PotentialHeight". And a calculated column with yes/no if unconstrained height is higher than max.PotentialHeight. lastly made the schedule filter to only show the walls that had a yes against them in the calculated field.

    So in theory someone can use that schedule as a check and go through any walls that appear in it to resolve them.

    Would love it to work in plan though like the fire ones. Just hit a brick wall with it.

  8.    #18
    Administrator Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    11,691
    Current Local Time
    03:14 PM

    Not allowed! Not allowed!
    So, im going to hold off on answering, since this is a copy and paste of a response in another thread. There isnt a point to me AND Rob both typing responses. I cant stand when people do this in forums, or across multiple forums.

  9.    #19
    Junior Member
    Join Date
    June 2, 2015
    Posts
    30
    Current Local Time
    09:14 PM

    Not allowed! Not allowed!
    It's more for other people searching the forum as well as me. One thread might come up in a search for solutions where as another won't. Putting knowledge in multiple places helps more people learn.

    But fair enough I know better than to annoy the administrators in the future.

  10.    #20
    Administrator Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    11,691
    Current Local Time
    03:14 PM

    Not allowed! Not allowed!
    Well, we disagree. But it's your thread. I'll see myself out.

    Sent from my Pixel 3 XL using Tapatalk

Similar Threads

  1. K coefficient vs type-instance parameter
    By r12 in forum Architecture - Family Creation
    Replies: 2
    Last Post: July 12th, 2016, 10:52 AM
  2. Cant get yes/no parameter to be instance based on tag family
    By byk3bep in forum Architecture - Family Creation
    Replies: 6
    Last Post: August 19th, 2014, 06:13 PM
  3. Replies: 0
    Last Post: August 26th, 2013, 07:45 AM
  4. Including instance parameter in type parameter formula
    By sabari2504 in forum Architecture - Family Creation
    Replies: 2
    Last Post: August 12th, 2013, 02:54 PM
  5. Parameter that works as a Type, not as an Instance
    By Stuntmonkee in forum Architecture - Family Creation
    Replies: 6
    Last Post: March 16th, 2011, 03:59 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •