SurvCE vs. Microsurvey Field Genius

I have used both.

Your frustration may stem more from user issues than choice of software.

If I have followed correctly you have had a couple field blunders which you tried to fix after the fact in the office, a tricky proposition for a novice user. I would focus on aligning your field and office software and adopting a working field data protocol rather than going with a new field soft.

party chef, post: 326980, member: 98 wrote: I have used both.

Your frustration may stem more from user issues than choice of software.

If I have followed correctly you have had a couple field blunders which you tried to fix after the fact in the office, a tricky proposition for a novice user. I would focus on aligning your field and office software and adopting a working field data protocol rather than going with a new field soft.

You've hit the nail on the head, in one respect: "a working field data protocol"...Ya, easier said than done. I've asked for advice on that, and it's all over the map. Everyone here does it differently, and it seems the bulk of folks are using GPS rather than total stations. It's just not something you're likely to learn "in school", either, (which for all intents and purposes, I am).

Today, I re-surveyed the original blunder, only to find that I did NOT carry the first point that I set up on (the last known good point) in the control file for the survey. As a result, SurvCE asked me to calculate the coordinates for that point. But when the raw file got back into the survey in the office, it was "floating in space". When I setup the DC, it asked me for the Back-sight point, which WAS in the control file, so I have no idea why the .rw5 came in so screwed up, but it's probably because it had no azimuth data. (I tried this time to use 0 for the back-sights, rather than carry azimuth...so much for that idea). I'm sure most surveyors who know what they're doing (or who have field crews who do), don't spend much time editing raw data.

Just not too sure how to crack this ongoing challenge. Thanks for the keen observation though.

I have both and find Field Genius easier to use but probably lot of that comes from many years use versus little of SurveCE.
Microsurvey make a point of its ease of use and being "idiot proof".
I wouldn't go that far but has merit (statement). Probably explains though why SurveCE is more powerful and feature superior but which needs more knowledge of the application etc.

Good field practice is essential and certainly won't be overcome by any software as you'd appreciate.

Have a look at FG, download and install and give it a try.
If you're struggling with your methods, outcomes or all then I'd run a simple test traverse and write down target and instrument heights with point numbers along with station setups.
I still do that (record station details) in a field book and it has saved my bacon more than once.
As for field practise. Does your TS take uploading of bearings?
Mine doesn't (Nikon), and I just set zero on TS as back sight.
I could well imagine if it does accept uploading bearings that could be an area for fouling up.
I also observe my back sight at times as a point, mainly as it's easier to retrieve data the way I want it from the software later.
I check back sights regularly as things can shift orientation without realising.

Keep asking, you'll get there.

Richard, post: 327110, member: 833 wrote: I have both and find Field Genius easier to use but probably lot of that comes from many years use versus little of SurveCE.

If you're struggling with your methods, outcomes or all then I'd run a simple test traverse and write down target and instrument heights with point numbers along with station setups.
I still do that (record station details) in a field book and it has saved my bacon more than once.
As for field practise. Does your TS take uploading of bearings?
Mine doesn't (Nikon), and I just set zero on TS as back sight.
I could well imagine if it does accept uploading bearings that could be an area for fouling up.
I also observe my back sight at times as a point, mainly as it's easier to retrieve data the way I want it from the software later.
I check back sights regularly as things can shift orientation without realising.

Keep asking, you'll get there.

The Topcon TS I'm using can set the back sight azimuth if the DC tells it to. I ran previous sessions that way, but, (as some here pointed out), it's much harder to immediately detect blunders when you flip the scope (0-0-13 on the back sight Direct, then 180-0-11 or whatever in reverse). The set report in SurveCE also gives you this information though. I've really had great results using the field book and pencil; if using a DC is useless without the field book, then maybe I'll just dump the DC, lol.

I think the largest contributor to this problem is the procedure I'm using to go back and forth from office to field and back again. Previous advice had me open a new job in SurvCE daily, so that I had a "clean" independent file for each day's work. But bringing my adjusted survey back into the DC as a "control file" has been problematic (to wit: the current problem of the point I set up on not being in the file). Continuing the same job (on another day, or a week later), would allow one to just pick up where they left off and keep going. That's the way I did it when I made my first major blunder; (set up on a point other than the one I was actually on!)

As Spledeus said in another thread: "Editing the .rw5 file is an essential skill". I've taken that to heart and dug in on it, but am realizing that the more you start messing with "raw data", the more likely the possibility of introducing another source of error. I think I'm going to have to learn to do it though.

I found a great Carlson document on the subject:( http://files.carlsonsw.com/mirror/manuals/Carlson_2015/source/Survey/Survey/EditProcess_Raw_Data_File/EditProcess_Raw_Data_File.htm ), although it discusses it in the context of what I assume is Carlson office software. Still a lot of information there though.

Thanks for the support.:-)

