Featurization and Categories

1

Today we featurize data using Layers, colors, names, and then we add site improvements to provide materials to those feature areas or feature lengths. We use tools like Smart Edit to join lines, break lines, trim or extend lines etc, we use relayer or standardize or smart edit to relayer the data, we use the properties pane to rename or name lines, we use later Manager or properties pane to colorize the data, we use MSI Library to define SIs and Materials and we assign those SIs to areas bounded by lines or to lines or points etc to complete the process or we use Categorize Layers to put the layers into categories and then assign SIs in that process. Then we run reports to determine the sectional or earthwork quantities.

A new process is coming that we are terming Featurization. You define the features once and centrally and these can be used over and over or copied and modified on projects. Features contain pay item details and how items get paid, but contain the quantities to help you bid the pay items. Once defined you simply featurize and object - could be a point a line or a polygon and the quantities are derived automatically.

I have a question - Features can have a Type, a Category and a Sub Category. There are currently two groupings - one for Utilities and one for Other Features (pavement, sidewalk, curb, pad, fence, silt fence etc.).

How do you think you would structure your Features using these parameters. Features can have attributes and Materials but sometimes material may be used as a category like Pavement - Concrete or pavement - asphalt or pipe - RCP or Pipe - HDPE etc. Size can be an attribute or part of a feature name like Pipe - RCP - 36ā€ - it is OK to ise it in the name but we donā€™t understand the name, we understand the material and the attributes like Rim Elev or Invert Elev or Diameter or Wall Thickness or Span or Rise or R(T) R(B) or R(C) for elliptical Pipe.

Appreciate that this is a loaded question and without knowing g the detail or trying it out it is hard for tou to know most likely, but shoot from the hip here and let us know how you think

You can have libraries for different DOTs or clients so you are not going to be limited to one way of doing things for all projects, and I am 100% sure as you start to use the Feature Based process you will change your mind at least 10x before you settle on one approach

I have to start you off with a master library and I want to see what you guys would want to start out with and how you would organize this yourselves if you had to start somewhere.

Categories and Sub Categories are used to organize Features for storage and recall but also for reporting purposes - you can sort and filter reports using these parameters. All features can have a full name and a short name, and when featurizing you can enter the shortname to select the feature eg CB for Curb or CB7 for Curb Type 7 or EOP or CL or FL or SW or PAD or SF for Silt Fence or EXCON for Existing Contour etc.

Let us know what you think

Alan

1 Like
2

If I understand correctly, you would have a ā€˜featureā€™ that is applied to a given data type - for example, If I say Type A curb that would be categorized and associated with a line + area based site improvement for concrete volume. Your process would skip a couple steps and just select the line object and ā€˜featureā€™ and it would then be included in a report for quantities?

Asphalt area would be similar but select a closed line object and the feature for what would have been an area-based site improvement.

For a utility, you could include other details in the ā€˜featureā€™ - pipe quantity per stick length, user inputs pipe dimensions and trench width, bedding quantity, backfill volume excluding pipe volume.

So this would be a quantities-only, 2D takeoff process?

3

2D for sure but also we are heading to 3D also.

Your other comments are correct

Alan

4

If I am following correctly, I think flexibility to create oneā€™s own criteria is most powerful, while following standards like count-length-area, etc.. (Add criteria to include surfaces statistics reporting as well, primarily 3D surface area!!!) Layers are great, but the same layer driven feature could exist in multiple phases or portions of construction.

I think to the estimating software that we use and some reporting requirements are different based on project funding. We might have to break a project and its associated pay items up into multiple groups pending funding sources (on the design side). # LFT of curb gets associated to this contract, # SYD of concrete walk, 6in may be fixed to this phase, # acres of clearing need to be applied to this work order. And it isnā€™t always cut and dry that it can be split by a referenced area/boundary like the ā€œarea of interestā€.

My most common design sub-grouping is typically split between existing cond, demo, plan/site, structure(s), utility and restoration.

Ideally it would be interesting to setup a central job template that laid out 1:project , 2:contract (or) phase and then 3:sub could be the pay item. Being able to split the pay items into design grouping or a different filtering would be beneficial as well.

If you could manage to have a library, I would setup a library of the pay items (broke down on how the item type would be measured/computed and in what unit). I often wouldnā€™t worry about materials as most pay items address the material. Then as I work through the project, I could copy in the pay item and apply as I design (or prepare a bid takeoff), and finally export full breakdown for estimate/bid. There may be some benefit to being able to apply more than one pay item to an object as well. You can always copy the item, but sometimes removal and replacement can be directly associated to the same object or multiple lifts can (HMA, AGG BASE, ETC) could be figured for one polygon.

A bonus would be able to associate the final pay item measurement type back to labeling too. Say for example ā€œclearing and grubbingā€ is set to handle by area with unit acre and can be associated with a closed polygon or surface. Then being able to add a label to that item displayed in its pay item unit (acreage) would be pretty handy. It would also be pretty cool to be able to filter display by category/subcategory, so you can quickly check your work (or) make sure you didnā€™t misfeaturize an item.

I understand much of these thoughts overlap with the existing MSI manager. Sounds like you are working up something pretty cool.