profile view station text height

[granite07]

The text height on my profile view is really small, I followed the instructions for text height given in another thread but the text has not changed, the profile interval did change so it seems like I was changing the right settings. The file originally was metric and is now imperial after changing the drawing units.

[wfberry]

Sinc:

You did notice he goes by granite !

<G>

Bill

[granite07]

After changing msu=inch the quantities and stationing are correct. The machine stopped responding if I selected convert objects rather than change units without conversion. There is no argument but through discussion and sharing and presenting arguments that describe the behavior we have observed exhibited by the modelspace units we will come to a better understanding of C3D. I have observed that C3D works fine in msu=inch and have not found an exception to this.

At Granite they taught me to just pound the phone on the desk and scream do you *^$#-(^!!#@ hear me now *&%^#_((*&& 🙂

[granite07]

I compiled this thread and a couple other threads with several tests, the results are posted here

http://civil3d.wikia.com/wiki/Civil_3D_Modelspace_Units
http://cife.stanford.edu/wiki/doku.php?id=granite:3dmodelling:modelspaceunits

[Sinc]

Ouch!

It's frustrating seeing things like that.

I feel somewhat responsible, in that I feel I probably failed to explain things adequately.  I probably also imparted some of my own personal frustration, as I think a number of things in Civil 3D were implemented in very confusing, very roundabout ways.  But your wiki entries are taking your own personal misunderstandings of how C3D currently works, and misunderstandings of what I've been trying to say in this thread, mixing it with how you wish it would work, and throwing in a bunch of core AutoCAD-related stuff that is actually not applicable to C3D users, and ending up with a gumbo jumbo.

I see some of your misunderstandings, and it makes me wish I could work with you one-on-one, and show you what's going on.  Because I can see you've gotten yourself trapped in a tangent.  As an early adopter of C3D, I've been there, done that.  It's easy to do.  C3D is very confusing in some respects, and lets us down in some ways, but your wiki posts are off-target.  My fear is they will create more confusion than illumination about how things are actually occurring inside of C3D.

The problem is figuring out how to straighten out the misunderstanding in a web forum, without spending hours and hours of what I'm finding to be increasingly-limited personal time...

[Jeff_M]

Wow, not sure how you came to the conclusions you did. All of your posts regarding this seem to point to confusion on your part, and not paying attention to (or are confused by) those who have offered their help.

Let's start with the video you include in the Wiki 'proving the Metric template inconsistencies'. What template did you use? I have not seen ANY metric C3D DWT's that use inches for the units. I just tested with a new C3D2012 install, started the program using the Metric shortcut, added an assembly and a lane subassembly set to a width of 7.2 meters. I then dimensioned the lane and it dimensioned as expected at 7.20. In your video the drawing's units are set to architectural, as evidenced by the coordinate display in the lower left corner. This tells me that one of two things is going on....either you did not start with a metric DWT, OR you changed the units in the DWG, and from here all the problems you seem to be having snowball into the mess you report.

When used correctly, the base AutoCAD "units" command should never need to be used, except possibly to change the precision of the displayed units. In all of your posts that talk about being able to use C3D in inches, I have yet to figure out why you are trying to force C3D to do something it was not intended to do.

BTW, what is a "VDC engineer"? In another post you said " I am a constructor and work in whatever unit works best for the specific conditions." Based on this you should realize that you MUST work in feet or meters, using the appropriate DWT, with C3D or you WILL run into a myriad of problems...just as you've been finding. The specific conditions for C3D say "use feet or meters", this means these ARE the units best for these conditions.

[granite07]

First, thank you for sharing your expert knowledge and taking time from your professional 'paid' time to contribute knowledge with your 'free' time; I appreciate and understand this.

Your knowledge of C3D and AutoCAD is infinitely deeper than mine and I want to understand (ungumbo the jumbo) how the software behaves, if you have time please explain:

• what aspects do you perceive as centrally misunderstood
• what aspects are the 'wishful thinking'
• where is the boundary between ACAD and C3D (which commands are which)

Second, feel free to edit the wiki to move the page on-target and simply push the controversial aspects of my post to a counter section at the bottom (customary practice in Wikipedia) with a note that it is not accepted by the majority and is a minority opinion.

