Discussion of FieldGenius related issues and questions.

Moderators: Brian Sloman, Jason Poitras, James Johnston

Post Reply
Posts: 5
Joined: Fri Nov 11, 2005 5:15 am
Location: Ulverstone, Tasmania, Australia


Post by glennd2 » Tue Jul 29, 2008 11:19 pm

I strongly believe that Field Genius should have the ability to record time stamps on every measurement taken in the field.
Nikon's AP700 field software has had this capability for 15years! (AP700 like FG formats to TDS).
TDS Survey Pro software has the ability to add a time stamp to raw data when required by the operator not automatically like AP700.
Time stamps on raw data should be compulsory! They are a very useful management and costing tool acting as a field diary for legal traceabilty.
The stamps in FG are created each time the project is accessed and do not differentiate between field and office.
I have struggled with this issue for several years now and suggest that a time stamp option similar to AP700 should be added to the next version of FG or sooner by patch.
How do other users feel about this matter?
Kind regards

Glen Cameron
Posts: 1395
Joined: Fri Nov 08, 2002 12:18 pm
Location: Corbeil, Ontario, Canada

Post by Glen Cameron » Wed Jul 30, 2008 4:58 am

The date and time stamp is actually recorded in the DBF file when each shot is recorded. This file can be opened in Excel to examine or print from.

Example shot from this file (field widths not shown in this viewer)(first line is the header, second is a shot):


3 10000.000000 10000.000000 100.000000 PKSET 1 1 2007-02-10T11:32:33 0 0

So the date and time portion is:
Glen W. Cameron, C.E.T.
City of North Bay, Ontario

Posts: 5
Joined: Fri Nov 11, 2005 5:15 am
Location: Ulverstone, Tasmania, Australia

Post by glennd2 » Wed Jul 30, 2008 7:40 am

Glenn, thanks for the tip to locate measurement time stamps in *.dbf!
This will do for the time being BUT I still believe that this info should appear at the end of each measurement record in the RAW data file as this file is really the defacto field book!
Looking forward to the inclusion of the stamps in next release of FG :wink:
Kind regards

Posts: 32
Joined: Thu Sep 28, 2006 12:08 pm
Location: Kaleden, BC Canada

Post by DKNTEC » Wed Jul 30, 2008 1:27 pm

Yes, thanks Glen for that tip about the .dbf file!
I have also wished MANY times for this timestamp information about the survey shots.
I knew I could see it in the Coordinate Database for each shot in the FG project file while it was still in my Tracker, but did not know how to find or print this information after the FG project was downloaded to the computer.

To expand upon glennd2’s 7:40am reply post;
I realize the .RAW data file itself is in the old “TDS specified format” & you likely can’t directly change that format.

Where I would REALLY like to see & use this survey shot timestamp information is while cleaning up a survey in MicroSurvey’s Active Traverse Editor (ATE) within the MSCAD drawing.

Ideally with this timestamp information incorporated into the FG/TDS record filter, or a similar offshoot of that, that could be turned on & off as needed to view or print.
Not just included as another Note, but preferably as a separate independent line item in ATE about the shots, similar to the SP and SK records, to allow viewing control of the shot timestamp.

This would be EXTREMELY useful to me as the complete record of the survey on a single printout, and for timetracking.

I realize this might be a bit difficult if you need to link the ATE to the .dbf file (if it is not already), and may cause problems using the ATE if the .dbf file is not available, but you guys can figure that out!
Perhaps with a toggle to turn the .dbf link on or off.

Also, an additional request is the ability to output the ATE as a separate file for job record & client purposes, perhaps in ASCII or Excel type format rather than just the current hardcopy printout.

By the way, I find the Help button on my “Show ‘FG/TDS record filter’ options” dialog box is “dead” – nothing happens, no help screen appears when I click on it.
Can that be fixed?


MSCAD 2008 SP 1.3 on XP Pro SP 2

