CodeBook libraries have insighted much opinion and debate over the years, in this post I'll touch on some of the history, what is available now and what makes a good library in my opinion.
Back in my day...
When I first started using CodeBook in 2003, it came with a library database built on the ADB briefing system and an image library of microGDS or AutoCAD blocks. At the time we had 3 major projects running simultaneously in AutoCAD, with each of them using a different briefing system - ADB, Hiltron and Healthcare Environments (HCE). Once we started to develop our exemplar rooms, we soon realised that the 'out-of-the-box' CodeBook library didn't contain everything that we needed and we would need to create project specific content. Also some of the existing blocks, weren't drawn in the way we wanted and so also required some attention.
Naturally each of these projects had their own project database and library, their own set of exemplar room layouts and after drawing equipment and room layouts 3 separate times with only minor differences between them we thought - there has to be a better way! At first the questions were - why doesn't CodeBook provide a decent library? Why are the blocks drawn so badly? I'm sure that I asked Peter these questions quite directly and probably a bit rudely on several occasions.
To his credit and in his usual style Peter explained politely, calmly and succintly that each practice does things differently, each project has different requirements and that he could spend the rest of his life drawing content and still not make everyone happy. Shortly after this he created a new build for me, which added additional fields in the database for different briefing systems (cwfCode2, cwfCode3 and cwfCode4) and enabled us to have an ADB, Hiltron and HCE code neatly sat in parrallel with each other all linked to the same CAD graphic.
The issue of library content had still not gone away though and so myself and a colleague decided to tackle the issue head on and organised a meeting between ADB, Hiltron and HCE. Peter also attended along with a few other architects and service engineers. There was hot debate about industry standards, what wasn't being provided and the lack of content sharing between the various parties. Unfortunately, the differing commercial interests of each party meant that the idea never really gained traction, despite the good intentions.
So whilst being a little disheartened, we decided to consolidate the libraries from these 3 major projects into our very own practice library ready for whatever future project came up, regardless of the briefing system used. This was very powerful and we also picked out the best exemplar rooms from each project and made them into assemblies ready-to-go on the next project. We still felt there was something missing though, as we had lots of individual room data templates (design, finishes, m&e) and assemblies which, on a large project, were very difficult to coordinate and manage. Soon enough, we had another new CodeBook build to try out which introduced Room Types and combined all of these separate templates, plus more.
I learned some valuable lessons back then and working together with Peter, gave us great results. Fast forward to 2011, Revit and Australia and I find that I'm having similar conversations with people albeit several years later on the other side of the world.
So what is available now and what makes a good library?
The standard CodeBook libraries offer both UK and Australian room data sheet templates and provides an AutoCAD library that can be converted into Revit families or A.N.Other platform. There is also now quite a lot of free content available on-line in the form of sketchup models or Revit families. The more astute manufacturers are starting to understand the benefits of modelling their products in Revit and making them available to the industry. Manufacturers producing these aesthetically pleasing accurate families, with O&M manuals and other FM data are already standing themselves apart from their competitors.
There are also companies whose core business is building families and generally speaking these are available for a reasonable price, but you are licensing the right to use the family - not the IP or the exclusive use of it. Not a problem for many practices, but there is yet a further option for the more discerning Revit user - to outsource the creation of your very own custom built library to India or Asia, where you can specify your requirements and have your families built cheaper than you could do in your own studio.
But with all of the above, you need to understand what it is that you are loading into your models and using in your documentation. What is the right level of detail (LOD)? Are the families dimensionally correct? Do they comply with local regulation? The responsibility for this has to remain with the party producing the model or drawings in my opinion and not necessarily the person who produced the family.
Many people think that you can start a project with an "off the shelf library", that will not require any editing throughout the duration of the job. The reality is that you will always have project specific content and each client will want to see greater or lesser detail, descriptions, groupings or coding systems than you currently have. Personally speaking I think investing resources into creating a generic library and then resisting the temptation to make it bespoke for as long as possible is a sound strategy.
At my practice we have made this investment and are now starting to realise the benefits of this work, plus have avoided large volumes of work duplication. In addition, we are generating a series of generic rooms and room data sheets with the goal that each project uses this as a starting point and, through the design development stage, update these to suit specific project / client requirements.
The concept is really quite simple, start from a point of compliance and don't re-invent the wheel each time you start a new project - however - many practices struggle to understand the value of this 'non-project-specific' work, or comprehend sufficiently enough to fund it. This really makes it a strategic matter and if a practice is serious about BIM and Healthcare, they will need to invest money and resources which cost in the short term, but will provide efficiencies in the future.
In addition to creating families and room assemblies, we've also spent considerable time reviewing the data component, in that we have several coding systems sat in parallel, complete with group, class and numerous other properties. These equipment properties are mapped to a corresponding Revit Equipment Parameter, contained within a Shared Parameter file, so that we have continuity and achieve synergies across multiple projects and studios.
Content sharing has been a hot topic of debate and whilst I'm a supporter of the ideal, I'm still uncertain of how it would work in practice. For example, if we were to give our library to another practice, they could not utilize it in the same way that we do in a 'plug-and-play' fashion. Why? Because it is setup to work in our Revit environment and is based on the criteria that we selected. Most practices will have similar requirements, but the naming conventions we use, the coding, description, equipment parameters, revit schedules, views and other 'template' related items will differ and so other than providing a visual representation, using someone else's library has limited value.
To summarize, some of the main elements that make a good library are:
1. Compliance with local standards
2. The correct LOD - i.e. don't model the nuts & bolts, just the general form.
4. Equipment data, and last but by no means least
5. Guidance material
You can have the best library in the world, but if no-one knows what it contains or how to use it.....maybe that's why you're reading this blog now!
There are many other parts to this issue, parameter mapping, types & catalog files, reports, legends etc... which I'll cover in separate posts.