The Civil 3D team is asking for your feedback on this. They appear utterly confused, and are considering categorizing this as a Wish List item now. Their confusion is unacceptable. It is no excuse. Maybe they have had turnover, and forgotten how to use QTO, I'm not sure.
Please the response below, and then my response below that. Please provide your feedback on this through the following link.
Thank you for the response. However, this is an unacceptable proposal.
You mention that this is how the program is designed to work. The design is based on a faulty algorithm of using 2D projected areas to compute quantities. Then we have the second problem that QTO is not using the Subassembly parameters correctly in Pay Item formulas, which you verified yourself.
I have a project critical situation where I need to create Pay Item cost estimates for both the Preliminary and Final design phases of a road widening project. The QTO program does not work, and there is no workaround to produce correct Pay Item lists. I submitted the bid on this project assuming manhours based on the software working correctly. This is why I submitted the QTO support requests classified as “Critical”.
I have paid for this software assuming that it worked correctly.
I totally agree, until the QTO is not using the Subassembly parameters correctly in Pay Item formulas issue can be fixed, we cannot use that feature. We are relegated to using Material Volume tables. I have submitted my comments in the link you provided.
Could I get some additional information on what isn't working properly here. I'm having a difficult time understanding the basis of your approach when using QTO. How exactly are your results "in error". The response notes that you can get accurate quantities by using a different method. If that is so, have you explored this other angle. I agree, Autodesk clearly doesn't work out solutions to broken issues soon enough, nor do enough extensive testing internally before issuing their software. The approach is to allow the user to blow things up, struggle with things, and spend endless time developing workarounds at the expense of your own company / project budget.
I assume this is a Civil 3D 2013 issue? Or is this an across the board issue?
I have read the various posts on the issue and see this is a serious issue with QTO if you are unaware of the issue and bidding on projects with QTO quantities directly. (which is the reason we use the software)
From the programming I have done in the past and in no way being and expert i would of thought it is something that is relatively easy to adjust by the autocesk team.
As an aside I got caught with a overestimate the other day as the standard urban side walk sums the top and bottom link areas of foot paths to give you double the area.
I am comfirming today the double counting of Item Area you have mentioned.
In my demonstration below we are computing square feet of CDOT Pay Item 212-00055 Sod (Buffalograss) between Sta. 20+75 and 21+00.
Image 1 is the Detailed QTO report, which I have attached also as a capture file so you can see it more clearly. Note the Foreslope link code Item Areas and the two identical Centroid Stations listed.
Then notice, the two corresponding Centroid Offsets listed for the indentical areas differ by 0.01.
Image 2 shows the areas outlined in White.
This would result in a blown estimate also for us, with project critical implications. We could lose future work or worse by producing such inaccurate estimates.
I agree with you that this and the other problems creates serious project critical issues.
The QTO issues are:
The record shows QTO has been an issue since 2009. In 2010, the record shows Autodesk Support tested QTO but has since failed to do anything about it.
Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register
Start with some of our most frequented solutions to get help installing your software.