Another Trimble Access Question

If you have a feature code library Access is going to try really hard to process the codes and generate linework.

And you are correct in thinking there is no way just to process just a range of point names

One solution might in that linked files are not processed.

Maybe you could save the linework for each guy as a separate dxf, link that plus the job file back into a new job.

Add what linework you need to tie the two parts together and save that as third dxf.

Then combine all 5 parts, either in Access, TBC or CAD.

Maybe.

Yeah so it can be handled a different way. Say crew A has point range they also need sting range so ep - ep9 B team ep10-ep20. Etc. . Where they are going to connect up to next crew B. I paint that number on ground or a pin flag if i am there first. So they B can use the Joint to point command. So when it all gets together it forces it to connect. So strings on line codes is another way or they will need to end them. Which ending can cause its own delima if it actually needs to connect.i just did this last two days. I was running r12i he s5. So as top of banks were getting close one of us used the join to point command. At end of code so i ran top1. He ran as top2. We did even and odd string. He simply gets close to tying into me top2 jp 1000. When i bring that into tbc bam they connect. No lines shooting across the site. Just add the strings. I only end something if it truly ends. So a creek that ends and fades into say a pasture . I do use close command as well for things like bldgs edge of water other stuff as well. So are u processing everything in Trimble access or TBC

I think ending the codes will solve the problem but was curious if there was maybe a setting or something that could also work.

Anyway, yeah we run the .job through TBC before drafting everything in Civil 3D.

This issue comes up occasionally but not to the extent that you mention. We also do not end line codes but that would work.

If the point ranges are split up like your example, beginning/starting the lines in each point range helps keep the project clean and orderly. For example, curb line shots in the 10,000 range will not connect to those in the 20,000 range if the first curb shot in the 20,000's starts the line. Once this became consistent with our coding, it pretty much took care of the problem.

I'm curious how the jobs are being combined - are the points being copied between jobs rather than linking? Access and TBC are good about not crossing up linework between different jobs, but once points are combined in a single job database there's not much that can be done about it; Access is going to treat those points as local and draw the linework.

We try really hard to not ever copy topo between jobs, because that can cause headaches during post-processing. That can cause double points coming in, one set with observations, one set that are just grid coordinates. If an adjustment is not being run, those detached grid coordinates will hold over the observations, which means that if the original file with the observations was modified in any way that would shift the coordinates, that change would not be reflected in TBC until an adjustment is run.

A few options that I can think of, pretty much what others are recommending:

-just link the points from the other job, don't import or copy them.

-if you want linework from the other job, export a DXF from that job, then link it back to the current one along with the linked CSV point file.

-if you want to not have to worry about any of that, do what @OleManRiver suggests and number linestrings, but assign ranges to crews.

My SOP for a long time is to use neither begin nor end codes, but just jump up to the next line code number for the next string. If multiple crews are on the same site, assign ranges. Then no matter how the data are combined, everything will fall into place. I find numbering linestrings makes it easier if I have to modify (fix) things in the field.

We run this exact scenario often. Many of our projects have 2 field staff completing topo at the same time. We don't use the linework functions within TBC so all we see are points in TBC, its perfect. Then we export them all to Civil3d for processing. Works flawlessly.

Use alpha numeric point names. I have the crews use their initials as a prefix. John Doe would be JD1000. Dudley Doright would be DD1000 etc.

So the normal workflow is 1 guy drags his job into TBC and does the relevant scaling and then we simply drag the jobs from guy 2 and guy 3 into that .vce so everything is combined and adjusted. When we export points from here and run them through the survey database in CAD everything looks fine because CAD looks at point numbers when processing linework-- which is apparently not something Access does (or at least not strictly) because when we go back into the .vce and export a new .job file which contains everyone's points and put those .job files on the collectors we end up with a nest of linework on the screen.

