AutoCAD Civil 3D Modelspace Units

Feel free to reuse this material with the following citation:
Peterson, F. and Fischer, M. “CIFE Wiki Technical Report: AutoCAD Civil 3D Modelspace Units.” CIFE wiki. Stanford University Center for Integrated Facility Engineering. Last accessed dd month yyyy. http://cife.stanford.edu/wiki/doku.php?id=granite:3dmodelling:modelspaceunits

Problem

The unit of measure in Civil 3D became a question back in March of 2010 when lab-experiments began for the software that possibly would be used on the MER99 experiment. I was confused by the default Imperial and Metric installation and why there were two separate icons on my desktop; which to use and am I then trapped in one unit of measure or the other and why. The first indication that the question has larger implications is the observation in the C3D Metric template of a dialog box that set an object to 7.20 Meter which when zoomed out had a dimension of 7.20 Inches - documented in this video clip http://granite.web.stanford.edu/civil3D_units.avi.

The specific problem guiding this research problem: If the modelspace unit is set ‘feet’ then the stationing is incorrectly displayed in 'inch'

Intuition

AutoCAD Civil 3D has two 'flavors' of the same underlying source-code that has some hard changes.

Research

The first concrete answer: “user Profiles used during startup… the difference is the template set as the QNew template, these are Metric and Imperial.” (C3D blog)

A review of the AutoCAD Civil 3D documentation, the Wiley Mastering AutoCAD Civil 3D 2010 Authored by James Wedding, and search of and participation in online forums here (profile view text), here (modelunit), and here (inquiry tool) did not provide the complete answer only pieces and a good foundation to begin from. A query of two knowledgeable C3D modellers by email found that it is important to start with either metric and imperial template and stay within one - why was not known. From review of text, blogs, and query of experts the following graphic of C3D settings related to model-space unit and unit of measure was assembled. http://c3dpeanuts.wordpress.com/2010/03/10/converting-civil-3d-objects-from-imperial-to-metric-and-vice-versa/


Figure From web forum review and participation the seven ways to change the modelspace and quantity units.

Question

Base question: “what is the difference” between civil 3D metric and imperial

  • why is the observed behavior 'observed'
  • how to test for why, and
  • what variables are provided

Scientific Approach & Setup

Approach

The research will progress through 1) web search, then 2) expert query, 3) testing the software with niche scenarios, then repeat from 1;

Setup

  1. A 3D dimensional model was built from a 2D dgn imported into the metric modelspace and a decimal unit of measure type; the 3D model dimensions were inches converted from the 2D plan meter dimensions. The experiment protocol used AutoCAD Civil 3D 2012 C3D F.51.0.0 with the 2010 dwg file type.
  2. From the available methods to change the modelspace and unit of measure units two approaches were selected with a third used as a check. 4d_model_for_mer99_overhead_construction_2.jpg

Figure The command aecdwgunit and the ambient settings found in the drawing utilities/drawing settings/ambient settings provide access to all the known settings.

  1. Variables: modelspace unit, ambient settings, unit of measure type, scale.
  2. Measured:
    1. Stationing unit of measure
    2. Properties unit of measure
    3. Inquiry tool unit of measure (added midway through tests)
    4. Quantity takeoff unit of measure
  3. criteria for success, if all four measured metrics are the correct unit then pass, else fail.

Observation Journal

There was no clear answer for several months. The most compelling evidence was a corridor cross section that was in the metric unit of measure meter but when dimensioned it was in the Imperial inch, the same measurement 7” == 7m. This indicated that the software developer had used the same source code with only a change of the unit of measure from inch to meter and the elimination of the source code that aggregated measurements of foot and yard. This was counter intuitive since this intuitively would cause problems later since the geometry (likley pixels for a given display resolution) for the length represented by 1-meter differed in the Imperial and Metric versions, they are incompatible but represent the same dimension. At the stage of the MER99 experiment where the quantities were addressed this issue was revisited. The MER99 model was modeled in the Metric template in 'true' scale of 1-meter = 39.370079-inch; the conversion required an excel calculator but the same would have been necessary if modeled in the Imperial template since the original dgn plans were in metric. Modeling in the Metric Template with the metric representation used by Autodesk was avoided since it was not certain if all 3rd party developers had worked closely with autodesk and their software understood the units in the model dwg. As it turned out the vendor tools appeared they did understand the units and as anticipated (lucked out) it was easy to convert between metric and imperial templates. A discussion with Autodesk validated the suspicions.