Last, to answer why I am "trying to force C3D to do something it was not intended to do;" well that is what I do to pay my bills. I use a dozen software applications and every one of their technical support technicians have asked the same question. This leads to "what is a 'VDC engineer'?" You will soon know, the simplest answer is everyone using C3D is a VDC engineer to a degree. As for units - civil engineers use engineering units but if you walk into the field and ask a field hand if they use decimal or fractional inches - they will say fractional, such as 1/32, 1/16, 1/8, 1/4. So, if I provide a virtual 3D model to the field hands on a tablet PC the units should be in the units their tape-measures are in. But, when modeling, I prefer to use decimal since it is easier to calculate in an excel calculator and when I review the model engineering units is preferred. So, easily changing the units depending on the specific conditions is a nice feature and I'd like to know how C3D behaves.

Per your excellent expert review I will revise the technical wiki to better document that the model is a dgn 2D import to a C3D metric template, a dimensional C3D corridor model is built on this, and that then the units are changed to english. Also, it was not clear that the test is with only a polyline. For the next week as I takeoff quantities it will become clear if the current 'inch' msu setting does not work with area, volume, or C3D corridor surface. Is there documentation or have others posted the problems encountered with 'inch' msu - sometimes the developer simply did not test the condition and so it is not 'intended' but still works fine. For an example of product specification limits, my laptop specifically is intended for 2GB of RAM but 8GB runs just fine and I suspect 16GB would as well (nevermind why I would use 16GB or tried 4GB then 8GB). The laptop manufacturer simply tested to 2GB, called it good and said that is what it is rated for, they never tested more then 2GB so it is not intended for this - meaning they are not responsible or will provide support for more.

The video was made with the Metric template and at that time I did not know how to change the unit or ambient settings - it was a 2010 install so maybe it has been fixed or as you suggest I unknowingly changed something - it was not a documented test since it is the 'discovery' that led to the current interest in looking 'under the hood' of C3D units function and behavior. Since, I have discovered that there is almost no documentation for the C3D units other than a generic 'do it this way' and not much on why - my wiki post is intended to seed this missing chapter.

Again, thank you for providing your expertise.

[wfberry]

Obviously I am not Jeff, but I would like to address your third question:

"where is the boundary between ACAD and C3D (which commands are which"

If you type HELP in the command line, you should (in 2010) get the Autocad Civil 3D 2010 HELP screen.  Select the contents tab and you have 3 choices:

AutoCAD 3D Help

AutoCAD Map 3D Help

AutoCAD Help

You can readily determine what command each product uses.  What my main concern now is that in Civil 3D 2012 the powers of the great Autocad in the SKY have eliminated this help portion.  If I am wrong, good, please show me where it is.

Bill

Granite:  The last statement is not directed to you.

[granite07]

[SOLVED] preliminary until reviewed

The specific problem this thread originally asked for help with is the profile view text height - I solved it this morning; the solution was to change the profile view style settings.

My third question given below should have been more specific. The question is within the context of Jeff's comments. It should have been "what specific core AutoCAD-related stuff that is not applicable to C3D did I throw in a bunch of ".

Also, the HELP command works fine in my C3D 2012 install - it brings up internet explorer by default without an obvious option to change to other browsers.

[Sinc]

I'm not Jeff either, but I can try to answer a little bit.

The confusion seems to start with this idea that you can simply flip units in C3D and everything will convert.  That actually doesn't really fit into what happens in the real world.

In the real world, we have projects that are either Metric or Imperial.  We don't "flip between them".  The two types of projects are fundamentally different, typically using different typical sections and standard details.  As but one simple example, take hieight of curb (or kerb).  If we work on an Imperial project, our typical curb height might be 6 inches.  However, on a Metric project, the typical curb height is likely to be 150mm.  6 incehs is not the same thing as 150mm.  So we can't flip between Imperial and Metric projects simply by flipping our units in our drawing.

This is very similar to the underlying reason why you don't want to try starting with a Metric template for an Imperial project, or vice-versa.  The Styles are pre-set for the correct units, applicable to that type of project.  You can't simply convert units and get the right results.  For example, in a Metric project, I might want contours at 0.5m intervals.  in an Imperial project, I might want contours at 1 foot intervals.  It would not make sense for me to start with an Imperial drawing that has contours at 1' intervals, change the drawing units from feet to meters, and end up with a drawing that has 0.305m contours.

What I'm trying to get at is the entire premise of flipping between Metric and Imperial by simply changing drawing units is flawed.

