Housing Project - workflow and file organization

[app_dp]

Our office is working on a Housing Project with 10 buildings with generally 2 types of buildings (floor plan layouts) - but here comes the catch - each type of building has 2 different GF ground floor plans (different entrance positions) and they also have different numbers of floor plans (4 or 5 above-ground floors) - so in the end we get 10 unique (but very similar) buildings.

How would one organize the modelling/drawing process to avoid unnecessary repetitive work? I was thinking about having a hotlink for "typical floor plan" - but I also have to label each flat with a unique code - so having zones in hotlinked files is a no-go? Should I have multiplicated zones on hidden layers and turn them on and off for each variation of the building?

Continuing - in the execution plan we also need to label construction elements with a unique code, that is composed of the building code - example A1-RC-1F (building A1 - reinforced concrete - 1st floor plan)

Bonus question regarding Zones and Schedules: Is it possible to have a Zone for the whole Apartment (A2-1F-5) and in the same apartment having zones for rooms (Kitchen, toilet, ...) - -and then organizing a schedule where the Rooms are bundled together according to Apartments? Instead of having it organized by Room name (Kitchen, Kitchen, Kitchen....)

Thanks a lot for the help

[Marc H]

Hi app_dp,

If I understand correctly, you are looking to economize design-time in this multi-building project portfolio using modules, but need to customize the identification and aggregate data.  I'll say here my experience with similar projects is limited to 'front-end' (site acquisition through schematics), so others here may have more sage approaches.

With that, yes, templating apartments and/or whole floor hot-link modules can be very effective, especially in this case where you will have very distributed edits when one or both of the two layouts change.  I suggest crafting the modules with the structures' frame and shell in mind, as that may affect how much program you put into each module.  As to zones, they can be included in the module, or they can be in the parent PLN.  I prefer to limit the modules to their physical elements and have the zones reside in the parent (building) PLN.  This provides the ability to add zones external to the modules (for example your first floors) and easily aggregate the data.  It should also address your customized ID numbering where the module is 'empty' of spatial elements. You could of course create a separate group of zones for the two layout modules and paste them in to save time.

As to 'gross' zones (e.g., apartment or floor size vs room), this is a bit more controversial.  If you have overlapping zones, they can produce unintended consequences.  Many avoid this by using zones for one purpose and labeled fills for others.  However, I prefer to use zones for multiple purposes (in line with the needs you express), because I like their categorization feature, stamp options, etc.  For this approach, I place room zones in full volume height (standard) within the rooms.  Then I place 1" high 'gross' zones at -1" below the floor, on their own layer/s.  Their categorization types reside alongside my room zone categorization list.  Physically separating in addition to layering, avoids overlap of the zones, while allowing several modeling, presentation, and documentation advantages and opportunities.  If this approach is of interest, you may want to make a small ConDoc test (i.e., checking the gross zones are indeed staying out of the various auto-features of the room zones. I only did a few simple schematic level tests when implementing this in my projects a few years back).  [One other thought that now occurs to me:  Putting the gross zones in a Design Option - I'm experimenting with 'storing' things in a DO that I do not want conflicting with my main model.  The caveat I am experiencing with introducing DOs into the project, though, is they create a lot more complexity.]

You also mentioned the desire to aggregate the room and apartment information in various schedules.  I achieve this by adding property fields to the various zones as I, alas, cannot use the grossing zone/s to group the room zones for this purpose.  But with added properties, one can aggregate on those as well and leverage the data.  For quality-checking, you can set up a view with the gross zones in background (or in Trace) to be sure the zones are properly assigned.  You may also check the grossing totals against the room zone totals (which should give you the grossing difference if your room zones are net).

Hope this helps.

Note: Always good to have a footer on your post, which can be added in your profile.  Also helpful to attach a screen shot of the issue or the project as it may inform others for response.

[mthd]

Hi there, it would nice if you could specify your version of AC and your computer system. That way others can advise you better on how to use AC efficiently with your 10 buildings housing project. 

All the best.