We, Bentley, have been working on compiling an ABD dataset compatible with Uniclass 2015 for some time. The recent changes to the tables has provided an opportunity to carry out a sanity check and ask you users of ABD etc. for your opinion about this standard and how you would want to see it implemented within ABD.
We are particularly interested in your views about how to set up a layering system, what information you would expect to see predefined in the dataset and what you would expect to set your self. Please remember we also have to consider the relevant standards for CAD levels, object naming etc.
Here is a link to the NBS website that has information about the Uniclass Standard.
If possible we would like you feedback as soon as possible, including examples and reasoning.
Many Thanks
Brenden
Eric,
Uniclass is the UK's version of Omniclass. Here is a 'quick' description.
Unknown said:Do we try to use a single table?
Looking at BS 1192-4:2014 (COBie) which is unfortunately not aligned with Uniclass 2015, there is reference to Table D Facilities (Ac Activities + Co Complexes), E (En Entities), F (Sp Spaces), G+H (Ee Elements) , L ( Pr Products), C Management. So I guess the answer is 'no'. Table 7 also suggests that some of the Uniclass tables can be replaced by other NRM tables.
Unknown said:Do we need to use multiple tables?
Probably. But, the UI needs to be able to aggregate the multiple tables sensibly for the user based on the relevant schema or task. COBie is related to one task / MVD. Plenty of other MVD's.
Bentley would need to start using mvdXML and Ifcdoc to avoid drowning in future by supporting:
"dynamic functionality that may be supported include:
Soft-typing vs hard typing is not really a preference question. Some properties will need to be hard-typed and managed using rules. It would seem that a lot of these rules would be defined and captured in xml format. IFC itself is written using a data definition language (Express-G). At the moment, there is a dangerous lack of tools to manage all those properties that will be needed to comply with BIM standards.
Unknown said:Will we use different tables during different phases of design e.g.( elements mainly during conceptual design being superseded by systems thereafter)
Apparently, the answer is yes according to PAS 1192-2 and COBie's take on Data Drops.
Need to develop the tools to handle the requirements behind these questions. Just formating and populating some of the property fields by itself is a start but not the answer.
I understand ans was looking at the Unical/Omniclass peices and how they would be used in a model to construct the 2d documents and the model. Not just the same and standards for that name. Kind of liek the discussion we went through after the AIA created a dead level symbology we have today.
I was looking at what would be your final naming and structure based upon what you need to create documents.
I need a PIECE that is composed of parts and a summary Piece
the parts are easy - anythgin I'd want to quantify or measure in a darwing.
The summary piece is what carries the Uniformat/Omniformat Name and data as a whole while the parts cary part information.
This would may be an overall part that could be created from the pieces or a manual Part with the Uniformat name.
Maybe this is the piece you measure from or the part that defines visible surfaces.
Thus you may need another part that is the part to measure.
for example. typical stud wall with brick face, conc. footing and coping.
The name would be composed from these.
And I would use Master Format for the parts this a start on the Assembly.
Think of how you build the model maybe as an ordering - Ground, Site, Footing, Foudation, Struture, Exterior Walls, floors, Roofs, Interior Walls Finishes, etc.
How you build in real life is very similar to how you ahve to bulild your model and how products relate to each other in thought.
You could still have a key to interpret the name but DO REMEMBER WE ARE NO LONGER Limited to 8 characters
So I'd likd a medium name with abbreviated names that tell the story
Horrible name but I would look at how I can divide this into libraries of Assemblies As each library could have many many assemblies.
Wall-Int-STLstud-gyp-brick
Ustn since 1988SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64bEric D. MilbergerArchitect + Master Planner + BIMSenior Master Planner NASA - Marshall Space Flight CenterThe Milberger Architectural Group, llc
Emil, I think that you are looking things wrong. IFC is about composition and spatial containment or 'part of' relationships, while Uniclass is about 'type of' relationships. If one does one kind of hierarchy, it would be good not to mix it up with another. Naming is context based. COBie has a particular requirement based on producing concatenated names based on various properties. It also has a requirement to number them uniquely. I suspect that the other MVD's will have other naming requirements. You seem to want to 'hard code' the naming/numbering system. I think that you will end up with a 'dead end' situation repeating the problem you mentioned in your post. What we should be looking at is providing the tools to re-map, generate, cascade names as required according to any selected Schema.