Door Schedule using incorrect Zones

[Wokka]

We have a large development with each room assigned an independant zone name and number. We also have (on another hidden layer) zones showing fire compartments. The schedule is calling up the fire compartment zone in most situations and not the correct real name. Is there a way to sort the schedule to reference only a particular catagorie of zone or some other filter method??

Cheers

[Wokka]

KeesW wrote:
Cadimage's Door and Window Builder schedules allow you to link door numbers to room numbers. Room numbers can be created with the Zone tool. For example, if room number is G23, doors into this room are automatically numbered G23A, G23B, ....etc. Would this solve the problem?

Revisiting this issue....

Kees, Can you give me a quick rundown of how you achieve this numbering system? or point me to info on the cadimage site that shows this. I'm wondering if this may help with issues of door numbers from hotlinked modules (but I doubt it...). Cadimage haven't been getting back to me.
Cheers

** Actually, I think i've got it.... the old <ZONE> in the ID trick.....

[KeesW]

Wokka

Yes, that's how it worked.

Kees

[Anonymous]

Hello,

I have a text object with a moveable hotspot that shows the zone name of the zone that the hotspot is in.

The 'old style' calculations show correct (layer visibility dependent)
zone info for doors. In addition it is possible to have a movable
hotspot in the object to show for example the locking direction and
have that information shown in the lists too.

In this example the 'Sijainti' field shows the rooms between the door is
located and the small arrow (--->) points to the protected one.



Regards, Juha

[Anonymous]

Link wrote:

I've not yet found a way to assign a door (or any object) to a particular zone and it doesn't seem to work by layer visibility or zone category. We have room zones, GFA zones, GBA zones, etc, etc, and have yet to get the correct zones in our door schedule automatically.

AC seems to use the last placed zone, so one workaround is to close the schedule window, cut out all the room zones, past them back in their original positions, then reopen (regenerate) the schedule.

Is this still true? If so that is a big shortcoming.

[Da3dalus]

Karl wrote:
I recall someone posting that there is a relation between the physical zone volume (it is a 3D object with volume, even if you are using it as a 2D stamp for area calcs) and some anchor point of an object. So, if your differing zones - occupying the same space - do not need to be volumetric, but only for the area stamp and scheduling, you could try making them thin and placing them at different z-heights? Or, maybe the zone that you WANT for the doors has to be thick enough to encompass the door base or header or...

I think Karl hit it on the head way back in 2010.

Fast forward to 2017 and ArchiCAD 20, we have a BIG project that uses several layers of Zones to design smoke compartments and other code analysis. Then the Door Schedules started having problems assigning numbers (we use the Automatic Markers). We tried everything else mentioned here, and then I remembered that we had a series of projects in which doors did not pick up Zone numbers because the Zones were set to 1" high (for graphic reasons). Other split-level and mechanical mezzanine projects had similar problems. So we developed a rule of thumb: The Door KNOB must be touching the Zone VOLUME the automatically number.

Therefore, to make the Doors ignore Zones that do not represent Rooms, just make those other Zones shorter than the door knob (1" is great). The only caveat is that you can't use those Zones to calculate volume... unless you do it temporarily, and then flatten them when you're done.

Another Note: We use a separate "Site" story just below my First Floor, at the same level (Height to Next = 0"). In the past, I could do my code analysis Zones on that Story, and the First Floor Doors would safely ignore them. In a recent project in AC20, the doors still got confused! So even separating by story doesn't work.

The Doors are truly 3D entities.