Area boundaries are no longer functional

[jamesr]

The area boundary function continually cuts off small areas that we need to include in our area calculations.

Per our vendor:
"In 9.0 room and area boundary detection was switched to more robust algorithm with the goal of no more missed detections of bounded rooms or areas. As side affect code extended use of gap patching to narrow channels which would not fit reasonable human (up to 6-12")."

This destroys our abilty to modify and/or generate BOMA calculations for our clients. Buildings of complex geometry cannot be evaluated correctly for area and we are forced to implement, by policy, sloppy drafting. Ironically, this appears to be a set of programming intended to make up for someones sloppy drafting. Worse is that this was not an issue in 8.1.

This is an issue of such substantial importance to every architect using Revit that waiting for the next release is not acceptable and a patch should be deployed.

[patricks]

I never trust Revit's automatic boundary placement anyway. I always just use the pick tool, uncheck Use Rules and place them according to BOMA standards.

[jond]

The abstract "average human" rule prevents one from being able to do this. Once the lines get close together revit will close/cut off the chain and give you the resulting area that it made - even if you made the lines first.

[David Conant]

The gap closing behavior has been present in Revit for many releases. What has changed is that more elements can bound a room. Prior to r9, columns were not room bounding. Thus, Revit did not see a narrow gap. To restore pre 9 behavior, select the offending columns, and uncheck their Room Bounding property. Revit will ignore them when calculating rooms and areas.

On a side note, I recall from my practice days that BOMA allowed a tolerance of +- 2% in area calculations. The 1sf difference shown in the example would exceed the tolerance only in a room of 50sf or less. Allowing a tolerance recognizes both the difficulty of making truly precise area calcs and variations in construction that can lead to differences between area as drawn and area as built. A .5" error in placing a 24' wall loses 1 sf of floor area. Many things like small bumps, niches, and pilasters were ignored simply because it was far too laborious to measure them. While CAD can deliver what seems to be a higher level of precision, it may be no more accurate in the end.

[jamesr]

So following that line of thinking, we have a highly precise tool that no longer allows architects to have control over accuracy. Let me explain:
BOMA provides 2% leeway from what was drawn versus what is built. This would assume that architects are using a precision tool and using professional judgement to verify the accuracy of their design from which field conditions and revisions inherent to construction produce changes. BOMA recognizes this and provides tolerance to limit liability. Revit 9 area boundaries now takes way the ability to graphically verify the accuracy of the design at its start point thereby removing the starting point of argument in a litigation setting. This is a serious problem in my view that has the ability to cost me substantially more money in the end than having my team deal with the little bumps, niches etc as they do the area calculations. Having been in litigation due a discrepancy between the calculated areas and the built areas, I know that the only leg I have to stand on is an accurate area boundary from the start.

I'll remind everyone that not all area calculation are base upon BOMA. The project I'm currently working on is a developer driven condo where they need every square foot to be counted in order to make the proforma viable. Assuming my area calculations are off by 2%, of which I must assume they are low, I am professionally obligated to tell my client that of the 600,000 sf of sell-able area, they are loosing 12,000 sf due to the program I'm using for design. With a sells price of $650/sf, that equals $7,800,000. Their proforma no longer works and I've lost a project. This is applicable in BOMA calculated buildings as well. This is obviously worst case, but it illustrates the need for a precision tool to work like a precision tool and stop trying to be smarter than the person using it.

We've tried your suggestion in removing the room bounding property, but our clients building area rules are complex enough that we elected to use area boundary lines. When a space is small enough - about 12" or less, such as a column next to curtain wall, the area between the column and the curtain wall is removed from the calculated area. This is area that is sell-able, and as such is very important to our client.

My company does not feel short cutting area calculations is an acceptable practice, and having it forced upon us is both frustrating and disheartening. If we wanted to do area calculations in the manner being suggested, that should be our option. It should not be a decision made for us.

[funkman]

