A large part of this story has been written in IOS but we're fundamentally shifting the way save works as part of it. SmartGrade previously has been the only product to actually save .ADF files but the addition of plansheets, orthomosaic backgrounds and large amounts of drone data has highlighted the problem of trying to save too big of a file over mobile. Even previously ok files have swelled.

The reality is we don't care about most of it because it originated from the desktop and much of it is duplicate information. The desired data is the Benchmarks, survey points and lines, and possibly the recover data. In most cases this could be combined with the original data on the desktop easily although I believe we should have a way to upload the entire file but not make it the main working path. This also aligns the saving of of these added objects with the method we have to use with IOS and effectively creates an autosave capability.

Currently in SmartDirt, photos, tracks and notes are created as local objects that are not part of the file. The presence of this denoted on the file screen by icons. My proposal is to extend these local objects to also handle the survey data. When a file is saved just this extra survey data is uploaded (deferred uploader) instead of the entire file.

My expectation is that there will be some situation where we will want to upload the entire ADF file including survey data. The likely situation is it's different person doing the survey or they're switching devices. To do that we should use the Upload feature on the file menu. This feature has existed since the beginning but the new wrinkle is that when pressed it takes the survey data, adds it to the ADF file and uploads the combined result.

The original SmartDirt view menu was a fixed and relatively inflexible as it was our first mobile product. The desktop software has evolved to support more surfaces and additional layers and we both need to support those and create a more dynamic View experience that reflects these changes. SmartDirt also needs to deviate away from some of the SmartGrade display choices as it's a different product with different optimizations although they may have some of the same data available.

Our current View organization for products is:

• Tracks
• Photos
• Measures
• Notes

• Ref - “Name of Ref surface”
  • Data Lines (Draw lines in black)
  • Annotation
  • Perimeters
  • Report Regions (sectional areas if subgrade surface)
• Diff - “Name of Difference surface”
  • Data Lines (Draw lines in med/dark green)
  • Annotation
  • Perimeters
  • Report Regions (stripping areas if Stripped surface)

Unassociated with Surface Data

• Benchmarks
• Cut/Fill Lines
• Stake List Points
• Pipelines
• Contour Lines Leave out

