Assumptions:

• Data comes from five sources - Serial G-rays, Flash based G-Rays, text files and optionally from the Track Server and AGTEK Access Server (automatic upload).
• We should present tracks the same way regardless of the source. As an analogy, each capture device is like a camera in that it captures data, but just stores them differently. In the end tracks are all pictures of what happened. The device shouldn't matter to the presentation. That means:

• We'll need to apply server rules to the data that forms tracks. (George has these implemented in his AGTrac project already along with code to read the new G-Ray)
• Gaps greater than 4 hours on the same date are separate tracks.
• Gaps less than 1 hour across a day are in the same track (UTC days require this).
• We check the 61st (or 121st) point for presence in a project, if not inside the projects, we put it in other.
• We have to create a local method (catalog) of storing projects and data. I'm thinking an xml file describing the Projects and Tracks for quickly populating the window when the import window displays. This does mean more code for housekeeping of what's there but lends a level of organization to all the data that is missing now. The challenge of trackwork has always been to handle the large amount of data in a clean, organized way that conveys the results without being bogged down by the quantity. If we end up with competition, this will be a key differentiator. Other tracking applications have opted for collecting data less frequently and throw out key information rather than deal with the detail.

• AGTEK Access/Trackserver is an option set on installation like we do with Netkeys. These features of the Import window do not appear if the registry is not set to use them.
• The single method of presentation means we should formalize our directory structure on disk and mirror that on AGTEK Access (when present).
• Installation creates a Projects folder under the data directory.
• Sources like the G-Rays, text files, and the trackserver are just a read source. We read them and store the data in the Projects\ProjectName\Tracks\Days folders. In fact, after reading any of those sources (except maybe the trackserver), we should ask or have the option of removing that data from the source. Going back to the camera analogy, you read your pictures in from the flash drive. Then you remove them from the flash drive to go back to your camera and shoot more.
• We'll want to store what's in those Projects folders and display it when you first open the import window. It's essentially a localized version of what we have stored on the trackserver. In fact, we'll want to be able to synchronize what's on the local machine with what we store in AGTEK Access.
• Trackserver becomes more of a mechanism for getting automated points or data read into the system remotely from Trackreader, etc. We store the organized data locally or on AGTEK Access.

New Import Window

Import gets rid of the tabs in previous incarnations as well as the Google window (for legal reasons). The idea here is that we have sources of data that feed into the track display.

Pressing any one of the source buttons displays an appropriate dialog for the device. The Flash Drive and Files buttons bring up standard File open dialogs (we may want to add a checkbox to the bottom of each as an option to delete the files once safely copied.) There are two reasons to keep them as separate buttons. One is to remember the last path used separately because the G-ray will always be a different drive. The second to make the differing sources more explicit and obvious. The Trackserver source is only displayed when the user has that option in the registry. Selecting the Trackserver button first prompts for the User ID and password, and on success shows the Treeview of track server to allow the user to download tracks to the local view. (Note: The AGTEK Access/Trackserver can be implemented last.) AGTEK Access shows the project and track structure currently on AGTEK Access for the customer.

TreeView The TreeView is very similar to what we do with the Trackserver now. A slight difference is to bold the Project names. We'll store this view locally in an XML file so there will always be something visible, even if it is just Other. The right mouse menus differ depending on whether you have a project selected or a track selected. The project right mouse menu looks like this:

Edit Project brings up the project window. Synchronize with AGTEK Access is an optional feature shown only when AGTEK Access set on in the Registry. The idea is that it will allow you to compare the local project to the one stored on AGTEK Access and update either. (One of the last things to implement.) Delete Project does just that. If picked, ask to confirm and also if it should delete the data associated with it. If the user answers no to the delete data but yes to deleting the project, move the data to the Other project.

The Track/vehicle right mouse menu looks like this.

Move Tracks to is a combo box that allows moving of the tracks to another project on the list. Assign Vehicle is a fast way of assigning vehicles to a different track based on the list stored in the local XML file. Hopefully, going to the Vehicles window is a rare occurrence of adding a new vehicle. Once a vehicle is assigned to a track, it stays in that project until a newer track is assigned to it. That eliminates a lot of the need to automatically assign the vehicle end date to 5 years in the future. Show in Google Earth takes the currently selected track and creates a KML file that opens in Google Earth (or the other designated mapping program set in Settings.) This is allowable under Google's licensing and does give the user a way to see it on the earth rather than just in preview or the program. Delete Tracks does just that after being confirmed. Another option not shown is “Upload to AGTEK Access which copies the file up the user's AGTEK Access Projects account. If the user has not logged in yet, the login window displays and the file uploads upon a successful login.

Track Preview Preview tracks is useful but the Google window we had before was slow and didn't work that well. It also probably wasn't legal. The idea here is display a preview of the selected track. George has an app written that is doing more that just displaying but for our purposes here I really just want the equivalent of a thumbnail. The scale is to give some form of reference to relative size.

Calendar The calendar does what old window did which I mostly can't remember. I proposed getting rid of it but was told it was used. I think the primary function is to show what days have activity from within a selected project.