Now just yesterday we returned to a site where we had 3 guys shooting stuff earlier this summer so we had 3 point ranges of topo. What we did to try to avoid this problem was export a .dxf of the linework from CAD and then turn off polylines in Access. This generally worked except now we couldn't see the fresh linework we were shooting because polylines were turned off...

Anyway, linking various files is a fine solution but it seems like it shouldn't be this complicated. Is there some reason Access can't simply look for starts in linestrings and then go down consecutive points to the point before the next start? I mean I'm not a programmer but this doesn't seem like rocket sorcery.

Bstrand,We create a project template file for every project. That way you don't need to continually export job files. We never export job files, we export csv files only and reference them into our jobs as needed. We just did this exact scenario this AM. We need additional topo so the party chief exported all of the topo points (thousands) in csv format to ensure no overlap. I'm not sure what is causing all of the points, in an instance like this, to re-process in access.

That makes sense. I've never worked so exclusively with .job files before as I have at this place, but the vast majority of our projects are small enough that's it's somewhat uncommon to visit the site more than once or twice, so working with .job files isn't typically a burden.

I know I've referenced point files in the past but I can't remember if Access drew linework from those points? If I reference point files and all it does it put a bunch of dots on the screen then I don't think that will be very helpful.

Referenced point files do not draw linework - that's why having a dxf also is helpful.

Interesting, it works great for us because we often expand our topo area and need to ensure we don't overlap existing data. That's our primary use. We never use DXFs, haven't ever found an efficient use for them with our workflow.

If its when you return to site and just want them to know what they have already located or a different crew I simply export a dxf or even a dwg access can handle that easily. They link to it . I will sometimes keep the text or add some text. For say where they need to continue or tie in. So i might say the two esge of roads point numbers. Etc. So they start the new line as well as a Join to point number. Not that big of a deal if it doesn’t as i will simply add to the code in TBC and just hit the res button and that works. Just don’t use the color yellow for the field. It is no clearly seen in the field on the data collector unless they choose monochrome. I export from TBC they build there own daily job files. So a bit different work flow. What is good about the dxf or dwg linked is they can just use it as a background map or make it active so they can stake to it if needed. I had printed off a sketch and asked that they look for a iron about so many feet down the curb line. They staked it out and offset . I could have computed a point but they basically did themselves. Why even go to cad is my question. You have everything adjusted linework done set up your labels and bring in symbols or add them to fdm or blocks. Plan set and you are done. It takes a little time but whatever dwt you have in cad you can bring that into a blank tbc project and get it all situated like you want all the extra notes I created a extra planset for all my legends notes so i can simply copy from one to my custom sheet and plot off or print to bluebeam. A lot of times i will finish the rough linework add extra notes to certain areas for the ls to have when doing boundary resolution and export a dwg. He would bring that into civil 3d. Se my notes like neighbor said this stump was on an old fence line and fence removed for row crops etc. so basically adding field notes where needed to the dwg once he is finished I simply bring back to tbc for computing the corners and doing the map cks before crew sets new corner . The map ck or cogo function is pretty nice in tbc as i can print or save it in a word doc report or excell pdf etc. i have one ls that sends me several at a time for a large project all boundary work. I run them save the report he can quickly see the issue when its fixed i ck again. He has different people in different state and little things like total distance on a line the short distance doesn’t add up exactly or area acreage is wrong usually copied text from a different one not added up. Or bearing reversed I usually point that out and fix and it’s simple stuff. But when client calls him he grabs his pdf bluebeam and my report which shows a sketch and is labeled and can check as well.

Are you doing mostly like lot surveys or altas. Heck other than adjustments and qa/qc you could simply export the linework straight from access. If all was good. I have only used a job file to send to crew’s when it was a strange project like someone had a scale factor and not enough metadata for me to know where. So i would set that up in tbc from a few different ways send them for simply testing to aid in finding the control from some other client. Sometimes i guess correctly and dont have to reverse engineer there stuff. Some use excell and use combine factor x’s the northing and easting which is a mess sometimes.