Also, there's a big difference between the drawing units (aka modelspace units) and the units used in a label (display units).  Sure, some of the people on a job site might work in inches.  But that doesn't mean we change our drawing modelspace units to inches.  It means we leave our modelspace units set as feet, and use a label that displays inches.  We can even model in feet, and create labels that display measurement in meters.  Or, by using Expressions, in any other unit we might desire.  (Except, unfortunately, for something like fractional inches...  This is where Autodesk let us down.  If we use standard Autocad Dimensions, then we can label our drawing with fractional inches.  But Civil 3D labels do not include an option for displaying fractional inches...  This is a failure of design in the current versions of Civil 3D.  True, in the Civil industry, we usually want to label things in decimal feet, but we DO regularly also need to label various things in fractional inches, and Autodesk failed to consider this.  There are ways to work around this problem, but they usually involve round-tripping data through Excel, or some other arduous workaround like that.)

All of this is even more critical when plotting comes into play.  (I don't know what you mean when you way you're a "VDC Engineer" and therefor have no use for plotting - if you have no use for plotting, why label things at all?  But I digress...)  Once upon a time, we had to manually calculate the correct height of text in modelspace units, in order to get our plots to look correct.  Now, this can largely be automated, by using Annotative objects and Civil 3D labels and elements, which makes our job as drafters significantly simpler.  However, it also means we need to use these features in the way they were designed.  When it comes to Civil 3D Styles, all of these are designed using the assumption that your modelspace units are feet (or meters), and your paperspace units are in inches (or millimeters).  If this is true, then all the calculations happen correctly and automatically, everything happens easily, all text gets sized correctly, and everything looks great.  If this is not true, then you end up fighting the software, as you discovered.  Most of your Wiki post details how you are fighting the software because you are trying to use it in a way it was not designed.  Really, the Wiki post can't be cleaned up by a few edits - it pretty much needs complete replacement.

Now, there ARE times when we might have data in a different set of units from the rest of our project.  So we might need to actually convert data from Feet to Meters, or vice-versa.  But we do that by actually converting the data.  We don't just jump into a drawing and change the drawing units.

[granite07]

Thank you for your clear and concise explanation. Your key points are knowledgeable and valid, but I raise a few more.

I am not labeling anything in the model; the only outputs from this model are the quantities for the CPM schedule and the visual surfaces for a 4D model. If it is used in the field then it will be either for TopCon controllers or tablet PCs with the inquiry tools used for distance (in the field they would actually use Navisworks since it has lighter hardware requirements and a tape-measure tool). Labeling a meter msu model in english units does nothing for the QTO or Navisworks file that will be meshed with files from other design teams.

The inch modelspace units - while fundamentally wrong and you may be correct have no 'reason' - are so far working fine; it is actually like it was made to use this way, there is no 'fighting it' outside a few issues like profile text height.

Consider this scenario: an integrated project team of contractor and subcontractors are creating a shared virtual model of the project - the roadway is in meter but the underground sub is in feet. As it is now, one or the other must 'fake' the dimensions or the roadway will be a small speck on the underground model.

The intent of the wiki post is to describe the C3D msu and u nit of measure behavior - found through essentially bashing it against a wall for awhile and observing what happens. The idea of a wiki like this is new so what is valued and what is not only time will tell.

[Sinc]

---

@granite07 wrote:

I am not labeling anything in the model; the only outputs from this model are the quantities for the CPM schedule and the visual surfaces for a 4D model. If it is used in the field then it will be either for TopCon controllers or tablet PCs with the inquiry tools used for distance (in the field they would actually use Navisworks since it has lighter hardware requirements and a tape-measure tool). Labeling a meter msu model in english units does nothing for the QTO or Navisworks file that will be meshed with files from other design teams.

---

And is this a workflow you've already been using with great success, or is this just an idea for how to proceed when you get to that point...?

Based upon my experience, my guess is the latter.  The whole idea makes me shudder.  Here's why...

There are typically lots of problems involved with trying to work with Survey Data if your MSU is in inches - as a superficial example, how do you set a point by keying in coordinates?  And I can't imagine using Navisworks in the field - in my experience, that's more of a planning and visualization tool, and is not useful for an actual construction team.  Maybe an inspector might like having a tablet PC with a Navisworks model in it, but I can't imagine a Surveyor using such a thing.

As far as attempting to do a single project in a mix of Meters and Feet, I've never heard of anyone doing that, and for good reason.  I know that for a while here, we had DOT projects that were designed in meters, and some people attempted to build these projects by converting everything to feet in the field, even though the plans were in meters.  They created massive confusion for themselves, with tons of errors.  Meanwhile, people who simply built the projects using meters (the units from the plans) had no problems.