The Serial G-Ray is the same one we've always used. Because of the serial connection, we have a more complicated interface than the file system based devices. This should look very similar to previous dialogs except it's smaller and in a popup window form. The user data flow should be something like this.

• Attach a G-Ray and press the Serial G-Ray button to get this window. • Press Read to display the data. • Either Assign a vehicle (The combo box has an “Add new vehicle option” as well as all previously defined vehicles (guess what another .xml file) or leave unspecifed • Press Send to import all data with the checkbox checked but leave the dialog up. Do something like a message box to confirm the data import and erase it if the “Delete data after safe import” was checked. • The user attaches the next G-Ray and presses Read to repeat the process.

Displays the standard file dialog with a filter for TES files. As I recall, the default open dialog could only be modified at the bottom. Adding a combobox for project (default - Autodetect, projectname1, projectname2 . . .) I think is desirable as well as a checkbox labeled “Delete after safe read” which is defaulted off but remembers it's current state for that session only. File multiselect is allowed and the last path should be remembered. Pressing Open runs the selected files through the track creation logic and creates them in the appropriate project as well as updates the treeview.

Displays the standard file dialog with a filter for Txt and TES files. As I recall, the default open dialog could only be modified at the bottom. Adding a combobox for project (default - Autodetect, projectname1, projectname2 . . .) I think is desirable as well as a checkbox labeled “Delete after safe read” which is defaulted off but remembers it's current state for that session only. File multiselect is allowed and the last path should be remembered. Pressing Open runs the selected files through the track creation logic and creates them in the appropriate project as well as updates the treeview.

The project window is similar to previous incarnations except that we don't have a sub-window for the project boundaries. We had to get rid of the google earth windows implemented by Mark because in my opinion, it wasn't legal under Google's user agreement to do it that way. Name and Description are the same. If Add Project is pressed, this window comes up with none of the fields filled in except Status defaulting to New. If Edit Project is pressed, the fields are populated with the selected Project's settings.

Status has been present but never really used in previous iterations. We'll use it now. The difference between New and Active is simple. Active has at least one track in it. New does not. Otherwise, for all intents and purposes, they are the same. The third choice, “Finished” has to do with displaying the project in the treeview, comparing new tracks against project boundaries, and a filter on whether it appears as a move track option. A project that is set as Finished is only used in all of those situations if the Settings window has “Show Finished Projects” checked. On the treeview itself, Project Names display in Bold except for Finished Projects. Finished Projects display as gray text.

The site boundary is defined by the coordinates in the boxes for lower left and upper right. This presentation is just another way of displaying the previous versions separate window for coordinates. New is the Use Perimeter button and Import button. Use Perimeter is only available when a job file is loaded in Trackwork and there are two benchmarks with Lat and Long on them in the file. Otherwise it is grayed. (if it's possible to show a tool tip, it should say “No Benchmarks with Lat-Long” as a hint. I'm not sure if tool tips are available for inactive buttons.) Assuming it is active, it should calculate a bounding box based on the perimeter + 50 feet offset ( I use 50 feet because that's half the error of worst case GPS, this is arbitrary.) The coordinates should fill the boundary text boxes after being pressed. Import uses George's new KML/KMZ reader to open those files and use placemarks saved in them for boundary coordinates. Match Benchmarks labels in the esw file to placemark names in the KML/KMZ and then use the perimeter as described above to create the boundary.

The calendar is used show activity days for the current project as the light green background. If the there's a track on a particular day, assigned to the selected project, that constitutes activity.

The Settings window is new. It controls

• The visibility of Projects marked as Finished. • Whether to ask about synchronization if the customer has the AGTEK Access registry setting on. (It should not be present if the AGTEK Access registry setting is not on. • What units to use if there's no ESW file loaded. (We use the ESW's units if it's present.) • The default mapping program to use if a track is selected, right click is pressed and “Show in #####” is selected. The choice here should fill in the ##### on the menu. We don't have the other export formats written yet so for now it's just Google Earth. When George writes the others, we'll incorporate them here. • The Default Project path is where we expect to find the Project directory structure and files. The default is shown below and that's what we'll install on a new install. The user can override this if they want to store on a network drive, etc.

The vehicle window is very similar to what we have now. The chief difference is a customer should need to go here a lot less since vehicle assignment is often handled when importing the data or in the treeview. The reasons to go here are to add new vehicles and edit them or to see assignments. One added feature is color designation for vehicles. We should have a local xml copy of vehicles and another on agtek access that can be reconciled. I suggest we stop using it on the Trackserver. Using the vehicle color will give us consistency in viewing.

On the Start Time and End time, lets do more of that automatically when a user designates a vehicle. It a user tags a track to a specific vehicle then we can create an end time 6 months in the future. That end time should be modified and ended if the user tags a later track with that vehicle.

Changing the current text files saved for track now into XML files with much greater depth and portability. We could store the processed results easily, Moving times, vehicle associations, colors, etc. Along with the coordinates of the haul line used, slopes of segments (CAT performance handbook slopes). Anything to make the track portable and stand alone after processing could be useful. A first pass at this could define a schema definition and we could add features as needed.