This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
windows:materials2018:materials-underground_revamp_planning_2018_desktop [2018/07/02 22:29] mikeclapp [Current Reports] |
windows:materials2018:materials-underground_revamp_planning_2018_desktop [2020/06/12 00:57] (current) mikeclapp [Version 1.06e (2nd Release)] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Materials (no 3D or 4D) ====== | + | ====== Materials/Underground (no 3D or 4D) ====== |
+ | |||
+ | ===== Version 1.06e (2nd Release) ===== | ||
+ | |||
+ | This is the followup to the initial release of Materials but also Underground and is intended to both clean up some unfinished issues and add functionality that was not done for the initial release. | ||
+ | |||
+ | |||
+ | * Curb and Gutter Output (Arc retention support) | ||
+ | * Phases on Materials | ||
+ | * Cost Code Lists (Access synced) | ||
+ | * Bidding Excel Outputs | ||
+ | * Bid2Win & HCSS (others?) | ||
+ | * Access Synced Structures and Materials lists | ||
+ | * Optimized KMZ files | ||
+ | * Phasing for Highway | ||
+ | * Applying Trenches to Templates | ||
+ | * More Standalone Materials and/or Underground | ||
+ | * Symbol Improvements | ||
+ | * Access synchronized Structures/Materials/Cost Code Lists | ||
+ | * COGO entry of pipe runs | ||
+ | * LandXML COGO output of pipe runs for Machine Control | ||
+ | * Calculator | ||
+ | |||
+ | |||
+ | Curb and Gutter Output (Arc retention support) | ||
+ | Phases on Materials | ||
+ | Cost Code Lists (Access synced) | ||
+ | Bidding Excel Outputs | ||
+ | Bid2Win & HCSS (others?) | ||
+ | Access Synced Structures and Materials lists | ||
+ | Optimized KMZ files | ||
+ | |||
+ | Phasing for Highway | ||
+ | Applying Trenches to Templates | ||
+ | |||
+ | More Standalone Materials and/or Underground | ||
+ | |||
+ | * Access synchronized Structures/Materials/Cost Code Lists | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Adding Cost Codes and Excel formatting to Materials/Underground ===== | ||
+ | |||
+ | |||
+ | ==== The parts ==== | ||
+ | |||
+ | Common Code Lists in Access. Downloadable and kept synced on startup | ||
+ | Increased Size of Structure Dialog. A | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | Do Phases choices in Materials section since we have to increase the size of the dialog anyway for this change. | ||
+ | |||
+ | ==== Importing cost code lists as Structures ===== | ||
+ | |||
+ | |||
+ | ===== User Flow ===== | ||
+ | |||
+ | The user has structures lists with Cost codes in them (ask Scott, is a code part of a structure or part of material or both) Upon startup if internet available, the progam checks the existing code lists against the code lists up there and downloads new ones as necessary. Code lists exist on the local machine, can be edited and uploaded there to the server. | ||
+ | |||
+ | |||
+ | ==== Bid2 Win Format Excel ===== | ||
+ | |||
+ | Bid2Win has a specific column format for export. | ||
+ | |||
+ | Column Value | ||
+ | |||
+ | A B C D G | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== Symbol import of SVG files ==== | ||
+ | |||
+ | We talked about making symbols earlier from SVG files and I verified the current way they can be added. Attached is a svg file that was just a SS manhole modified to have a solid center circle. If placed in the \AGTEK\Resources\Symbols folder on startup the program creates png equivalent. If Edit symbols within Materials is used it will appear there as an option but needs to be enabled on that list to be used. | ||
+ | |||
+ | Ideally we’d streamline the process by adding an import on the Symbols dialog and allow picking .svg and maybe .png files to import so the process is a little less opaque. I don’t anticipate supporting every sort of svg file because they can have everything from bitmaps to gradients within them and we would not be able to display them correctly. That said we can probably parse the file and just use the things we can read which is pretty rich and a better representation of most things drawn on plan sheets. | ||
+ | |||
+ | I see no reason for us to create functions to draw .svg files like the old materials. Inkscape is free and capable and there are plenty of others out there as well. We can also supplement it more icons ourselves. | ||
+ | |||
+ | FYI, I’m working on the story for code lists but that also includes storing Structures and Materials lists on the cloud. By reading Scott’s reply it looks like he’s mainly looking for codes on structures rather than Materials but I’m going to clarify that. The natural way to support code lists that follow the current patten of Materials and Structures is to have a Code list dialog similar to Materials on the Edit menu. From there we could import/export/upload and it would save to a .csv similar to what we do now. We’ll add the upload to the Materials and Structure dialogs as well but that will require us to build the support into the server for them. Not difficult since the pattern is already established but something we may stage later depending on timing. Also because we need to widen the Structure window to support a code list column, it’s probably also the time to add materials phasing that we’ve been planning for. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ====== Old Specification ====== | ||
+ | |||
+ | |||
+ | |||
+ | ** I no longer have any association with this program (MC) 9/25/2018 ** | ||
This a rewrite to a common codebase with Earthwork but it is a standalone program. There is no dependence on Sitework/Gradework and Underground is not integrated either. The basic concept is: | This a rewrite to a common codebase with Earthwork but it is a standalone program. There is no dependence on Sitework/Gradework and Underground is not integrated either. The basic concept is: | ||
Line 135: | Line 234: | ||
- | ===== Menus ===== | + | ====== Menus ====== |
^ Now | ^ Sitework | ^ 2018 | | | | ^ Now | ^ Sitework | ^ 2018 | | | | ||
Line 298: | Line 397: | ||
My proposal is that we add a Materials Layer. Not only does that allow segregated information that users can snap to but it also provides the beginning of a mechanism to tell the program to use an area also as a sectional area/report region. In this view we should also support the saved colors and patterns of the structures rather than the randomized ones currently done by Sitework. | My proposal is that we add a Materials Layer. Not only does that allow segregated information that users can snap to but it also provides the beginning of a mechanism to tell the program to use an area also as a sectional area/report region. In this view we should also support the saved colors and patterns of the structures rather than the randomized ones currently done by Sitework. | ||
+ | |||
+ | |||
+ | ====== Materials 1.1 Paving & Curb & Gutter workflow ====== | ||
+ | |||
+ | While Earthwork could have this functionality I'm going to argue that this belongs in Materials to broaden our Materials only market. It actually adds the first element of 3D as well and starts the trend to make Materials a full fledged product line. If the customer does have Sitework and Materials we can leverage capabilities like conform, etc. but it has to be allowed to work standalone. | ||
+ | |||
+ | ===== Intro ===== | ||
+ | Automated machine control systems use to just read a 3d Polyline and use that for guidance. They've evolved to require COGO representations instead and that includes two lines for the curb and the centerline for the stationing. That includes both horizontal and vertical COGO. The output mechanism of choice is LandXML. | ||
+ | |||
+ | While we can offer advantages to Leica paving systems the export model extends to other brands. Some of the chief Leica advantages are the ConX connection, the use of mobile apps in demo, and our support. | ||
+ | |||
+ | Our advantages are broadening a market to companies outside of earthwork, mobile app proliferation, and expansion of tracking to paving tracks. | ||
+ | |||
+ | |||
+ | ==== General workflow ==== | ||
+ | |||
+ | * Read the CAD File (geometry) | ||
+ | * Allow the user to tag by layer or individually geometry that's going to be used. | ||
+ | * Organize that data by work layer in Materials | ||
+ | * Ideally we'd retain this identified geometry using the same geometry even if we represent it onscreen as a polyline | ||
+ | * If the data is already 3D then we provide an interactive point review method on that data. If it isn't 3D or is wrong we provide an editing method ala' Sitework functionality to modify the line | ||
+ | * Create an Export LandXML dialog that not only allows layer export modification (color/name/inclusion) and include the capability to write it to ConX. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | Happy Path | ||
+ | |||
+ | CAD file contains necessary lines specified as COGO and has three-dimensions | ||
+ | |||
+ | |||
+ | ====Links to Test Plan Document==== | ||
+ | https://agtek.s3.amazonaws.com/Agtek/I3IsqbHipmgC | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||