Civil3D 2011 - Overwriting/Modifying Control Point

[Anonymous]

FIrst time poster, long time lurker ...

We have been processing/adjusting our field control observations in an outside program (Star-net) and then importing the control into our C3D Database through an import event (PNEZD File). Once the control has been imported we import our field data (.fbk file) through an import event as well. The problem that we are having is once you process a .fbk that uses one of those control points it "locks" the control point, so the next day when we get another field download and the control is re-adjusted, we can't update the control points in the C3D Database.

The only way we have found to get our newly adjust control into the C3D Database is too delete all of the "import events" that use the control point and then import our new control. This is a HUGE hassle.

Any help would be appreciated.

Thanks,

Dan

[Sinc]

I think the scary part is that your control is being re-adjusted with every daily import... 

Your control points shouldn't be floating like that.

[Anonymous]

So you would take the first observation to a control point as gospel? What if they start a traverse on one day and finish it the next? What if you run a bench level through the control points and want to adjust the elvevations to the new values? These points have to be able to move.

~Dan

[rl_jackson]

Are you using GPS for Control Points only, and then doing standard cadastral for the rest?

After review of the Star-net software, not even sure that's needed. C3D will do that for Cadastral

[stacy.dunn]

Which version are you using?  In 2011, I have no problem editing control points after importing other data that uses them.

As far as field methods go, I have found that it almost always works out better in the long run to perform all of your control work (horizontal and vertical) first and then shoot topo.  You will have to move around the site multiple times, but there are far fewer problems with data integrity.

[Anonymous]

If I read what you are doing correctly, the crew is picking up topo as they are running in the control.  If that is the case you do not process the topo until they have all of the control run in and adjusted.  Then import your topo one time from the adjusted points.

[Anonymous]

@blt

Yeah, it looks like that's what we will have to start doing. Thanks everybody for your input!

~Dan

[AllenJessup]

---

@Anonymous wrote:

As far as field methods go, I have found that it almost always works out better in the long run to perform all of your control work (horizontal and vertical) first and then shoot topo.  You will have to move around the site multiple times, but there are far fewer problems with data integrity.

---

I know that's a procedural thing and doesn't bear directly on the question about the software. But I agree that the Control work should be settled first. Before importing any Topo.

Allen

[Sinc]

I third that motion.

[Anonymous]

I agree with everyone who says that the control should be finalised before topo survey begins (for jobs with more than one network), but I also agree with Dan because in the real world this is not always practical.

For example we have various sites which are part of a larger project to survey over a large area and it is urgent. We only have a total station availiable this week and there is no local control. So we go out and survey each of the sites with an assumed datum. We import the data into Civil3D and process the points and linework. The next week the GPS gear is availiable to bring in control to each site.

We should then be able to add the control point file to the Civil3D database and have the total station networks adjust to it. But when I bring in the control file it strips the point number and gives it a name of the point number with a '0.1' suffix. Instead of an option to overwrite.

We need more options for resolving duplicate points in the survey database.

Cheers