The default setting for the metric and imperial template

  • Metric: Meter modelspace unit, decimal unit of measure type, and meter ambient setting with exception of dimension that is millimeter
  • Imperial (first check; this is likely due to other factors and is incorrect, but it was observed): Inch modelspace unit and feet drawing unit, architectural unit of measure type, feet ambient setting with exception of dimension that is inch
  • Imperial (second check; changed after file was open a few minutes): Feet modelspace unit, decimal unit of measure type, feet ambient setting with exception of dimension that is inch; this means that by default a 24.00 wide object by default, is 2' if the unit of measure type is changed to engineering.

Experiments

  1. Convert from Metric to Imperial 6/29/2011; with command aecdwgsetup change unit of measure type to “Decimal” from “Engineering” then change drawing utilities/drawing settings/ambient settings to english.
  2. Try0: Changing the drawing units to feet from inch corrected an issue with the text in profile view but created a problem with the stationing and QTO, that is the modelspace unit. Attempting to change back to inch resulted in a non-responsive system after an hour of runtime. An Autodesk forum thread for the non-response from change from feet to inch is posted. 4d_model_for_mer99_overhead_construction_3.jpg
  3. Try1: Change the Prospector/settings/edit drawing settings to a custom scale 1/12 or 0.0833333. This change did not affect the stationing or QTO.
  4. Undo: Attempt to restore backup to preconversion. The last backup is from 06/10/2011 and predates the addition of corridor workzones, a major task.
  5. Baseline: The modelspace was changed to inch without rescaling the existing objects and the stationing is now in the correct feet unit of measure, the QTO test object 'CL1>02>NB-025-012.5.1.2 CL1.NB.-SHIFT.KRAIL' is in the correct feet unit of measure but the properties length is in inch.
  6. Test0: A brute force attempt to change from feet to inch using aecdwgsetup - the runtime starts at 2PM and will run for three hours until 5PM (this test was not attempted)
  7. Test1: The modelspace units are inch, units decimal and the ambient settings are varied from feet to inch. The result is the same as baseline. 4d_model_for_mer99_overhead_construction_4.jpg
  8. Test2: The modelspace units are inch, the ambient settings are feet and the unit of measure type is varied from decimal to engineering. The result is the properties are now given in feet and therefore the problem with unit of measure is solved (retest added the inquiry tool as a metric). 4d_model_for_mer99_overhead_construction_9.jpg
  9. Test3: The modelspace units are inch, the unit of measure type is engineering, and the ambient settings are varied from feet to inch and mile. There are no observed changes. 4d_model_for_mer99_overhead_construction_6.jpg
  10. Test4: The modelspace units are inch, the unit of measure type is engineering, the ambient settings are feet and the scale is varied from 1:1 to 1:1” and 1”:1'. There are no observed changes.

4d_model_for_mer99_overhead_construction_7.jpg

Validation

Validation by test

The inch modelspace unit of measure does not appear to have detrimental affects when combined with the engineering unit of measure type. The 'inch' msu appears to behave correct and is a valid msu. As expected, when the modelspace is changed to feet or the unit of measure is changed to decimal, the application cannot accommodate an inch msu, the displayed units of measure are incorrect. In seven separate tests the inch msu passed the four metrics when the unit of measure is engineering, the unit of measure failed to correctly display in the properties display. The tests show that the scale and ambient units have no affect on the display in this scenario.

4d_model_for_mer99_overhead_construction_8.jpg
Figure If the modelspace unit is changed to feet then we should expect the quantities to no longer be displayed as engineering (modelspace unit / 12 including decimal remainder to represent inch) to only feet, similar to decimal.

4d_model_for_mer99_overhead_construction_10b.jpg

Validation by pragmatic use

