Search the Community
Showing results for tags 'tag'.
I got my data tags mostly under control. there are two things I could not find online help with: 1. What exactly is a multiple attachment points, what does it serve and how do you invoke it? 2. Is it possible to harvest twi different types of data, Bayonne line is a #area# and another is #Window#.#ClearArea#. From what I experimented with it all has come from one source, so what I am looking for is a tag that responds to A or B and not A and B.
I came across this problem recently and I think adding these two functions into tags would be the solution. Let me explain : There are numerous times when we as professionals need to provide information on construction documents that reference a specific element inside a unified workspace. I have been trying to unify various different code references to a single type of space object reference system without re-creating the their ID's from scatch all over again. Let, for example, take building code and lighting areas. 1. For building code - in order to analyze any spaces, i have come to the conclusion that a space would be described the envelope the building code dictates. In commercial spaces, this can be resolved by creating a space of all tenancies into the design layer, or into another design layer overlaying the plans. However, this is where the challenge comes in. Let's say you need to calculate the number of fixtures (i.e. takeoffs) by space. Or more importantly, let's say you need to provide a tabulation of the individual spaces for energy code - note by tenancy, but by rooms. What do you do? a. Option 1 - provide a single space for every room. That is the easier solution to showing on a worksheet the number of objects in a room. But, what if you also want to use those spaces to calculate occupancy for every tenant for the building code? You would essentially have to provide a record tenancy for every room that is in said tenancy space. However, for buiding code purposes, you would eliminate the ability to create a unified tag that summarizes the occupancy for the entire tenancy. Instead, you would only be able to do it room by room. Overall tenancy would then have to be on a worksheet level. Unifying and combing different elements like building code, energy code, zoning, and program would be easy on the one hand, on the other, checking the number from a plan examiner standpoint - would be a nightmare - the worksheets would be tremendously long. b. Option 2 - provide an overlay of spaces governing their own functions. If you need to provide an overall area for a space in building code - and given that the space would provide the area, it is easy to calculate the number of people for that tenancy. If you need to show the number of fixtures for each room, another space overlay would be created that can summarize the number of symbols and what symbols are in that particular room. The problem becomes - room id's. Tenancy would have one id. Space by spaces would have another, and there is no way to link them - except for location in space by ID and location in space by Name (as the function used in worksheets). This would ultimately join the complexities of different spaces that need to be shown on various drawings into a single coherent package - because these spaces ultimately overlap each other. Tags - is something that can be shown on drawings automatically, and adding just those two function would prove to be very useful especially when overlaying and unifying many different elements of construction drawings.
I am not sure why there is so little conversation about it. I find it very common to reuse drawings at different scales and lack of control over window & door tag size makes it very difficult. The only solution so far, from what I know, is to adjust text size in advanced settings but that in turn forces the text to be different size in every viewport which in turn when copying notes from viewport to viewport makes the whole exercise quite cumbersome.