When I was working for JPL, NASA ran into a similar problem.  We were working on sending a satellite to Mars, and the team was international, primarily with people from the US and France.  An error in Metric vs. Imperial units resulted in a bad engine burn that destroyed the spacecraft when it reached Mars, losing many millions of dollars worth of equipment and years of time.  So no matter what project you're working on, I'd say it's ALWAYS a bad idea to try and have different team members using different units.

I really think you're going down the wrong path, and will be encountering more and more problems as you go along.  But that's just my recommendation.

[Jeff_M]

---

Sinc wrote:

I really think you're going down the wrong path, and will be encountering more and more problems as you go along.  But that's just my recommendation.

---

Ditto, ditto, ditto.....

It might be all fun and games now, but, IMHO, the "VCS" Engineers (which I still haven't figured out exactly what this means) are looking at this from the wrong direction and are just asking for trouble later on.

[Cadguru42]

I'm trying to understand what a "VDC" or "VCD" or whatever engineer is.  Also, if you're not making printouts of the model, then what's the point in trying to force C3D to use inches?  Just use dimensions and labels that are in inches if you want, but the model should always be in feet or meters as that's what the program is designed for.  I also don't understand how Navisworks in the field will be used for construction.  If there is something to Navisworks that I don't know about, I'd love to hear it because we'd like to get it if that's the case.  (I'm trying to figure out a logical reason how to convince the boss to buy me a tablet <grin/>)

[granite07]

Again, this conversation thread is excellent and the dialog is rich in context due to the wealth of knowledge and experience contributing.

First, I will digress - the loss of the Mars orbiter due to inconsistent units is used as an example in many engineering program courses and is a reality of our world. There is validated research by Professor Raymond E. Levitt that explains this problem and similar problems by applying organizational theory - the gist is that a failure like that in the Mars Orbiter Project can be predicted with usable accuracy but the exact failure is not predictable.

Second, for five years I was a highway laborer (it took me five years of non-union work in residential and commercial before I found highway work) and experienced first hand the CalTrans transition to Metric plans you describe; this is my basis for the need to have easily converted measurements. We (Union Highway Laborers) carried two tapemeasures, one in metric and one in english; this is still the field practice today (if you think you can force metric on informally educated field crews, think again). The survey stakes were placed by Caltrans in Metric, as field crews we never saw plans and worked off the stakes and a verbal description of the subassembly we were working on that day (a DI blockout is a DI blockout is a DI blockout). Try calling out to Joe, "hey cut the 2x4 to 2-meter" and see what happens - ask "hey cut the 2x4 to 6-foot" and you don't even need a tape, he can eyeball it; same for a .4572 meter highway form kicker. Hopefully you get the image now - and notice that none of this stuff is actually on the plans, it is implied to exist but certainly is necessary to construct the project. We only used the metric tape to measure offset from the stake, maybe elevation (you build off existing elevation anyways so plan elevation quickly become meaningless as the project proceeds; as I learned, I formed a concrete on-ramp off the grade stakes and was 'too grade' but not to the roadway paved two-inches 'off grade' the previous week) and from there it was in english since we 'made up' the details that are always left as 'field issues'. The point here is that it is not as simple as those who built the projects using meters and those who did not; the workforce is the same and I'd wager there were english tapemeasures at both contractors.

You correctly point out a weakness, it is an idea for how to proceed when I get to that point. But, it is a plan based on experience in the building industry were Navisworks and tablet PC's are accepted and provide a value. I have assumed that this value will transfer to the civil industry but, you are correct it is an assumption. So, yes it is a workflow I've already been using with great success, but not in the civil industry. Also, I assumed the civil 3D export file used for topcon would be exported in a usable unit of measure - I will review this with the engineer responsible for the equipment controllers (thank you for the peer review on this).

The field crews I referenced for using the tablet PC with Navisworks is not the survey crew but the construction crew (the people actually holding shovels). From my experience and after discussing the plan with a Labor forman with 30+ experience, we easily see the value of the Navisworks visualization model and the ability to takeoff spot measurements. For example,visualize yourself standing in an empty field with the exception of survey stakes and you are to build something - in sequence - you have never seen a picture of (in five years of building highways I never saw the plans, schedule, or budget, ever)  except for the image you imagine in your mind - clearly there will be some inconsistencies in the final product and possibly rework. Your intuition may be correct that 4D visualization is for planning and is not useful for an actual construction team but this is a nice question to validate - we simply do not know. My intuition is that the guys with the handtools will find it useful and this will be a grassroots or bottom-up accumulation of savings that will increase the project bottom line more than the cost of implementing. But, maybe 4D simulation has no place in the civil industry (outside public relations outreach PB uses it for - more like a Pixar clip) and is a building industry tool that will not transfer over. Again, thank you for the peer review, you have helped establish that this is a real question without a clear answer.