Richard Sands
Posts: 425
Joined: Mon Feb 14, 2005 1:10 pm
Location: Tasmania


Post by Richard Sands » Wed Jul 30, 2008 2:38 pm

Glen C, I know we've discussed this but it came to a head recently with a job.
Monitoring a milk vat as it emptied - displacement(distortion) against volume.
This was a legal case against the milk vat manufacturers.
I needed to corelate the shots taken against the time stamps on the flow meter.
The current way uses the dbf file for the time stamps.
The problem with that is if something changes then the timestamps reflect the change and are updated. So the actual time of the observation is lost. (I know it can be obtained from an original of the DBF file).
Another situation is where we observe timed depths (soundings) that are time related to an observation from GPS/Total station.
I also understand you have indicated this is being taken into account.
But users need to be aware a re-cordinate or change in the raw data transaltes to an UPDATE of the time against the point.

Richard Sands
Posts: 425
Joined: Mon Feb 14, 2005 1:10 pm
Location: Tasmania

raw data format

Post by Richard Sands » Sat Aug 02, 2008 12:23 am

From Dan's comment above
I realize the .RAW data file itself is in the old “TDS specified format” & you likely can’t directly change that format.
I'm not familiar with TDS formats but if its 'old' then maybe now is a time to revamp field genius at the same as add time stamps? I was of the understanding the format was current.
More on the Nikon raw data format- it certainly is far easier to read data and is inclusive of all information that involve everything relating to the job in one file, making it completely 'transportable' from job to job, year in year out.
I have re-run many an old Nikon raw data file to bring it into my current survey.
Its not so easy with the raw data file from Field Genius to 're-use' it as some of the data required and yet part of the original project is missing.

Posts: 23
Joined: Sat Feb 11, 2006 7:33 pm

Post by rgreen00 » Sat Aug 02, 2008 8:00 am

What if I'm not running Excel??

What can I do then?

Posts: 32
Joined: Thu Sep 28, 2006 12:08 pm
Location: Kaleden, BC Canada

1-TDS RAW info. 2- FG Raw data file Improvements needed

Post by DKNTEC » Sat Aug 02, 2008 3:15 pm

Hi Richard,
See MicroSurvey's Knowledgebase;
Raw Data File Format - TDS RW5 Specs
FieldGenius 2004/2005/2006/2007 and Evidence Recorder 3.0/4.0 use the TDS RW5 Raw File format. Complete specifications are available in the following document, provided to MicroSurvey by Tripod Data Systems. TDSRawDataSpec.pdf

.RW5 is TDS's (proprietary I assume) extension name. .RAW is MicroSurvey's extension name. The file format & content is exactly the same I believe.

It is ASCII, look at (your FG project).RAW file in any Text Editor.

The format must be something like 20 years old. I have used it since my first TDS CMT500 data collector of about 1991.
I used TDS-PC PLUS for editing it - like a primitive ancestor of MS ATE.

.RAW timestamps only the opening of the survey project file, but not the shots.

I agree it is time for FG to out-grow this old restrictive format.

I do like the fact that TDS RAW is in simple ASCII format, and would like to see that remain if possible, if only to keep it as a simple text file for the original survey data record file.
Or maybe CSV format if ASCII is too limited.

I concur STRONGLY that the field survey record data and shot timestamps should be in the same file! Both for record & working reference.
It is a hassle flipping back & forth to, & digging around in, the .dbf to see timestamps, while working in ATE.

Ideally the drawing ATE (and also the ATE "output" file requested in my first post here) would have both;
-Timestamp of original field shot
-Timestamp of last revision. It should NOT show ALL the revisions (that is available in the drawing ACE (Active Coordinate Editor) point History, and would unnecessarily clutter the ATE), just the last one for record purposes.

