August 29, 2010
Posted by Brian Hailey under Civil3D
| Tags: Civil 3D
So, Almas over at Being Civil wrote about how to get a property line label to look correctly. You can read it HERE. He had two solutions, the first was to use a code that would combine the P and the L together to form the property line symbol, the second is to simply toggle on the Flip Anchors with Text option in the style.
In the situation he had, either of those solutions would work just fine but, what about this situation? 1) I don’t want to use letters that have a predefined code for them and 2) I want to adjust the label so that the entire thing is centered on the line, not just one of the letters. In this example, I have a Water Line and a Sewer Line label and I want them to look something like:
In this case I created a label with two text components, a “W” and an “L” (for Water Line). I attach the bottom center of the “W” to the label location and then add a negative Y adjustment so the line is passing through the bottom of the “W”. I then attach the top left of the “L” to the middle center of the “W” and everything looks good, that is until the label flips to be plan readable, hence the point of Almas’ post.
Again, if you haven’t done so, go to Being Civil and read it. This post will make much more sense if you do!
Now if I follow along and do as Almas recommends and toggle on the Flip Anchors option in the style, this is what happens:
It’s close, REALLY close but just not quite right. The problem is, even though the anchors flipped when the text did, the adjustment I made to the “W” component was relative to the line! In the left label, it adjusts above the line and in the right label, it adjusts below the line. So, what to do? (To learn more about what Flipping Anchors does, read one of my previous posts HERE.)
Well, it really isn’t all that hard, you just have to think outside the box a bit. Have you ever noticed when creating label styles that you can toggle on and off the visiblility of different components? Well, we are going to use that to our advantage. Add a new text component, a placement component, to the label and attach it middle center to the label point (I didn’t even bother changing the “Label Text” default) and change the visibility option to False. Now, attach the first component (the “W” in this case) to that placement component. Now, when the label flips to be plan readable, the placement text flips and the “W” adjusts relative to this instead of the line!
In the top portion of the following image, you can see the results of this label style. In the bottom portion, I’ve turned the visibility of the placement text on (and made it green) as well as adding in a pink direction arrow so you can see the lines are running in opposite directions.
Hopefully this makes sense to everyone. If you have questions, leave comments on this post and I’ll answer them as I can.
August 26, 2010
Have you ever brought a Google Earth surface into your Civil 3D drawing and it comes in at the wrong elevation? Now, I’m not tallking off by 50′ (well maybe if you’re in Florida) but drastically off. I did a test and in Google Earth, I zoomed in on Longs Peak, one of the 14,000′ mountains visible from my house. In C3D, I set an appropriate coordinate system, import the surface, and everything works. Here’s a screenshot of the surface properties:
However, in two other drawings, using the exact same coordinate systems, the elevations are drastically different:
Now, what on earth could be causing such a drastic change in the elevations? It’s almost like the elevations on the left are being scaled by the conversion factor from feet to meters and on the right the conversion factor from feet to inches, and that’s exactly what is happening. It’s using the drawing units, the AutoCAD drawing units, to scale the Google Earth surface elevations (which units are in meters) as it brings it into the drawing.
In the above image, the left surface was brought into the drawing with units set to unitless (INSUNITS=0) so the elevations are set to meters, since that’s the units Google Earth uses. On the right, the drawing units are set to inches (INSUNITS=1), so that’s how many inches high Longs Peak is. If you are working in an imperial drawing, i.e., your Civil 3D units are set to feet, then you must have the AutoCAD drawing units also set to feet (INSUNITS=2). If you are working in a metric drawing, i.e. your Civil 3D units are set to meters, then you must have the AutoCAD drawing units set to meters (INSUNITS= 6).
Thanks Jeff for letting me know about this one!
August 22, 2010
Posted by Brian Hailey under Civil3D
| Tags: Bug
, Civil 3D
Looks like I discovered a bug in C3D 2011. When you create a table style set up a specific way the sorting does not work. In order to see this issue, create a table style that:
1) Sorts on a specific column
2) The data of that column is formatted to use the new digit grouping (the comma in 1,000 is an example of digit grouping), and
3) The data spans more than one group (i.e. 700 – 1,300)
In this example, I’ve created a line table from a series of polyline labels. The table style is not set to sort and so it places the labels in the table in the order they were created:
For this example, I’m going to sort by the length of the lines. For whatever reason, that is the important piece of data for this table. After editing the style, the table sorts just as expected:
Now, if I change the data format for the length of the lines to add the new digit grouping, you’ll see the table no longer sorts correctly.
Now, I haven’t been able to confirm this but, it seems that the sorting process isn’t looking at the value of the entire number for the sorting purposes but rather the very first group. That’s why it thinks 1,000 is less then 900; it sees 1 as less then 900.
Unfortunately, at this point, I really don’t know of a viable workaround other then to not set the numbers to group the digits. If anyone can think of a workaround, I would love to hear it.