Hi,
A lot of companies have their own level / layer naming conventions for 2D draughting, and there is a temptation for them to mandate that ABD should be configured to follow those standards. My gut reaction is that there are probably a number of reasons why it would be a bad idea / approach. For example:
* Levels appear to have a close tie-in with DataGroups; Would there not be a huge config burden in mapping DataGroup items to manually defined layers?
* Levels appear to have a close tie-in with Dynamic drawing views. Would there not be a huge config burden in setting line styles etc?
* Clients sometime mandate their own level standards be used. Wouldn't regular changes to the level libraries in operation be confusing for staff and increase the chance of potential errors & required rework?
I'm trying to minimise the amount of ongoing admin / config required for ABD within the company. I would have thought therefore that using (and deviating as little as possible from) the GB dataset would be the best approach in my case? From what I have seen:
* The GB dataset is based on Uniclass codings (pretty industry standard / probably likely to be accepted by most clients?)
* Most DataGroup items automatically get put on the relevant layers, and explorer does a good job of auto-generating schedules.
* The dynamic drawings we've produced thus far have looked pretty good to say that they've been auto-generated only from the 3D & layering data.
I'm worried that by customising our ABD configuration too much, we would either risk losing the main benefits we are trying to realise by moving to BIM, or we would be creating way too much ongoing admin work in maintaining those configurations.
I'm interested in hearing / discussing potential approaches to level management in members' ABD configurations. I'm specifically interested in level management for the purposes of BIM, and - though I assume the concepts are the same worldwide - I am operating in the UK.
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
Regards
Marc
I think you're right to question standards Eric. Over here in the UK BS 1192 seems to be being bandied about a lot in BIM circles, and appears to be being used widely as the basis for naming conventions. In my opinion, BS 1192 is fundamentally flawed in respect of naming conventions (as is any naming convention like it).
Why... Well, the fundamental aim of a name is to be able to uniquely identify an object (to allow robust storage, referencing & retrieval). 99.9% of staff in engineering firms don't grasp that the content of an object is 100% irrelevant to that aim (unfortunately this extends to a lot of board-level appointees on standards committees). As such, engineering firms tend to get lost / paralyzed in the detail of their objects when trying to come up with processes to manage them. This has happened with BS 1192 as well, which leads me to believe that it will not last long in its current form.
BS 1192 says that information about the content of objects should be encoded into their name. This is an example of a "significant part numbering system", and has been shown in theory and practice only to be appropriate for managing objects when the full population of objects is known at the time the system is devised. Such systems are very bad at accommodating change (but how much of that is there in a typical engineering project, eh?). Over time, in the presence of change, such a system is *guaranteed* to decay into disorder, slowly or rapidly, depending on how good you are at predicting the future, and how much effort you want to spend on maintenance. A cynic might suggest that the types of people you typically get planning these systems & procedures naively think that their vast experience in the industry enables them to see the future in perfect clarity! :D
The justification in BS 1192 for its naming convention seems to be Windows Filesystem(!!); They suggest that the codings enable sorting & search in Windows. I.e. They are trying to use (just) a filesystem when what is really required is a database. They conveniently forget to mention that the coding system is useless unless you know the code. And when people don't know the code, they tend to just guess (which brings its own set of problems / costs to a project). Better (in my view) for staff to be faced with a dumb/uninterpretable document number as opposed to a number which they *think* they can interpret correctly. In the former case, they are forced to go away & consult a database, whereas in the latter they carry on regardless naively thinking they have the right information (and potentially do a load of abortive work & create disorder / confusion in the project). Three points strike me:
* There just isn't enough information in those BS 1192 encoded filenames (and they're already too cumbersome).* It is a half-way house solution, and nowhere near good enough in this day & age. * If it can be expected a user has Windows, then it can also be expected a user could run & use a simple database of some form (and I'm not talking about expensive proprietry EDM's here).
Sorry about the rant but I could go on for hours about file naming conventions, it is such a poorly understood subject (in the field of Engineering at least). The same fundamental issues have come up again and again in every business I've worked with!
In spite of all of the above, I think for now my company is going to have to work with BS 1192 (mandated by clients, rightly or wrongly), and so I am interested to hear how ABD users have been doing similar, especially in relation to level names / management.
I mean initially, I had planned to just follow BS 1192 for naming of files, and then within DGN's just stick to the standard GB dataset level naming conventions (from uniclass). That seemed doable to me, if not slightly fragile due to the fundamental problems with BS 1192. But extending the scope of naming conventions to levels within DGNs just seems extremely fragile to me.