No more funky looking curves in your drawing, no more visually scanning out in the field trying to identify the PC and the PT.
Are the funky-looking curves you refer to shaped like incandescent light bulbs, such as a curve at the end of a concrete median? Visually scanning for PCs and PTs is a pain, and can be subjective unless you're lucky enough to find a joint where the curbing was poured.
?ÿ
?ÿ
I found the key is to always have sets of 3 point curves, and bull noses never work, you need to put a PC/PT on the point of that nose. Sure, more points, but faster than figuring it out later. Always think in terms of 3 point curves, never 4 points on a curve and expect the software to figure it out, and always evenly space the points on the curve. If you evenly space them, and only do three points, it essentially eliminates this problem. 100% of the time, if you need 4 points, it really needs 5 (middle point being the PCC point)
?ÿ
---------------------------------------------
Another interesting anomaly occurred as I was testing some codes when importing. I wanted to see what happens with all my codes and their displayed point descriptions when I would write down a bunch of made up observations after the initial code. Just as a test I had the codes "bol leaning badly" (bol = bollard) and "up leaning" (up = utility pole). These codes ended up making a survey figure as it pinged on the "le" which I have as a code for Landscape Edging.
---------------------------------------------
I have a feeling I may need to more carefully go through my Figure Prefix Database and watch my wild cards and maybe include a space after a bunch of the prefix names? Use of the # as a wildcard? I guess I just found out you can put wildcards here?
Thought I would try to reach out to you before I do this as my Figure Prefix Database Manager runs exxxxtreeemly slow.
An easy solution to this is to put an "_" (underscore) or some other symbol at the beginning and instead of spaces in between words:?ÿ
BOL _LEANING_BADLY
UP _LEANING
this isnt a bug it is a feature...you can do as many line codes together as you like, which is really helpful when you create a surface and have multiple breaklines intersect. You do not want crossing breaklines, so you either have to be careful to fall short of the intersection with each shot, or you put multiple codes on the same point
TOP BRK TOE would have all of those line and surface breakline codes end at the same point.
?ÿ
?ÿ
It should not create a line just by adding a number without first entering in the line command.?ÿ?ÿIf you start a parking space line when you are shooting them in, do you end that line??ÿ if not, that is why it is connecting all of them.?ÿ Make sure to add an end code to stop the current line.?ÿ?ÿ
If you want to add notes to a point, use the Field Code Escape.?ÿ I think the default is a frontslash "/"?ÿ?ÿ
BOL _LEANING_BADLY would become BOL /LEANING BADLY/?ÿ ?ÿAnything inside the escape characters will be ignored.
The figure prefix database editor can be really slow, especially when creating files.?ÿ Fortunately, the file is a simple text file.?ÿ It is called ____.fdb_xdef.?ÿ Fill in the blank with the name you see in the survey toolspace tab.?ÿ Mine is KHA.f2f_xdef?ÿ Make a backup copy first!?ÿ The file is located at C:ProgramDataAutodeskC3D 2020enuSurvey
The file can be edited with other software and is in xml format.?ÿ I use notepad++ to open, format and edit it.
?ÿ ?ÿ ?ÿEach line in the editor looks like this:
?ÿ <Record>
I??ve set up these civil 3D databases for a few companies based on individual feature libraries and layering standards, if you haven??t resolved this already, I??d certainly take a look at your data for you a little more in depth.?ÿ
