[Neil Brammall]

Thanks for hosting @Tom Hughes, and thanks to everyone for your questions.

[Neil Brammall]

Thanks @Steven. Yes, you make a very important point about the need for persistent and unique identifiers to support interoperability. There’s quite a wide variety in how assets are ID’d at source, and how we manage this is currently very high on my list.

[Neil Brammall]

Thanks @DRossiter87 for the comment on wayleaves and easements. Yes, we’re certainly looking at representing “Zones of Interest”, which could encompass rights of access, into the data model.

[Neil Brammall]

Regarding outbound APIs @Tom Hughes – absolutely, we’re always open to thoughts and suggestions from this community, and would appreciate these insights.

 

[Neil Brammall]

Hi @Tom Hughes. Regarding collaboration and relationships. As I said, stakeholder engagement has probably been the most important part of the project to date. My colleague @holgerkessler is the stakeholder engagement lead, and he maintains a huge and evolving plan to track who we need to talk to and engage with. Our delivery partners at the London Mayor’s Office and Ordnance Survey have also maintained close relationships with the asset owners in the pilot areas.

I don’t think there’s an easy answer to this – for us it’s been about prioritising engagement above almost anything else, and spending lots of time and effort on talking, listening and engaging with anyone and everyone with an interest in this area.

Forums like this are great in providing a focal point, and a place to discuss and share – any way to get a receptive audience in one place is very welcome!

[Neil Brammall]

Hi @Mehran. There are no plans currently to extend NUAR beyond the initial use cases – that’s part of the “laser focus” on use cases that I referred to in my answer to Tom.

That’s not to say that the work going on with sensors etc. isn’t really exciting though, and our aim is to build the NUAR platform in a flexible way, so interoperability and extensibility are possible in the future, for instance if there’s a strong use case around sensor data and – most importantly – a strong desire for our stakeholders to take advantage of it.

[Neil Brammall]

Hi @Tom Hughes. Regarding identification and prioritisation of use cases, this was driven overwhelmingly by consultation with the stakeholders. It almost pains me to say this as a “Technical Advisor”, but stakeholder engagement has been by far the most important part of the project! We have listened to the pain points of a huge range of stakeholders, and identified use cases that are achievable and help to address those pain points. So, everything has been driven by consideration of the problems – so often it’s the other way around, with a cool solution being developed then finding a problem for it to solve (I’m also guilty of this, believe me!)

The other key thing is that, having identified our use cases, we’ve kept a laser focus on them – it’s so easy to get sidetracked, try to solve everything and end up solving nothing. 

[Neil Brammall]

Hi @Steven. (I remember meeting you at an ODI workshop some time ago, in the days when people gathered together in the same room!)

To take your questions one by one:

1. There are many different data models implemented by the different asset owners, and very little common ground between them. The challenge has been to map these many heterogeneous representations into the MUDDI conceptual model, and the future challenge is how to scale that. During the pilots we have worked intensively with individual asset owners to understand these mappings, and we have also tried to take a “step up” and identify common ground across different organisations in the same sector. As we move forward we’ll be looking to consolidate that common ground within sectors to come up with a standard set of mappings that we will have to make minor adjustments to as new asset owners come on board.

2. For the pilot, the data model has been implemented as a relational database, but early sandbox work did include some work with graph databases.

3. The NUAR data is at this stage is generally deemed to be at the “Group-based Access” point on the ODI data spectrum, i.e. accessible to authorised users only, with some locations and assets deemed to by highly sensitive and subject to greater access control.

 

[Neil Brammall]

Hi @Koye. The integration of datasets from different suppliers is one of the main challenges of this sort of combined platform. We’ve worked with dozens of asset owners during the pilots, and there is a real disparity between how data is represented and stored at source (quite understandably – the data held by asset owners needs to support many, many use cases and business processes of course, not just NUAR!)

We’re trying to manage this in two main ways:

– by adopting a harmonised data model (based on the evolving OGC MUDDI standard) that allows us to represent disparate source data in a standardised way

– by providing as much flexibility as possible in the ways that asset owners can provide data to the system

There are 700+ asset owners in the UK, so a one size fits all approach to ingesting data won’t work. The pilot projects have given us great confidence that, while this is a significant challenge, it is not insoluble.

 

Regards your question about an OS licence, this honestly isn’t my area, so I will need to take this offline. Our analysis of data requirements includes consideration of the background mapping of course, and this question also cuts across who will have access of course – initially, access will be to statutory undertakers and their supply chain.

[Neil Brammall]

Hi @DRossiter87. At this point in time we haven’t included Wayleaves and Easements in the pilot system. We have done some more generic work around representing “Zones of Interest” etc though, and this is an area that we continue to work on and refine. We’re very much aware that just the “centreline” of a linear asset isn’t always the full story from a safe dig point of view! What’s your view on representing wayleaves and easements specifically?

[Neil Brammall]

Hi Tom.

Regarding the pilot locations, it’s correct that a key reason was the ability to build on existing work, but the differences between the areas held great appeal as you say. Not only were we able to see differences between dense urban networks and sparser suburban and rural locations, but there were also real differences (and some similarities) between how data is represented in the two areas. These differences allowed us to build our understanding of how to visualise and interact with data in different locations, but also an understanding of the flexibility that we would need to provide for such a wide range of asset owners.

[Neil Brammall]

Good morning. As @Tom Hughes said, I’m here online and ready to answer any questions.