shorter

ISO19650 requires two fields: Status and Revision, to be added as metadata, along with others. The revision code is composed of three parts: a letter and two sets of numbers, separated by a fullstop. e.g. P01.01 We need to be able to enter a revision code like this AND utilise automatic revisioning via the Title Block Manager. Current behaviour means we have to use either 'letters' or 'numbers' in the revision numbering options to ensure that when we add a revision to multiple sheets VW adds the next revision to all sheets as opposed to the same revision if we set the revision numbering options to manual. We need three fields in the revision data tab: Preliminary or Contractual = P or C (and the means to add our own) Revision Number Sub-Revision Number (with option to ignore this and when ignored incrementally increase the Revision Number only). We also need others fields and have been asking for many years... We need 'Approved' and 'Checked' fields in the Revision Data tab. Note ISO19650 is an international standard, not peculiar to the UK as BS1192 was so some compliance with international standards is becoming expected of all CAD software.

We only tested it once when one bright BIM coordinator said we will all share IFC4 despite no software being fully accredited. The IFC2x3 export was absolutely flawless. The IFC4 looked like a complete mess. It was an exhibition designer's model so not the usual model.

Exactly. Simple use of class attributes. It also depends on where you model, and how you structure your files. Do you have separate wall and foundation or ground beams layers, for example?

@zoomer have you had any success exporting to IFC4? We had big problems on one project so didn’t use it. However I note that autodesk are now shouting about it like they invented it, so it is likely to become de rigeur amongst Revit users soon.

In viewports they are which is why we do not recommend using them and have a system where we do not need to and still produce a workable solution... !!!

Try to work with class atrributes in the organisation palette as your first line of defence. Work as you intend to print. Most BIM models are built with GAs in mind, therefore class in design layer = class in viewport. Keeps it nice an simple. If you need to vary it in the viewport use viewport class overrides as a last resort. We never use VP class overrides unless we absolutely have to. Data Visualisation is tantilising but cannot be automated across many files, whereas class attribute update can be. The problem with VW has always been that there are too many ways to control output (at least 10 ways...?), and DV just adds to the melange, although in a good way.

probably because of their irregular flintyness?

Using Worksheets for compliance checking. If like us you use worksheets to check your Vectorworks Information Model, a really useful feature is to start your search criteria with Visibility = Visible followed by your search criteria, e.g. Type = Symbol This makes your worksheet relate only to the objects visible in the view, rather than the entire model, so if you have the active layer only visible, the worksheet only returns the objects of that visible layer. It is far quicker to respond when you have a large model. However, it would be even better if it related to the view itself so as you zoomed in and out the results related to the objects in the view window.

We work almost exclusively with the page boundary off in a design layer. To avoid error, it would be useful if the settings in the purge command to delete objects outside of the page boundary were greyed out when the page boundary is off.

It's the same issue with showing detail on elevations way in the distance. Totally unnecessary, and arguably confusing and error-inducing for construction drawings but great for 'presentation'. We would issue separate sections. We would not bother with joining viewports. We would simply say 'refer to drawing xyz for continuation'. That said, the number of times I have been asked if it's possible to generate an unfolded elevation...

Export PDF >

Try this...DrawingList.vwx

What is the purpose of this export? Suggest ticking the 'Export Viewports as 2D graphics in Modelspace' if you are trying to faithfully issue the viewports you see on the sheet.

By the way, when creating or selecting multiple DVs, a preview button would be useful, like on viewports.

I can, by selecting all objects that have IFC entity including objects inside symbols and groups, highlight compliant objects, but not the inverse. I need to select all objects that have no ifc entity unless they are inside a symbol that is!

I have set up a quick test file to figure out how to make the splendid data visualisation (DV) work when we have a mixture of 1 ifc entity extrusions, i.e. where a rectangle is simply extruded and an ifc pset has been attached to the extrusion, 2 ifc entity extrusions inside a non-ifc entity symbols, i.e. where the extrusion in 1 is simply made into a symbol. and 3 non-ifc entity extrusions inside ifc entity symbols, where a rectangle is extruded, and made into a symbol and an ifc pset has been attached to the symbol. If I set DV to look for objects with no ifc entity, object 2 and 3 highlight red. This is not what I want because while object 2 has an IFC entity it is inside a non-IFC entity symbol, However, because the object inside the symbol is an ifc entity it will export ok. If I set DV to look for objects that are not symbols and have no ifc entity, object 3 highlights, even though the symbol enclosing the non-ifc entity is an ifc entity. Again, this is not what I want because the symbol is an ifc entity and therefore will export ok. If I look for objects that are not symbols, and put a non IFC object inside the non-ifc symbol, the non ifc object highlights red, which is correct. I just need to set it so that object 3 does not highlight! Annoyingly we cannot manually edit the search criteria of the DV function as we can with worksheet databases. Not sure it would help TBH. Not the sort of thing I should be doing on a Friday evening, I admit.

IIRC the naming standards worksheets only allow a limited number of classes. We use mapping tables and either map the classes via the DWG export settings or using Class and Layer Mapping, although neither are totally foolproof.

Thanks. They are due an update soon.

When you say exported, do you mean as PDF or DWG? What do you need to export them for? Because you have modelled in one layer, as opposed to a layer per floor, you will have to use Horizontal Section Viewports for plans, and similarly, Section Viepworts for Elevations and Sections. However, it depends on whether you want to export to PDF or PDF for use in another software, where you place those viewports.

Such as?

The separator should be '-' to be ISO19650 (UK) compliant.

The batch convert dialog needs an overhaul and behave more like a cloud server interface, allowing you to choose which folders you want to convert and which are to remain as-is. Was reminded of this need after batch converting a load of projects on One Drive where, like Dropbox, etc, you can de-select folders to sync and therefore remove from the batch conversion process, like 'SS' or Superseded folders and existing Archives. For example, my Dropbox folder structure allows me to deselect folders that I do not want to sync.... Thanks

Thanks, @Tom W It's not tied to collaborative projects, just file sizes in general versus RAM. The 'other' software suggests keeping to a model 100Mb in size for every 8Gb of RAM. I am also looking to compare file size with open times because anecdotally, we have examples of files taking hours to open in the 'other' software.

It is quite usual to find file size limits defined in BIM Execution Plans (BEPs). These tend to relate to the native model size, and the federated model. Like the definitions of level of detail (LOD), file size limits are a very sensible constraint, or 'brake', to stop the usual competition (or race to the bottom) to see who can create the largest file. Unfortunately, like LOD, few seem to pay any attention to the limits set. Depending on whose BEP and system requirements you read, the max. file size limits vary from 100Mb to 250Mb for native models, although we received one the other day with a 25Gb limit! These limits are based on the expectation that not everyone has render-quality workstations. So, question is, what do you think is an acceptable file size for Vectorworks, based on 'average' Mac or PC specification? I would be interested to know what size files you tend to generate, and how much RAM you have, plus how long the file takes to open.

Once you have an office standard, then you will discover the true horror of auto-classing... 😉