A colleague is running a job that requires them to use an agency's feature code library, but the field guy isn't sure how attributes are entered. Is that typically done from a drop-down list, or are they entered into the description with a delimiter?
The Descriptions fields are separate from Attributes - although I have heard some folks mix and match the terms, which can get confusing.
If the FXL is set up to actually use true attributes, the entry method depends on the attribute itself. For instance, we have dropdowns for tree types & sizes, a numeric-only field for junction box length/width, and an alphanumeric text entry field for LS numbers and stamped items on caps.
The critical piece is this: to get the attributes to pop up after each measurement, field staff do have to ensure that the "prompt for attributes" option is enabled when they set up their measurements screen:
If they don't, they can still enter the attributes, either before measuring or in the Point Manager....but it's a pain and I generally prefer it to pop up each time after I measure.
The field guy apparently only used the description field to code the points, and they've been bringing the points into TBC via CSV files, then processing the codes, then exporting shapefiles, but nothing is coming into C3D when they import the shapefiles. The attributes are missing, as the field guy wasn't aware of what was needed.
Short of reshooting 1500 points spread over about 10 miles of highway (!), what's the best way to massage the JXL or CSV to get the points properly coded with attributes?
Thanks for all the help! (And I'm glad it's not my project!)
they’ve been bringing the points into TBC via CSV files
😑
then processing the codes, then exporting shapefiles
🤨
nothing is coming into C3D when they import the shapefiles
🤔
the field guy wasn’t aware of what was needed
Now that part doesn't surprise me, but...damn that's a lot of work to do without reading project specifications first.
Short of reshooting 1500 points spread over about 10 miles of highway (!), what’s the best way to massage the JXL or CSV to get the points properly coded with attributes?
Honestly, from the workflow you're describing, someone on that team needs to do some basic Access and TBC training. There are a ton of tutorials, online training sessions, and power hours, all for free. At a minimum, understanding that post-processing requires importing raw data (rather than static CSV files) is about as basic as it gets (whether it's TBC or Infinity or whatever).
Attributes can be selected in TBC, even if it's just a CSV that was imported, but it's designed to take the raw JXL/JOB files. It'll take a little time, but far less than redoing the entire job. (Assuming, of course, that the attributes were recorded in the field notes or somewhere else so office staff can reliably pick them for each point.)
Thanks for all the help! (And I’m glad it’s not my project!)
No problem, and I would not want to deal with that either!
I see quite a few problem projects, and while this is pretty far out on the spectrum, it's still surprisingly common.
The attribute editing in TBC sounds like what they'll have to do. I'll pass that info along.
Thanks again for the insightful and useful assist!
There might be a way to finagle attributes to the code of civil3d points, but I don’t think it natively supports attributes like ORD does. But who is responsible fir the “field guy” who gave him direction to do 10 miles of locations with the right information?!
"But who is responsible fir the “field guy” who gave him direction to do 10 miles of locations with the right information?!"
The outfit is a former employer that still does a lot of things the way they did when I worked there, and I've been gone for 30 years. It's a high-volume shop that for most of its life made its money on construction staking and bundled ALTAs.
A few years ago they added a subsurface utility location subsidiary, and that's where this contract fits in. It's a Caltrans project, so they have to provide the data in a format that they're not accustomed to generating. As far as I know they've never used point attributes before (nor have I!), and there clearly wasn't enough communication between the higher-ups and the field guy (I'll call him Dan, because that's his name).
Dan is a very capable field surveyor, reliably able to take a job and run with it solo. He's the only one in that office that I trust to work on my projects. Unfortunately, he was thrown into this one without adequate preparation. He did a great job establishing the control (which, per contract, required calibrating to legacy control), and I'm sure his location/topo data is solid, but he used his own customary descriptors and no attributes, so all of that has to be altered after the fact.
It's a live-and-learn situation for them. But I reckon they'll still make money on it.
