OK, first things first. Don’t do this.
Or at least don’t do this unless you really need to and know what you’re doing. And if you decide to proceed, you are so on your own its not funny.
Ed: He’s not kidding. It’s not easy to convey the “Are you kidding me?” look in an e-mail, but Manchester managed to do it when Mark proposed this. JW
As you may know, NEZ data for Survey Points in the Survey database cannot be edited using the C3D UI. Control points can be edited, but not Survey Points. Well, this bugged me, so I set out to determine if might be some way to do this. This is what I discovered.
The Survey.sdb is really a MS Access file in disguise. By changing the extension from .sdb to .mdb (or right-clicking and choosing Open with…and selecting Access) you can open the database. This db contains many tables and other foreign looking stuff. Open the Point:Table and you’ll see a list of all your Sruvey Points. If you look at the Elevation column, you see that the elevations are in meters (regardless of your drawing units). You can enter new elevations (in meters) and then save and close the db. If you changed the extension, you’ll need to change it back to .sdb.
Back in C3D, open the Survey db and click on the Survey Point collection. Notice your points are edited! You’ll need to reinsert to show the edits in the drawing.
Be careful and Enjoy!
Â
Isn’t the survey database based on observations and not coordinates? This would create a discrepancy between the observation derived coordinate and edited one. This may also explain why you can’t (field grayed-out) edit the coordinates in Survey Toolspace stored in the .sdb file. The coordinates can be adjusted indirectly by editing the target/instrument heights/angles/distances and control point elevations. From a surveyor’s perspective, what you propose to do by changing the elevation is to say he got the field measurement wrong. If this is the case, the prudent thing to do is to determine the measurement error or re-shoot the point.
Andy makes some very valid points. From a technical POV, the measurements from which the shot were derived should be edited.
It seems that some (not necessarily Andy) want their cake and to eat it too: a protected, un-editable survey point database and the ability to easily edit the points without having to reimport an FBK file or modify measurements.
This post is much less of a _recommended_ practice and more of an attempt to provide end users with methods to do what they need/want to do.
Thanks for the great feedback.
MARK proposed it???? I was the one that sent that email!
Sheesh….a guy can’t get no respect around here 😉
But seriously, folks, James is right – the vibe I got was “sure, you CAN do that, but why on earth would you WANT to???” Kind of like “sure, you CAN scoop your eyeballs out with a spoon, but it’s not really a great idea”
OK, some clarification – it was mark who discovered it. I was merely along for the ride, and thought to pipe up and ask the Manchvegas team if it was a good idea.
And it’s not as bad as scooping your eyeballs out, but that’s the amount of shock that I seemed to receive in the email reply 😉
We find that, as surveyors, we strongly need the ability to graphically edit points.
Sometimes the field surveyor really DOES get it wrong. Breaklines may accidentally cross by a minimal amount, causing unwanted effects to the surface. Or whatever. Frequently, it is something that can easily be fixed in the office, without going out to the field and reshooting the point. There are times when reshooting the point is the only option, but frequently it requires another site visit, more field time, more delays, etc., all of which isn’t really necessary. So that leaves editing field measurements and reimporting FBKs, which is pretty nasty.
An optional ability to lock down the survey database makes sense, but the current setup is very troublesome. A real fix may require a complete readdressing of the whole idea of FBK import, but that’s probably necessary anyway. FBKs may have served the LDD community well enough for the last decade, but the shortcomings are very apparent in the dynamic, model-driven C3D paradigm.
Mark – what I really want is the cake, with ice cream and fruit sprinkles on top…
The ideal scenario for me would be similar to the Civil3D surface creation and editing routine, which allow me to create a surface using original data. After the surface is built I can make edits, add or remove data, and all of those commands are stored so that they can be repeated if necessary.
This would be similar to other survey processing software, which allows the user to store and edit a series of commands after the original field data is processed.
As a surveyor, the fact that the point cannot be directly editted without a lot of run-around is a major turn-off from using Civil3D.
FOr example, one of the things that we do quite often is start a job in an assumed system (5000,10000,100) and then later on move the drawing points into State Plane or NAVD88, or some other existing system. With Civil3d, I’ve found that to be incredibly difficult to do, to the point that I generally do it in AutoCAD 2005 and then import the drawing to Civil3d.
If there is a workaround to it, please let me know, but that loss of function alone(not being able to edit points easily) almost makes me want to switch to Carlson.