Walk this way: building a footpath decision support tool (part one)
Today is the first in a new series of posts, going behind the scenes of the development of a decision support tool. A tool that is designed to help identify where work needs to be done on the footpath network.
I started working on this a little while back, and have picked it up again recently. And I have decided to blog about its work-in-progress development, discussing and tracking along with the key milestones reached along the way.
Part one starts below, and looks at the why behind the tool, the important process of coming up with a name, and the reuse of some previous development work as a component of the solution.
Let's start with why
Condition and fault data is a mainstay of asset information management, and for some time, I have thought it would be neat to have an in-house treatment selection tool.
The idea really started to bubble away when I got some inspiration from this question posted on the IPWEA Asset Management discussion board. The question was posed about ways to do a rolling analysis of footpaths.
So the basic idea was to (virtually) walk down every path on the network, and at every one-metre increment, stop and assess a given length of path ahead. And this would happen regardless of changes to the asset underneath. This means if the analysis section length spanned three different slabs of path constructed at different times, they would still be evaluated as a single section.
The example provided in that post was; "along a straight stretch of road” each section “would be measured from 0-50m, 1-51m, 2-52m, 3-53m etc."
Thinking this was an exciting challenge, I set about solving the core problem, by developing a unique methodology applied in a RAMM context. This would be using footpath inventory data typically found in the RAMM databases of road-controlling authorities across New Zealand.
To summarise the tool's general premise, it will dynamically generate candidate maintenance and renewal treatment sites across the network, regardless of changes to the underlying footpath asset (within the given segment). It will bring together the footpath asset inventory and fault data collected for the network, and evaluate these inputs to determine a candidate list of work sites.
Defining a simple guiding principle for the project
The key guiding principle for this project is to build a lightweight (in a good way) decision-support tool. A tool that will;
wrangle the data you probably already have now (or can obtain relatively cheaply)
deliver valuable and actionable insights across the entire network
have a low implementation burden on the client
do the heavy lifting on the analysis front so the client can invest their time in making the important decisions
and can be provided at a relatively low cost.
So, a lightweight, low-cost tool to deliver actionable insights. Sounds great. But what are we going to call this thing?
Is a project really a project without a codename?
Before this work was put out into the world, this project needed a codename. And it needed one for two reasons;
I am a fan of using codenames for internal projects here at The Datastack.
There is an essential prerequisite for any decision support tool in the NZ infrastructure asset management industry; it MUST have some convoluted or ambiguous acronym for its name.
The name would need to reference the idea of segmenting assets to identify candidate treatment sections. That is an essential outcome of the tool; where does the data tell us we need to do work on the network?
So, I spent a comprehensive four to five minutes brainstorming some ideas. And many iterations came up along the way.
In close second place was PASTA - the Pathways Asset Segmentation and Treatment App.
But this ultimately had too much of a culinary flavour to it, if you know what I mean.
So after much deliberation over a single coffee (hey… it was just a four to five minute brainstorming session after all), I landed on assetSTART, the asset Segmentation, Treatment And Ranking Tool.
Yes, that will do the trick nicely. By using asset in the name rather than something more path-centric, it can be easily adapted for other assets later on down the line.
Having just saved $5,000 on branding costs while somehow also simultaneously proving why investing in branding is a worthwhile endeavour, it was time to start tackling some of the problems. And to tackle the first part of the solution, I looked at my existing toolkit of solutions.
Solving the problem of segmentation
One of the critical elements of the core idea is how the path network is to be segmented.
The footpath assets in RAMM are typically defined based on homogenous sections of paths, i.e., a length of contiguous footpath constructed of a particular material on a particular date.
And along a given road, these can create a patchwork-esque effect, as sections of the original asset are replaced over time.
So, we need to use the footpath inventory data to tell us where the assets are. But at the same time, we want to ignore the changes in assets for creating our broader analysis segments.
Enter the Linear Entity Segmentation Algorithm, or LESA (refer to discussion of ambiguous acronyms above).
Applying LESA to the path network
I have written about LESA previously here. This is a tool I developed to segment linear objects into smaller segments of a length of your choosing.
To provide a refresher on what it does, in the original blog post, I used an example of a road that is 600m long.
And LESA can segment this into smaller sections, such as 200m lengths.
This is an excellent foundation for assetSTART as LESA can provide the core segmentation logic. LESA was always designed to segment linear things like roads, treatment lengths and footpaths. So it is immediately relevant to the path network.
One adaptation for inclusion in assetSTART is to segment starting from every metre down the path iteratively, so it’s LESA 1.5 in some respects.
And that is a wrap on this first look at assetSTART. Keep an eye out for part 2, where we will continue to dive into the development of the assetSTART solution!