A 2nd big gripe wth the old TDS format is in a Left/Right Horz Distance offset shot, it takes the offset dist as a SIN dist, recalculates and stores the resulting calculated horz angle directly to the offset point, losing the actual original shot horz angle that was on the gun.
Therefore to correct a field goof-up of incorrectly inputting L instead of R requires you to manually recalculate the shot horz angle twice to "flip it" to the other side & then revise the ATE horz angle accordingly.
This is a nuisance & a little error prone.
Especially considering the toggle for L/R is a simple - or + of the offset distance to begin with.
We should be able to cleanup this field error by simply changing a record item in ATE from + to -.
See my old post on this topic in the MS CAD Forum– “How to Change Left/Right OFFSET in ATE?” – Sept 28/2006
We are still awaiting that improvement too.

Richard, I have never used, and know nothing about, the Nikon raw data file. What is it like? What file format? - ASCII, dbf, CSV?

I realize this thread is becoming an overlap of MSCAD & FG forums, and topics, but they apply to both.

Edit 8/2/08 9:20pm

Richard Sands
Posts: 425
Joined: Mon Feb 14, 2005 1:10 pm
Location: Tasmania


Post by Richard Sands » Sat Aug 02, 2008 11:03 pm

Thanks Dan for elaborating on TDS background.
I've been familiar with the FG raw data file and whilst realising its a familiarity thing did find it very complicated when viewed against a nikon raw data file.
Its all simple text file.
I too would opt for ASCII format for any raw data files, something that can be opened and understood easily.

A Nikon raw data file goes like this, in part

CO,11-Aug-2003 15:51:12
CO,HDm=94.921 BS Zm=254.754 DELTAS: HD=0.004 Z=-0.005
SS,44,1.600,14.150,266.2058,85.0238,16:01:58,PP 283273
CO,H O/S:44,1.600,14.150,45.5645,85.0238,16:01:58

Yes this is crossing over into MSCAD territory, but FG is very much part of MSCAD and I imagine it was written first for MSCAD, but then also for all (most) other survey packages about??

Other things I dislike is the difference between the way Mscad AutoMap is set up to accept 'spaces' in the coding so similar codes can share one set of treatment by MSCAD.
That was a BIG plus when it was introduced and allowed a freedom not previously known when using codes.
Now with FG we need an expanded AutoMap to incorporate these Codes and all the associated symbology etc. Hopefully that will get fixed soon.

Your comment on the way FG handles offset shots is one of the things I was referring to in my post regarding Recoordinating the raw data file. I'm still not convinced it is something to take lightly and one needs to be cautious of the outcome.
That said I haven't needed to change these in the Nikon so can't comment about the offset side (ill try that next time in Mscad with a Nikon file).

With the advent of FG and time since its inception as well as the change from FelixCad to IntelliCad there has obviously been changes to make it all work and come together. However this mixing of 'cultures' comes with its associated issues that at time show up as inconsistencies across the two platforms as well as within the application itself.

I would welcome a 'new' look at FG and MSCAD in light of its latest formats and address some of the legacies of old formats and methods that bog down or are just plain old hat in 2008.

I make no bones about my programing skills - they are ZILCH. But I do question when for egs my GIS program can for egs cut and paste bucketloads of data between two (or more) open instances of the same program running simultaneously one on each monitor, but MSCAD can't handle that.

That brings in another side of MSCAD/FG. - The GIS options of surveying.
I don't know of any data collection application that will handle GIS from a surveying perspective. FG is getting there with the ability to add attributes to points, but the linework is 'left out in the cold'.
I am sure this is the way of the future - a way to collect all data either from total station or GPS or combo and it's a need waiting to be filled.

I hope (all) these comments are taken in the correct light and not as an attack on 'perceived failings' of any program. We are the end users and see the end product in a different way to those who devise and test-run them. We are at the 'rubber hits the road' point with earthmoving machinery grunting at their tracks, and other deadlines to meet and when things don't work efficiently or we see ways to improve/ streamline processes then hopefully we can all work together to make a better product.

Post Reply