|
|
Re: NCS and BIM
I have to agree with Arron on the fact that BIM is front loaded, As we think of a front loaded standard we can't make the graphical output the main focus. I feel Omniclass is part of the items that front load information into BIM objects, but it is only one piece of information that can go into an object.
Besides for assigning an Omnoclass number there has to be other things that we can standardize that is under the hood of the BIM object.
Re: NCS and BIM
I'd have to agree that the NCS really addresses the documented portion of a project. Any standards created for BIM need to focus on the information and how it can be organized so that it may be shared efficiently. Essentially, it's the same reason that most of us adpoted the NCS, so that we could interoperate with other designers and not have to create a new standard every time this happens.
Our office finds itself in the position of working with multiple architects on a single project lately and it can be difficult to setup a standard for each project. Sometimes we get lucky and get to take the lead, but other times its a time consuming compromise between firms.
Re: NCS and BIM
I have always considered 'drawing' representing building components.Originally Posted by twiceroadsfool
and I suspect most of us here can agree that 'modeling' is also representing building components.
so yes there are differences in data management, format, and deliverables; but i believe this thread was created to discuss the commonalities between NCS and NBIMS and to discover ways to bridge the gaps.
My bad i had forgotten this was included in 4.0 and wasn't aware it was in 3.1. unfortunately my office was stuck on 2.0 until just this past june. I am sorry you are not finding the provided content useful.
it is important to define an ends before considering a means. NBIMS lays out an ambitious vision:
1) product modelling and computer-aided engineering
2) ISO 10303 (also known as STEP: Standard for the Exchange of Product Model Data)
3) Industry Foundation Classes (IFC), and
4) Building Information Modelling (BIM)
we should not loose sight of this as it is a well rationed approach.
at the moment there are plenty of areas for NCS to speak up still on clarifying 2D representation throughout more of the facility lifecycle. Matthew (MAM who started this thread) mentions at least a dozen of them on his Revittize blog. i encourage everyone to visit his site and read the NCS tagged posts.
this is rather astute of you that yes i do currently represent a very large owner. and to be honest i have learned quite a bit here. for instance i now have a better appreciation for the fact that the operations and maintenance of a facility represents 70-80% of the lifecycle cost of our buildings. it is indeed this perspective that i suggest the future of NBIMS should consider; and therefore the future of NCS as well.
this is well presented in the MacLeamy curve. what is not is the additional fact that each BIM authoring tool has an important role within an ever expanding workflow for developing a facility. we need to move beyond the concept that the BIM is a single repository per portfolio/facility/building/project/discipline but rather a federation of many BIMs. perhaps then we can more readily agree on a path forward. but you are right in eluding that developing software specific solutions for each app will be helpful for both enabling collaboration and excellerating adoption.
how about i go first with a concrete example suggestion for discussion:
- i don't like how the Revit 'Export CAD Formats' wizard creates a DWG for a View. It creates an XREF link OK but unfortunately it is to a newly generated file that is not what we AutoCad users would expect to be the corresponding master Model DWG. it is to some other file that we end up throwing away. and then the sheets don't work, and then you have to ... well you get the idea. anyway this should be an easy thing for Autodesk to resolve and would make sharing content significantly smoother.
Re: NCS and BIM
Im not disagreeing that were "representing building components" Im disagreeing that "thats what weve done for the last twenty years." We represented building components, then we spent a fair amount of time heckling our staffs over things like leader Line offsets, Tags sizes and locations, and Pen tables and lineweights. None of which is relevant in the Built environment. Is it relevant in a drawing? Eh... arguably. Theres another thread here started about the important of Aesthetic "prettiness" in Architectural Drawings, and in that thread i think youll find a great deal of posts articulating that good LOOKING and good WORKING are different. As far as that goes, i think the NBIMS and the NCS need to be, should be, and will have to be, very different. If they focus on the output of lineweights for Electrical Outlets, but not the Quality of Content and articulation of those Electrical Components, then the NBIMS will never be much. I have faith they wont go that way.
Its not that im not finding it useful... Its just woefully out of touch. Not all Toilets are the same. Not all Tank Toilets are the same. But they have "a symbol" for a tank toilet. So fine, in the days when we were doing simple 2d drawings, it served a purpose for visual clarity. Im not sure that task is still relevant. I'd RATHER they came out and said "Here are the SPECIFIC data fields we want your Model to contain." i dont mean the LOD matrix, that tells us when to model what, and its all good. But tell us, SPECIFICALLY: What data do walls get, what information fields do doors get, what do mechanical units get... Then we will be finding the rubber hitting the road. Suddenly Shared Parameters files will start making the rounds, and Schedules will all interpolate each others offices... Suddenly Content for free will actually work (because we can barely use each others stuff now... And manufacturers think "metadata rich" means stuffing their website in to the URL of a component, LOL.My bad i had forgotten this was included in 4.0 and wasn't aware it was in 3.1. unfortunately my office was stuck on 2.0 until just this past june. I am sorry you are not finding the provided content useful.
All good and well- as i stated in my earlier post- that they defined the "vision" first... But if they dont get in to the means, it wont mean much. Consider "IFC." All of the heavy hitters supposedly are completely compliant now. So were all good, right? Ever actually pull an IFC from one platform in to another? Now, i mean for MORE than just a geometrical representation. Items come together, but its a sloppy disasterous mess. I mean, ive seen it work, but- much like your Revit to AutoCAD example- you dont get a product like the one you WOULD have made.it is important to define an ends before considering a means. NBIMS lays out an ambitious vision:
1) product modelling and computer-aided engineering
2) ISO 10303 (also known as STEP: Standard for the Exchange of Product Model Data)
3) Industry Foundation Classes (IFC), and
4) Building Information Modelling (BIM)
we should not loose sight of this as it is a well rationed approach.
at the moment there are plenty of areas for NCS to speak up still on clarifying 2D representation throughout more of the facility lifecycle. Matthew (MAM who started this thread) mentions at least a dozen of them on his Revittize blog. i encourage everyone to visit his site and read the NCS tagged posts.
Just yesterday i took some Framing members from Tekla > IFC > Revit... They came in as IN PLACE architectural columns. Thousands of them. Shame on both Tekla and Revit. (Im not singling them out... thats what i mean though, if ALL of the manufacturers dont do more, based on a more serious demand from the "standard" then its useless).
I dont know of many people still considering it one model. I mean, by the time one of our projects is in the ground, theres probably at least 20 models for it... At LEAST. Design Models, Construction Coordination Models generated from and advanced from Design models, Fabrication Models, Record Models... All the MORE reason why the NBIMS needs to start laying some serious groundwork for Application Specific directives, instead of the very glossy veneer its gotten so far. Were able to really push it, on not having to do much rework between the Design Teams, the Construction Coordination, and the Fabricators making it all a reality, but its not as seamless as it could be. NBIMS doing something as simple as saying "All walls have a field for "Fire Resistance" (in hours) and then stipulating that IFC compliance means "translates that field correctly in and out from the counterpart softwares" would go a long way. Imagine if they did that for all items? yes, it would be a ton of leg work, and you would start to see less anarchy amongst the modeling world.this is rather astute of you that yes i do currently represent a very large owner. and to be honest i have learned quite a bit here. for instance i now have a better appreciation for the fact that the operations and maintenance of a facility represents 70-80% of the lifecycle cost of our buildings. it is indeed this perspective that i suggest the future of NBIMS should consider; and therefore the future of NCS as well.
this is well presented in the MacLeamy curve. what is not is the additional fact that each BIM authoring tool has an important role within an ever expanding workflow for developing a facility. we need to move beyond the concept that the BIM is a single repository per portfolio/facility/building/project/discipline but rather a federation of many BIMs. perhaps then we can more readily agree on a path forward. but you are right in eluding that developing software specific solutions for each app will be helpful for both enabling collaboration and excellerating adoption.
We could do worse, in making a starting suggestion... But we could do better, too. Yeah, exporting currently stinks. The way it makes a CAD file is lousy. But the way it makes a file format-neutral file is lousy too. Id rather no one focus on a tool that turns a Smart Model in to dumb (non-intelligent, not an insult...) 2D drawings, and focus on getting the people who need the CAD drawings in to the current world, where they dont need them anymore.how about i go first with a concrete example suggestion for discussion:
- i don't like how the Revit 'Export CAD Formats' wizard creates a DWG for a View. It creates an XREF link OK but unfortunately it is to a newly generated file that is not what we AutoCad users would expect to be the corresponding master Model DWG. it is to some other file that we end up throwing away. and then the sheets don't work, and then you have to ... well you get the idea. anyway this should be an easy thing for Autodesk to resolve and would make sharing content significantly smoother.
Ive worked with Owners, Tenants, architects, engineers, Construction crews, fabricators, and on and on. I cant think of a solid reason to maintain a better method for punting a Revit file to AutoCAD.
Re: NCS and BIM
I don't see how people don't get IFC working to a useable level? People complain about it all the time but actually puts effort into understanding what IFC is doing and how it is storing and translating data.
For instance you say all your columns came in as architectural. Did you map them as structural members? Did u identify how the section mapping setups should work so they don't come in as proxies?
Do you know what data is being mapped to in terms of psets?
I just brought in an archicad high rise 180mb into revit with 3 missing elements after a clean comment and asking for a reissue with changes. I went through solibri identified some elements to be corrected on the export reported them to the architect to change his setup. Made sure my IFC and cad import (yes they are linked). We found the issue related to a connection setup for the missing doors so that was fixed and all it came in. Beams, structural columns (if they are arch why would they match steel sections lif they are arch items and therefore won't generate as an extrusion) slabs, ramps, facade curtain walls and breakdown on the IFC roof container are all the same mapping is crucial and auto desks out of the box is woefully inadequate which becomes worse when u customize revit add subcategories without setting up your maps.
The real issue with IFC is no one really understands it, they just think it is a cad format that converts things to smart objects. look at files in their native formats either via solibri, IFC viewer (1.2mb) free download. Realizes where the file is breaking down and most importantly corrects and understands what needs to be changed to be mapped. My only wish is that revit can't more properly define parameters outside of pests into their correct schemas, and I'm guessing u could set that up with some good API work with the IFC export.
IFC is much bigger then a translator, it's not meant to be a translator it's meant to be a format where data from models can be all located in a database and view definitions can be extracted for a particular purpose. It's not turn it into this or that it's the end result think navisworks but way more powerful. The issue is there is no commercial software apart from solibri to support the dvelopment on higher end functionality and modeling, but for the most part it does what it's meant to quite well, and anything u can't have natively you can build into the schema to support it since it's open source.
Even if every software export out there was perfect without proper mapping procedures both export and import into the other packages (which requires some knowledge of the program and how it preps data, their standards, your standards any customisations) for a purpose the data from each vendor software it won't work anyway. I know your after quick and dirty but for me getting that model across took me an hour to remove the 60 missing elements and hundreds of misaligned and wrong categorized items not including e time it took the arch but it only took them a couple of hours to get back to me with a new IFC with the correct mapping. Just by talking looking and understanding how we both work and setting up a workflow exactly like an initial bim exec meeting on revit project.
Ps I am not a programmer I just read the IFC schema and a quick read over how programs read and write IFC files most packages offer info on help files or you can ask for it. Changing the revit IFC importer text file is hardly programming.
Last edited by m20roxxers; 2010-09-29 at 10:21 AM.
Re: NCS and BIM
Thanks for the awesome reply, im glad the IFC is working well for you guys in getting things back and forth.
Allow me to elaborate (briefly, since im late), but to also clarify: Its not that i think IFC is junk, but there are things it needs to do differently. Part of my issue is exactly what you stated: i dont know what the elements were mapped to, nor wil i have the opportunity to know that. Part of us defining it as a "standard" means we wont always get to HAVE a kickoff meeting, wont always get to tailor the exports, or ask for new ones after the fact. The IFC file will be there, and that will be that.
Can you tailor it to get "closer" (okay, ill bite, REALLY close, in your case) to what it should be? Maybe. But if its doable- and ill concede that maybe it is- THOSE classifications should be set in the NBIMS. And if they are (they may be), then the software ought to ship preconfigured correctly, if its "compliant."
Second, i understand its not JUST a translator, but that is one thing that we use it for. Viewing an IFC is one thing (i use DDS myself), but using it to integrate with authoring tools is another. Right now, it wont matter how i remap the items, theyre coming in as In-Place families, regardless. Thats a revit specific thing, and to be clear, im not faulting IFC or the NBIMS for it, im faulting all of them for it. The information and the data is all good, as long as you dont need to work with it. But if you DO, youre going to go back to your application, whatever that may be. But 30,000 metal studs all as independent In-place families, is going to bring a model to a crashing halt. Maybe we need it for coordination, maybe we dont. That should be up to us.
But again, to be fair, im not holding THAT against the NBIMS. Im holding the fact that what we have now, passes for IFC compliance.
I think its awesome you guys were able to make it work, and to be honest- id love to see it. But id also love to see it happen in an environment where the other parties arent there, so theres no more retooling their workflow. if were talking about a standard, were talking about an Owner who may have an IFC from a building, and the people who authored it may be well out of the picture.
I make the IFC's work, at getting the geometry in for coordination. But its heavy. Realyl heavy. In a "do it in a link and try never loading it since its such a drag" kind of way. Id like to see all parties involved work on THAT. (Again, to be fair, it happens we we Export OUT and go to other wares too. Forget export to DWG, ive seen our models after going RVT > IFC > Bentley, and its rough at best).
Re: NCS and BIM
i have also had significant success creating a workflow for migrating residential ArchiCad projects to AutoCad Architecture projects using IFC. After just one day of trial and error all appropriate objects were properly defined on both sides and could be moved through IFC from one to the other fairly seamlessly. this was of course for a relatively conservative set of object types with no complex geometries. i did not attempt to troubleshoot problems with round tripping back across these platforms however as there were many. in fact i was surprised that roundtripping even within the same platform was fairly poor. the Graphisoft result was much better than the Autodesk. this was circa 2007 using IFC2x.
on the NCS side:
but none of the 2D documentation information can be ported over using IFC. so a second series of coordination efforts needed to be enabled using DWG files as well. this is where this thread should be focused on. where does NCS speak up on interoperability where NBIMS does not.
on the NBIMS side:
as for the need for attribute mapping consistency (i.e. Revit shared parameters and the like) i am pleased to say that i am in agreement with 'twiceroadsfool' that this is a worthy issue for us to pursue at this time. regardless of HOW we store the data we certainly can move forward with coming to a consensus of WHAT we want to store. it isn't that difficult.
a request:
my office (my day gig is for the GSA) is about to spend a significant amount of money to actually model a building to partial LOD500 in order to explore this very issue. we will be creating Revit Families for all equip that needs to be tracked for preventative maintenance. the lessons learned will be made public. we are considering using the AECsystems ObjectElementMatrix spreadsheet that the VA had produced last year as a starting point:
http://www.cfm.va.gov/til/bim/BIMGui...loads/oemf.xls
it is quite excellant and i encourage you all to check it out.
my request is that if any of you know of another or a better list of object attributes then please by all means let me know. thank you.
Re: NCS and BIM
The same is true in Revit. Round trip in and out of Revit isnt that great. I HAVE heard that ArchiCAD's is the best of them, though when i WAS using ArchiCAD i wasnt playing with IFC, so i have to plead ignorance.
I wholeheartedly, and super enthusiastically, agree. This (what you just stated) is the primary reason i hate the acronym "BIM" even though its in my job title. Manufacturers now readily think that storing their company website, company telelphone number, and Paint Color in a Revit Family qualifies as "BIM" since theres information in it. i would LOVE a document that delineates what data is paramount. We have one internally, of course, but... were not the NBIMS.on the NCS side:
but none of the 2D documentation information can be ported over using IFC. so a second series of coordination efforts needed to be enabled using DWG files as well. this is where this thread should be focused on. where does NCS speak up on interoperability where NBIMS does not.
on the NBIMS side:
as for the need for attribute mapping consistency (i.e. Revit shared parameters and the like) i am pleased to say that i am in agreement with 'twiceroadsfool' that this is a worthy issue for us to pursue at this time. regardless of HOW we store the data we certainly can move forward with coming to a consensus of WHAT we want to store. it isn't that difficult.
if you would like, you can shoot me an email about this. Were actually doing some work for your day gig right now.a request:
my office (my day gig is for the GSA) is about to spend a significant amount of money to actually model a building to partial LOD500 in order to explore this very issue. we will be creating Revit Families for all equip that needs to be tracked for preventative maintenance. the lessons learned will be made public. we are considering using the AECsystems ObjectElementMatrix spreadsheet that the VA had produced last year as a starting point:
http://www.cfm.va.gov/til/bim/BIMGui...loads/oemf.xls
it is quite excellant and i encourage you all to check it out.
my request is that if any of you know of another or a better list of object attributes then please by all means let me know. thank you.Id be happy to send you what we use as our project Guidelines, for the different Levels of Detail, including up to Level 500. Our Level of Detail matrix up through 300 is specific to Construction Documentation, through 400 is Construction Coordination Specific (so it encompasses more than Revit, since most of our Subs and fabricators arent using Revit), and LOD 500 is much the same in that regard.
Feel free to email me at the office: aaronmaller at beckgroup.com
Re: NCS and BIM
that sounds very interesting and rather generous. i will contact you via email next.
for all others here is my GSA contact info should you find it useful:
Matthew J. Waychoff
Computer Integrated Facilities Manager
Public Buildings Service, Region03 - 3P1PGS
U.S. General Services Administration
o2154465725
m2672503336
f2158738437
matthew.waychoff@gsa.gov
Re: NCS and BIM
my office (my day gig is for the GSA) is about to spend a significant amount of money to actually model a building to partial LOD500 in order to explore this very issue. we will be creating Revit Families for all equip that needs to be tracked for preventative maintenance. the lessons learned will be made public. we are considering using the AECsystems ObjectElementMatrix spreadsheet that the VA had produced last year as a starting point:
http://www.cfm.va.gov/til/bim/BIMGui...loads/oemf.xls
it is quite excellant and i encourage you all to check it out.
my request is that if any of you know of another or a better list of object attributes then please by all means let me know. thank you.[/QUOTE]
Wow. That VA list is kind of insane! Like looking for additional tax data for foundations, and then total ownership costs.
God forbid any of our clients really ever want to pay for embedding that much data in a model. And then who gets to find all the data, and validate it. And then updating it over time, because many of those values will vary by time.
Then we get to translate it into another CAD format.
Just wow.
There will never be a standard that can do what people are trying to do with that. It's just too broad, and it will always be either too complex, or conversely it will not cover something that someone somewhere will consider vital. Personally I would start with a less comprehensive standard and then add to it over time, after their is some buy-in from the user community.
But hey, someone has to try to sort this out, so hat's off, that is quite a list.
Posting Permissions
Reply With Quote