In Carlson desktop can you lock points?
Ie the control you use or establish after fieldwork can be locked which then enables a rerun of the raw data against your locked, fixed control.
That's what I do in MicroSurvey.
If you edit the raw data then points can be adjusted per the editing by the software.
I think I said elsewhere, I keep one DC file (normally and edit the days field work to just include the work not processed and run that through my desktop.
But make backups of each days work (PC).
I also backup before each major data addition, adjustment. Microsurvey makes that dead easy, along with a note for comments.

I would strongly discourage the use of Azimuths when working with a data collector. Not to least of the reasons is the fact that is that the programmers do not really expect you to run azimuths so the software is slanted to angle-right angular measurement, even though there are multiple ways of accounting for the turned angles. Plus, the data collector software normally provides the Back-azimuth in the information that it supplies about your current setup.

I would also discourage starting a new file for each day's fieldwork. If nothing else, that leaves you with the task of assembling the various days' data files into a coherent statement of the entire survey and opens the way for more blunders. If the practice of a new file for each day's field work is for data security and integrity, simply download the associated files at the end of each day's work. But continue in the same file the next day. That way, when you are done with the field work everything is in one file all together. But you still have accounted for the project on a day by day basis.

JerryS, post: 327239, member: 205 wrote: I would strongly discourage the use of Azimuths when working with a data collector. Not to least of the reasons is the fact that is that the programmers do not really expect you to run azimuths so the software is slanted to angle-right angular measurement, even though there are multiple ways of accounting for the turned angles. Plus, the data collector software normally provides the Back-azimuth in the information that it supplies about your current setup.

I would also discourage starting a new file for each day's fieldwork. If nothing else, that leaves you with the task of assembling the various days' data files into a coherent statement of the entire survey and opens the way for more blunders. If the practice of a new file for each day's field work is for data security and integrity, simply download the associated files at the end of each day's work. But continue in the same file the next day. That way, when you are done with the field work everything is in one file all together. But you still have accounted for the project on a day by day basis.

Thank you, Sir. That is the most articulate explanation of the reasons NOT to do what I've been doing I've come across yet. Doing either (carrying azimuths, and starting new files each day on the same survey), increases the likelihood for blunders...especially for one not trained to pick them up immediately. Doing BOTH together increases the likelihood by the square of the sum of the individual likelihoods. I looked that up.:-D

I'm not sure I can "lock" previous points in the DC so they can't be changed in the field (by accident for example), but I know I can move them to the control file for reference if something goes wrong. Thanks very much for the advice.

rfc, post: 327121, member: 8882 wrote: the more you start messing with "raw data", the more likely the possibility of introducing another source of error.

It's a rare field day when I don't enter something in the DC incorrectly. I always start the day by entering the date as a note, and once back in the office I append the day's raw data to the RWB (raw data backup) file I maintain for all but the smallest jobs. After editing my goofs in the RWB, I use it to generate a Star*Net input file, and append the day's Star*Net data to the master DAT file for the job.

P.S. I wouldn't dream of starting a new DC file every day. If one day's mistakes are likely to cause trouble later - like when a control point gets positioned incorrectly - I fix the problem in the office, generate a corrected coordinate file, and upload it to the DC before returning to the field. But most of the time my goofs involve sideshots that I'm unlikely to need again in the field, so I just fix them for use in the office and don't bother fixing them in the DC.

Here are some things that some people do.

Take a check shot on the BS as the first and last shot of a set-up.

Always shoot a check a third known point before mapping or staking, one variant on this is to stake out the last topo shot and shoot it as check for the first topo shot of a set up.

Record all control angles and slope distance in the book.

Measure up at the end of a set up as a check.

Book that they have checked level at the end of a set-up.

Run the entire control traverse before starting the mapping.

Run a consistent low rod and bump up pretty high to a consistent high rod, when appropriate to attempt to avoid confusion.

Book the rod changes.

It does not really matter what tools you are using, in some ways it does not really matter what protocol you are using but you need to have one and also a understanding of what and why.

I do not do most of these things, but I have at some point or another.

One thing I do do is strive to do things the same way every time and develop a kind of muscle memory for my assorted tasks.

In regards to file management, I like the one big file approach also, but it does not work for some applications. I have been the same job, daily, for over a year and a half now, and it would cause more problems than it would solve. There are other considerations depending on how data is imported as well.

I've been thinking about this tonight. It's not the software. It's common practices of keeping things simple. First off is keep tract of traverse or control points. Write the point number on the flagging attached to the nail, hub, spike, or what ever you're using. Setup on a point and look down. Ask the rodman what is the point number are you giving the backsight on? Key it in the DC. Big key point! Shoot, check, and record the backsight. Download point data, and raw data everyday. Give it a birth date when saving the files. I can tell you, and show you where I was on any given day for the last 20 years. I bet my traverse points still have numbers on them. Find 2 and I'll find every shot I took on the project. Keep it simple.

Master say, "NO software is worth a damn if you do not know how to use it."
PEBCAK happens.