Wow, I don't know if am more astounded by the extent of the area innacuracies and (albeit consequential) litigatation issues or by Autodesk's response (it's close enough).

I would hope that this is rectified by the factory extremely quickly, as James has so eloquently clarified the issue.

[greg.mcdowell]

I think there are a couple issues here... one being on what we should and should not be responsible for and how BIM helps and/or hinders that... the other being what level of accuracy we should be expecting.

As to the first issue... explicity quantifing anything in our profession is potentially problematic as we have very little to no control over the actual field dimensions. Ours specs allow for a certain degree of "fluff" in construction (called tolerance) and I don't think it's appropriate to hold us to something we can't control. What we can be responsible for is "design intent" and that, I think, begins to lead to the second issue...

The level of accuracy we need and/or expect from our software is, to some extent, customizable. We can choose to set the units to greater or lesser degrees of accuracy and this will DRASTICALLY affect the outcome. Even setting it to the greatest possible accuracy there can still be errors (you can move an object in AutoCAD, for example, 1/512" but you can't measure it) though they're small enough to be neglible... but that's the real trick, at what level does the rounding error affect the "design intent"?

You could argue that we need be only as accurate as the accuracy in the building program... and if that's the case is it a problem if the calculated and building areas differ by a couple units?

The BOMA issue of allowing aras to be off by 2% is an extreme. I would guess that the accuracy we're talking about in Revit is much, much smaller (to the point that quantifing it as a percentage would be impractical)... although the larger the area being measured the more potential there is for rounding to make a difference... and in cases like this perhaps simply increasing the accuracy could be enough to bring it back to within acceptable limits.

[greg.mcdowell]

Yeah... I know what you're saying... and we definitely need to be able to have some trust in our software (I mean if a calculator added 2 and 2 and got almost 4 that would NOT be good).

Part of what I'm trying to get a handle on (and where my post was coming from) is how the ability to quantify everything is going to affect Architecture. It's sometimes hard to get across to the interns I've worked with but we are not in the business of producing shop drawings...

According to the AIA contracts we're also not responsible for providing quantities and the like to the contractor... that's their job. And if we start to assume the responsibilities of our contractors then we also start to take on some the liability... I've run into this myself (as has a poster above it sounds like) even before BIM (in actuality we've been using BIM, as a concept at least, in AutoCAD for years... the drawings have information that we're always querying) and I am constantly reminding myself of this fact.

So what do we do about it? We can point to the likes of Frank Gehry all day long and his relationship with fabricators and how they pull shop drawings directly from the computer model. But what we don't know is the sort of contractual relationship he might have with these fabricators. I'd be willing to bet that they've got something written up that would relieve him of at least some of the liability. So maybe part of the answer is for Architects to begin forming relationships with fabricators... that and have a really good lawyer! <grin>

I'm just rambling a bit here... I do agree, as I said before, that we need to be able to rely on our software and if there is a "problem" with how Revit calculates areas we need to let the developers know (though this isn't the correct place for that) so they can isolate and correct the issue.

[iru69]

So following that line of thinking, we have a highly precise tool that no longer allows architects to have control over accuracy.
It seems like the issue kind of leapt off the logic rail from how much tolerance Revit allows for a "gap" when room bounding to Revit not being accurate.

As Patrick pointed out, if every inch counts that much that millions of dollars are at stake, then can't you manually place the boundary lines yourself?

[Wes Macaulay]

I think I'm okay with Revit approximating room areas, but when it comes to area plans, the gap feature has to go... and preferably by the next build!

Imagine a 10" wide area -- say a mechanical shaft. I can't include that in my areas any more!

This situation constitutes itself as an emergency. In Vancouver, buildings are designed to maximize the built area, and how are we supposed to determine what these little areas contribute to the project? Over 60 floors, this could put us over our maximum floor area for the site. David, Lilli, Matt... I hope you can get someone to fix this real soon!

Edit: I have submitted a support request to have this changed. I sent along the file that I have also attached to this message.

[ita]

Well the accuracy of Revit as expressed by the factory is from my experience quite reasonable in the Real Estate world. From past experience, the accuracy of real estate agent's promotional literature and the actual leased areas measured by the surveyor for the Lease Documents can vary to such a % that it would make a building estimator blush.

We do not have to be accurate to the nth degree; buildings areas are not necessarily accurate to 2 decimal places and allow the surveyor confirm that the actual area to BOMA rules in the lease document. I am sure that the small inaccuracies in area will not send the building owner broke - and if does then the building was not going to be financially viable anyway!!

[greg.mcdowell]

that's pretty significan't... I took your file into AutoCAD and the area on the right should be 167sf but it's only showing as 157sf in Revit... not good

[Steve Jager]

If the powers to be in my firm get wind of this they will most likely not use Revit for any area computations and instead rely on a manual effort in plan acad. This just plain sucks!
Furthermore, our Revit detractors will most likely fuel the fire for sticking with acad 2006/07.

After all of my effort to convince my firm to use Revit will probably be wasted. Thanks Autodesk for once again stumbling and crashing again. Who the hell makes these kind of decisions at corporate?

I will now have to spend some quality time away from my family verifying my two school projects and then having to report to my supervisor that there are multiple errors in the numbers we have been reporting to our client and cm. Great news!

[patricks]

If the powers to be in my firm get wind of this they will most likely not use Revit for any area computations and instead rely on a manual effort in plan acad. This just plain sucks!
Furthermore, our Revit detractors will most likely fuel the fire for sticking with acad 2006/07.



this really makes no sense to me. Why would you rely on another program to manually figure area, when you can manually place area boundary lines anywhere you want in Revit?

I guess I'm just not grasping why people seem to be so alarmed that automatic tools don't work. It doesn't surprise me at all that the automatic tools don't always follow the user's wishes. Computers have never been that way since the first punch-card machines. This is why I will often use automatic area lines through the design process to make sure my building area is within budget and to make sure it meets code, local site design requirements, etc, but when it comes time to report the final areas, I will usually just manually place my boundary lines.

It is my opinion that when accuracy is of utmost importance to things that vary so greatly (endless different building designs), you should never rely on the program to place the boundary lines for you. Maybe if the computer was designing the building, but no, the user is designing and drafting the building, so in my opinion the user should be the one placing the area boundary lines according to whatever rules take precedence in the area (BOMA or others).

This is why I don't see this gap issue as that big of a deal. As someone stated, turn off room bounding for columns and move on.

[greg.mcdowell]

check out Wes' file above... he manually drew Area Boundary lines and it still did not calc the area correctly... it's not about whether Revit picks the correct location for the line or not.

my best guess is that this is an unexpected side affect of the new Rooms object... but what do I know <g>

[Wes Macaulay]

Actually, I think this is a case of changed functionality of room and area boundaries. The room boundaries change is great -- kudos to the Factory! -- but the change in Areas is totally unacceptable and needs to be changed ASAP.

[jamesr]

That is the primary issue; you cannot place the boundary lines manually unless the boundary lines maintain a "gap space" of at least 12" or greater. R9 jumps the boundary and deletes any areas that are "not of reasonable size to fit a human being". Imagine that you have an AutoCAD polyline that suddenly moves because of the fact it is too close to another polyline and you do not have the ability to control it. That is what R9 does.

Please understand that the difference here is not in the fabrication of the building, nor is it the provision of building component information to the contractor. This is an issue of providing information to the client, to whom I have a contractual agreement to design a building which meets our mutually agreed upon goals. Our office has a policy of accurate drafting. Walls are 4-7/8", not 5" for example. We expect the software we use to provide sufficient accuracy, i.e. substantially better than construction tolerance, to give us accurate information as we have entered it. There is a huge difference between accuracy and precision. You can have incredibly precise work, but if the base information is erroneous, you don't have accuracy. This is the current dilemma. There are work arounds, but they are just that, work arounds which take time and architectural fee. Fee I would rather spend on providing a quality design.

[jpolding]

Thanks for posting this issue! Is there a setting that we're overlooking, like changing the gap tolerance or precision? I'm looking and can't find anything. If the factory hasn't built this in, please do so or let us know where it can be found.

[iru69]

Yikes! After looking at Wes's file, I get it now. Obviously some of us were under the impression that Revit was simply ignoring small niches when placing boundary lines... but apparently if you manually calculate the area within the visible boundary lines, it does not correlate with what Revit is reporting.

James, it seemed like you were more interested in making an argument for how this problem affects you rather than really describing what the problem actually was which is what led to some confusion. Anyone who looks at Wes's file will get it right away.

[tamas]

I am looking at a fix for this issue with area plans. Give me a few days to report back what I have found.

Thanks for your patience.

Tamas

[wildcat_714]

Anyone who looks at Wes's file will get it right away.
Definitely agree with this. It made it very clear and more than a little depressing.
p-

[Tom Dorner]

This is completely unacceptable and must be addressed ASAP.

We use Revit area plans for lease area calculations and the area Revit calculates is written into the leases of the property management firm we do 90% of our business with. We and our client rely on accurate area calculations. If there are errors on our part (or the software we use is inaccurate) we get charged the area differential. This means that we as architects end up paying for the error over the life of the lease. ($20/SF per year for 5-20 years)

I'm as big of supporter of Revit as anyone, but this is a deal breaker for our use of Revit for area calculations.

As for the statement that BOMA allows for a 2% deviation, it is from the preface of the 1996 version of BOMA. It states that the original area re-measured by a different party is deemed accurate if the difference is less than 2%.

This is not the same as the area can vary by 2% once the area measurement has been deemed accurate. In practical terms, property management firms expect that once the area is calculated for a building that we get each floor to close out by 1RSF per tenant. The 1 RSF they give us is for rounding.

We have many buildings where we end up with little slivers and slices some as narrow as a few inches in tenant suites. After 20 years of remodeling, that is what you have to deal with. For Revit to ignore these areas will end up costing us a fortune, put us out of business and me out of a job.

[BWG]

This is extremely bad news. We have already sent out some projects that could end up costing us if we have any of these conditions, which it looks like we will. I have had this happen once before using another program; hence, switched to revit.

[Wes Macaulay]

I wouldn't worry about it too much, folks -- I'm sure the Factory will fix this soon. I'm glad we've got developers in such close contact to us who can turn that big Adesk ship around on a dime.

[phyllisr]

This thread is getting pretty long as is my post so unless you have nothing better to do, skip it. Unless you are a spreadsheet nerd like me. I am confident Autodesk will find a solution to something this critical. Clearly, the discussion about accuracy pushed a lot of buttons, some related to BOMA and some not. To explain how critical this issue is for those of us deep into BOMA calculations done correctly based on the ANSI/BOMA Z65.1-1996, it is not about the 2% rule or the real estate market or accuracy. For those who migrated to Revit a long time ago, remember the 8 decimal display in AutoCAD means that an AEC object (a wall, for example) with an angle of 0.00000000234 and one that is actually 0 will not behave correctly. We went crazy trying to figure out why.

What matters is not whether my Revit model shows 300,000 SF or 300,006 SF but that I can justify one or the other. Any changes must correctly result in the same total as leases change. It is no different than a paper copy that you measure by hand. You may not be able to measure anything finer than one inch but you can base your measurements on an assumption that remains consistent. If you assume the building is 100' x 100', the SF remains at 10,000 even if the building is actually 100'-1" x 99'-11".

The accuracy problem with the Revit areas and rooms is that changes will not result in a consistent set of assumptions, not that we or the owner care specifically about this inch or that. Attached is a PDF with the tenant and client name removed of a BOMA calculation that I have been maintaining for a client for 18 years beginning with the 1980 standard that we modified to do something similar to what the 1996 standard now does.

I would challenge anyone to maintain a spreadsheet with this level of complexity without mining consistent information from the model. In the best of circumstances, getting column 5 and 20 to equal is a nightmare. This was difficult in AutoCAD V9, easier in ADT, and easier still in Revit. It's not the actual constructed accuracy, it's reliable assumptions and consistency.

We are deploying 9.0 soon and now that we know it's a problem, we will be aware and find a short term work-around until Autodesk fixes this. Perhaps Autodesk could give us a gift at the same time and correct the spelling for the dimension parameter in the ADA parking stall family. ACCESSIBLE instead of ACCESIBLE.

[Wes Macaulay]

I've been thinking more about how Area Plans now need an area object -- you can't just create area boundaries and be done with it: like rooms you have to add the 3D area object first.

This is a pain -- more work for us to add the 3D area object -- but I suppose it's good in that during the prelim phases of a project you can use area plans for space planning and have volumes to hand off to HVAC for calculating heat loading based on the volume of the spaces, etc.

What do you think about this?

Also be sure to vote on the poll with this thread since I have a support request in to change area boundaries so that areas bounded with segments less than 1' long are calculated correctly, and included in Revit's area plan calculations. The Factory needs to see what our needs are.

[phyllisr]

What do you think about this?
As long as you made the suggestion, perhaps an object approach would solve an earlier problem I had with sections and a request for an "area plan" in section view.

http://forums.augi.com/show thread.Phip?t=36557&highlight=Elevation+Area

This is a great idea and I fully support this approach. Even if I do not get my section view solution.

[Chad Smith]

I read this whole thread before looking at Wes' example file, and Damn!! that has to be fixed.
As the designer in the office, all of my drawings are costed off and are to the clients requirements. I'm a little concerned about my projects I've done in 9.0 now.

[MRV]

This could be bad... real bad, depending on the situation.

So if I add a 10" wide wingwall projecting out from a house slab, in theory Revit will report no change in sq.ft. of slab? Somebody better get the factory on this asap!

Michael Vaughn

[tamas]

So if I add a 10" wide wingwall projecting out from a house slab, in theory Revit will report no change in sq.ft. of slab? Somebody better get the factory on this asap!

Michael VaughnMichael,

I think what you describe here can be checked in about 1 minute. Have you tried it?

We have done extensive testing on 9.0 and found these cases occurring rather infrequently.

Tamas

[MRV]

Just checked it again, and it IS reporting incorrect areas. I'm sending the file to support.


Michael

[phyllisr]

Picture is worth a thousand words... Took Wes's original example, added another area, included a color fill and created a quick schedule. Easier to see what happens. Better than reading the whole thread. Note that the ignored area within a boundary does not schedule even though the smaller "totally" unenclosed area does. There is no way to determine what is missing and what is not without "up close and personal" review of every area once a color fill is added.

Please vote on the urgency of this issue.

[iru69]

Also be sure to vote on the poll with this thread since I have a support request in to change area boundaries so that areas bounded with segments less than 1' long are calculated correctly, and included in Revit's area plan calculations. The Factory needs to see what our needs are.
I'm not sure why there's even a poll - this doesn't seem like an issue that's up for debate - it just needs to be fixed as soon as possible.

We have done extensive testing on 9.0 and found these cases occurring rather infrequently.
Not sure what this means... the Factory thinks that because it's infrequent or only occurs in unusual situations, it's not that important?

What if Excel infrequently calculated formulas incorrectly? While I understand that it may take time to resolve the issue, I don't understand how this can be anything less than a top priority. The area within the purple lines should be exact. If Revit is following certain rules to determine the areas to be calculated, then the purple lines shouldn't extend beyond those areas.

Even if this issue doesn't affect most users directly, even if it was always like this and only came to light now, this issue undermines the confidence in everything Revit does report. Maybe Revit infrequently calculates dimensions incorrectly?

I originally felt people were being a bit over-dramatic about this (and now, maybe I am too?), but we went from "I'm looking for a fix for this issue" to "these cases occurring rather infrequently" and I'm trying to figure out what to make of that.

[tonyisenhoff]

I'm not sure why there's even a poll - this doesn't seem like an issue that's up for debate - it just needs to be fixed as soon as possible.

Even if this issue doesn't affect most users directly, even if it was always like this and only came to light now, this issue undermines the confidence in everything Revit does report. Maybe Revit infrequently calculates dimensions incorrectly?

I second this - It needs to be fixed!

[tamas]

Even if this issue doesn't affect most users directly, even if it was always like this and only came to light now, this issue undermines the confidence in everything Revit does report. Maybe Revit infrequently calculates dimensions incorrectly?

I originally felt people were being a bit over-dramatic about this (and now, maybe I am too?), but we went from "I'm looking for a fix for this issue" to "these cases occurring rather infrequently" and I'm trying to figure out what to make of that.Let me try to be clearer. By "cases", I referred to narrow channels formed by area boundary lines and small such lines in tight pointy corners. Judging by our internal testing I concluded that those conditions occur infrequently in real life user examples.
The calculations are deterministic, but they unfortunately ignore those tight spaces as Wes demonstrated.

We appreciate the importance of this issue. For some legal reason (that is little known to me) we are not at liberty to discuss matters that relate to future changes. I think it is better if I restrain from responding to these threads.

Tamas

[iru69]

Let me try to be clearer...
Right... I understood the meaning of the statements independently. What I was trying to figure out is how the second statement (today) related to the first statement from a couple of weeks ago.


We appreciate the importance of this issue. For some legal reason (that is little known to me) we are not at liberty to discuss matters that relate to future changes. I think it is better if I restrain from responding to these threads.
I'm glad to hear the Factory appreciates the importance of this issue. That's what was becoming less clear.

While the decision may not be up to you personally, Autodesk (the Factory) can choose how they want to communicate with their customers any way they want to. If Autodesk decides the AUGI forums doesn't serve their interests as a way to communicate with their customers, that's ultimately Autodesk's loss more than ours.

[brd]

I am a faithful Revit user in a 100% Revit office. Our principles have had the patience of a saint over the last 18 months as the entire staff switches over to this software. Long story short, their patience is growing thin. Lately, I have personally debated the strengths of Revit's Area Plans features with our principles who have sworn the numbers are wrong. So I am quite discouraged to hear that I've been wrong all along because Revit doesn't calculate the area correctly. I'm actually legitimately afraid of what the principle's reactions will be to this news.

I thought I had a good grasp of Revit's computing rules in regards to area plans. Apparently, Revit knows to place to the boundary line on the inside face of glass when a window is greater than 50% of the wall height compared to the face of stud when it is less than 50% of wall height. I deems that extra couple of inches as inhabitable space (even though you can't really stand in a 4" window opening when there is wall on all four sides of it) while it deems anything less than 12" wide as uninhabitable. I can hear my boss' reaction now... don't "computers" have that name because they "compute" instead of think. Without exception, Revit ABSOLUTELY MUST give us the correct numbers. I'm afraid to even check our current drawings for fear of actually getting the answer.

[bowlingbrad]

Since this is a V9 issue it would be nice if people had the ability to just go back to V8.1.

Here's a perfect example of the need for a 'rollback' feature.

I haven't installed 9 yet. I'm glad. I'll just wait for a new build... Sorry to all those who are having issues. I know our ownership would have had a kiniption fit if they knew the area plans were 'calculated' incorrectly.

[DanielleAnderson]

Since this is a V9 issue it would be nice if people had the ability to just go back to V8.1.

Here's a perfect example of the need for a 'rollback' feature.

I haven't installed 9 yet. I'm glad. I'll just wait for a new build... Sorry to all those who are having issues. I know our ownership would have had a kiniption fit if they knew the area plans were 'calculated' incorrectly.

Well said. We haven't rolled out v9 yet in our office and I think I am going to bring this issue to the attention of the decision makers. This could very much have a detrimental affect on successful implementation here (which we are in the process of). It wouldn't go over very well if I had to scratch my head in a demo and say "awe, shucks, it's just the way it is"...

[Wes Macaulay]

Revit's area plans were spot-on in 8.1 -- so need to worry about that. And with 9.0, you can look at your area boundaries and know right away whether Revit is going to calculate the area improperly. Tamas is quite correct in saying that the situation isn't very common -- I don't have a project and don't recall a project where this would be a problem, but I can readily imagine a project where we might need to schedule such tight spaces. So in reality, for most people and most projects, this problem is theoretical. But irusun is correct in saying that this functionality is unacceptable -- just like it would be in Excel.

Does anyone actually have a situation that would be affected by this? Brd, I think you can go thru your drawings and easily identify where you'd have a narrow panhandle or other narrow area affected by this problem.

The Factory has seen that this situation needs immediate resolution, and what Tamas can't say is that it's going to be fixed in a new build or in 9.1 or whatever. But it will be soon.

Do you guys remember when they killed the ability to rotate crop regions? We cried, and they brought them back. (PS: any chance that we can get them so that you don't have to rotate them backwards to get this to work??)

[sbrown]

We have numerous small shafts in our hotel projects that would be completely ignored in 9.0

[cphubb]

We have numerous small shafts in our hotel projects that would be completely ignored in 9.0

We also look closely at shafts in our medical projects. While someone might say whats a little 10" x 3' Shaft (2.5 sf) but add that to the thousands of these in a typical hospital and you can lose lots of area quick. I know from experience that hospitals are as anal about SF totals as developers and landlords. Since we are selling the BIM process as our "Extra" to these hospitals and there are already accuracy trust issues this is really a bad thing. We need to be able to overlap the boundaries for a 0 sf loss between adjacent areas and be able to trust the accuracy implicitly or we will all be in real trouble.

[Wes Macaulay]

My support request came back saying this is going to be fixed in a new build. There was no timeframe for this, but we can rest assured that the issue will be fixed very soon.

So Scott and Chris, you guys would have 10" wide segments that followed around shafts and so on?

[DanielleAnderson]

So Scott and Chris, you guys would have 10" wide segments that followed around shafts and so on?

Yep, me too, I would prefer to make the decision on whether or not to round up or down with these numbers.

[MRV]

Although I keep hearing that this situation is "not common", I'd like to add this:

For our work (in residential), a quick way to do the site plan for permits is to link in the building, and use filled regions and detail lines to draw driveways, sidewalks, roads, etc. For tabulation of areas, really the only tool available for us is the area boundary, there is no "area" command as in Autocad. Sometimes while sketching "living areas" and "garage" boundaries, we must follow a 5 1/2" brick ledge, or 9 1/2" total thickness wall. And this can be impacted by the new interpretation of area boundaries. These are numbers that taxes are derived from, and are used on every project. So YES, we do need accurate numbers, let the rounding be user selectable or whatever, but give us an option to have good numbers.

Michael Vaughn
BWG Architecture

[ita]

In this state of Western Oz, - almost without exception - lease and rental agreements require/have a land surveyor measure and certify the leased area, including common areas and other areas to be shared etc. This survey document is the basis of all rental values and outgoings including rates and taxes, so to have room areas that accurate is not as important here as would seem elsewhere.

The error margin appears to be highly significant (contrary to my earlier thread) and where the area measurments are that critical, Adesk has an obligation to rectify the situation in very in short time. For all that, I still like the Room system family and how it functions.

[sbrown]

Think of back to back wall mounted toilets, they typically need 10" - 12" clear shaft behind them. This currently would not be counted. this is NOT an uncommon problem. In condo unit plans, apartments, hotels, etc all have many small chases, but you don't want to count the area on each floor so you need to be able to count it when you want to and not when you don't.

[neb1998]

Bottom line of this entire post...

W E N E E D A D A M N A R E A T O O L

autodesk, revit team, whoever the f is reading this that can implement this....i will pay 1000 dollars to implement the dumb tool and i bet if we get 1 dollar from every guy on the forumns we will be able to pay you to implement the dumb tool.

I mean i think its easier to create this tool than toast 3 pieces of bread in a 2 slot toaster...but autodesk keeps trying to toast the 3rd piece

[cphubb]

[QUOTE=So Scott and Chris, you guys would have 10" wide segments that followed around shafts and so on?[/QUOTE]


Yes a typical plumbing shaft or Medical gas shaft may be from 6" to 14" deep and 1'-3' wide. Since we count all the net and get it to reconcile with the gross we need to count the 100 or so of these shafts. Not to mention on the management side the shafts need to be numbered so maintenance people can find them. It would appear that a 9"x3' shaft would not even tag.

[cphubb]

Bottom line of this entire post...

W E N E E D A D A M N A R E A T O O L


What would this accomplish to solve this problem? Are are you going to manually check each room shaft opening etc and Manually create a schedule of all those areas? If that is the case go back to Autocad.

BTW if they were to create an area tool it would probable skip the areas less than 12" anyway so until this problem is fixed it is a moot point

[lev.lipkin]

We do plan to fix Area tool issue as soon as possible by allowing channels of width 1" or more, which might result in some 'leaks' of areas if area boundary curves are not trimmed to each other at corners (investigation of such cases causes some delay, but I hope this would get through rather soon).

Also plan to have filled regions report their areas as property has good chances to get into future release.

I hope this would help with issues mentioned in this thread.

[Wes Macaulay]

Also plan to have filled regions report their areas as property has good chances to get into future release.
Hehe -- Joe... are you listening? Can you say limiting distance calculations? They're going to get a whole lot easier soon. There you go, guys -- a "dumb" area tool. Ben, your bet is already toast.

Cheers Lev -- this is all good news

[BillyGrey]

Thanks Lev, Tamas, and all who have contributed to this thread.
Although I did not air my insecurities about this issue, it had/has me a bit worried.

It is refreshing and calming to have the developers popping-in and providing input on such an important problem. Please feel free to do this frequently on more issues.

Thanks again,

Bill

[Gadget Man]

Well the accuracy of Revit as expressed by the factory is from my experience quite reasonable in the Real Estate world...(ITA, I noticed your second post too and I am using the above expression only as an opening... not against you :) )

In all this (brilliant!) discussion I failed to find one basic factor.
In my view, we are mostly using the computers not for the speed of drawing (many draftsman can come up with the basic hand drawn floor plan and elevations quicker than it is to produce them on the computer) but for ability to quickly duplicate/change them and for the accuracy of our drawings! Because many of us take the quantities produced by a computer for real! Is there any more (supposedly) accurate everyday tool available?

After all, as somebody said, the computers should be used to compute! And if their computations are wrong at the very start of the whole process, it will be compounded at all the later stages without doubt!

One would think, that the computers should give us a possibility (with their ZOOM tools and all...) to draw and measure to such a precision and accuracy as we (!!!) think appropriate for the application! So what all this business of "gap patching to narrow channels which would not fit reasonable human" rule has to do with anything? Various quantities produced by a computer are used for numerous purposes and, for sure, are not limited to spaces that would "fit reasonable human"... This shouldn't even be a factor!

In any case, in my opinion it always comes to one thing, as jamesr said: "...that should be our option. It should not be a decision made for us."

[Chad Smith]

Also plan to have filled regions report their areas as property has good chances to get into future release.Are there plans to add an area calcs to the tape measure tool too? I don't care about areas of filled regions, I just want it on the tape measure command.

[Phil Palmer]

We do plan to fix Area tool issue as soon as possible by allowing channels of width 1" or more, which might result in some 'leaks' of areas if area boundary curves are not trimmed to each other at corners (investigation of such cases causes some delay, but I hope this would get through rather soon).

Also plan to have filled regions report their areas as property has good chances to get into future release.

I hope this would help with issues mentioned in this thread.
Filled regions reporting areas is good.

Will it be possible to 'Tag' the reported areas as well, I could see this being a requirement.

[zenomail105021]

For the life of me I just can't comprehend why the people responsible for developing this program are fighting a DUMB AREA TOOL. It is a remarkable knee jerk response. It makes their entire philosophical approach questionable, i.e if they can't get this, what can they get? Unbelievable!

If they can't figure it out at least give us Macro's and we can figure it out (this and other issues). I guess once they tie you to a subscription they just don't care because they don't have to. This subscription thing bothers me because it encourages mediocrity to my way of thinking. Nothing personal, just human nature. And just my opinion.

Bill Maddox

[dpasa]

Are we going to have an update soon? Areas are a powerful feature and I need it every day so please Revit Team hurry up!

[dpasa]

I got an answer regarding the "areas" issue we all deal with. We are going to get a new update very soon that fixes this error. So, check the download page.

[tamas]

I got an answer regarding the "areas" issue we all deal with. We are going to get a new update very soon that fixes this error. So, check the download page.Please read the post (http://forums.augi.com/showthread.php?t=40450) by Steve Stafford about the updated build (20060518_2300) that was just released and addresses this problem.

We have changed the internal tolerance related to area plans to allow narrower channels (at least 2cm wide) and pointy corners with small boundary lines.

Tamas

[BillyGrey]

Kudos to the team Tamas, and thank you.

B

[mmodernc]

I'm still drawing my boundary lines man u allie.
So if I am doing a lot of file linking should i stick to the faster? April Build?
How did it get faster anyway? and how did it get unfaster now. Am I correct in saying that there are three ways of using area tool i.e. rentable area, gross area and manual area i.e. no rules i.e. when you set up a new area scheme not a "rentable" or "gross" and/or you uncheck "use area rules".
The three Fates you have to live with-Clients, Councils and Computers.