Level management in the context of UK BIM (ABD SS5)

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.

  • I have to agree.
    That is why I am always questioning the standards and the problem with all this openness. Now don't get me wrong. Open is find if you need it. HOWEVER

    There needs to be a very complete, well thought out, and productive set of standards that most everyone can be happy to use. I dind much of this openess is NOT because of the need for openess but because of a lack of a very complete solution.

    Ustn since 1988
    SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64b

    Eric D. Milberger
    Architect + Master Planner + BIM

    Senior  Master Planner NASA - Marshall Space Flight Center

    The Milberger Architectural Group, llc

  • Hi Thomas,
    Changing the levels in a dataset is a fairly long and tedious operation. We are currency producing a UK dataset containing level names that are fully BS 1192:2 compliant (there is a name formatting issue in the GB dataset for historical reasons) and that has involved a significant investment of time. This will be available a few weeks after SS6 is released.
    The best approach to customisation is to add a set of company dataset folders to contain company wide customisations, complemented by project customisations of needed. All of your customisations are then in a clearly separate location so easily managed when dataset updates come along.
    I recommend that you implement the forthcoming SS6 release as soon as you are able, the DataGroup management tools are hugely enhanced and very useable. That will make any work that you need to do in the DataGroup far easier particularly with respect to organising customisations into company and project.
    There is a conceptual shift in ABD and it's precursors away from levels to properties. Levels are just about graphic display while editing models, the DataGroup properties are the 'I' in BIM.
    I recommend that you stick with the delivered levels but look at adding company folders and also at customising Drawing Seeds to control output. This course in the LEARN server should help with the latter: learn.bentley.com/.../ViewLearningPathWithMasterCourseExpanded;mcId=100731
    or this article:
    communities.bentley.com/.../abd-sheet-borders-and-title-block-fields-with-drawing-composition-tools-and-detailing-styles

    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.

  • Hi Marc,

    Thats very helpful, thank you. I shall look out for SS6 (is there an anticipated release date as yet?).

    Some of our staff were at the Manchester conference last week and mentioned the current work on a UK dataset, so that should be a help to what I'm doing at the moment.

    From the sounds of I think ABD is pretty impressive / comprehensive in how it will automate much of our compliance with BS 1192. We're just in a phase at the moment though where we have lots of staff still using legacy systems, and it would probably be too much to expect them to change to match what ABD does in their own work.

    I get the feeling our projects maybe need to be all-or-nothing with respect to ABD usage. If they aren't I predict we will end up needing a lot of manual work to translate between the two, and that would wipe out any benefits we'd have been looking for in deploying ABD.