To use the ilink QTO application used in the previous successful case study requires changing to a hard drive with a x32 OS. For completion in testing, the following list of quantity takeoff tools software are included. Civil projects have earthwork volume, mass concrete, and item counts, making it different than buildings which most quantity takeoff tools are validated. A test procedure is needed specifically for civil quantity takeoff and is as follows.
-
Open the test file in the qto software or open the qto in the test software, whichever the case is
The following objects are detected at the following levels
null <blank>
detected (there but unusable –> does not work)
properties available <list properties> (does not work)
quantity (works)
layer, name, or ontology are available
locations are available
automated, minimal user involvement (works good)
check if detected with layer name and properties
(proposed) check if poly line is detected

The test objects used to evaluate the QTO applications, these objects are point, polyLine, 2D object, mass element, and 3D solid
| Software Developer | version | Mass Element | Polyline | 2D Area | 3D Volume | Corridor | Locations | Date |
| Autodesk Quantity Takeoff | 3.0.243.0 | detected | | | | | No | 4/7/2011 |
| Tocoman iLink 3.0 ACAD 2009 | 1.1.54.0 | 2009 proxy | | | | | Yes | 4/8/2011 |
| Tocoman Express + C3D QTO | 2.0 | | | | | | Yes | 4/14/2011 |
| Agtek Earthwork 4D | 1.04 | explode | | | | | Yes | 4/11/2011 |
| Innovaya | ACAD | | | | | | | check if innovaya has an ACAD 2011 QTO product (possibly have ACAD 2011 takeoff and export) email 4/6/2011 –> yes obtaining updated software license |
| CivilPM | | | | | | | | no response - website domain for sale |
| C3D QTO payitems | 2011 & 2012 | No | Yes | Yes | No | 2D 'link' & 1D 'point' | No - forced | 4/12/2011, 8/5/2011, 11/17/2011 final understanding |
| C3D QTO compute materials | 2012 | No | No | Yes? | No | 3D shape & 2D surface difference | No - forced | 11/17/2011 final understanding |
| C3D QTO composite volumes | 2012 | No | No | No | No | Surface | No - forced | 11/17/2011 final understanding |
| Carlson Takeoff | | | | | | | | experiment timed out, review of Carlson + C3D found today (9/16/2011) |
| Leica Construction Office | | | | | | | | experiment timed out |
| Trimble Paydirt | | | | | | | | experiment timed out |
| inSight | | | | | | | | experiment timed out |
| Bentley InRoads | | | | | | | | experiment timed out |
The MER99 quantities are represented by Autodesk Civil 3D 2011×64 model objects (dwg2007). The quantities are measured using Tocoman ilink Architecture 2009×32; requiring a virtual machine with an x32 OS. The MER99 C3D model is opened in the Architecture 2009 application and the ilink application is started.
A quantity takeoff of the objects in the C3D model by layer name
open C3D dwg file
enter ilink3 in the command line
select the ilink 'object groups' wizard
select the inlik object groups advanced tab
check the following ilink object types for presence
Beam
Block (17 layers)
0 (n=69)
00 (n=1614)
05_existDI (n=11)
06_existDrain (n=21)
07.6_topoFlowlines (n=3)
11_Sheet Format (n=1)
15.5_mainlineWallText (n=3)
20.2_curbs (n=1)
35_drainInlet (n=35)
37.0_text_SWPP (n=181)
37.1_text_SWPP (n=20)
37.2_flow_SWPP (n=3)
41.1_bridgeTopo (n=21)
60.1_wallElev (n=2)
60.2_ (n=18)
60.5_walldots (n=324)
70.0_section0 (n=5)
Block (multi view)
Brace
Column
Curtain wall
Door
Mass element
Opening
Railing
Roof
Roof slab
Slab
Space
Stair
Structural member
wall
Window
XRef
Add an 'object grouping' criteria for layer and select the location box [next]
assign locations as defined in Tocoman 'quantity manager'
[finish]
The ilink dialog box now has a list of the object 'blocks' by layer and the number of blocks in each.
A review of the ilink list of 'blocks'.
only 2D blocks are listed
not all 2D layers are listed
none of the 3D layers are listed
Case study:
| Layer | Type | SolidType | Listed |
| 41.4_bridgePiers | 3D solid | Extrusion | |
| 06_existDrain | | NA | X |
| 0 | NA | NA | X |
| 00 | | NA | X |
| 05_existDI | | NA | X |
| 06_existDrain | | NA | X |
| 07.6_topoFlowlines | | NA | X |
| 11_Sheet Format | | NA | X |
| 15.5_mainlineWallText | | NA | X |
| 20.2_curbs | | NA | X |
| 35_drainInlet | Block reference | NA | X |
| 37.0_text_SWPP | Block reference | NA | X |
| 37.1_text_SWPP | | NA | X |
| 37.2_flow_SWPP | | NA | X |
| 41.1_bridgeTopo | | NA | X |
| 60.1_wallElev | | NA | X |
| 60.2_ | | NA | X |
| 60.5_walldots | | NA | X |
| 70.0_section0 | | NA | X |
All the blocks “seen” by ilink are 'block references'; what is a 'block'.
(1) Learn blocks (Autodesk site)
and how to define blocks in C3D for quantity takeoff.
(2) Review and learn property sets. Notes from email with Tomi September 14, 2008
In 2009 case study with rail alignment structure I added property sets for heavy construction into the model. It contains predefined lists for selecting object's position and orientation, which together define the location. The contents of the lists can be managed using Style Manager.
Select Style Manager from ADT's Format menu
Browse to Multi-Purpose Objects > Classification Definitions in the tree at left
Select the property that you want to modify
Edit the values in Classifications tab at the right
Objects also calculate LCY and BCY values by themselves, so there is no need to use factors in the linking. Calculation utilizes the Soil and State properties. Contents of the lists shouldn't be modified, if you do not make matching modifications into the calculation rules. You can access the rules using Style Manager.
Select Style Manager from ADT's Format menu
Browse to Documentation Objects > Property Set Definitions in the tree at left
Select the property set that you want to modify
Edit the property definitions in Definitions tab at right
Also, I had to change the grading objects from mass element to slabs. Otherwise you couldn't calculate the top area, which seems to be used in the recipes.
Write:
Works:
MSOffice / Bill of Quantities (xls)
No error but does not write
SOffice / Estimate (xls)
Has error:
Description : Could not load file or assembly 'Aspose.Cells, Version=5.0.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56' or one of its dependencies. The system cannot find the file specified.
MSOffice / Estimate (xls/xlsx)
MSOffice / Bill of Quantities (xls/xlsx)
Read:
No error but does not read
MSOffice / Estimate Template (xls)
Error:
Could not load file or assembly 'Aspose.Cells, Version=5.0.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56' or one of its dependencies. The system cannot find the file specified.
MSOffice / Bill of Quantities (xls/xlsx)
MSOffice / Estimate Template (xls/xlsx)
Additonal components option only works for “MSOffice / Estimate Template (xls)”
Only tried bill of Quantities template not Estimate template
lab-based ReTRAC backfill case study with C3D+4D –> ACAD –> ilink –> QM + HCSS –> control+4D –> XML –> Coding succeded with the use of mass elements
TCM tests:
1) 1D block drafted in C3D 2011 x64 and detected in ACAD 2009 x32 w/ TCM ilink MB –> properties limited to EA
2) 3D block drafted in C3D 2011 x64 and detected in ACAD 2009 x32 w/ TCM ilink MB –> properties limited to EA
3) 3D mass element drafted in C3D 2011 x64 and detection attempted in ACAD 2009 x32 w/ TCM ilink MB –> not detected
4) 3D mass element attempted in ACAD 2009 x32 –> dialog box with instructions that this is not allowed due to the presense of objects created in a newer version. implies that the entire model must be constructed in C3D 2009 or modifications must be made in ACAD 2011 implying that ilink ACAD 2011 is necessary; at this point (April 2011) we would move to 2012.
the combination of developers and versions has lead to a dead end and indicates this method is not scalable –> I recomend investigating the use of ifc and open source tools as the core to individually developed applications therefore removing reliance on vendor-developers
Next step:
Wednesday
0) open ACAD 2011, build mass elements and then open in ACAD 2009 to test ilink
1) contact Tomi and wait for further instructions (possible path with devbelopment of civil TCM)
2) contact Agtek, obtain license and install files, test w/ C3D (possible use as on-screen tool with C3D)
3) install autodesk QTO and test (possibly has gretaer then C3D functions and export)
4) check if innovaya has an ACAD 2011 QTO product (possibly have ACAD 2011 takeoff and export)
5) check if sfiron has a takoff tool
Thursday
6) wait for further instructions
Friday
7) use RGW quantities in TCM QM and note the reduced degree of accuracy and missing link in the model-based plan
2D microstation –> 2D ACAD 2011 –> C3D 2011+4D –> 3D ACAD 2009 –> ilink –> QM + HCSS –> Control+4D –> XML+timecard csv –> Coding –> csv outputfile
2D microstation –> 2D ACAD 2011 –> C3D 2011+4D 'RGW bill of material' –> QM + HCSS –> Control+4D –> XML+timecard csv –> Coding –> csv outputfile
no need for VM other than as a backup in case of x32 software, same for 2nd SSD x32 OS
12/06/2011 2) “Tocoman Server Writer” “Writing to Tocoman Server Failed. Can't Create data package” “Object reference not set to an instance of an object.” - solved, <check> create components if missing (locations and calculations still must be entered manually? and default calculation library?)
Per the Autodesk 'blocks' site I 'PURGED' the C3D file of unused blocks and zero length geometry
Abandoned use of iLink with C3D for now
The tests in this section were completed with a test Civil 3D dwg file (not the simple object test file posted above) containing 10 Corridor alignments: 1 mainline highway, 2 ramps, 2 detours, and 5 retaining walls.
Using the MER99 Civil 3D model NorthBound on-ramp R1 fill volume as a test of the composite volumes QTO function; comparison measured volumes:
C3D Composite Volume QTO 27,227 M3
RGW MER99 Estimating QTO 26,258 M3
The difference is 969.03 CY, 4% greater than the RGW total and represents about 55
end-dump loads, assuming 6 trucks and a 2-hour round-trip (one truck arrives every 20-minutes), this volume represents one morning of embankment activity and about $10,000 for the labor, equipment, material, and haul. A fairly fine level of detail well within the typical degree of detail achieved in planning.
The volumes are within 4% and in the judgement of Val - the MER99 project engineer - are close enough. The C3D quantities are broken down into 6 workzones, this differs from the RGW QTO that is given at the alignment location level of detail. The workzone values are (these have no comparison available):
R1>01 5,213.37 CY
R1>02 12,127.54 CY
R1>03 13,778.82 CY
R1>04 4,430.16 CY
R1>05 0.00 CY
R1>06 61.72 CY
There are two surfaces, gradeSlope and embankSlope
grade slope is embankSlope + narrow strip after curb
embankSlope is just the slope
actually need to include dike for complete - it is 8” so there will be some error due to it exclusion throughout
retainingWall
On the MERCED99 project the mainline alignment, a ramp alignment, and a retaining wall alignment converges at the top of the profile - all three have daylight slopes that intersect. Without locations this requires three corridors and a hierarchy of slope layering for the composite volume takeoff.
There is an issue: Some slope surfaces overlap more than one base surface - for example Ramp1 daylight slope overlaps the RW3 daylight, MainLine CL99 daylight, and the base surface. Composite volumes allows selecting only one base surface, therefore the volume cannot be calculated.
The issue becomes more complicated: When the workzone location property is added the three corridors in the affected region become 9 corridors.
Current:
This should resolve some locations by chance since some corridors are now overlapping with one surface - in this case chance did not happen and all the corridor daylights overlap with more than one surface.
One location can be eliminated because the overlap is minimal and one surface is the predominate composite.
Three conditions:
Overlap with two corridors
Overlap with corridor and base surface
Overlap with multiple corridors and base
Solution try:
As a solution the corridors were divided into regions at the boundary between adjacent corridors, for example R1>03 overlaps workzones NB>10 and NB>11 at the midpoint. So corridor R1>03 has two regions split at the NB 10 and 11 boundary.
Why this does not work: The regions do not produce individual surfaces for the composite volume; there are two corridor solids [bodies] produced but these are not available for composite volume - and still some surfaces overlap with the base surface
The MER99 conflicts
R1 daylight overlaps the base surface and RW3 daylight
Regions R1>02A (72+90 - 74+72) overlaps with RW3 daylight, base surface, and R1>02B (74+72 - 76+59) overlaps NB>09 daylight
Regions R1>03 (76+59 - 78+80) R1>03B (78+80 - 80+45) overlap NB>10 & NB>11 respectively
Regions R1>04a overlaps NB>12 and R1>04a overlaps NB>13
Initial Proposed solution and why not used: The regions must be divided into individual corridors to produce a surface; this will not be used because the samplLines for composite volumes have already been produced and changes require a lot of rework - same for payItem QTO that must be given new code set style and associated payItem. Dividing corridors at these boundaries requires subdividing workzones and breaks the regular workzone spacing. This forces resizing all the project workzones and results in double or triple the corridors.
Try: create 5 dummy corridors for the comparison surfaces
split R1>02 into 2 dummies A & B, one with NB>09 and the other the surface
R1>03 dummy with NB>10: 99CL1_R1>03-dummy test_NB.D_light 78+70.74' to 80+45.00' target exisitngSurface
split R1>04 into 2 dummies A & B, one with NB>12 and the other the basesurface
A 80+45.00' to 82+75.00'
B 82+75.00' to 83+94.00'
revised Composite volume QTO with dummy surfaces
R1>02A-dummy to baseSurface
R1>02B-dummy to 99CL1>NB>09_embankSlope
R1>03 to 99Cl1_R1>03-dummy
R1>04A-dummy to 99CL1>NB>12_embankSlope
R1>04B-dummy to baseSurface
[Dissemination] http://forums.autodesk.com/t5/AutoCAD-Civil-3D/Composite-volume-for-multiple-overlapping-surfaces/td-p/3219628
Created a payItem file with a location prefix attached to each payitem - if a payItem is in 6 locations then the payItem file has the same item with 6 prefixes to make 6 individual items. Then created a corridor for each location, using the same prefix. This approach works, is slow, and has many repetitive steps.
Attempt to introduce location attribute with parcel function; this forum discussion is on locations in C3D
Research: Mastering AutoCAD C3D 2010 Wedding and McEachron Chapter 6: Don't Fence Me In: Parcels; suggest the use of parcels as a location breakdown tool
Create 'Site' for each project MER99 site and locations CL991, R1, and R2
Move Alignments created with single site to respective sites
MER99:
CL990: 99CL1OG
CL991: CL991, RW1, RW3, RW5, D1, d2
R1: R1, RW4
R2: R2, RW2
Test1: Create Parcels for R1 and name with location ontology
A contributor to the autodesk C3D help forum suggested using the composite bounded volume function as a location-based QTO tool. This suggestion would result in volumes by location but does not address shape volume and 2D items. Since these items require the subdivision of the 3D model, then the volumes are already defined by what would have been the bounded volumes. A quick test showed that the current bounded volumes approach is iterative - meaning it is slow, tedious, and error prone.
2011-10-29 Autodesk released this solution as a download http://docs.autodesk.com/CIV3D/2012/ENU/animations/volumes_dashboard.html
C3D QTO Notes: The information is conveyed through the visual object display; if I want to know if a pay item has anything attached you must select that pay item then select the function to highlight attached objects then visually 'look' if anything is not attached - for lack of a better term, this sucks. The corridor QTO function with assigned C3D 'payItems' does not have locations.
The Civil 3D 2010+ integrated quantity takeoff tool can recognize
1D point or count
polyline (closed) - Yes
polyline (open) - Yes
3D polyline (closed)
solid - No
-
ACAD Block
3D block reference - No
C3D object - Yes
-
This calibration compares several quantity takeoff reports to find the behavior when
cross section depth are varied,
payItem is assigned to differing codes,
compare quantity for similar items (such as pave, to base, to grade, to scarify), and
observe the internal behavior for how Civil 3D QTO handles the volume unit of measure.
Testbed 3D model
The C3D corridor model is built in inch model space unit
A payItem file csv built with code of account prefixed with location codes (increases from 120 payItems, 270 activities and 320 budget items, to 2,500 codes) with SF and CY unit of measures for area and volume.
Pay items are assigned to corridor 'codes' 'link' for area and 'point' for length
A new code set style is defined for each location, therefore a workaround to the missing C3D location property
During setup the style, label style, render material, and material area fill style are tested for behavior(these are for 2D plansheets), see C3D Surface Setting section in experiment protocal
A detailed quantity takeoff report is then generated, saved as a Detailed (
XML).xsl file then imported to excel for analysis
-
strikethrough is used to indicate that further testing nullified or better explained this intermediate test conclusion
A comparison of 99CL1>03>M grade (SF, and scarify (SF); scarify and subgrade have the same qto (area) 4,456.2SF;
Properties area 8,912SF
Properties area 8,912SF
Inquiry area 8,915SF
Area (22'-3.6” * 399'-9”) = 8,914SF
[conclusion] 2x 4,456.2 SF = 8,912.4SF; therefore the quantity takeoff reports by left/right subassembly for median
As cross section depth was varied from 8” to 2' no change in volume was observed; the base has a quantity of several CY although the depth is 0 and never has been anything other than 0 or another assembly.
Test 1: change assembly pave2 depth to 2' - no change in quantity - conclude that Pave and Pave1 are the same
Test 2: change assembly pave1 depth to 2' - no change in quantity - conclude ???
Test 3: keep assembly pave1 depth at 2' and relink - no change in quantity or number of entries for takeoff
The payItem was assigned to differing links no change was observed; Test for pave to pave1
99CL1>03>M assign payitem to Pave1
99CL1>06>M assign payitem to Pave
result: both have quantity in QTO report
Test: 99CL1>06>M assign payitem to Pave1 - still has quantity in QTO report - conclude that pave and pave1 are the same; the subassembly has pave1, pave2, and for shoulder a pave3 level but no 'pave'
[Observed]: each new report contains previous (deleted) payitem link and new link, that is, n+1 links (I read a blog post several weeks ago that warns of this); see further testing in section Multiple Quantities Test and PayItems Remain on Report Will investigate and test in following section dedicated to sticking quantities in the report.
A comparison of 99CL1>03>M pave (CY), base (CY), 1) knockdown and pave have same qto (volume) 13.75* (assigned CY)
The 99CL1>03>M workzone knockdown and pave volume 13.75 CY (per subassembly half) is incorrect given that the length is 399'-9.2699” with a cross-section of 11.15' for an area of 4,456.2SF and consistent depth .951'; the product converted to CY is 156.96CY.
First, the possible internal variables are defined, 1) C3D may convert between unit of measure for model space unit and 2) payItem unit (this warning was found through review of AutoCAD forum postings, exact post is not recorded)
Second, a permutation table of the possible combinations these conversions can be applied to the three inputs of depth, area, and the product of depth and area.
Then, a table with the depth, area, and product modified by the possible internal conversions. These are:
Depth divided by 12 to change from assumed inch to feet
Area of corridor divided by 144 to change from assumed inch to feet
Product of area and depth divided by 27 to change from cubic feet to cubic yard.
[Preliminary Solution] The closest match found to the quantity report volume 13.75CY is 13.75CY (actually 13.753704CY but the QTO rounds to two decimal places so nothing can be derived from the subsequent digits that differ - the QTO may have the same value and rounded). Initially, the value found was 13.08 and raised the question, why is there a .67CY difference; .00135CY per SY or 5% difference; indicating there is something more to the embedded C3D function. To back into 13.75:
-
The modified depth input (now 1'), which has a displayed feet unit of measure, is then divided by 12; indicating this field is assumed in inch unit of measure.
The input corridor area 4,456.2 SF is not modified from SF
The product of the depth and area is then divided by 27 to convert to CY
| Permutation | Factor | Depth | UoM | Factor | Area | UoM | Factor | Modifier | Volume | UoM |
| 1:1:1:1 | 1 | .951 | LF | 1 | 4456.2 | SF | 1 | 1 | 4,237.85 | CF |
| 12:1:1:1 | 1/12 | .951 | LF | 1 | 4456.2 | SF | 1 | 1 | 353.15 | |
| 1:144:1:1 | 1 | .951 | LF | 1/144 | 4456.2 | SF | 1 | 1 | 29.43 | |
| 1:1:27:1 | 1 | .951 | LF | 1 | 4456.2 | SF | 1/27 | 1 | 156.96 | CY |
| 1:144:27:1 | 1/12 | .951 | LF | 1/144 | 4456.2 | SF | 1/27 | 1 | 1.09 | |
| 12:1:27:1 | 1/12 | .951 | LF | 1 | 4456.2 | SF | 1/27 | 1 | 13.08 | |
| 12:144:1:1 | 1/12 | .951 | LF | 1/144 | 4456.2 | SF | 1 | 1 | 2.45 | |
| 12:144:27:1 | 1/12 | .951 | LF | 1/144 | 4456.2 | SF | 1/27 | 1 | 0.09 | |
| 12:1:27:11.415 | 1/12 | .951 | LF | 1 | 4456.2 | SF | 1/27 | 1/11.415 | 13.75 | CY |
A new corridor model was constructed wspecifically for testing, the subassembly.MedianFlushWithBarrier is 100' long, 20' wide, and is in feet model space unit and decimal unit of measure.
Baseline test: The subassembly Pave1 depth is 1' and Pave2 depth is 2' - the code set style Pave is linked to a payItem 111.111.111 Pave1 and Pave1 is linked to payItem 222.222.222 Pave2.
The reported QTO for 111.111.111 Pave 1 is the correct 1,000 CF and 222.222.222 Pave2 is the correct 2,000CF but reported as two items in the report.
Observed from results that in feet msu the depth may be divided by 12 but results in a correct final value, indicating that internally inch is used for some or all calculations. In inch msu the division by 12 to change to inch is redundant and results in an error.
Like in inch mus, in feet msu the surface area is not changed from SF or is correctly handles internally,
The CF unit of measure correctly removed the 1/27 multiplier found with the CY unit of measure and used either a 1/1 multiplier or some other multiplier that resulted in the correct value.
Appears that the subassembly Pave1 depth = code set style link Pave
Test1: vary the depth: The Pave1 depth is .9' and Pave2 depth is 1.9'. The results are the same, the sourceCode uses the int string type and only nominal numbers are used.
Test2: add surface to the corridor and assign materials, change to isometric view and observe the corridor model an hide various parts. The subassembly.MedianFlushWithBarrier has the following layers from top to bottom:
Pave: pave area (top surface)
Pave1: pave volume (attribute:Pave1 depth)
Pave2: pave volume (attribute:Pave2 depth)
Base: base volume (attribute:Base depth)
Subbase: grade volume (attribute:Subbase depth)
Datum: subgrade area (bottom surface)
The volumes are from surface up to next surface.
Test3: vary the depth and payItem: Pave1=Pave1 depth is 2' payItem Pave1; Pave2=Pave2 depth is 3' payItem Pave2, Pave=Pave no depth available payItem TestPave1
payItem Pave1 = 4 x 1000 CF = 4,000 CF
payItem Pave2 = 4 x 1000 CF = 4,000 CF
payItem TestPave1 = 2 x 1,000 CF = 2,000 CF (error, should be SF, redo and retest)
retest (change UoM to SF) TestPave = no result on QTO report only Pave1 and Pave2
Test4: vary depth and payItem: Pave1=Pave1 depth is 5' payItem Pave1 CF; Pave2=Pave2 depth is 3' payItem Pave2 CF; Pave=Pave no depth available payItem TestPave1 SF; Barrier=Barrier(point) payItem Barrier LF; Barrier=Barrier(link) payItem Barrier Test LF; Pave1=Pave1 (point) depth is 5' payItem Pave1test CF; Pave2=Pave2 (point) depth is 3' payItem Pave2test CF; rebuild corridor, regen model, save
payItem Pave1 = 4 x 1000 CF = 4,000 CF
payItem Pave2 = 4 x 1000 CF = 4,000 CF
everything else is missing they were on a different report, was viewing volume report and these are on linear report, the reports are:
Test5: create new code set style, assign same payItems as above, and remove payitems from previous code set style, change corridor width from 20' to 10'; summary report gives total rather than Lt and Rt subassembly
payItem Pave = 1000 SF [correct] [solved]
payItem Pave1 = 5,000 CF [actual is 100 LF]
payItem TestPave1 = 200 CF [actual is 100 LF]
payItem Pave2 = 3,000 CF [actual is 100 LF]
payItem TestPave2 = 200 CF [actual is 100 LF]
payItem testBarrier = 383.34 LF [actual is 100 LF]
payItem Barrier = 800 LF [actual is 100 LF, there are 8 points so 8 x 100 = 800] [Solved]
Test6: Vary the Pave1 depth; Summary (
HTML).xsl report
Test7: delete assembly and create new assembly
Intuition: the multiple quantities are a combination of A) Lt and Rt subassemblyies and B) the corridor length divided by the frequency interval (100' /25 ' = 4); further testing does not support this.
Observed: the code style set associated with a subassembly is defined independent of the corridor code set style; unknown effect on QTO report
Deleted old code set style by finding referencing items and then replacing with current code set style - two items remain on the QTO payItem report
Closed C3D and restarted, items still remain
Shutdown machine and retsart
Testn: [proposed] test pave1 point and barrier link to understand values found in test5
[Conclusion] the C3D QTO function rounds the corridor layer depth to a Nominal number and divides the depth by 12.
-
Test in inch msu with new 100' corridor model and 20' wide LaneSuperelevationAOR subassembly. The PayItem file is the same with payItem 111.111.111 Pave1 and payItem 222.222.222 Pave2.
Test parameter is Pave depth * 100' * 20' = CF; A new C3D dwg file was created:
test_QTO_20110612.dwg
AECDWGSETUP inch, engineering
-UNITS command, options 3, 2, 1, 0, 0, N
| Test | Depth | Correct | Units | Expected | Actual | Explained |
| Base | .01' | 20 | CF | NA | 166.67 | =MAX(1,ROUND(x,1))/12 |
| Try 1 | .02' | 40 | CF | MAX(1,ROUND(.02,1))/12 = 167 | 166.67 | inconclusive, could be unpurged value |
| Try 2 | .05' | 100 | CF | MAX(1,ROUND(.05,1))/12 = 167 | 166.67 | |
| Try 3 | .09' | 180 | CF | MAX(1,ROUND(.09,1))/12 = 167 | 166.67 | inconclusive, could be unpurged value |
| Try 4 | 1.20' | 2400 | CF | MAX(1,ROUND(1.2,1))/12 = 200 | 166.67 | appears an unpurged value from Try 2 |
create new code set style and purge per “PayItems Remain on Report: Try5” - [observation] also changed payItems codes without success
| Test | Depth | Correct | Units | Expected | Actual | Explained |
| Try 5 | 1.20' | 2400 | CF | MAX(1,ROUND(1.2,1))/12 = 200 | 166.67 | =Min(MAX(1,ROUND(x,1))/12,1) |
| Try 6 | 2.40' | 4800 | CF | MAX(1,ROUND(1.2,1))/12 = 400 | 166.67 | [0>(Int x)>1]/12; expected whole numbers from 0 to 1 |
Find boundary in >1 to slightly over 1 domain [0>(Int x)>1]/12 - [observation] if payitem file is changed then any items assigned to a codeSetstyle link will remain and cannot be removed since it will not appear on the link's edit payItem dialog box list
| Test | Depth | Correct | Units | Expected | Actual | Explained |
| Try 7 | .50' | 1000 | CF | MIN(MAX(1,ROUND(x,1))/12,1) = 166.67 | 166.67 | |
| Try 8 | .90' | 1800 | CF | MIN(MAX(1,ROUND(x,1))/12,1) = 166.67 | 166.67 | |
Purge payItem file - create new corridor dwg file and new payItem file
test_QTO_20110612_B.dwg
AECDWGSETUP inch, engineering
-UNITS command, options 3, 2, 1, 0, 0, N
QTO summary report has 288,000
| Test | Depth | Correct | Units | Expected | Actual | Explained |
| Try 9 | .95' | 1900 | CF | MIN(MAX(1,ROUND(x,1))/12,1) = 166.67 | 288,000 | L*12 x W*12 * Round(D, 0) |
| Try10 | 1.05' | 2100 | CF | MIN(MAX(1,ROUND(x,1))/12,1) = 166.67 | 288,000 | L*12 x W*12 * Round(D, 0) |
Recheck AECDWGSETUP and check that QTO report is still in inch - then -UNITS and enter for every option without changing anything.
| Test | Depth | Correct | Units | Expected | Actual | Explained |
| Try11 | .95' | 1900 | CF | L*12 x W*12 * min[1,Round(D, 0)] = 288,000 | 166.67 | AECDWGSETUP=inch but if -UNITS=inch then [(L*12) * (W*12) * Round(D, 0)]/12 |
| Try12 | 1.05' | 2100 | CF | L*12 x W*12 * min[1,Round(D, 0)] = 288,000 | 166.67 | |
[conclusion] I think the issue with QTO in inch model space is now clear:
Default L * W * min[1,Round(D, 0)]
If the AECDWGSETUP is set to inch msu and engineering then the QTO report is in inch: L*12 * W*12 * min[1,Round(D, 0)]
If the -UNITS command is then called and no changes are made, just press enter. Then the QTO report is in feet and incorrectly divides roadway depth by 12: L*12/12 * W*12/12 * min[1,Round(D, 0)]/12
Intuitively -Units must be an ACAD command and AECDWGSETUP is a C3D command; I think they are not talking to each other completely and assume opposing base conditions
The roadway sections are assumed never greater than 1' but since the value is stored as an integer memory reference - appearing to assume the depth will be specified in inches - the depth cannot be a fractional value, therefore the depth cannot be more than or less than 1' with the exception of 0'.
It took all afternoon to finally find this through trial and error since the testing must be made with new corridor modals since once a takeoff is made sometimes the values are not purged and cannot be trusted - see next section about payItems that remain on the report
test_QTO_20110612_C.dwg
AECDWGSETUP msu=feet, decimal
-UNITS 2, 4, 1, 0, 0, N,
| Test | Depth | Correct | Units | Expected | Actual | Explained |
| Try13a | 1.05' | 2100 | CF | L * W * min[1,Round(D, 0)] = 2000 | 2000 | |
| Try13b | .95' | 1900 | CF | L * W * min[1,Round(D, 0)] = 2000 | 2000 | |
| Try13c | 2.05' | 4100 | CF | L * W * min[1,Round(D, 0)] = 2000 | 2000 | |
| Try13d | 1.95' | 3900 | CF | L * W * min[1,Round(D, 0)] = 2000 | 2000 | |
| Try13e | .20' | 400 | CF | L * W * min[1,Round(D, 0)] = 2000 | 2000 | min[1,Round(D, 0)]:if Round(D, 0)=0then1 |
| Try13f | .50' | 1000 | CF | L * W * min[1,Round(D, 0)] = 2000 | 2000 | |
create new C3D corridor file to verify repeated results, [observation] with no selection in the model space the properties panel has a general, 3D visualization, plot style, view, and misc sections. In misc the annotation scale controls the on-screen text size, scaling the profile view text.
test_QTO_20110612_D.dwg
AECDWGSETUP inch, engineering
-UNITS command, options 3, 4, 1, 0, 0, N
Try14: AECDWGSETUP=inch msu : -UNITS=
| Test | Depth | Correct | Units | Expected | Actual | Explained |
| Try14a | .05' | 100 | CF | L * W * min[1,Round(D, 0)]:if Round(D, 0)=0then1 = 2000 | 288,000 | inch |
| Try14b | .25' | 500 | CF | L * W * min[1,Round(D, 0)]:if Round(D, 0)=0then1 = 2000 | 288,000 | inch |
Drawing settings/ambient settings/dimension/unit change inch to foot - still has 288,000
[conclusion] The observed behavior in the tests is either inconsistent or there is another variable not well understood. I tried to change all the variables to replicate the change from QTO report from feet to inch and back but cannot. It is an interesting behavior but irrelevant for purposes here, what is clear is that the depth of the roadway never changes from 1', therefore making the volume capability of QTO report unusable (only pave tested, assuming that base and subbase are similar). The roadway sections are assumed by the C3D designers never greater than 1' but since the value is stored as an integer memory reference - appearing to assume the depth will be specified in inches - the depth cannot be a fractional value, therefore the depth cannot be more than or less than 1' with the exception of 0'.
Disseminated: http://forums.autodesk.com/t5/AutoCAD-Civil-3D/2012-subassembly-code-name-inconsistency-or-code-set-style-edits/m-p/3122084/highlight/false#M157801
test files and excel tables with results and test equations
[SOLVED] the payitem file has ”, CF” the 20110912-copy payItem file has ”,CF” without a leading space; removing the space changed the unit of measure to the correct cubic feet; the space prevented recognition of the units and defaulted to cubic inch. The rounding issue remains in msu feet and inch.
Disseminated: http://forums.autodesk.com/t5/AutoCAD-Civil-3D/QTO-payItem-bug/td-p/3156334
The 99CL1>04>M Barrier point payItem QTO report returns 4 identical quantities of 580.036LF, only one is correct; all barrier locations have four quantities
As a test with a new payItem file
CL1>M>05 area is 3,187SF - QTO report is 3,184 SF; nearly exact
CL1>M>06 area is 6,154SF - QTO report is 6,180SF; nearly exact
For location 99CL1>05>M (there are numerous items with this issue) there are three pairs (previously discovered pair is for Lt and Rt) of values for subgrade: 14.96, 464.68, and 1112.58SF; the last matches scarify roadway 1112.58SF
[SOLVED] Each quantity is the linear length of a point on the subassembly; barrier has four points so there are four quantities of identical value. For subassemblies likley to have a linear measurement as QTO there should be a dedicated point for takeoffLength.
try1: delete the 'code set style' and add new - the payItems remain
try2: change 'code set style' to basic for M> 07, 08, 09 - the pave, grade, subgrade, and scarify links were removed, but the point code for barrier and a manually assigned install KRail payitem remain [workaround]
try3: open new payItem file, with all new payItem codes - this cleared the entire list [workaround]
Barrier (point code) does not show on the quantity report with the new payItem file (possible that previous quantities were left from when barrier was given a payItem with the link code)
A retest with a new corridor file containing a 100' test corridor tried the following:
Baseline: assign payItem to corridor code set style link pave1 and pave2 to payItem pave1 and pave2
Try1: change the payItem codes to payItems pave1test and pave2test then run QTO report; new items show on report baseline items are removed
Try2: delete all the links in the code set style, the corridor properties code tab still displays the corridor assembly links, when a QTO report is run, return correctly that no payItems are assigned
Try3: add new code set style, add pave1 and pave2 link payitems, and barrier point payitems, then run QTO report; no barrier length and now there are new values for the pave1 and pave2
Try4: change to new2 code set style and add pave1test, pave2test payitem links and barriertest payitem point, also added surfaces to corridor, then ran QTO report; now there is a combination of pave and pavetest payitems with a range of values.
[solved] Try5: check if the remaining payItems reported are still associated on the old code set style
The subassembly has payItems assigned on two code set styles
removed the payItems from code set style not used
ran QTO report, old items are now gone
Disseminated
If item is assigned to a primitive and then this is copied the assignment is copied too - have to remove assigned pay item from copy
If the payItem file is associated with the file, then items are assigned, and then it is noticed an error, then these errors are corrected in the payItem file: 1) does the payItem file needs reassociation, 2) won't this erase all previous associations?
While revising the QTO for Retaining Wall 4 workzone 2 I read the quantity into Tocoman Quantity Manager without converting form english to metric. But, I noticed that I'd defined a metric unit of measure - m2 rather than sy or sf. And, realized that I never tested if C3D converts an english model space unit to metric if a metric unit is designated in the payItem file.
Test: setup payItem file with item for slope_link for m2, sy, and sf - then assign to the corridor code for:
Try1 slope_link on RW4>02
813.53m2 –> 8,756.77sf or 813.53sy - this is exactly 2x the correct value
486.48sy
4378.36sf –> 486.48sy OK or 406.76m2
Try2: the previous test for RW4>02 is difficult to hand calc for verification due to the uneven surface, so we will try C1>M>06 a flat rectangular surface
Try3A: RW4>2 wall
Try3B: RW4>2 slopeLink - repeat try1
Civil 3D will convert the modelspace units to the payItem unit.
-
The next question is, how long have I been reading files with mismatched units and how much rework will this require. I will review the read files and do spot checks.
Literature:
Adding entries requires opening notepad or excel for edits. If the edits expand the pay item list, the items will show correctly in the pay item vista - if they are removed, who knows. If you use a category file and your edits expand the pay item list or add new categories, you will need to edit the categorization file. The pay items in a category are hard-coded in the category file.
AutoCAD Civil 3D and Pay Items, November 4, 2010 Phillip Zimmerman
-
Errors:
During mapping the following issues were found with payItem file
+add CL1>M>04-25-012.5.1.0 install Krail;
+add CL1>M>03-25-012.5.1.0 install Krail;
+add CL1>M>15-25-012.5.1.0 install Krail
+add 025-012.5.1.2 SB>04 shift KRail
+add 025-012.5.1.2 SB>15 shift KRail
+add 025-012.5.1.3 R1>01,04 remove Krail
+add 025-012.5.1.3 R2>10 remove Krail
+add CL1>NB> 05 through 14 025-012.5.1.2 shfitKrail
+add CL1>NB> 04 through 15 025-012.5.1.3 remove krail
+add CL1>SB> 04 through 14 025-012.5.1.3 remove krail
+add site 025-012.5.1.3 remove krail
+add site 027-080.4.0.0_fenceTypeCL
+add CL1>SB> 01,03,05, -037-060.2.0.0 demo downdrain
+rename Site»-043-019.6.0.0 construct ditch to 019.7.0.0 and change unit of measure to LF
+add CL1>NB>02 to 10 028-083.2.0.0 demoMBGR
+add CL1>SB>02,03,05 028-083.2.0.0
+add CL1>M>10,11,12 038-083.2.0.0
+change site»-043-019.0.6.4 place chokers to R2>10> and ask Carl where else the chokers are
remove CL1>M>04-074-051.9.5.0 Blockout 2
+change CL1>*>*-073-051.5.0.0 to SF
+change CL1>*>*-074-051.4.3.0 to CY
+add 087-060.3.0.0_drain_10-RCP750mm R1>02
+add 088-060.3.0.0_drain_10-RCP600mm R1>02, 03
+change cl1>NB>14-87-060.3.0.0 drains 8 install to cl1>M>14-87-060.3.0.0 and cl1>SB>14-87-060.3.0.0
+change CL1>SB>10-087-60.3.0.0 6A & 6B Install RCP450mm to CL1>SB>10-088-060.3.0.0 RCP600mm
+add cl1>NB>12-088-060.3.0.0 drain7 install RCP600mm
remove cl1>SB>12-088-060.3.0.0 7A & 7B
+add CL1>RW2>02>092-060.3.3.0 drain5 CSP600
+add CL1>RW2>08>092-060.3.3.0 drain7 CSP600
+rename cl1>sb>12, 11-102-073.9.2.0 place cobblestone concrete to NB; maybe change 11 to R2>03
+change CL1>NB>10-119-083.1.0.0 to M
+change cl1>SB>12-119-083.1.0.0 to m
+add cl1>M>11-119-083.1.0.0
+add R2>EPS>06, 05-122-083.5.0.0 Form/Place 732A
+add R1>EPS>01, 05, 06-122-083.5.0.0
+change RDWY>05, 06-122-083.5.0.0
+add CL1>NB>05-122-083.5.0.0
Test:
Test1: update payItem file with edits
Test2: Compute quantities - overview
QTO_test1_Detailed Linear (csv)_20111021.csv
csv-summary: compiles individual selected object for a payItem into a sum
xml-detailed: lists each object selected for a payItem as a separate quantity
[CONCLUSION] summary report will be used, detailed breakdown is not necessary
Test3: Compute summary - report review
volumes are not reported for 3D solid - yup, already discovered this months ago and forgot [WORKAROUND] convert to mass objects and takeoff one at a time from properties
CL1>M>03-076-051.7.5.2 approach slab
CL1>M>ABT1-073-051.4.0.0 abutment footing
CL1>M>ABT1-074-051.4.9.0 abutment backwall
CL1>M>BENT2-073-051.4.0.5 bent footing
CL1>M>BENT2-074-051.4.3.0 bent
looks like wrong quantity
CL1>NB>15-043-019.1.5.6 CL1.NB.-SUBGRADE.ROADWAY 142,091,871.8 SF
checked Imperial - Lanes.atc
checked subassembly
checked assembly
should not have QTY
-CL1>SB>10-087-060.3.0.0 CL1.SB.DRAIN 6A-INSTALL.RCP 450MM 16.198 LF
anticipated issue from test, mitigated with ' - ' to indicate deleted codes
try: deleting this line item
*CL1>SB>01-043-019.1.5.6 CL1.SB.MVP5-CONSTRUCT. SF
Site»-043-019.6.0.0 SITE..-EMBANK.ROADWAY - removed associated objects
-
Research
-
-
Test setup with designated test corridor model as described above.
Try1: corridor shapes have quantity & material surface does not have quantity
Try2: Process
Turn off surfaces
-
Modify(Ribbon)/Profile&Section Views/SampleLines/
SampleLine(Ribbon)
Analysis/Volumes and Materials/Compute Materials - setup
Analysis/Volumes and Materials/Volume Report
Volume Report Review - looks good but no locations
Try3: Location-based material takeoff
Changing the name of links in edit does not change the name of link in codes
Change the object (link) name in compute materials - not allowed
Change object (link) name in corridor toolspace/settings/general/multipurpose styles/code set style - no
Change the object (link) name in assembly code set style - no
Change the object (link) name in subassembly code set style - not allowed when part of an assembly
Change the object (link) name in subassembly code set style - no
-
Seems overly tedious - try another approach
-
[SOLVED] Try4
Create a template Quantity Takeoff Criteria for the objects in the C3D model
Create SampleLine Group for Alignment CL991
Home/Profile & section Views / Sample Line - select alignment
Sample Line Tools / Sample Line Creation Method / From Corridor Sections
Select next Corridor Section
[Observed] New sample lines are not appearing
'Create Sample Lines - from Corridor Station' dialog box, select next corridor and start to end stations
[RESEARCH]
found the answer here; need to actually select the create sample line group option not just check that it is checked
Then right click Alignment/sample line group/sample line
(refresh if necessary)
(may need to select OK and close dialog box then reopen for the object selections to appear
and on Sample Line Group Properties Material List tab import criteria from template Quantity Takeoff Criteria
Select 'Map Objects with Same Name'
map items that did not map
Rename Sample Line Group Properties with location and select OK
repeat until all corridors have a sample line group,
4.5min each x 77 locations x 80% efficiency (I get bored during the 2min wait and start reading news) = 275 min = 4 hours 40 minutes of nearly mindless clicking.
tuned machine and worked on resolving RevoDrive crash from two-weeks ago - 4 hours
start 12:20:30 –> crashed
start 12:26:00 –> 12:28:50 2.83 min x 77 x .8 = 174.3 = 2 hours 50 minutes of clicking; took 4 hours to save 2 hours but moved forward on finding a RevoDrive solution
start 2:20:40 –> 2:25:57 5.28 minutes
the delay is after creating the sample lines from corridor stations, OK then Enter and then long 5-minute delay before the new sample line appears in the toolspace alignment sample line group
[DISSEMINATED]
-
-
test 09/21/2011 report quantities accuracy
Procedure, create inch msu dwg file named computeMaterialsTest_20110921.dwg and build 100' x 20' corridor with .25' pave1 and .5' base1
follow try 4 solution; sample line and 'material list' quantity takeoff criteria
fatal error 2x
[OBSERVED] fatal error if material is linked with object with a depth of 0; I linked subbase to subbase1 which had a depth of 0 and so had a fatal error both with the compute materials function and the sample line properties function (same function with different names)
'Report Quantities' (
XML) C:\Users\Administrator\AppData\Local\Temp\QuantityReportTemp.xml
[VALIDATED] Import xml file to excel;
10 entries for each station, solved with column equation sum[=IF(E16=E15,IF(B16=B15,0,E16),E16)]
the units are given as feet and then there is a column with CY - this means the final volume is in CY
check Pave1 L*W*D = 100'*20'*.25'*(1/27)= 18.52CY = computeMaterialsReport 18.52CY
check Base1 L*W*D = 100'*20'*.50'*(1/27)= 37.04CY = computeMaterialsReport 37.04CY
[OBSERVED] in compute materials matching the 'criteria' with the 'object' is inconsistent
>90% there are three options for 'object' in the 99CL1
Pave1
Base
Subgrade
sometime Curb
Occasionally there are more, for 99CL1>SB>15 and 99CL1>NB>03 these are:
Pave1, Pave2, Pave3
Base, Base1, Base2, Base3
SR
Subbase, Subbase1, Subbase2, Subbase3
The reason probbaly has something to do with the different assembly used in the alignment end-areas
-
compute materials macro to increment through reports
-
-
ReTest: during technical review of a report detailing observations made during the Merced C3D portion of the experiment - a function of compute materials has been overlooked
setup: compute materials 99CL1_FG alignment 99CL1>M>13 sampleLine create material with “Import another criteria” and selected the C3D “Material List” criteria [used a standard C3D criteria list to remove variables for error]. Then, associate the objects to criteria; this model has the subbase material assigned a payItem code so we selected this as a test. The runtime to apply these changes is long. Created a payItem file with only objects for workzone 99CL1>M>13 - the subGrade unit of measure changed from SF to CY. Reassociated the code in corridor properties.
Try1 Base setup Takeoff Report - CL1>M>13-043-019.1.5.6 18.5 CY (each for two subassemblies)
Try2 Change UoM to SY (check for UoM) Takeoff Report - CL1>M>13-043-019.1.5.6 1,337.41 SY
Try3 Check CY and SY manually
.446 CY
1,337 SY
SY is correct, CY is incorrect
[OBSERVED] Try4 repeat Try3 with Pave (.951' depth) base (1' depth) and subbase (.001' depth) in compute materials and takeoff report payItem list - all three are 18.5CY for half assembly
-
Does not explain how to setup compute materials for including on volumes on payItems report “To extract cumulative volumes of closed corridor areas, apply pay item codes to corridor links.Links with pay item codes are used to extract pay item area or volumetric quantities of materials such as asphalt, gravel, or soil.” “Exercise 4: Assigning Pay Item Codes to Corridors”
Vague reference “Import pay item files from contracting agencies, tag objects, closed areas, and collections, and compute quantities to create quantity reports and tables.” “Material and Quantity Analysis”
material shape style “Edit Feature Settings - Quantity Takeoff Dialog Box”
Expert query: a professional engineer that advertises as an Autodesk Civil 3D consultant was unaware of the compute materials payItem function
[observation] Test corridor; a 100' simple corridor model for testing
the payItem file cannot takeoff a volume and surface for the same payItem - this is important because for implicit objects that are derived some may be better defined from one unit of measure or another.
the volumes for subgrade, base, and pave are the same; this does not seem correct since they have different cross sections
Background: The QTO process is designed with the assumption the project has few locations - this is the correct assumption for the design and abstracted production and cost applied. In construction the core focus is on work sequence and therefor requires a location breakdown, often of location, sublocation, workzones, and on structures the pour zone. Civil 3D lacks the location aspect except for the parcel feature that is intended for sitework and redundant due to the computeMaterials and QTO payItem conditions.
Solution as of 2011-10-31: A corridor and primitives for each location but results in many corridors and primitives. The use of loops to create many of something resolves the repetitive aspect of many tasks in C3D when locations are applied. The new Calculating 'Volumes with the Volumes Dashboard' follows this approach; the surfaces were once created individually with a dialog box that is now called repeatedly through a meta dialog box that they call a dashboard.
Proposed solution: I think a similar location solution would work well for alignments, corridors, sampleLines, and computeMaterials, and probably other applications for features I have not used.
Background: Civil 3D is derived from architectural CAD software and carries some of the traditions from that field. One is the use of accronym layer names of the form 'wall-left-struct-fill' which works fine for designers except constructors use an ontology code of the form 10-01-051-10-13 which means the same thing but is integrated with the enterprise cost system and estimating applications, and builds into the financial reports of companies. Civil 3D does not have distinct fields for a standard ontology let alone custom ontologies, or even a field for an ontology separated with delineations. So, the layer name field is all that is available to record the ontology and description using delineation to separate the levels. This results in redundantly entering the ontology description into clearly linked items within C3D on average 7 times. There are some automated nameing features, for there are templates for naming with some autofill capacity in the toolspace settings - expanding these is all that is needed, see http://www.cadforum.cz/cadforum_en/string-concatenation-in-autocad-fields-and-block-attributes-tip8281.
Solution as of 2011-10-31: There is no solution, some items almost concatenate like alignment(location)-corridorName(sublocation).
Proposed solution: autofill and concatenate related civil 3D sub-components, for example site(location)-alignment(sublocation)-corridorName(sequentialIndexedSubLocation)-sequentialIndex(workzone)-sequentialIndex(concPlacement) and related sampleLines.
Background: compute materials has a matching function built in that could be more powerful if the ontology aspects of the application were better supported.
Proposed solution: regular expression matching and similar matching approaches to link associated items automatically, for example link payItem to code set style.
Background: some feature in Civil 3D already have this included, for example surfaces are automatically created for all the links in the corridor assemblies.
Proposed solution: Every corridor need a sampleLine, therefore automatically create a sampleLine with each corridor created.
cannot find where are the volume report settings - I need to change the default style sheet and the location reports are saved.
Also, needs an add-on that cycles through all alignments, sampleLine groups, and material lists, and generates a report for each; it is going to take awhile togenerate all these and then import the xml to excel. And, increment the report file name so it does not just write the same report over itself repetedly, it is going to take forever to create each report, rename the file, then run the next report. does anyone test this software for a reality check - it works but not in one lifetime?
[Disseminated]
None of these address ontology codes and is a noted deficiency of the corridor solids in the help forum thread
The gist: this helps 4D sequence-location simulation but does not help with location-based quantities so is redundant with surfaces.
http://labs.autodesk.com/utilities/civil3d_corridor_solids/
Research:
-
-
body objects
solids are not dynamic
still requires daylight surfaces, that are the most difficult anyways
shape names are generic, Shape-0, Shape-1 - do not name with subassembly shape names
-
This is a step in the right direction and a new approach but I do not think it is a location-based quantity takeoff solution or improvement on the current C3D capacity as an integrated model-based sub-component. The solids allow an approach to dividing the model into sublocations for 4D sequence simulations.
The solids are formed by
Behavior with QTO payItems
payItems can be assigned to solids and if 'select items with payItem' feature is selected the solids are selected
QTO report computes as items are assigned payItems
volumes are zero; CF and CY
areas are zero
-
The gist: this helps with earthwork volume calculations by location but does not help with the other location-based quantities and so until then is simply redundant.
http://docs.autodesk.com/CIV3D/2012/ENU/filesCVE/GUID-B75FEF9F-1020-4E66-B1B4-196732B540D0.htm
The release notes claim 'Calculate volumes in multiple volume surfaces' but for this particular quantity takeoff function the existing composite volume QTO tool did that already as long as multiple surfaces existed, that was the difficult aspect of the workflow. The new quantities tool looks like it is an improvement and satisfies location-based quantities but does not have an ontology code and relies on individually creating each. This approach does not allow selecting all and setting the base surface at once so may actually be a step backwards in that respect since you now must repeatedly define the base surface. But, overall it is the right direction for location-based quantities and has an improved workflow leveraging a meta panorama dialog box; particularly good if you only need earthwork volumes.
http://docs.autodesk.com/CIV3D/2012/ENU/animations/volumes_dashboard.html
Since the volume reported is incorrect and the internal conversions used are not documented in AutoCAD C3D the volume test will be used with 2 modifiers, first a 1.0512x to correct for the depth rounding and then a .08334x to correct for the attempted conversion of depth to inches - for a combined .0876x; this is only an approximation to return to the correct value and if the workzone volume is significantly greater or smaller than the test case then the multiplier will not work sufficiently. The workzones are similarly sized so this approximation is sufficient.
The subassembly layers have those with area and no depth and those with depth and therefore volume
The retaining wall solution developed by Christopher Fugitt will be used.
Sometimes multiple reported quantities are correctly reflecting 1) multiple subassemblies within an assembly, such as, Lt and Rt, and multiple xyz (unknown multiple)
The point links are calculated as individual items, for example, a barrier rail with 8 points has 8 equal quantities, the need manual deleting, they are LF so should be searchable in QTO report
The payItem file must be loaded and then the links made without mistake, else new payItem file and all new payItem codes to start over; removing style links seems to reset most payItems. If a code set style has payItems associated to a subassembly and then the code set style is changed, without deleting the previous style or removing the payItems, then the next QTO report will have quantities from both the old style payItems and the new style payItems.
Three functions must be used to obtain the full quantity takeoff:
The compute volume report provides the material by station, but not by left and right assembly
The point, length, and area quantities are a separate function that must have breaks at location boundaries; this function has an ontology code feature but each location must have a unique code prefix and corridor for surface area (maybe surface area calculated by computeMaterials but then left/right issue remains) - making for a long chart of accounts and many corridors.
Last, from preliminary but incomplete testing it looks like the earthwork volume can be completed using the parcel function or bounded volumes function but if there are already corridors for each location, might as well just use the composite volume function and skip the parcels function setup.
If for this experiment, we accepted the project Primavera schedule as sufficiently accurate (we know it cannot be and raises the question of where the schedule came from and the purposes/games of the schedule) and ignored the quantities then the corridor solids would vastly improve the process for creating a Civil 3D model for the 4D visualization. In reality, right now this probably is sufficient for 99.9% of the civil infrastructure world but does not make a whole model-based solution. In my opinion, if they want to create a piece of a whole integrated model-based planning tool then they need a true location-based quantity takeoff with properties for an ontology code with breakdown for location and product with an understanding that the ontology code will later be increased in level of detail to include multiple processes, appliedResources, and eventually specific resources (Staub-French).
Test CL1>M>05 and CL1>M>06 for correction multiplier sensitivity, find % variance for expected.
Test the behavior of code links to fields in subassembly
-
The BridgeBoxGirder2 C3D subassembly has the surface of the deck, surface of the bridge, and volume of the bridge. What we need is the volume of the bottom-deck, stem, and topdeck separately. The bridge box-girder needs a custom subassembly that can provide a takeoff for subcomponents.
After the process of testing, understanding, and implementing outlined above, a QTO report is ready. In excel we have a QTO for 240 objects by project location; there are 250 locations, these are workzones. We created the QTO with a combined use of 1) corridor payItem code, 2) ACAD primitive payItem, 3) composite volume, 4) volume report (sampleLine), 5) mass element property, 6) analysis/inquiry tools, 7) distributed CalTrans quantities (x/n locations), 8) distributed bid quantities, and 9) we made an educated guess on a few. We then listed the 240 item quantities (without locations) and compared the CalTrans QTO, with the Contractor Bid QTO, with the C3D+TCM.QM QTO as a variance analysis. We found errors and made correctins with rework to the model, added some missing items, deleted a redundant item, and found 16 items that have an unexplained variance greater than 40%. The final variance breakdown that I feel comfortable with given the uncertainy introduced by 1) earthwork density state conversion, 2) variance from actual conditions, 3) production inaccuracy, 4) unaccounted for climate affect on production, and 5) feedback of actual event inaccuracies (did activity a start wednesday or thursday?):
>70% & unexplained: 16 items, all related to formwork on the retaining wall and box girder bridge. The bridge object is one lump object while the retaining wall is broken into 3 items - wall, footing, and barrier. Without a specific formwork link on these, then it is expected that they will have the largest variance and be difficult/impossible to explain.
44 (19%): items without a comparison value
>200%, 2: the C3D seems correct
>100%, 4: these are short duration items that will not significantly affect the schedule
80%, 6: the C3D seems correct
60% 12: mostly structural surfaces
40% 14: the C3D seems correct
20% 21: a mix of items,the C3D seems correct
<20% 110 (47%) considered an acceptable variance an at this time difficult to distinguish which is correct
Dissemination: Why are the volume report and payItem QTO different - suggested a hand calc from plans - found error in RW4>02 http://forums.autodesk.com/t5/AutoCAD-Civil-3D/Quantity-takeoff-calibration-variances/td-p/3364281
Update quantities with corrected RW4>02 values: found that TCM adds values with previous imports, creating duplicate values - must check every item and remove duplicates.