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 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).
Thomas,
I would concur with Marc's approach. My set-up includes the delivered UK dataset at system level with company and project level datasets above. I have used the catalog item manager(or manual xml editing) to remove all unwanted delivered content from the menus, though it still exists at base level to ensure no tools etc break by accidentally removing default content.
In terms of my company dataset, I have copied the structure and naming of the delivered UK dataset, as duplicate part.catalog names will always be taken from the highest level, ie I can copy company data into project and amend/customise without it affecting either the company standard, or delivered default.
In terms of connect and datasets:
I have configured connect to work with my legacy SS6 datasets, and also have created a new dataset based on the connect delivered Dataset_UK.
I would urge you to dive head first into Connect and the new dataset at the earliest though as it is quite different from the previous UK versions, naming conventions and content is drastically diffident, is based on Uniclass 2015 and as it has been compiled in connect so is better suited than the effort it takes to port an SS6 dataset(I only did this out of neccessity for legacy jobs). If you persist with SS6 now, particularily when you are still quite new to it, you will find it harder to migrate further down the line.
From what I have seen so far, I have not found anything missing in Connect that was present in SS6 other than DEM.
Hi Duncan,
That sounds promising on CONNECT. I've obliterated DEM from the company deployment anyway, so not bothered about that no longer being there. Its good that it sounds like older Datasets can be migrated manually if required, and I also take your point about it being better to go straight to CONNECT & Uniclass 2015.
Can I ask, have you found any route to enable CONNECT projects to be output into a format suitable to feed into v8i at client hand-over? I'm just thinking mostly for if/when Network Rail insist that we provide information to them compatible with their systems.
Not a problem outputting to v8i. Do you mean output in terms of drawing packs or model files. If drawings, then cached dv's from connect work no problem whatsoever in v8i and indeed flattened dgn's are v8 format anyway. If it is more for model files and assuming that network rails standards are set in v8, I would recommend 1 of two options.
1. migrating the v8i dataset and working within that environment in Connect. I have found that I can work seemlessly with both versions without any mishaps. indeed I find some models export to IFC easier in ss6 than they do in connect and vice versa.(and also the odd function that bugs up like flooding floor slabs)
2. would be to backward migrate the Uniclass 2015 dataset to ss6, though this will probably be more work that it is worth.
In short v8i will read any connect files. it is just a question of linking the datagroup catalogues and F+P info so that all displays correctly.
OR just use idgn format. read only but retains all info and readable in both.
HTH
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.