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)
|A||1.0||2.0||1||ASPHALT TYPE S4||2|
|A||1.0||2.0||2||ASPHALT TYPE S3||4|
Our question is whether anybody is already doing something like this and what are the potential pitfalls we would have to be careful about?
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:
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.
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.