Last, I am not endorsing the inch unit of measure or changing the msu. This is now a test to find and document how the model space unit behaves to better understand C3D. If nothing else to explain why exactly only feet and meter is prudent. Not everyone is persuaded by a simple 'do not do that' or as the current C3D documentation lays it out, basically is mute on the subject. I am the first to admit this started as a misunderstanding that turned into an opportunity to understand. And, if I misunderstood then there will be others that will too and I'd like them to have something I did not - a documented explanation.

Google "VDC Engineer" or "Civil VDC Engineer" (without the quotes)

This is adapted from a USACOE technical report:

http://cife.stanford.edu/wiki/doku.php?id=granite:civil_vdc

[Cadguru42]

I have never heard of VDC, but it sounds like it's just new term for BIM for Civil engineering.  Anyway, if you're wanting to use Navisworks in the field based on the Civil 3D data, I'm not sure how Navisworks get that data since I don't have Navisworks.  However, I would assume that it handles importing data like almost all other CAD type software and what it would get from C3D is the surface.  It won't matter if the Civil 3D drawing is in feet or meters because once you export it, Navisworks is the one you're wanting to extract the data from.  If Navisworks can grab spot elevations and dimensions, then it is that software that you need to worry about if you want something in inches or centimeters or whatever. 

I'm very curious how you guys ever built anything correctly without having the plans.  Perhaps that's why California is so messed up? 🙂   How do you know what the cross section is at a specific station?  Did you completely rely on just the surveyor stakes and "verbal descriptions"?  That's just a recipe for disaster.  How'd you know how much asphalt and base stone to use without plans?  What about storm pipes?  How'd you ever know how much cover to have, how much depth, or even the type of pipe to use for a particular section?

[granite07]

I think this may be the end of this thread, it has digressed out of the topic scope of changing profile view text size settings under various model space unit settings. But, I'd like to answer the proverbial 'how it really was in the field'.

Yes, we completely relied on the surveyor stakes and "verbal descriptions"; also, the piles of various material and components in the yard and the construction equipment on-site suggested what to do.  Also, all projects are to some degree a disaster, as engineers we minimize the disaster. Only once did I asked the project engineer if I could see than plans - he showed me the CalTrans standard details book, explained it all very well and really helped me to understand. I politely listened,waited for him to finish, thanked him, and went back to my crew and never had any need to look at the CalTrans standard plans or ask the project engineer for anything other than to order small tools- the plans meant nothing (similar experience with the one time the PM showed me the schedule on the office trailer wall, the next week it was the 'old' schedule).

We knew how much asphalt and base stone to use because when the hole was full that was how much - the last truck dumps the partial load somewhere and radios the next truck to turn around and go back to the quarry.  How did we know how many trucks to call for the day, because it was less than several trucks or that is what is available today. Also, we knew how many days it would take because on the last day we were done. The point is, what do I care about total quantities, cost, production, and profit, all that matters is building it correctly and the before mentioned items should fall in place.

I never built a storm drainage system  - so I do not know the answer. But, if I do not know how to construct a storm drain then I will not build it, someone else who does know will build it and I will watch for however long it takes me to know (maybe years and numerous projects), then I will know how much cover to have, how much depth, and even the type of pipe to use for a particular section.

Read Vitruvius and you will see that what I describe has been the 'real' construction practice (outside classroom problem sets and industrial engineering day dreaming about what happens in the field) for at-least a couple thousand years and likely more - I have not seen anything in my experience on projects from $1 to $300M to suggest practices today are much different.

[granite07]

found the simplest answer to the original question:

with no selection in the model space the properties panel is global with general, 3D visualization, plot style, view, and misc subsections. In the misc subsection the annotation scale controls the on-screen text size, scaling the profile view text - just find one that looks right, for me it is 1/128" = 1'-0". Or if you think this is just annoying clutter on the screen and could care less about 'seeing' the data since it is all imported as text files and outputs to gps or quantities files anayways - scroll it down to something really small like 1:1.