?ÿ
Yes I know most here are not fans of C3D for surveying purposes but it's paid for and what I'm used to using for almost the last decade so for now I will have to make do as I have other expenses I'm dealing with besides buying additional software. I will admit at my last place of employment they had a very robust survey database (probably close to 300+ point descriptions & linework codes) and for the most part it worked every time so long as the coding was done correctly. But I digress...
?ÿ
I've setup a very simple and basic survey database to start off with that has simple point descriptions (each associate with a point & label style) and survey figure prefix coding (for linework with their own styles). However, what I am noticing is that when I code say the same edge of pavement (EOP) description for multiple lines of the same description type in a practice file, those lines want to link together even those some points were labeled EOP1 and other labeled EOP2. And I also can't get linework for curves to even generate at all. I do remember this was a problem at my last place of employment (a ~25person civil/survey firm) where they had issues when they implemented the new C3D survey database coding methods and it took several months to get all of the field crews on the same page and coding features for linework correctly. However, I wasn't a part of the database creation process nor the coding situation/learning curve in the field - I just dealt with the data import events. And before somebody says it, yes I have searched and read through multiple articles, threads here & videos elsewhere but I can't seem to figure out what I'm doing wrong - spent almost 2 hours doing this over the past couple evenings.
?ÿ
That being said - can somebody who's familiar with the coding requirements take a look at the attached image where I have added my code descriptions for survey figure prefixes and let me know how I should code the following:
- say I have strip pavement for a road and I want to pick up each edge of pavement at ~ 25' intervals as EOP1 on the left and EOP2 on the right (for now I'll neglect crown/CL as linework until I can master just this). How would I start the linework to tie together in ascending point order while only walking the road once and keeping the linework for the survey figures from zig zagging back & forth at each 25' interval? Also how would I stop the linework for a particular linear feature? my practice code text file didn't import appropriately
- say I'm picking up back of curb (coded as BC) at a radius and I want to pickup the PC, PT and roughly the mid point on the curve to give Civil 3D an idea of the radius - how should I code the beginning of curve, the point on the curve that helps define it's radius & the end of curve/point of tangency??ÿ
You have the code for back of curb "BC", and the "Special Code" for starting a curve also "BC".?ÿ That's bound to be a problem.?ÿ
In my coding system back of curb is "TBC" and I use "PC" to start a curve, and "PT" to end it. So the point coding of a string of points would go like this:
TBC B?ÿ ?ÿ ?ÿ(beginning the line)
TBC
TBC
TBC PC?ÿ (beginning the curve)
TBC
TBC?ÿ ?ÿ ?ÿ (any number of points on the curve)
TBC
TBC PT?ÿ (end the curve)
TBC
TBC
TBC E (ending the line)
?ÿ
For the record, C3d is poor survey software, but fine mapping software.
?ÿ
?ÿ
?ÿ?ÿ
I don't see anything in the data you posted that jumps out at me as being wrong.?ÿ It's mostly setup like ours.
A few things to look review:
- Do you have an EOP code?
- Is your format column in the description key set set to $*
- I assume your starting a new set of linework each time: such as EOP1 B and EOP2 B
TBC B (beginning the line)
TBC
TBC
TBC PC (beginning the curve)
TBC
TBC (any number of points on the curve)
TBC
TBC PT (end the curve)
TBC
TBC
TBC E (ending the line)
This is exactly how I have done it too.?ÿ I have never tried setting up the codes though so I have no idea how that part of it works.
Been mulling this one all morning, and the only thing I can think of (in addition to the other replies above) is the setting for "process linework sequence".
Should be set to "by point number" rather than "import order":
If set to import order, and the points being imported are not sorted by number, it can result in a big mess of string connections.
?ÿ
?ÿ
Like others, nothing is jumping out at me as being wrong. Hate to say this, but since I've never seen a problem with two separate lines connecting, there's got to be operator error somewhere in your process. It's happened to all of us.
There are a couple of things I will address. First, I don't think you have to apologize for using Civil 3D. There are lots of darn good surveyors on this site who use it. I've used it (not that I'm a darn good surveyor) and Carlson, and I would take Civil 3D any day of the week. For me, Civil 3D is a marketable skill.
Second, I know I would be in the minority (maybe alone on an island), but for curves, I advocate not trying to pick up the PC and the PT. If you are making a survey figure for an EOP, and you skip directly to a point on the curve, and start picking up the line out of the curve, it will draw a tangent arc to the lines coming in and going out. No more funky looking curves in your drawing, no more visually scanning out in the field trying to identify the PC and the PT.
Guys - thanks for all of this! Apologies as I just got in from the field earlier just before dark and had some emails to shoot off after dinner so I'm going to try to look over all of these comments & see if I can adjust my coding & procedure appropriately in order to get the linework generating correctly. again thank you to all that responded!
One other thing I remembered that might be a possible explanation for the curve issue.
Sometimes a curb might only be built through the return when it turns down a street that hasn't been designed yet.?ÿ If you're going along shooting the TBC and your last point in the string is the PT then it might not draw correctly.?ÿ In a situation like this I'd stop 0.1' before the end of the curb and call that the PT and then take another shot at the very end and code that TBC E.
If none of your curves are drawing though then clearly something else is going on.
As far as the linework coding, this is the appropriate order of input:
Code LineworkCommand GeometryCommand FurtherDescription
?ÿ
For example (and these linework code sets may be different than yours, they can easily be set to whatever you want)
?ÿ
TBC B PC RECESSED
or?ÿTBC E PT CL HC RAMP
?ÿ
To shoot a 3 point curve:?ÿ
TBC PC, TBC, TBC (the 3 point is assumed)
To shoot a curve with over 3 points, or any combination of compound and reverse curves, use PC on 1st shot but add PT for the final shot.
Finally, my favorite (that I can never convince anybody to use in the field, I work in the office) is the ??on curve? command. You don??t even need to hit the PC or PT, as long as you have 2 shots on each tangent in and out defining the bearing. Just take a TBC OC (again your code set may differ) and it will fillet the two tangents with a radius dependent on where you took your shot on the curve. It makes for perfect linework especially on the hot dog islands that have a mushroom head 80% of the time
?ÿ
That's what I do also. Except that I make the PT shot maybe a foot from the end. If you only do 0.1', and the rod isn't perfect plumb for both shots, you may form some crazy tangent out that fouls up the curve creation.
??on curve? command
?ÿ
I wonder if Carlson has a similar feature?
yes.?ÿ this truth I have suffered a few times.?ÿ
One thing the team i joined had done over several years was to establish the Figure Prefix and Point description sets and then tie them to the output fromTBC (the application not the curb?ÿ 😉 ).
We open a Debug survey database to import points then do QA/QC against them to see what and where they fall based upon the predetermined definitions.
If a point fails the Point Description, its sent to the Points Layer in Magenta, magenta is a warning to look further, and see why it didnt get imported and processed.
Same thing for The Figure prefixes, if the linework doesnt process, or processes bizarre short circuits, the file gets cleaned up and then reimported and then saved and imported into the Final Survey DB, which is created for each new major project so we keep eveything constantly under wraps, and never import new data through that DB, just add or modify individual points/mtext/multileaders etc.etc.etc....
The workflows take time, Im glad I didnt have to spend those months, or even years to figure it out.?ÿ?ÿ The Coding to desc also gets muddier still when you start to consider the overridden layers/style etc etc etc.....
KISS almost works, but the big picture is here, always look outside your viewpoint, the answer you're not seeing right in front of you might be someones balliwick
?ÿ
this site has been a HUGE mental gain for me.
?ÿ
btw, when i saw that screen shot of the V-Nodes....Layer....i about sH!t myself, that could easily send our layers in the 1500 ranges...... yikes.
Okay, I guess I'm not alone on that island after all. Another survivor from the Minnow.
Why not just import a dxf from your data collector? The linework should be edited in the field as it's collected.?ÿ Even when working correctly, C3D line generation will take more time and provide a generally lower quality than Access or SurvCE.?ÿ You don't need new software, you just need to stop trying to force a square peg in a round hole.