Following the test sequence is a period of pragmatic use of the application in inch modelspace unit and continued discussion on the forum thread.

  • Alignment: The file import for alignment profile reads the station and elevation values as inch, therefore the foot stationing and elevation values were multiplied by 12 and then imported, where the displayed units are in engineering feet.
  • Superelevation: The super elevation function is not producing the expected cross section, possibly dude to the inch msu. So as a test a 1 mile per hour design speed is changed to (1mile = 5,280 feet : 1 foot = 12 inch) 1*5280*12 = 63,360 inch per hour. The C3D automatically converts this from mile to what it 'thinks' should be feet by multiplying by 5,280, so whatever value is applied for design speed will be multiplied by 5,280 and cancels out of the previous equation. Therefore, if design speed is entered as 1-mile per hour then (with this model in inch msu) the msu speed is 5,280 per hour or 1/12 of what it should be - 63,360 msu per hour; so the desired design speed is scaled by 12. The design speed of 60-mile per hour will be entered as 720-mile per hour. The lookup table used by C3D for superelevation does not have a 720-mile per hour entry so “Design speed is beyond the maximum speed defined in the table.”
  • Analysis/Volumes: The volume QTO from surfaces provides a Cubic Yard unit of measure with the current settings, but the export file value has no unit of measure and is not cubic yard, feet, or inch. Not sure if this is related to the msu = inch; a workaround, copy and paste the table to excel rather than export.
  • The Google earth export file is correctly dimensioned
  • The superelevation works fine in inch msu but the startpoint for subassemblies is retained in feet but represented as inch, so 3.5' is represented as 3.5”.

Claimed Contribution

Initially, the difference between the C3D imperial and C3D metric versions guided this inquiry; the focus became general to the behavior of C3D unit of measure settings. At different times the inquiry tool, toolspace pallet, toolpallet retaining wall, text height, and quantity takeoff unit of measures were clearly incorrect but it was unclear why, how to test for why, and what variables are provided in C3D. A review of the existing literature and blogs gave pieces of an answer to these questions. The previously mentioned texts established a baseline documentation of some available settings and the blog discussion established that the topic is tacit and accepted as outside the domain of the software developer documentation. Through testing a polyline, this inquiry resolves the observed initial behavior of the Civil 3D unit of measure variables, provides what those variables are, and suggests a process for testing which variable is causing an issue. The profile view text height and toolpalette retaining wall are still unresolved. This contribution now allows those working in the C3D space to systematically approach the unit of measure knowing the variables available. If a reader has the same issue as used here then they can reuse the results without further testing.

In one blog the contributor stated that Autodesk C3D software engineers assumed that a sub-foot unit was not necessary and so selected foot at the base modelspace unit. As a result, elevations in increments of less than a foot are not possible except for the use of a workaround. Possibly, the solution found here resolves that issue - simply model in inch modelspace unit; further testing is necessary to find this but the possibility is given here.

Limitations & Suggested Work

Some of the blog reviewers raised the argument that according to the intended application of Civil 3D and as the documentation provides for, C3D only works in modelspace units 'feet'. This is known as the neat approach in computer science. From the pragmatic or real world tests done here it looks like - while they are correct - the modelspeace unit 'inch' does not affect the specific application of the C3D application here on the Merced 99 project. It may be that the C3D algorithms like superelevation calculations based on design speed are what will not work - this was not tested and the blog did not give specifics. Also, the retaining wall given in the imperial tool pallet is still metric and the profile view text in in metric scale; both are extremely small and therefore unusable. These were tested and corrected - documentation is in this wiki.

This study began with the Metric template, a dimensional 3D model using the dimensions in inch and then changed from metric settings to english settings, these settings then modified to adjust for the inch unit. Nobody is likely to replicate this process since it was a deliberate misuse of the c3D application intended to 'shake-out' the details of the units and find the boundaries of the application and the behavior of the units functions and settings.

Further testing with original models made in modelspace feet and engineering type compared to modelspace inch and engineering type. Also, testing area, volume, and corridor surface objects will expand the contribution from just polylines.

Conclusion

Right now the model space unit is so intuitive and clear that this entire page seems unnecessary. But, on my first day of modeling with a bunch of dgn MER99 project files ready to convert into dwg, the very first task of choosing the C3D Imperial or C3D Metric icon to start the 3D modeling process was the most confusing thing I have ever experienced. Where were my 4D glasses when I needed them!

Method of Dissemination

Acknowledgements

Thank you to the following autodesk forum contributors: wfberry, sinc, MichaelMerlino7407, Patchy, peterfunkautodesk, gccdaemon, and BrianHailey. Early during this process (back in January 2010) Amir Kavousian helped explain the Civil 3D settings and Dana Probert provided some coaching.

granite/3dmodelling/modelspaceunits.txt · Last modified: by forest.peterson
www.chimeric.de Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0