I'm interested in hearing what would be the best approach to parring back the UK dataset somewhat?
The out-of-the-box Dataset_UK is very buildings & architecture focussed, whereas my clients' organisation is a multidisciplinary site construction company. I find the dataset content is too detailed for our needs in areas, and then virtually non-existant in other areas.
Every piece of help or guidance I've found, as well as every consultant I've spoken to has told me that AECOsim is great for *ADDING* content, and has shown me how to do that. And they've told me that the datasets are intended to be tailored to suit particular needs. However, I haven't actually seen anyone successfully *REMOVING* dataset content, at least without errors & instability ensuing, I think simply because the various tools & procedures AECOsim relies on are so interdependent.
Lets, for instance, say that I want to remove all datagroup content where the uniclass code is 3-digits or longer (i.e. retaining everything under the G0 & G00 level tables, for instance). How would I approach this? Is there a particular order I should tackle the Level Library, Family / Part libraries and Datagroup catalogue definitions? Are those the only things that would need changing, or have I overlooked something? Which config or PCF files would maybe need amending?
The end goal I guess, is that I want to vastly simplify the AECOsim user experience for our staff, who are mostly very new to AECOsim. It presents them with too many options, most of which are irrelevant to their needs as designers and engineers. If we could par back the level libraries, define our own set of useful families/parts, and ensure that our datagroup catalogues contain only the most basic & most-used items for our firm, then we would be able to slowly build & develop content from there.
I'm told, "oh you just need to make a Dataset_Company" for your own standards. But this doesn't stop all the Dataset_UK content seeping through into things from people's local C-drives.
Any help / advice / pointers would be much appreciated, as not being able to *subtract* out-the-box content seems like a fundamental flaw in AECOsim's supposed capability & flexibility (which is why my client invested in Bentley in the first place).
Thanks in advance.
Hi Thomas,
The configuration scenario where the default dataset is used with company/user content separated into company/project dataset locations is intended to be a relatively simple solution that offers some performance benefits by using the local copy of the default dataset (an aspect that we are reviewing while compiling similar guidance for CONNECT Edition) and to simplify the application of future dataset updates.
If one of the primary requirements is to reduce/minimize the delivered content a different approach is required.
One option would be to copy the UK dataset to your network, remove unwanted content, then use that as the location for your own custom content. I would not do that as your custom content would be mingled with the remaining delivered content.
A better option is to copy the UK dataset to your network, remove unwanted content, but have a Company dataset location to maintain the separation between Bentley and custom content.
To reduce DataGroup content you could try the Catalog Item Manager. This tool moves xml content from the delivered dataset to a library file, so the content still exists but is not present in the UI. In its current form the tool ahs limitations. It only move the xml content and does not affect related resources such as cells used by DataGroup items; but in your context where you wish to simplify the user experience should provide the required outcome.
The way I would use this tool is to modify a copy of the delivered dataset, treat that as the WiP source for the operational dataset.
Steps:
There are some details to fill in around this, but that is the overview.
Are you considering moving to CONNECT Edition? A point of change like this would be the best time to do so.
We have minimized the content in parts of the CONNECT Edition UK dataset.
Marc
Answer Verified By: Thomas Hartley
On CONNECT...
I am keen to move to CONNECT Edition as soon as possible, as I think it will solve many of the problems & niggles we've been seeing. We are still, in the grand scheme of things, new to AECOsim, and do not have any major legacy projects in SS6 (although we do work with Network Rail and may need to run SS6 alongside CONNECT so that we're able to delivery work to them compatible with their systems?).
The main thing holding me back from a full-scale migration is that I've been lead to believe that whilst Microstation CONNECT is complete, some elements of AECOsim are still not yet fully operational? My client requires the use of the basic tools within Arch, Struct, Mech and Elec, as well as cut-from-the-model draughting, schedules, linksets / project explorer, and soon also automation using a C# or VBA API.
It would be good to see a completion schedule for AECOsim CONNECT, so that I'm able to assess if/when to migrate?
Also, I don't suppose it would hurt for me to install CONNECT on my own machine to start testing with.
I've drafted some notes on Catalog Item Manger which I hope will be useful.
Not really sure what the suggestion that "some elements of AECOsim are still not yet fully operational" means. Could that be filled out with some details? Obviously there are features that we will be developing further, both ABD specific and at the MicroStation platform level.
Our release schedule consists of:
Note that there isn't a simple migration path from V8i to the CONNECT Edition UK Dataset as we made significant changes to content naming to accommodate Uniclass 2015 classification, particularly removing classification codes from object names wherever possible.
Hi Marc, the catalog item manager link above doesn't work, though I found the content from your recent activity and the post looks really useful, thanks.
With regard to ABD CE, I've been told that the Dataset_UK for it hasn't been released yet, and its been suggested to me that the Electrical & Mechanical tools might not yet be fully ported over?
That sounds like good news on object names having classifications removed from them. Does that extend to the discipline codes also, as I've always wondered why individual levels, objects and families / parts would even require such classification?
BS1192 file & folder naming conventions encode that data into file & folder names, meaning that those classifications come through by reference in ABD rather than at a lower level. I.e. If I want to query whether an Architect produced the data, I can look at the <originator> field in the reference file name and see whether they are an Architect, or I could look at the reference filename <discipline> field and see whether the file content is being considered part of an Architectural system (even if it was specified by a non-Architect firm, for example). As it is now in v8i and Dataset_UK, there is nothing much (other than manual checking) to stop an Electrical firm including an S-G261_Beam in their sub-model, and it almost implies to anyone who doesn't know better that the Structural engineer put that there (and it therefore has been calculated & validated structurally).
Hi Marc,
Is this answer still relevant to CONNECT edition? I've been trying this approach over the past few days and putting the Dataset at the Organisation level of our custom config, but I'm wondering whether it may be more appropriate to have one copy of the Dataset in each WorkSpace\Standards folder (that way, we can have a BIM manager responsible for creating & maintaining each main clients' workspace config)?
As a first pass, I'm trying to configure an AECOsim WorkSpace to support compliance with Network Rail's BIM Standard (NR/L2/INI/EDT/CP0091). And then after that, for instance, we want to do the same for other major clients' CAD / BIM policies in separate WorkSpaces.
I'm only having partial success. Whilst I can add the seeds, dgnlibs, cells etc that Network Rail provide, parts of Dataset_UK are still polluting the workspace. E.g. Under text & dimension styles, the NR ones show, but so do all the styles emanating from the Dataset (which I just don't want to even be there as available options for our users to select). I also haven't switched out the dataset level library for NR's level library yet either (seems a bit daunting if I'm honest as I know its tied in with the Family & Part system and catalogues).
It all seems quite delicate; Changes I make to configure the Workspace to NR standards seem to inevitably break another part of the application.
We're quite a niche contractor really. We don't specialise in Buildings or Architecture, we do multidisciplinary site construction (material conveying facilities, bridges, nuclear handling facilities, rail depots & platforms etc). Its almost as though we need to strip back the "building" focus of ABD, and develop datasets that support the domains we work in, which we're finding is no mean feat. Even finding consultants who can come in & help us seems difficult.
In the scenario you describe it could be appropriate to have a self-contained dataset in each workspace. The intention behind the Organization > WorkSpace > WorkSet structure is to enable that kind of granularity.
Here's an example:
Say you have this WorkSpace:
<server>\CONFIGURATIONS\CE\WorkSpaces\NR\
In NR create/copy the dataset folder Dataset_NR:
<server>\CONFIGURATIONS\CE\WorkSpaces\NR\Dataset_NR\
In the CFG file <server>\CONFIGURATIONS\CE\WorkSpaces\NR.cfg define:
TF_DATASETS = $(_USTN_WORKSPACEROOT)
Then in the WorkSets within that WorkSpace in each WorkSet CFG define
TF_DATASETNAME = Dataset_NR
Alternatively Dataset_NR (or other datasets, e.g. Dataset_UK) could be located at the Custom Configuration level:
<server>\CONFIGURATIONS\CE\Datasets\Dataset_NR
In which case NR.cfg would define the dataset location as:
TF_DATASETS = $(_USTN_CONFIGURATION)
However...
In the case of NR they are still using V8i applications and datasets, so their dataset content would need to be migrated to CONNECT Edition. Given that you only want to use some of the NR content the scale of that task may be reduced.
Of relevance to us from the UK Dataset:
a. Structural - virtually all this.
b. Architectural - Spaces, walls, doors, windows, roofs, stairs, ladders, handrails. The internal building furniture & fittings aren't much use to us at all.
c. Mechanical - piping, tanks / vessels, HVAC, fixed equipment (as basic as parametric cubes with o/a height, length, width would suffice for the majority of pieces of mechanical kit we work with). The Mech catalogue is vast, relative to our needs. E.g. Most of the time all we need to do is place a basic volume to represent a "Plant Item", rather than say, a "horizontal stacked-plate heat-exchanger".
d. Electrical - virtually all of this.
We are delivering models yes. Most of the content NR have provided has been non-AECOsim (2D cells, level libs, text & dim styles, and seed files). Most of what we've modelled to date has been via the solid modelling tools, rather than via catalogue items.
On a side note, what's the status of Bentley Configuration Explorer with regard to CONNECT? I'm finding it doesn't work with the CONNECT shortcut, and can't track down whether a CONNECT update has been done.
Glad you asked, exactly the same question arose for me as I was looking into this question.
Anyone needing the latest version should ask via a Service Request, we will then be able to send a download link.