Jump to content

shorter

Member
 View Profile  See their activity

  • Posts

    3,099

  • Joined

  • Last visited

 Content Type 

Posts posted by shorter

    Drawing Document Process

    in Architecture

    Posted · Edited by shorter

    On 4/7/2023 at 1:08 PM, Stel19 said:

    Hi Pat, this is purely for my own studies for uni. One of our research questions reads as follows. "Are you aware of the document process status? How many statuses are there for different documents? (Such as drawings\ specs\models\manuals\documents)". The research I have been doing online just seems vague. I mean my basic question in a way is, do you need to follow the ISO 19650 status codes that can be used for any type of document or can you simply use the below? 

    DRAFT

    WORK IN PROGRESS

    INFORMATION

    APPROVAL

    TENDER

    CONSTRUCTION

    RECORD

    COSTING

     

    Thank you for your help! 

     

    Don't confuse 'Status' with 'Issued for'.  Status Code is a uniquely ISO19650 construct that bears no relation to the actual use of the document, i.e. for planning, or for approval.   For example, a drawing could be issued 'For Costing but the Status Code could be 'S2'.  'S2' alone is useless in defining the purpose of issue, so we woud normally back this up with a 'reason for issue' clearly noted on the drawing, if not in the revision/issue record too.

     

    Note: the above is not an 'official' approach but the one that we adopt because of inadequacies in the status code system.  We have a similar issue with revision/issue numbers.  We would use P01, P02, for preliminary issue, and then T01, T02 for Tender Issue, and C01, C02, for construction issue.  Other than P0n, etc, the other two are not catered for under ISO19650.  If you are not careful it is possible to issue the same drawing twice with the same revision/issue number, but with different status codes!

    • Like 2

    Edit viewport in-place

    in Architecture

    Posted

    On 3/17/2023 at 11:08 AM, mahmoudsmonem said:

    Thank you for your reply, I do completely agree, however that's a shared project between different people, and the way it is setup is to have layers for stories/levels rather for each drawing. 

    Not necessarily.

    Stories v. Non-Stories (Residential Design)

    in Architecture

    Posted · Edited by shorter

    All this is showing it that out of the box, software rarely works as we need it and some thought and preparation of content and having a strategy matters more.

     

    Sadly we find this is rarely the case and users end up confused by what 'should work' but doesn't because they have used content out of the box.

     

    In their defence, Vectorworks engineers cannot possibly know what we need.

     

    We have just spent over 300 hours building 500 objects for a client because the out of the box content, along with content from other sources like BIM Object and the NBS BIM Library, does not do what they need, and more importantly is not ISO19650 or COBie compliant.

    Stories v. Non-Stories (Residential Design)

    in Architecture

    Posted

    8 minutes ago, line-weight said:

    Part of my routine is to delete them all, when I am setting up a new file.

     

    Me too.

     

    9 minutes ago, line-weight said:

    What I want there to be is an absolutely clear distinction between:

    - Storeys

    - Storey level types (a level type, for example FFL) that might occur in any storey

    - Storey level type instances (an individual instance of a level type, for example 2nd floor FFL)

     

    Exactly.  There are 'omipotent' levels that are always the same on all repeating floors (Vectorworks, show me a building type where this is routinely NOT the case) and instances, where we need to edit a bespoke level.

    Stories v. Non-Stories (Residential Design)

    in Architecture

    Posted · Edited by shorter

    Further to the storey levels comment...  Just tested in 2023 and one would 'logically' expect any storey level set by 'default storey level' to be editable when changing the 'default storey levels', or is that too obvious?

     

    I have a 10 storey template model.

     

    I have storeys.

     

    I have storey levels set by our default ISO19650 compliant UK Residential project template, which annoyingly we still cannot import from another file... grrrrr

     

    The storeys are for FFL, SSL, etc.

     

    I want to change the SSL level for each floor.

     

    The steps should be...

     

    1 Select all storeys.

    2 Click 'Default Storey Levels'

    3 Edit Default Storey Level, e.g. SSL

    4 VW edits the SSL level in all storeys selected.

    • Like 1

    Stories v. Non-Stories (Residential Design)

    in Architecture

    Posted · Edited by shorter

    We use a mixture depending on the file and the project.

     

    A simple assignment of storey to a layer is good for minute adjustment of levels across the model, without using a plethora of storey levels, i.e. letting the storey define simply the FFL of each floor.

     

    In reality once floor levels are set, they don't vary much and if you are dealing with large scale rwsidential, there are only a few different floor to floors we use whcih are dependant on brick dims.  The ground floor level though often needs adjustment and this of course changes the entire model.  You can avoid this though by going back to the old drawing board approach of modelling at 0m, but issue drawings stating that Ground Floor FFL = 0m = 35m AOD, etc, so if the ground floor FFL changes, the model remains where it is.  You simply adjust the reference elevation and coordinate this with your consultants.

     

    The inability to change all storey levels in all storeys, though, is an absolute pain on larger projects and more time consuming that adjusting layer elevation!

     

    Creating a content library that simply sets walls to anticipate layer elevation and layer wall height is a very quick and reliable solution and avoids the issue @Ryan Russell mentions, I think, where the OOTB walls are looking for specific storey levels, particularly inside components and if they don't exist cause the wall to remain 2D, and this causes much confusion (we have had lots of supprt queries related to this one despite us saying 'don't use the OOTB content!').

    Rogue Record Format

    in Architecture

    Posted

    2 hours ago, Nikolay Zhelyazkov said:

    Maybe you forgot about the Title Block Border Styles or something similar?

     

    Unlikely...!

     

    The only objects left in the source file were symbols.  Of course, it would not be beyond the realms of possibility for the invisible record format to jump on to a symbol, but there were definitely no title block borders in the file, to the extent that once we had copied the data from the file into a fresh file, by referencing and binding, the record format magically disappeared.

     

    2 hours ago, Nikolay Zhelyazkov said:

    Is the TBB record the one that was referenced without you wanting it? If so, could you tell me the steps to reproduce this?

     

    Yes.  I would not be able to replicate it on demand.

×
×
  • Create New...