Differences

This shows you the differences between two versions of the page.

--- windows:trackwork:trackwork_import_window_and_agtek_access_integration [2011/01/20 22:41]
mikeclapp
+++ windows:trackwork:trackwork_import_window_and_agtek_access_integration [2012/10/10 16:45] (current)
@@ Line 7: / Line 7: @@
   * 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)
+                * 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 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.
-	    * Gaps less than 1 hour across a day are in the same track (UTC days require this).
+           * 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.
-	    * 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.
@@ Line 57: / Line 53: @@
 **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.
+==== Data Sources ====
+=== Serial G-Ray ===
+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.
+=== Source: Flash Drive G-Ray button ===
+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.
+=== Source: Files button ===
+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.
+=== Other Windows ===
+== Project Window ==
+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.
+== Settings Window ==
+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.
+== Vehicle Window ==
+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.
+== Other Ideas ==
+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.

AGTEK R & D Wiki

User Tools

Site Tools

Differences

Page Tools