This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
android:smartdirt:android_project_stories [2018/04/03 00:22] mikeclapp |
android:smartdirt:android_project_stories [2019/10/29 20:06] (current) mikeclapp [Story 17 - Adding Mapping] |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Story 16 - Adding RTK ====== | ||
+ | |||
+ | |||
+ | |||
+ | ===== Changes/addition of Save ===== | ||
+ | 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. | ||
+ | |||
+ | === Naming conventions === | ||
+ | There are different conventions on naming depending on the circumstance. A new job is straightforward and already functional with "New - Date-Time" | ||
+ | |||
+ | For an existing job we have a couple of | ||
+ | |||
+ | * Not overwrite our existing ADF file | ||
+ | * Try to keep the file name length reasonable | ||
+ | * Create an identifiable file association with the base file | ||
+ | |||
+ | We have a visible size limitation in the save window. My initial thought is to prepend "Surv 10-28-19 job-name.adf" as the filename leaving off the timestamp. In cases where the filename already exists we can warn of that fact but we also allow the user to edit this name. My thinking is it covers most cases. Within the same day we're likely to be adding data to the existing survey file so overwriting is not an issue. If it is the warning and allowing the user to edit should be sufficient. (Thoughts?) | ||
+ | |||
+ | |||
+ | === Combining with the ADF 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. | ||
+ | |||
+ | |||
+ | ==== Adding Share from Save to Measure screens ===== | ||
+ | |||
+ | We're currently adding a share option under the save for GCP's although we might switch the button to the universal share icon. We could also add this to measure screens with a different context than GCP files. Instead ideally we'd screen capture at the extents of the measure area and then add the text elements from the measure report screen as an addition. Sharing to email or text sends that picture attached with the measure report text. Sharing to dropbox creates the image and (text file, 2nd screenshot?). Let's think of likely context uses. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ====== Story 17 - Adding Mapping ====== | ||
+ | |||
+ | Button for map toggle beneath shoot when in RTK. Otherwise on the right side, even with the camera button on the other side. The map button works as follows (shown from IOS SmartTrack beta 1.4). Default view unless New is off (what should the default for new be, map or satellite?) | ||
+ | |||
+ | IOS interface for example. Button upper right | ||
+ | |||
+ | {{:android:smartdirt:ios_mapicon.png?200|}} | ||
+ | |||
+ | |||
+ | |||
+ | Tapping once brings up the map view | ||
+ | |||
+ | {{:android:smartdirt:iosmap.png?200|}} | ||
+ | |||
+ | |||
+ | Tapping again switches to satellite view | ||
+ | |||
+ | {{:android:smartdirt:iossatellite.jpg?200|}} | ||
+ | |||
+ | |||
+ | Pressing and holding on the map button in satellite displays the opacity control | ||
+ | |||
+ | {{:android:smartdirt:iostranspar1.png?200|}} | ||
+ | |||
+ | |||
+ | With full opacity set. | ||
+ | |||
+ | {{:android:smartdirt:iostranspar2.png?200|}} | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ====== Story 15 - Revisiting the View Menu ====== | ||
+ | |||
+ | 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. | ||
+ | |||
+ | ===== Current View Organization ===== | ||
+ | |||
+ | Our current View organization for products is: | ||
+ | |||
+ | === User Field Created objects - Tracks, Photos, Measures, Notes === | ||
+ | |||
+ | === ADF Data === | ||
+ | |||
+ | === View Controls === | ||
+ | |||
+ | |||
+ | ===== New View Organization ===== | ||
+ | |||
+ | |||
+ | === User Field Created objects === | ||
+ | * Tracks | ||
+ | * Photos | ||
+ | * Measures | ||
+ | * Notes | ||
+ | |||
+ | |||
+ | === ADF Data === | ||
+ | |||
+ | * **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 | ||
+ | * <del>Contour Lines | ||
+ | </del> 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 | ||
+ | |||
+ | |||
+ | |||
+ | === View Controls === | ||
+ | |||
+ | * Skip Cut/Fill model | ||
+ | * Map Background | ||
+ | * None | ||
+ | * Cut-fill color | ||
+ | * Image | ||
+ | * Color Increment | ||
+ | * Auto | ||
+ | |||
+ | |||
====== Story 14 - Measure Area Improvements ====== | ====== Story 14 - Measure Area Improvements ====== |