Do you use concurrent Event Records?

[SamuelColdiron]

This is an exploratory question. We are playing with the idea of tracking our Base and Surface materials as stacked records to better represent how they are in real life.

Currently, we have a Base Event that tracks Base Type and Thickness. Then we have a Surface Event that has columns for Exposed Surface, Primary Surface (the predominant material), Original Surface, and then total thickness. So you have one Base Event record that spans the segment and one Surface Event record that spans the segment. This gets us most of the information we need, but you don't have the full picture of all the potential layers of material between the base and the exposed surface.

What we want to do is have an Event that has three columns, Surface Layer (where in the stack is this record of material), Surface Type, and Thickness. That would give you multiple live event records on top of each other; in essence Concurrent Event Records.

NEW SURFACE EVENT (Made up data)

ROUTE_ID	FROM_MEASURE	TO_MEASURE	LAYER	TYPE	THICKNESS
A	1.0	2.0	BASE	HOT SAND	4
A	1.0	2.0	1	ASPHALT TYPE S4	2
A	1.0	2.0	2	ASPHALT TYPE S3	4
A	1.0	2.0	3	ARMOR COAT	0.25
A	1.0	2.0	4	ARMOR COAT	0.5

Our question is whether anybody is already doing something like this and what are the potential pitfalls we would have to be careful about?

[KyleGonterwitz]

we do this in Kansas.  Here is a link to our web service of pavement layers for our state highway system.  We can group up the distinct material types into base and surface categories for HPMS from this detailed layer with lookup tables and stored procedures.

Layer: Pavement Layers (ID: 0)  - here is a link to our old system of managing pavement layers using EXOR, we are doing it a little differently in Roads and Highways - now we will track actions applied to a pavement layer starting point, and apply the action to that layer starting point forward in time to create a view of the current existing pavement materials.  

Things to consider:

• keep a sequence (like your "LAYER") from bottom to top or top to bottom and consider what will happen with a mill and overlay.  You will cut into the top layer or more.
• Mill and overlay are "actions" to the pavement. If you recycle pavement, that can be a distinct material type, you may want to keep information about the material recycled and how many recycles occur form some "original" pavement material.
• Other actions might include replacing dowels and/or joints of concrete slabs, or seals, which we sometimes consider "0 depth" and we don't want to report seals as a surface material.
• You definitely should want to track pavement layer dates as well as major grading dates, project numbers, and project stationings. 
• Major grading activities might be considered a layer and that activity wipes out all existing layers
• you cant edit pavement layers out of temporal sequence - it just cant be done.  If you find you missed a layer due to a project, you will have to re-enter the layers from the bottom up in the temporal sequence they were put down.
• We used to always do full width mill/overlays, but these days we are doing smaller cross sectional pavement jobs or adding passing lanes, we would want to track the cross sectional width and center line offset of the pavement jobs for projects that aren't the full pavement width.
• As you overlay and overlay and overlay over a period of time, the available pavement width will decrease, it becomes the shape of a trapezoid, another argument for tracking width.  

I've got a lot more details I could share offline about how we are doing this now, this is what comes to mind in terms of ideas and potential pitfalls.

[RyanKoschatzky]

Samuel,

Interesting, a few thoughts as I percolate on the idea, the domain list for layer and especially type might get to long and that could lead to selection of incorrect types. Secondary the QC to ensure that doesn’t happen might be too complex and/or time intense.

Depending on construction techniques (really stepping outside my knowledge base) the events changes might be at more intervals and time than the data model can support as one event at least conceptually in my mind.

I could see breaking out the pavement event to include more event tables: ie Seal Coat, Surface, Binder, Base Subbase etc. Then creating a product outside R&H that overlays the events onto the linework. Calculate a field that takes into account all the pavement layers and gives the total for that segment.  

Also, just spit balling, why not also add in a date field, you can capture when the material was applied.

I don’t think you should call it surface event as it is more than just that. Something like pavement event might be more appropriate to encompass all aspects of the event.