I am using QTO to get the top surface area of a stock subassembly that I have laid out at a 100% grade (1:1 H:V) with a 5 foot offset.
For 100' of Corridor stationing, QTO returns an area of 499.93 sqft, which is appx. equal to the 2D projected area in plan view (5'x100').
The requirement is to return the area using the 3D lengths of the links for quantities. The 3D length of the 1:1 top surface is 7.07'. The surface area quantity for the concrete on this side of the "concrete lined channel" is 7.07'x100' = 707 sqft.
The differences get more dramatic the more vertical the slope is of course. For example, wall face area calculations by using links with a significant vertical displacement (wall height) coupled with a small offset (batter).
Speaking of other approaches, now that there is QTO in Navisworks 2014 has anybody looked at doing either Civil3D areas or volumes in Simulate/Manage?
"One thing I want to be clear about is that the Pay Item / Takeoff system is not intended as a way to calc material volumes. It's really about counting things, getting linear distances and area totals. Not that it wouldn't make sense for material volumes to also come out of the same system"
"... Certainly something to look at for the future."
Dave,
This is an embarassment on your part. You are shockingly misinformed in regard to the software that you manage. I can see now how exactly this QTO issue has gotten nowhere in the last 4 years.
The Civil 3D Help clearly explains over and over how to use Pay Items in Corridors to compute Material volumes using Subassembly parameters. See the images from the Help below. We need this capability.
Your proposed surface and soilds workarounds are unaceeptable. That does not create and support Pay List functionality.
I formally request that you escalate this product defect issue to your superiors immediately.
Hi troma,
Those are great questions. See my responses below:
Yes, a very simple, yet powerful one called the " Pay Item Formula Parameters Dialog Box". I'm using it below here to compute tonnage. It can also read in default subassembly parameters.
No, the slope of the link as an Output Parameter is not available. The Default Slope from the subassembly is available.
You can read in the Default Slope. The "Item Area" parameter seen in the formula example above is the projected surface area to the XY plane. I'm using the Default Lane Slope of -2% below for my concrete paving layer just to demonstrate the slope capability below:
I know what you're thinking. What about multiplying the "Item Area" parameter above by a factor of 1/cos(theta) as a workaround to undo the projection?
Take the concrete lined channel example:
For one side of a hypothetical longitudinally flat channel with constant cross slope you could use the Default Slope of the assembly to compute the surface area (essentially undoing the default projected area calculation). This would handle this scenario with the projection coming solely from the XZ plane, with no YZ plane projection component to worry about.
You have three problems to consider:
1) Your slope angle (theta) from the XZ plane can vary with any vertical (YZ plane) transitioning, only the Default subassembly parameters are available to you, not the Link slope.
2) Rarely is anything flat in the the YZ plane in Civil due to drainage criteria. You have now way of addressing the YZ plane projection component.
3) Only the Default subassembly parameters are available to you. So for example, you would have to use separate Link codes for each side of that concrete channel, and the bottom, just to pick up the individual Default Subassembly slopes.
Summary:
We need Civil 3D development to simply "undo" the 2D projected area calculation in QTO. We need the "Item Area" parameter in QTO to return the surface area.
Dave Simeone, the Civil 3D Product Manager, does not understand that QTO is already designed , sold and marketed to us to return area, volumes and tonnage quantities in Pay Item format.
This is a lack of product understanding, that is totally unacceptable.
I firmly believe now, the software desparately needs someone, perhaps Peter Funk, to lead the effort to quickly correct this glaring product defect and oversight that has been lingering and frustrating End Users for about 4 years now, from my research into the record.
Fred, thanks for explaining that for me. This definitely appears to be false advertising, since the Product Manager says that it can't handle volumes but the promotional material says it does.
Mark Green
Working on Civil 3D in Canada
When you are repairing the product defects in QTO, add Pay Item functionality to the Corridor Shapes in the Code Set Styles just as there is for Points and Links.
I love software that computes incorrectly... what an EPIC FAIL. InRoads probably does it right LOL