* Highway (This does not display if no alignments, torn on whether it goes in View or Data section

• Alignment
• NE or Station Offset
• Station Display

• Skip Cut/Fill model
• Map Background
  • None
  • Cut-fill color
  • Image
• Color Increment
  • Auto

As part of a demo we showed Smartdirt and the customer was very interested. They also had some feedback for improvements that seemed both reasonable and valuable. This story is based on that feedback and applies to the Measure mode in SmartDirt.

• Display Elevation for the current Measure points instead of just Cut/Fill
• Add the ability to enter a compaction fill factor in the Measure Report
• Calculate the net cut/fill and display as export/import on the Measure Report
• Allow the user to specify an elevation plane for a measure area (explanation story below.

This version is based on the release version + recent changes Mike A has made to support site licenses and fix bugs. It does not use the Science Experiment changes and these changes will also need to be migrated.

The current version displays the Cut/Fill at the last measure point entered or the measure point being edited (dragged). This version turns it into a toggle similar to the distance/slope display when not in measure mode. This makes it easy for the site foreman to look within a bank a pads for example to find the lowest elevation on a fill pad or the highest on a cut pad. That gives them a floor that they can move dirt to before using grade setters all the time. The default is to show the elevation of the reference surface with the ability to toggle to cut/fill.

The vast majority of this is interface changes with some simple math. On the android version we'll need to tighten up the vertical spacing compared to now to allow enough room. Also note that although there's room allowed for and the cost code dialog is shown, I do not intend to release cost codes in this version. It's simply a placeholder for where it will go upon release.

Added above the cut and fill numbers and in line with the surface comparisons is the compaction fill factor. The compaction fill factor is numeric only (change the keyboard to a numberpad) value that is multiplied with the raw fill volume to reflect compaction. For example, putting in a compaction factor of 1.15 is a 15% swell so a 5000 cubic yard raw fill is actually displayed as 5750 cy in the display and calculation of the net import or export. A value less than 1 actually decreases the fill number.

Displaying the net of the cut and fill numbers is simple subtracting cut from fill for the measure. A negative number shows as an import and a positive number displays as an export.

Part of the value of SmartDirt to the foreman is allow them to do rough operations before staking and grade setting might have arrived. For example, the foreman checks a block of fill pads and finds the lowest one is elevation 248. By knowing that it's possible to start filling and compacting those pads before the grade setter is available (or in the cut) he can turn the machines loose without worrying about moving dirt twice. Currently we only display the total cut/fill in the measure area but this feature would allow him to set a plane to compare against and quantify the volumes to that plane. That 248 elevation may tell him there's 22,000 yds of fill which means he fill there for two 10,000 yard days before getting the grade checkers over.

Ideally, we wouldn't need to calculate another Isopach with this because of delays and the fact we can have multiple measure areas with different elevation planes means it's less than practical either. When we talked (Bill) the thought that because we were just doing a grid calc it might be possible to avoid an Isopach recalc.

There are several important features of the interface beyond the volume calc. The most important IMO is the feedback that the current measure area has a plane applied to it. I think we'll do it two ways (graphics to follow). The first is that instead of displaying Subgrade - Existing for example when a grading plane is applied we'll show the elevation instead. So at the top of the Measure area and on the report and KMZ output we'll show “248 - Existing” for that measure area. The second, more subtle difference is to shade those measure areas and boundaries a different color than the current black. My first suggestion would be the purple transparency but I think we'll have to experiment to get the final color and opacity. Removing the measure plane would revert the volumes and color shading

I'm not sure coming up 0.0 is the correct default but lack a better number. If possible, when not set it should come up with the cursor bar there and the keypad up. Clear is the definitive way to remove the Elevation limit.

SmartDirt is moving back to the mainstream field message. It will share features and catch up with the newer SmartPlan version as well as serve as a template for an IOS version of the product. Emphasis will be put on having the geometry of the job which is a nice barrier to entry that SmartPlan does not possess. These features are:

• Multi-Measure - Currently prototyped but some interface changes to the new SmartPlan implementation (zoom controller modifications & note taking.
• Layer list support of Photos, Tracks, Notes, & measure areas. See new SmartPlan (1.4) for modeling of interface
• Persistence of documentation objects beyond the session. Documentation objects are (Photos, Tracks, Notes, & measure areas. Smartplan 1.4 has a way of doing it now that doesn't save to the file and Mike A says it would work for SmartDirt for Photos, tracks, and notes. Measure areas will take some reconciliation with SmartPlan methods to store.
• Saving of measure areas in the kmz file output
• Grid Volume optimization
• Report Simplification
• Put Me here changed to IOS version (already complete)

The current prototype of multi-measure is fine as far as function but I used it to evolve what we're currently doing in the 1.4 version of SmartPlan for Android and IOS. Note that the IOS implementation drove some of the Android changes because the desire is to make the two platforms similar within reason.

The primary change is changing the zoom controller buttons while in Measure mode from tracks (L), Camera (UR), and notes (LR) to Snap (L) and New Measure (R) omitting the Note button entirely in the Android version. In the IOS version the Note button will be a back button in measure mode. Moving these functions to the zoom controller is partially driven by the IOS screen space limitations on the equivalent of the action bar but this is also true of Android phones. It's simply much more convenient to not require the user to go to the menu for snap especially.

Here's an example of the Measure screen on a phone:

Features of note (bottom to top):

• Bottom info bar up and right arrow controls. The up_caret.png displays the name and notes for the measure area. It's a tap control that expands the bottom bar to show the name of the measure area (entry/editing) and allows notes to be added to the info (Length, Area, Volumes) that is automatically included in the KMZ file. The right control arrow cycles between the selected measure area (replaces the action bar arrow in the prototype). Note that Mike A is implementing this in SmartPlan 1.4 as this is being written so I suggest leveraging that code.
• The zoom controller buttons for Tracks, Camera, and Note have been replaced with a New Measure button on the right and a Snap button on the left.
• Below the top info bar the area where we display the measure name and file name has a new semi-transparent backdrop that extends across the width of the screen. See SmartPlan 1.4 for an example. It just look better than the block background we currently use.
• The first two action bar icons are now View and Exit Measure. With the use of the zoom controller we have extra space. I don't want clear to be easy to hit accidentally. The menu options left (in order) are:
  • Clear
  • 3D View
  • File
  • Settings
  • Save
• I'm removing the Report option altogether

Along with persistence of the data objects we also want to be able to control visibility, find and delete individual items. The screen below is derived from SmartPlan which has this capability as of 1.4 and it should serve as a model for implementation on SmartDirt. These data objects appear at the top of the layer list. They can be hidden with the checkbox and deleted by swiping. Please try this with SmartPlan for an example of how this work. In fact I recommend using that code.

(Photos, Tracks, Notes, & measure areas) In Android up until Smartplan 1.4 we did not up to this point persist these objects once the program or file was closed. On the Apple version we did due to having no natural save points. This and other changes are moving the mobile products further in the direction of field documentation. Note that SmartPlan 1.4 already has the features very close to completion. When possible I suggest picking up that code whenever possible.

Files with persistent documentation objects display that fact with a glyph to the right of the filename. See the example below

With the ability to persist documentation objects we also need to be able to remove them without deleting the file. We do this with the long press menu that currently exists by adding a “Clear” option.

We currently save photos, tracks and notes in the KMZ output. We're just adding measure areas as well. The measure area is described as a polygon area and the property sheet contains the surfaces compared, the Area, LF, cut and fill for that measure area.

See the sample KMZ file here (example KMZ link). Note that this is the same sample file I used for saving in SmartPlan and the property sheet does not include the Surfaces compared, cut and fill but should for a SmartDirt based Measure area.

Currently the Measure View upper information bar is present but not used for anything. I'd like to change that and both reclaim some space at the top of the screen and display more relevant information. Here are some proposed screen shots but they can be summarized as removing the N,E, Z, Point and Line labeling and replacing them with the surfaces (ie; Subgrade vs Existing) in the upper left that pressing and holding on displays the surface selection and a Cut/Fill number with arrow on the right. This should enable us to shrink the upper bar by at roughly half. The cut/fill number reflects the cut or fill at the current measure point. One of the desired uses is to allow a user to put down a single measure point and then edit and drag it around to examine the cut/fill rather than having to walk over to it in the main screen mode.

The current 3D View only shows the a Northing and Easting value if picked on the previous screen and the point and line label are not particularly useful either. In the new screen shown below the Northing and Easting values are actively tied to the user's gps position instead being based on a point picked on the main screen. I've also shortened them to just tenths to not imply any great accuracy since SmartDirt is based on autonomous GPS. The layout they are on is shortened vertically at the top but extended vertically at the bottom to accommodate a little larger text at the bottom. I've also changed the Cut/Fill number to be larger still and moved the arrow to one side. There is some experimentation required on size.

The 2D View changes are simply increasing the size of the bottom info panel to match the new 3D view. The idea is to make the numbers easier to read.

(already complete)

This is for documentation purposes. IOS lacks a Setting page accessible from the program where we had the Put-Me-Here functionality in Android. Instead we made the GPS icon on the main screen have a long-press capability. Long-Pressing on the GPS icon with a point selected now asks the user whether they want to move the GPS position to the selected point. Pressing Ok acts as a Put-me-here. Subsequent long presses allow the user to clear the Put-me-here unlike previous versions which required reloading the file.

• Deferred Uploader support
• Save Dialog changes due to Deferred Uploader
• Add Access Uploader to the About tab

This is a small update mainly to add to Deferred Uploader to SmartDirt and other Android apps. The addition of the uploader means that we can clean up the Save dialog and also remove a potential issue for customers who don't select upload

The deferred uploader is already complete. In the past we could not exit the program and upload our tracks and pictures if we did not have an internet connection. Upload could continue once the program was restarted but this is hidden from the user. To reflect the new ability, the save window should now look like this:

The Upload, Save As, KMZ, and LLA options have been eliminated. Saving the file will automatically send the files to the uploader which will upload when a network connection is present. We're going to remove the LLA file option due to other tracking options being available so the export format automatically becomes KMZ and removes the need for those two options. Also, the default file name is highlighted (minus the .kmz extension) and the keyboard raised when the user enters the screen. If the user just wants to save he can hit the save button and use the default name and upload.

Also notice that the file extension is added to the right of the filename and is not editable.

Access Upload status

The Access Upload status pages are something we on look at when something has gone wrong. It doesn't need to be on the menu and it's preferable that it be out the way. For lack of a better location I propose we add a button to Settings-About that takes upload status pages.

The expanded tracks capabilities have led to a desire to augment tracks with photos that are georeferenced (with possibly compass indicators)

• A camera icon on the main screen beneath the right zoom buttons
  • The presence of the camera icon is user selectable through a Preferences (name?) tab under Settings. We intend to also use this tab in SmartGrade with a similar option for a Record button and staking offset distance. When disabled the camera button is never visible in the zoom controller.
• When pressed, the camera button takes the user to the camera app.
  • Does the Camera app return at the first picture? (I'm thinking no). If not how do we register those shots in SmartGrade as belonging to us. We also need to record Lat-Long and compass although the camera meta data has fields for lat-long and might have them for the compass. Assuming we make the user end the session, I'm assuming he backs out of the camera app and we return to the screen.
  • A screen marker displays on screen to denote the picture (need to design, ideally it show direction)

A large portion of the user interface to picture taking capability is extending the zoom controller to support optional buttons other than the zoom buttons controlled by the user. The presence of these buttons is controlled by the Preferences Tab under Settings. Other options could be a track button for SmartDirt and a Record button for SmartGrade Staking mode. We may find other uses later. Disabling the buttons causes them to never be displayed in the zoom controller.

Ideally, when a user has buttons turned on, the program would place a button for that option first beneath the right zoom controls with the next additional button placed on the left below Home -togglezoom. The reasoning is this accommodates older phones in landscape mode the most gracefully. Since we don't have more than two options at this time this is probably sufficient. Making it open ended enough to expand downward would be nice but isn't necessary right now. Also note that some buttons are tap to do something (zoom, camera) and some need to show a state (track on/off).

The use story as an example is this: A user is going be doing a lot of tracks and taking pictures. He could toggle tracks by pressing Menu-Track each time to toggle the state of tracking but it would be much easier if he could go to Settings-Preference once and turn on the Track and Camera buttons. He might do this a lot and just leave them on so they are persistent every time he goes out. Other users might never do this so not turning them on by default doesn't clutter up the screen at much. He walks around the job site and uses the camera button to take pictures as desired.

The key to not swelling ADF file sizes is going to Access links. This is a background process (Mike A talked about uploading temporarily and finalizing on exit with the Tracks.) Note: Big duh on my part. We don't store pictures in ADF at any time because we don't store tracks either.

Connectivity Scenarios

1. User takes pictures on site, exits program and says yes to saving and uploading tracks and has internet. If he has an internet connection the uploader service begins uploading the files as soon as the connection is established.
2. Same as above but no internet (cell coverage or tablet without cell). The challenge here is that all the behind the scenes things like uploading pictures, and creating links can't take place. We don't want to embed pictures in the GPX or KMZ but unless we can create a delayed process, we might have to. In fact at this point, even with a cell connection, we could start uploading files but could not create links in the files until they finished (create a small dummy for link url and replace it?). In a case where we have no connectivity, the KMZ becomes a better storage format than GPX because it can contain picture files along with the KML.

• What do we get from the camera? Lat-Long, Time, Rotation?
• How do we get the correct picture marked for SmartDirt and can we rename them?
• Do we store the photos in a separate part of Access Projects? (Yes, Photos)
• Rename photos using File Name?
• How does the user view and Share? GPX? KML/KMZ?
• Tapping camera point marker to display photos?

We have a couple of tools to use for viewing in Google Earth, GPX files and KMZ files. GPX is ideal because we already write them and the can be played back in SmartDirt or SmartGrade. In the GPX format, the Link type and the Point type attributes look ideal for our use.

KMZ Example This example has two camera shots along with the file tracks. Tapping the Camera marker show the picture taken with links in the property that point to Access photos. These photos could also be embedded in the KMZ if necessary. Note: The image tag used in the properties sets the image size to 640×480 in order to keep the popup reasonable but it does not affect the native resolution of what's stored.

My ability to decipher the GPX standards site means that my GPX sample is lacking. If it's possible, using the linktype along with the waypoint would result in what I'd like for it to do. The KMZ example is really how I'd like it to work. Although I like GPX for it's capabilities in playback and track storage, Google Earth doesn't handle it very well. Clicking on a GPX file opens Google Earth but does not load the GPX. When opening it requires extra selections and dialogs that might confuse a user. I'm leaning towards KMZ for our output for that reason.

GPX Example

Optional - Now that we have KMZ writing we should think about enabling the KMZ Measure Report export. We don't need cut/fill color but we should export the measure perimeter and put the report data as the properties. Mockup to follow.

• Add surface switching/3D view switching.
• Station & Offset support

The Highway tab was in early versions of SmartDirt but was never implemented to due to time. This version has been modified to allow selection of more than one alignment.

What it does is this:

• The user can toggle the top info panel to display Northing/Easting or Station offset. NE is already implemented and does not change.
• With NE selected the Alignment combo box is grayed. If Station Offset is selected it becomes selectable.
• The default Alignment selected is the longest line. Station and Offset displayed is relative to the selected COGO Alignment. Naturally, Station and offset is less precise when on the inside of curves as the user moves further away from the alignment due to converging station lines.
• The design perimeter clips the display of station and offset.
• The selected polyline of highway data is bolded in the display.

* Add surface switching/3D view switching.

• Station & Offset support

We currently have surface switching in SmartGrade although we need to verify the 3D view is correct (it differs from 4D). SmartDirt presents another problem as well. In Grade we only have a single surface to compare to the survey shot. Picking the tiny arrow for each surface is unrealistic so we need to do a new selection window for the View and Compare to surfaces.

(There are updates to these pictures but overwriting is failing)

Behaviour

Pressing on the surfaces text displays the surfaces dialog where the user can select their view surface and their compare surface. The dialog does not need to be followed slavishly. The key features are radio button next to any selectable surface. It's likely that the lists may need to be scrollable due to the number of choices. Please suggest any other interface that may make sense for exclusively selecting the two surfaces.

Note: Feature not shown. The triangle that denotes a selectable item should point sideways (graphic won't update) and point at the view surface being shown for feedback. I thought about swapping surface order and always placing the view surface on top but I think that make the cut/fill indicator more confusing.

My original idea was to make the view items independent of the view surface but SmartDirt has evolved past my original simple idea. We need to create some automatic switching of certain view settings when a job is opened based on the View surface. For example, if Design is the View surface then we turn on Design Lines and turn off Existing lines and Annotation. If Existing is chosen, turn off the Design lines and Annotation. The user should be able to override this during their session but the behavior reverts to automatic if the program is quit and restarted.

Addition 9-13-12: When a file is loaded, if there is no Isopach but there are images, automatically switch the Other view and turn on images. Likewise, if the file loaded has no images but does have an Isopach, automatically set the Other view to show Cut/Fill despite prior settings.

• File List Enhancements
• Image backgrounds
• Add Distance between points/ slope between points feature (ala RTK)
• Multiple Tracks and note taking

When the file listing was first developed, we were not worried about upload the files back into Access. The saving of IsoPach has changed that. Especially for large files and for demos. Deleting files is also sort of painful. This proposes to create a long press popup on a selected file with the following functions

• Check for Updates - polls Access to see there is a newer version of the file. If so it asks “There is a newer version of this file, Download and overwrite?” with a Yes No button option.
• Upload - Uploads the current file to Access under the same source project. The main use is to save precalced files.
• Rename - Allows file renaming. Use would probably be for retaining current copy on access while uploading calced version.
• Delete - Removes file - Ask for confirmation.

Delete is not something we do often but when we do need to, it's usually more than one file. This is a proposed change to the way the Delete Menu option works. The new flow is this:

• When a user presses Delete from the File Menu we display the list with checkboxes for multiple selection and have delete and cancels buttons at the bottom.

• Multiple files can be selected and when Delete is pressed, a confirmation appears.

Distance/Slope is a feature we had in the GradePilot software. What it does is this. The user picks the first point and then picks a second point as shown in the graphic below. At the top right the distance between the points displays. The triangle denotes that tapping there toggles the value to a slope. Slope is shown as slope percentage (%) until it reaches 10:1 and then it displays as a ratio.

Time to complete the work on images, started back in story 7. The following items need to be completely implemented:

• Re-enable images
• Implement the manual sheet selector
• Fix bugs
• Display thumbnails instead of tiles if zoomed out enough.

This expands the use of tracking by adding multiple tracks and the ability to attach notes to track segments. I'm imagining using the long press edit gesture from Measure to select track points and bring up a text box (w/ keyboard and microphone capability) to assign a note to a track.

The changes are these:

• We allow multiple tracks. Turning Track off/on no longer removes the last track from the screen.
• Those track lines can have lines assigned by long-pressing on the track line. When this happens we display this:

The first time the text is blank. The second time we leave the last label highlighted so any change overwrites it but if you're just marking power lines, you can just press save without reentering the label. We also want to support the microphone/ Google speech to text. Pressing Save, saves the label to the track. Pressing back exits without saving the label.

On saving the tracks we need to put the label and the separate tracks in the GPX. This is supported within GPX and I believe the track will be named by it when read into Google Earth. I don't believe LLA supports multiple tracks and labels. We will be transitioning the desktop software from lla to GPX in the very near term

The more complex part is probably how someone plays back or shows the note. I'm not sure the current label functionality in earthwork is right for the job.

Cost Codes first originated in SmartTrack for segmenting work into different buckets for associated costs. The next outgrowth of this is support for Cost Codes in SmartDirt and SmartPlan as well as a Foreman's Project Journal that aggregates events by day and Project. The Journal feature will likely be a separate app that is called by different apps and eventually the web.

• Cost Code Interface

Cost Codes are something that can be assigned to just about any user created data. They are optional but Tracks, photos, notes and measure areas all have the supporting interface. It also creates the need to support some project settings like the cost code list and time zone.

Adding a cost code to a photo is just a slight variation from naming your photos. Press and hold on the picture and it displays a window similar to the current version's naming options. Added to it is the control used in SmartTrack to code segments and notes. The Tracks and Notes are pretty much identical in function and interface.

Measure Areas have a little more information than other user created data but the interface is similar. The Measure Name is still the focus and highlighted when going into the panel.

When a User created Item has a cost code we show that code on the view list (SmartTracks does so with Segments and notes). It's just a quick way to see something is coded without opening it. See the example below.

The ADF format originated during our first attempts at mobile on Android phones. Over time we've added Smartplan and the information model that KMZ file output supports. Also, new to version 1.19 of Sitework 4D is the documentation layer which supports placemark-like behavior and html property sheets as well as annotation and perimeter line support in surfaces other than Design/Subgrade, Existing/Stripped.

The KMZ file's advantage over the original ADF is the property sheet (html) information that gives much more information than just the line information. The downside to it is much less control over content, lack of 3D information, poorer handling of image overlays. Combine that with the better than average chance that even the AGTEK KMZ output would be rewritten by Google Earth.

My goal is match the KMZ output capabilities and information while maintaining it's clear advantage in handling 3D information. The biggest drawback is that we currently use Google Earth for authoring content after the fact and will need to provide some tools in the desktop program (or web) to do so. KMZ outputs from Earthwork include the following:

(working list to be added to)

Support for ADF refactoring, support for image overlays and GE like property sheets/info. The link below is to a KMZ and ESW example of Pine Street that I believe has every data type contained in it.

File: Pine Street Everything 2per.esw https://agtek.s3.amazonaws.com/Agtek/VmPz1tBeYh0X

File: Pine Street Everything May-17.kmz https://agtek.s3.amazonaws.com/Agtek/CFyDPtK5iLuk

The primary change is that when an item that has Info is selected. The point/line label field is replaced by the item name, the elevation is no longer displayed, and an Info button (like smartplan) displays near where the elevation value was. Pressing Info displays the Webview like SmartPlan

The Journal is a collection of activities for a project by the day. It's accessed through the Journal option on the menu.

In some ways the information contained is the same info saved as a KMZ file or shown on the View list but it's organized differently and also has the capability to see any event that occurs on the project for the day rather than just that user's. It also contains extensive filtering and sorting to organize that data for the user. By default it shows the events in chronological order (Reverse Chron?). It could also be sorted by event type, have filters to only show certain events although all events are saved to the server.

The Journal is a log of events and SmartDirt and SmartPlan generate fairly straightforward events. An event happens whenever the user creates a Note, Track, Photo, or Measure area. It looks something like this.

My first thought is pressing and holding on an event would take us to the appropriate notes/code/name dialog so any desired editing could take place. I can also envision having line items that can be expanded but I don't think SmartDirt/SmartPlan would generate any event that required expansion. It's more likely SmartTrack with it's more voluminous statistics would be the first program to use it.

Events are what we put in the Journal so we have to know what constitutes an event. Here's a starting list

SmartDirt/SmartPlan Events

• Photos (with a name change (not photo 1, 2, 3) or cost code assigned)
• Tracks (all)
• Measure Areas (all)
• Notes (all)
• Journal Event (created on journal screen, not geographically tied)

Other App/SmartTrack Specific Events

• User Triggered Machine summary ( give me the stats for this time period and these machines)
• Segment Creation (end time of segment has already passed)
• End of Day event

The daily personal log is likely to be short enough that sorting is a more important function than filtering. When we get to a project log I can easily see the need to filter events. I may not care about every picture for example.

Work on interface for selection of what type of events to see.

Sorting by time (default most recent to oldest), event type (photos, measures, etc.)

New features Rev 1:

• Points are marked with different icons for snapped point compared to free entry
• Menu loses Undo, gains snap and Exit Measure. (I'm hoping Exit Measure will fit but it may not)
• Not shown but implied. Back button now removes last entered point

New features Rev 2:

• Point Edit. Point edit is hard to show as a mockup but here's a description of what it does.

Measure points can be long pressed. Longpressing generates a sound (chirp, beep, haptic vibration) and puts interface into edit mode. In edit mode, only the selected point can be dragged (change color of selected point?). The point shouldn't move with a tap, only a drag. This is to prevent inadvertent edits. To finish and end edit mode I'd like to try just tapping somewhere on the screen and see how that feels. Other options might be a LongPress, or a menu (least preferred). Pressing the back button cancels the edit.

If possible, it would be great to update the measure numbers during editing.

SmartDirt currently will create tracks but not save them. Now we have a sales request to save the tracks and my one beta user also requested that ability. The biggest problem is a lack of interface. My proposal is this. When goes to exit and has tracks, ask if he wants to save the tracks. If he says yes, take him to a version of our save dialog (layout and explanation to follow). If he says no, ask if he wants to release the key as it is now. It's a little bit of 20 questions but the best way I can imagine for now.

On a related note: I'm wondering if long term we want to use GPX instead of LLA as our track format. We can extend it, it automatically is readable into Google Earth, and other products can play it back. The downside is we would need to write a reader for Trackwork.

Here's a proposed screen. Compared to the other Save windows, here are some thoughts.

• I can't think of a reason to do Save As so I don't have that interface in here.
• A default name could be Track-Date. I thought of throwing job name in there but since we have a project name, I'm not sure it's necessary.
• Upload and Save are defaulted on. These might not be necessary as options but the case of where we don't have cell coverage means there needs to be a way to save it on the phone for later use.
• I'm thinking that we save LLA and a matching GPX file to bridge the time of switching to just GPX files in Trackwork, Earthwork, etc. Yes it will take more space but it covers the bases. It also points out a missing piece in SmartDirt that I omitted.

The user reads and ESW/ESZ file where the desktop software has georeferenced a PDF or bitmap to a NE type coordinate system. That process usually does a transformation to the PDF to match data or allow digitizing. (Note: Data other than the bitmap and benchmarks should not be required to be in the ADF. One use case is that an estimator reads the plans into Sitework prebid/pretakeoff and just georeferences it in Sitework.).

After saving the file the user either exports to ADF from Sitework (longer term) or reads the saved file into the ADF creator. Once in ADF Creator, the user exports the file to an ADF that includes the required PDF or bitmap and uploads the results to AGTEK Access. (Update: it looks like in the short term, converting PDF's in Android is non-trivial. The ADF creator on the other hand could use our existing PDF solution to write out bitmaps and store them in the ADF file. This seems like the easiest first pass. I'm torn if this belongs here or in the notes below.)

Once in AGTEK Access, the file is opened and the bitmap with any lines that might be present are displayed on the screen. Situations with no surfaces but a pdf need to be handled gracefully with no isopach/surface warnings. When both surfaces and a bitmap exist, show the cut/fill color (isopach) first but it may be necessary to delete the surface/isopach information if the user loads a pdf backgroud/bitmap.

The user can now walk over the PDF with an arrow showing his position. If he zooms in we try to show the best reasonable version of that bitmap (resampling?) we can while still being responsive. (Thought: if no data lines exist in the file except for benchmarks and the boundary, do we allow them to just pick a point on the screen and show the distance to that? It would be handy and lessen the need to do vector based PDF's as soon)

SideNotes:

There can be more than one PDF per esw but the desktop only allows display of one at time due to memory limitations. The SmartSuite Apps do not need to show more than one PDF at a time either and will require a method of switching pages but for now I'm satisfied with a single page.

• I don't need Vector PDF's for first pass
• As ugly as it is, we should also allow an emailed ADF file to start up either AGTEK program. I believe the OS allows for more than one association and prompts the user when a choice needs to be made.

• ADF file support for Georeferenced PDF and bitmap display.
• ADF creator support for ESZ files (zipped .esw with included pdf and bitmaps)
• SmartDirt/Grade display of PDF/Bitmaps georeferenced by desktop software (via ADF)

• AutoSwitching Sheets? Use the image boundary combined with current position to load. In case of overlaps, use the smaller of the two. Use of tags ala' Google maps to allow selection of sheets.
• In cases where there is no data other than benchmarks and the image, allow the user to pick a pixel for distance feedback.

Don't think you have to match my screen example slavishly. The examples out there are limited as far as knowing what's possible. The idea is that a user can choose the sheet displayed manually by pressing and holding within the sheet. After pressing and holding a bubble pops up with the possible sheets to load based on the location of the press. In this case there's a press within two sheet boundaries and we display the names of those two sheets. The one currently displayed is highlighted. Tapping a sheet name, loads the corresponding image.

The user wants to do a measure area but doesn't have a good idea of where the boundaries are in the file. (Remember this is a big empty field he's staring at). He decides to walk around what he can see has been done (earthmoving). He presses Menu, then Track and the program starts collecting points on the screen but not closer than 3 ft to the last one. He walks around the area of excavation and a line with points shows the path he walks. From that, he can now go into Measure mode and roughly trace his path to generate quantities. At any time he can turn off the tracks by picking Menu-Tracks and turning off the tracking

• The points and lines are not saved at this time and are strictly screen reference.
• We don't want to use the actual Track for measure, just as reference

• I'm hard-coding the collection distance on points to 3 feet without putting in an interface to change that. SmartSet/SmartGrade does have that in the spec but I'm not sure it's important here.

The after released story. These are features we can imagine being there but probably won't make it into the first release.

• 3D views (tied to position), (tied to motion sensor on the phone ala skyview?)

• Allow user toggle off the GPS using the existing icon. In this mode he can pan the view sideways with a side to side swipe, tilt the view (constrained to not go below ground) with a two finger up and down (ala google maps), Zoom in and out with pinch, and move on the surface using single finger swipe up and down.

The “completion” story. Final release features and polish.

• Easter Egg statistics on memory usage (or other measures) for optimizing.
• Remove Mesh display from non-developer versions
• 3D view(first implementation)
• Perform measurements
  • Line measurements (slope and planview length)
  • Path measurements (MC, I don't remember what this one is.)
  • Area measurements (slope and planview areas)
  • Volumetric measurements (this one could be slid back
    • Reporting, emailing reports
• View menu polish (shade increment, station offset)
• Memory optimization

• View change is triggered by selecting 3D from Menu.
• Positioning is based on GPS position. 10 feet in back of actual position with the direction matching the GPS arrow. (this may mean that we need to refine the direction to use GPS bearings in some situations.) The head position should be about 6 feet up.
• Exiting 3D view should be done via menu (planview, return to planview?)

• Measure mode is started by selection on the Main menu. It is exited by selecting “Map” on the Measure mode menu.
• Selecting measure mode changes the main screen views to support showing measurements and changes to menu to reflect the measure functionality. Functions include: Back, Clear, Report, and Map mode (in that order as well).
  • Back removes the last point ( I can't figure out a reasonable way to do this with a gesture.)
  • Clear removes all the points in a measure area.
  • Report displays a detailed report of the measure lengths and area (including slope values) with a different view, allows sending of the report in an email along with either a screenshot of the area or a KMZ (https://agtek.s3.amazonaws.com/Agtek/AK7iezbjp8yJ) of the area and data along with the reports.
  • Map exits Measure mode and returns to the main map screen.
• When measure mode is entered, a tap on the screen starts the measure area at that location. the second tap draws a line and shows the length of the line. Subsequent taps show the total length and the length of the last line segment. Also, at the third tap, the end and start points are connected with a white line signifying the closed area. At the third point, the area and cut-fill numbers also are calculated.

• Create interface and support for user specified shade increments.
• Add support for COGO line/Station-Offset to ADF and SmartDirt
• Hook up display of Station-Offset.

Under Settings create a “Put me here” option. It functions like this. I have an open file and pick a point on the screen. I press Menu-Settings and select “Put me here”. The transformation of GPS to job coordinates changes to put you on the spot that was picked. A second but probably more common path is to allow reading of files without benchmarks but allow the user to pick a point and do the same “Put me here option”. The assumption in this case is that North is North for rotation purposes.

Note: The bug in the 2.3 version of Android means that we probably have to have an alternative method of determining direction. Unchecking “Use Compass direction” means that we'll sample the GPS heading and use that for direction. Not optimal but the bug renders the 3D view virtually unusable for any view other than south. I had hoped this was a bug unique to Sprint but indications is that it's an Android 2.3.3 problem. Since users are pretty much at a carrier's mercy, we probably have to accommodate the problem for current and future users.

The “completion” story. This will add missing features not included in the previous stories. This will also add features required to productize the application.

• Perform measurements (moved from story 3)
  • Line measurements (slope and planview length)
  • Path measurements (MC, I don't remember what this one is.)
  • Area measurements (slope and planview areas)
  • Volumetric measurements (this one could be slid back
    • Reporting, emailing reports

• Copy protection / access key (technology TBD) (thoughts below)
  • We have the communication and login information incorporated as part of AGTEK Access.
  • We extend the AGTEK Access structure to accommodate keys available and a check in/check out mechanism.
  • The phones have unique ID's that we can use for checkin/checkout.
  • This also implies some additional interface for internal use to add keys, remove keys, and time monitoring.
• Integration into the production build.
• Obfuscator into the production huild.
• Work with Tech Pubs to craft user's guide

• Prompt to enter Login and Password
• Show keys available, In use. User selects key and program starts in File tabs (local)
• On program exit, ask if the user wishes to retain the key checkout.

Mockups of the View screens. To be implemented when the File replacement is available. You can ignore the PDF/Tiff transparency control (3rd image) for now.

The first “interactive” iteration where something interesting (to the user) is being shown. A user loads the plan and displays the site on his screen. He aligns the map, and may zoom in or out to bring interesting detail into view. After interrogating a few points, he decides to make a series of measurements on the screen; line, path, area. Finally he measures a volume from a cut area and from a fill area. Building on story 1, this version will display additional information on the plan (e.g. topo info). Requires the addition of meshing code.

• Expand the view menu to allow for zooming
• Expand the UI to allow for pinch zoom
• Display topographic information
• TBD ESW replacement
• AGTEK Access upload/download
  • Menu item “File” displays a tab view with two tabs. First tab (default) shows the local files. 2nd tab show the AGTEK Access Projects.
  • Within the individual tabs, a separate menu is available for Upload, Delete, Rename, email. (just delete implemented rev 1.)
  • In the local tab, tapping a job loads it.
  • In AGTEK Access tab, Show last project and files underneath it, then show other projects. The object is to show the most likely project and files you want while allowing the user to change projects easily. When a file is tapped, it downloads to the phone and local storage. Other operations (multiple downloads?) may be needed.

The first “color” iteration. A user loads a plan on his phone and displays the site. The application notices that there is no triangle mesh associated with this data set and prompts the user requesting for permission to produce the mesh (using appropriate user specific terminology). The task, being time intensive is forked as a background thread. When complete the mesh is cached on the local storage to allow for quick startup next time. The mesh is then used to display cut/fill information on the plan with the design lines. Building on story 1, this version will display design surface based on the plan file. This requires the addition of meshing code.

• Generate tri-mesh of the plan.
• Display design surface on the plan.

The core iteration. A user opens the application and loads a design file. Displays a plan showing only the design lines. The user can load the design, walk around and have the GPS track the location.

• Design read from AGT file
  • File may be hand loaded on the SD card for this iteration.
• Only show design lines
• Allow user to align the map
• Allow user to scroll manually.
• Zoom and Pan functionality
• Read GPS values, transform to NE/Screen positioning
• Investigate Triangle “port” or find new code.

The programmer's iteration. Provide basic application framework inside of Eclipse, checked into SVN.

• Basic program layout
• UI has “map view” drawing a simplified symbol on the screen (perhaps AGTEK logo)
• Integrated test to pave the way for real development.
• SVN tag == “Story_0”
• Integrate into build structure
• Develop Architectural overview
• Develop task lists for each story

• Shader support
• Report variations (instead of cut/fill color) Water flow, slopes (excessive slopes)
• Drone control? Flying Patterns