Data-Centric Product Interoperability with Autodesk Data Exchange SDK: A Beginner's Introduction for Developers

GIULIO PAGAN: Hi, everyone. And welcome to this class for beginners, for developers, and power users, where we'll hopefully learn about the Autodesk Data Exchange SDK. And before we move on, I'll use the usual safe harbor statement. Please do not take decisions based on what you see here. I think you're all familiar with the content. I'll leave you just to give you a second to have a look. And then I will introduce myself.

So my name is Giulio. I'm a solution architect working for Autodesk Consulting and based in UK. My background is aeronautical engineering. But I've been working for a long time now in software engineering and solution architecture. And I've been working many years at Autodesk.

So I'm familiar with most of the products. But I've been working quite-- I've been quite excited to work in the last few years on some of the new APIs and the Autodesk platform in particular. So I will now let-- I am here today with one colleague and a customer. So I'll let them introduce themselves.

GAURAV BHAMRE: Right. Thanks, Giulio. Hello, everyone. My name is Gaurav Bhamre. I am the product manager at Autodesk. I've been at Autodesk for now three years and working under the Autodesk Platform Services cohort. Our focus is towards creating interoperable solutions or interoperability solutions. Before this, I used to be an ACC specialist working on BIM technologies, construction technologies, and BIM workflows. That's all about me. I'd like to hand it over to Puria.

PURIA SAFARI HESARI: Hi, everyone. My name is Puria Safari. I'm a senior computational design lead at Ramboll and a self-taught developer. I have been in the industry for almost 10 years and with Ramboll for the past six years.

And I have had the opportunity to work with a lot of development projects, both in Ramboll but also other companies. And this could include plugin development for various softwares, but also extensive experience with interoperability tools for in-house use within different companies.

On the session, we're going to look into the bigger picture. And then we're going to look at the Autodesk Data Exchange concepts. We're going to quickly have an overview of the demo scenario that we're going to present here and then how you configure your environment to get set up using the SDK. And then we're going to look at the results that the demo creates. And we're going to, at the end, take you towards where you can find more information, when to use the SDK, but also a bit on the SDK roadmap, as it's currently in the beta stage.

But before doing that, I just wanted to use the opportunity to give you an overview about Ramboll. Ramboll is a large company with over 18,000 employees across 35 countries. We have an architecture, engineering, and consultancy services in house.

The company was founded in Denmark back in 1945, so getting close to 80 years old. We're presence in the Nordics, UK, North America, Europe, and Asia. And our main focus areas are within buildings, transport, energy, environmental health, water, consulting, and architecture. And the company is a foundation-owned company. So it's owned by the Ramboll Foundation.

And so our vision and how we got into this and using Data Exchange and so on is that we have decided to try to reach by 2025 an adopted data-centric approach to how we deliver projects. And what we mean-- how we want this to be, how we want the solution to look like is that we want our data to be an open resource and not tied to a specific application.

We want the data to be readily accessible through a single source of truth. We want the data to be easily exchanged across applications. We want the data to be suitable to support sustainability metrics for analytics. And we also want the data to be actively managed and controlled so that we have consistency across our data.

GIULIO PAGAN: All right. And now, let's take a small step back. And let's try to explain what has driven this vision, this need for better data management. A lot of the concerns that you see here are still present. And it won't be difficult to address all the areas which you see highlighted on the right side.

Common issues are associated to a lost design intent or reduced trust in data or aging data. So data is not refreshed enough for use or uncertainty on projects, the project status, or certainly, a worst scenario, a data which is not fit for purpose. So in a nutshell, the information does not always, in many cases, flow properly. And that results in some of issues you see listed here.

So in order to meet Ramboll's vision, we need something new. We need to change something. And the focus here is in trying to increase the usability of the data and provide technology which will allow us to define newer, better workflows-- so effectively, a linear data management-- and also enable a centralized control.

The picture shows-- depicts what we define sometime as a digital thread. What that means is that the information has to be available across all different phases of a construction. And it has to be available in such a way so that information can flow downstream and upstream. And in reality, what happens very often, that this flow is just not possible. It just happens in one direction, but maybe not the other.

So going back to the big picture that Ramboll wants to achieve-- we think there is an alignment here between what Autodesk is doing when it comes to interoperability and what Ramboll wants to achieve within the next few years. We're going to focus this class here on interoperability, which is one aspect of all of this.

And what you see here is, again, a representation, different representation of a problem. We just mentioned, there is a large ecosystem of applications which, one way or another, they do talk to each other, typically exchanging files. But they very often hit rocks on the way, which translates into delays in the workflow. And in the worst cases, there is a loss of quality.

Now, what we hope to achieve is to basically streamline all of this and, a bit at a time, enable more and more workflows, which exchange data in a better way, in a more granular way. And I will explain a bit better what that means. This high interoperability data hub concept rotates around the idea of having data at the center, provided in a vendor-neutral way.

And this way, this is really about a new way to manage data. It's not about a specific use case, even if you see, you can see on the left, the typical use cases would be about data extraction, exchange model coordination, maybe, more specifically. But they are quite generic scenario, which you may find in any stage in a construction industry. And you also find out that this problem is across markets.

The journey is complex. But you can see some of the potential benefits on the right side. So that's what we hope to achieve starting with the tools which we have at our disposal. So today, we have already a significant number of APIs, some older than others. And especially, the older ones are designed or have been designed in the past for a system which is almost exclusively operating with files.

Now, more recently, certain APIs allow us to go further. So some of you may have already come across the design automation API that has been-- by putting products in the cloud, it allows you to automate repetitive tasks. And you can have access to a lot of product functionality-- very powerful, but of course, limited by the fact that it's very specific to certain products.

Model Properties historically came out with its own limitations but its own advantages as well. But it was probably a first API which was trying to provide a better access and easier access to the data.

Now, I would say, I would tend to call the last two as a kind of latest generation. We are very new. We have a Data Model API and Data Exchange API and associated SDK.

Now, all of these can be used in some cases, in similar scenarios. But we're going to see in a table. We put together a table for you to understand a bit more the differences. This class will focus on the Data Exchange API and SDK in particular.

So in one slide, you can see that each way to manage data using the API can be associated with different value proposition. So whether the Model Derivative API is perhaps more suitable nowadays to translate formats, there are APIs like the Autodesk Data Models API, the Model Properties, and Data Exchange, which have much better with granular data. As we said before, this class will focus on the SDK for Data Exchange, which is particularly suitable for solving interoperability issues.

I will let you now take your time to read this. Sometime, we are approached by questions on which one is for what. And unfortunately, it's not a black and white answer. There is an overlapping. And I believe that as we move forward, it will be also more clarity as we move towards a more data-centric approach for a platform.

Now, I'm going to switch topics a second. And I'm going to show a new way to think about the data. Sorry, just skipped one slide. Let me go back. OK. Animation is tricking me here. But basically, if we start with idea of a model represented by nodes, where instead of thinking about a file as the ultimate repository for the data, for the design, we can think of this in a slightly different way.

And now, we have nodes, which represent entities. And these entities are linked. They may be linked by relationship, the relationship between nodes. In this way, you can think of a house as a bunch of nodes each linked to each other. And then that allows you to also more easily split the house into its entities.

And ultimately, this is the most interesting part. This way of thinking about a model makes it easier for people to consume the data because the reality is even if your house is useful as it is, different people will need to look at different parts of the house. Some might be more interested in the roof, some more interested in the windows, and so on. But ultimately, Data Exchange and the Model API look at the data in this way, which is why we are showing this more innovative way to look at data.

And in this context, now, we're getting to the nitty gritty, if you want, of the class. We're going to explore, with help from Puria from Ramboll, the Autodesk Data Exchange SDK, which allows developers to extend what we call the interoperable landscape. So we saw that in the previous slide before. And why? That's because there is the innovate. Autodesk Data Exchange come with a number of out-of-the-box connectors. But the problem is that the SDK will allow partners, customers, and Autodesk to create more and more connectors.

What can you do at the moment? Well, it can be used to create new connections between. And if there are connections not between application A and application B, but they are-- the way they get connected in B is via the platform. This is important to understand that.

The SDK allows you to load, unload, and manage data exchanges and to navigate hubs, projects and folders-- so concepts that you should be familiar with if you've been using Autodesk Construction Cloud. You can read data in the exchanges. And we will explain a bit better maybe what the exchange is. And you can manipulate the data and ultimately improve this flow, which is at the heart of the challenge.

It's also possible to work with specific versions of exchange, which means that the data might flow from A to B once. But then when changes occur, it's possible to track what has changed through revisions. So this is how often this exchange is represented-- so again as an ecosystem applications, but all connected to a same platform.

Now, another important concept that I would like to mention very quickly is the ACS pattern. So we talked briefly about nodes. And then we mentioned entities. But an entity can really be all of these things you can see represented here. You can have a collection of entities. And this collection may contain components.

Components contain assets. Assets could contain subcomponents. And then you have a space, which is a logical way to group assets. And then you can have, when you have the data, some of the data of a model represents a snapshot. And you can have each snapshot can be associated to a revision.

If you have a basic concept-- because this will pop out later on when we dive into the demo. So when we look at the SDK for this exchange, you will come across the definition of parameters, which are well-defined properties which correspond to a schema definition. Then you will come across the concept of geometries. Geometries can be BREP, Boundary Representation models. There are also meshes, which are supported in primitive geometries.

And the SDK provides classes for creating, manipulating primitives and for reading and writing, to an extent, BREPs meshes. Elements are wrapped around what we call an asset. And they can hold the reference to also child elements. So it is possible to also create nested structures. And you will see, later on, in the examples, the elements are grouped together in a collection, which we call element data model object.

There is a few more definitions. But this is just to highlight that, basically, starting from the left, you have a Revit file. A Revit file contains a lot of data. So the advantages we have with Autodesk Data Exchange is that we can take some of the data, put it in what we call Data Exchange. And Data Exchange contains data as in a collection of assets.

Through what we call a fulfillment, this collection of assets goes into an exchange snapshot. And it's stored somewhere in the platform. This is when we talk about model store space. This is where this data is extracted. And it's stored in the platform.

And the way it leaves is in shape of snapshots. These snapshots contains a number of instance assets, which are mapped to assets. And this allows the tracking of a history.

I think this is one more slide. And then we can start to have a bit more fun, hopefully, just looking at the code associated with this. An element can contain geometry and/or instance parameters. And the instance parameters can be built-in or custom. The difference is in the schema definition. But they are, at the moment, managed in the same way using the SDK.

The geometry can be a BREP, a mesh, and a primitive. And we currently support, if I'm correct, OBJ and Step on input-- on output. On input, maybe an IFC as well. Primitives can be all those. And there are APIs which would allow you to potentially create some of these primitives. And now, I'm going to let my friend Puria describe the concepts behind the demo.

PURIA SAFARI HESARI: Great. Thanks, Giulio. So the demo itself is a very, very simple console app, which partially automates the creation of a new exchange which contains data from multiple sources. So what do I mean by that?

As you can see here on the slide, we basically have a designer which works on a project as an example and has decided to share a part of the design or the entire design with another party. This might be another colleague inside the company or it might be a third, a kind of a collaborator, another company, a third-party vendor. It could be any third-party user here.

And before doing that, we want to enrich the data and merge or append data to the existing data that the designer is sharing. In this case, the data sits in an Excel file. But this could really be anything. It could be a database. Or it could come from another model and so on.

The console app is doing the processing. And it utilizes this exchange and takes the data, the Excel data, and append the necessary additional data to the shared design, and creates a new exchange out of that. Once we have this new exchange, it can now be shared with another designer. Or you can create as an example. You can create a report out of it in Power BI.

And so the workflow itself can be divided into three steps. The top one here is basically the designer creating the exchange. So it's basically an ask. And there is data shared here that includes walls in a form of an exchange, and the middle one, which is the part that we're going to focus the most on. And what the code is about is basically reading the exchange and the data. And it reads the Excel data and merges those into a new exchange and creates a new exchange on the ACC, basically.

And as the last part, where you can see at the bottom of the page here, we can basically access this, the new exchange, and do what sort of fun we want to do with it. In this case, we're looking at it using Power BI, where we can create a dashboard and visualize or use the added and merged data.

The program or the console application itself consists of four main parts. We have the program, which is the entry point for the code and communicates with the other parts and the demo configuration. It's just using this authorization to create a configuration object. We will look a bit more in detail into this, as we need a set of IDs and identifiers for authentication, et cetera, to be able to connect to the exchange.

So the configuration part is only doing that and creates an object so that it can be used in the program. And then we have the Data Exchange helper, which contains the calls to the Data Exchange SDK, such as read or write. And then we have the Excel helper here, which uses an open XML API to read the data from an Excel file. But bear in mind that this is just for the purpose of the demo. This could as well be a database or another source where you get the data from.

So in order to get started, we need to register on an app on the Autodesk Platform Services. And for the purpose of this demo, we're going to use the .NET SDK, which is a client-side SDK for the Data Exchange Services. And it's written in .NET, as you see on the slide. And it provides a data model for automatic handling of read and write deltas and the local storage for optimizing data operations. So that's what we're going to focus on.

In order to get started, if you don't have an account yet, you need to sign up. And you need to create an app on the Autodesk Platform Services. It's fairly a straightforward procedure. You have some links here provided on this slide that you can follow in order to get set up. But one thing that is important to mention is the callback URL. And that needs to be set to the localhost 88. And this is for the purpose when you're running this locally. And it's used for the three-legged authentication when you connect to the ACC.

So in order to get ready and set up the demo code, you need to download the Data Exchange SDK, the one that we saw on one of the slides earlier. And you need to get hold of the demo code that we provide you in this class. And you can use-- you can download the entire code from the repository and use that.

You need to open the demo project in the Visual Studio code. And then there is a bit of an instruction in terms of setting up packages that the console application uses. So we need to create a package source for the SDK so that it becomes available to the Nugget package in Visual Studio.

There is a link here as well for the detailed steps on how to do this. And then you need to build the code using the .NET framework 4.8. And then you should be pretty much ready to go.

So going back to the configuration object that I talked about earlier-- in order to connect to the ACC and be able to read exchanges and create exchanges, you need a set of variables to use. You can see the variables that are needed that we have put together to be used for this console application. You see the exchange file URL, which is a unique identifier for the exchange.

The class name does not necessarily need to sit here. But it's just a Revit class that is used to filter out the elements that we're interested in the demo, in the console app. The Excel that we use as the replacement for the database or the data source-- and it's just the file name of that Excel file.

We have the application name. This is basically the application that you created on the Autodesk Platform Services. Then we have-- once you do that, you get a client ID, which is the client ID here, and also a client secret, which is given to you through the app that you create, and then the callback, which is what we touched upon earlier, that you need to set to localhost 88.

We also need the Hub ID, which identifies the ACC hub, the project ID, which is, in our case, is a test project set up for the demo, and the folder, where basically the folder that contains the existing exchange, and the new exchange name. So if you remember the high-level description of the console app, we're going to use an exchange and enrich that or append data to that and create a new exchange. And this is basically the name of that new exchange.

I also just want to give you the tips that you can use the other API, which was the GraphQL API, for reading the data and for querying data from an exchange. We have also created a simple model in Revit using Revit 2024 as the exchange that we start with. And this acts as the model that the designer first shares with another party. And the program is basically using this model, or an exchange created from this model, to append data to it and to create the new model. So this is also provided to you. You can use straight out of the box.

Now, looking into the code, the main program is what we talked about earlier. This is what we have here. It consists of six simple steps. And the first step is basically using the JSON file that we talked about earlier with all the variables that we need and creates a-- and basically deserialize that and creates an object for us to be able to access the variables.

In the second step, we're basically reading the Excel data, as we talked about earlier. We will look into this later on in detail. Then we have the third step, which connects to the exchange and reads the existing data exchange. And then we-- yeah, I think I put the step 3 and 4 together there. The step 3 is actually the connection to the exchange and to the ACC. And the fourth step is reading the data from a specific exchange.

And on the fifth step, we're creating a new exchange, into which we want to put the data from the existing exchange, but also from the Excel file. And that happens on the step 6, where the new exchange is created and a new viewable is generated. But we look into that in detail.

So moving on, we have the JSON file that we talked about earlier. This is what it would look like. Good thing-- sorry, a quick thing to mention on the last one is probably remember to not expose this. Because these are your-- the details that gives you the permission to access the exchanges and to create or read the exchanges on your ACC. So be sure to not commit this when you use the code. And you will also see that this is not provided in the code.

And moving on to the next one, this is basically the step 2, where we just using the open XML, reading the Excel data, and put that into a data table. I don't think we need to spend a lot of time in that.

Here is basically the step 3, where we connect to ACC and to our data exchange. We use some of those variables that we talked about earlier-- the application name, which you get by creating the app on the Autodesk Platform Services, and the client ID, the client secret, and the callback. You get all that through-- you configure all that. And you get access to those variables once you set up the app. And so we use those to create the client object here, which is what's going to be used throughout the rest of the demo to connect and to communicate with our exchange.

So moving into the step 4, this is where we're reading the data from an existing exchange. And so as you can see, we're getting the exchange details by using the client object that we earlier touched upon. And we're basically getting the projects in the hub. And then we're looking for the ID for the specific project that we're interested in. And this is a workaround currently for the SDK Version 4.00.4. However, at the point of the actual presentation in AU, this might have been changed or bumped up. But for AU, the best thing is to follow the documentations and the website to see the latest build and so on.

Using this, we define-- we can access a specific exchange. And we can get the exchange data for that specific exchange, which you see on the left. And in this step, we're basically having a-- continuing on this step 4 once we have the data exchange. Once we have the exchange data here, we can now start looking into the different elements and their properties or the instance parameters.

And so what's going on here is that we-- from the exchange data, we create a data element, data model. In that element, data model, we're querying or filtering out the walls here by setting the categories, which we have done in our JSON file. And in the loop, we're basically going through all each element separately in our element model. And we're looking at the current instance parameters that is associated to each one of them.

Once we have done that and we know that we have a connection to an exchange and we can access the data, we can get on with starting with creating a new exchange. So here, we basically giving it all the details that the request needs to create a new exchange in the ACC. And we get that-- we get back an exchange data for the new model, which we can start adding data to.

So in order to add the data to the new exchange, we need to grab the data from the exchange that we read in the step 4. And what we are doing at the first step here is that we want to go through all the elements and grab the geometry to start with. And so it's important to remember that each element in an data exchange, in each element in the exchange on ACC can contain a list of geometries.

So one element could basically have two separate parts of geometry. And so that is basically what the loop is doing here. The first loop is actually looking into each element. And the second one here is looking into grabbing all geometry parts for a single element. And we're basically creating a geometry collection, the wall geometries, and put those into the list of geometries.

And in the next step, we basically want to-- at this point, we basically have access to the geometry. And we can recreate the geometry from the existing exchange. But we also want to carry over all the instance parameters that we had in the exchange that we're reading.

So what we're doing here is basically going through all the elements again and looking at the-- and going through all their instance parameters and copy those over to the new exchange. Now, the instance parameters might-- will have different types, different data types. So make sure that you handle that, either in an else if statements or a switch case, et cetera.

Once we've done that, we can create the parameters and add those to an existing-- to a wall, basically. So at the first step here, we-- sorry if we go back to the previous slide again-- yeah. So in the first step here, we create the wall for each element that we're looping through. And then we go through all the existing parameters, add those to the new wall.

And at the last step, we also checking the-- we create the parameters, obviously. But also, we're checking for the IFC GUID, which in our case and in the console app, act as the identifier to match the data from the-- in the current exchange and the one that we're creating with the enriched or appended data.

Once we have done that, we have only one left, one step, or two steps left. Now, we have access to the geometry. We have access to the previous parameters. And we only need to add the new parameters that are coming from the Excel data.

If you remember, we looked-- we did a comparison by the IFC GUIDs. And if we have a matching IFC GUID, we're adding additional data or parameters, custom parameters, to those elements. And this is what's happening here.

And at the last step, you can see, the geometry is being pushed as well to the elements. And remember here that the model is basically the element data model from the newly-created exchange that we had on step 4.

Once all that is done, we need to use the exchange data object, which is exposed by the element model, to sync this with the cloud. So at this point, we're actually writing the data and making that available on the ACC and on the exchange. And in the second step, which is quite important, is where the viewable on the ACC gets created.

I also would like to highlight that if you do not do this step, you will not be able to see the exchange in your ACC folders and the viewable. However, the data still exists there. So if you would, for example, use the GraphQL API, you would be able to access the data.

And as you can see here, we have the newly-- the additional data or custom parameters added. And you can easily check this either using the online viewer on ACC or, as mentioned earlier, using Postman to explore the data using the GraphQL tools.

GIULIO PAGAN: All right. Thank you very much, Puria. And very quickly-- so what's the next step? We have created this console app, which creates an extended exchange. Now, yes, as Puria pointed out, we can take a look at ACC. And you can already see something there.

But what if you wanted to do some analysis of such data? If you remember, in the conceptual description of a demo, there was a manager that would like to do a bit of analysis. Well, the good news is here that there is no coding required for this kind of task, or unless you really are keen to do it that way or you need extra flexibility.

But what you can do is download the Autodesk Data Connector for Power BI, which will allow you to connect Power BI directly to an exchange. Once you've done that, and assuming you have some skills with Power BI, then you'll be able to see your data in there. And you will be able to use the power of BI to create the visualization you want.

And thanks to the installer provided, you also have the option to view the model within your dashboard. So you can basically use this widget, which you can see here in this slide. And it will allow you to then interact with the viewer. And as you click on a wall, you'll be able to filter the content of a table.

Hopefully, this has given you a bit of an overview of basic functionality. We came up with a bit of a fictional scenario here. But it's touching on quite a few methods which you have to use again and again. Now, you may want to read more about this or review what has been done. Hopefully, the presentation helps as a starting point. But the next step is certainly to go to the official site, where you can read a bit more.

But our tip here is to, as soon as you are ready, install the SDK, set them up, and look at the examples. Both examples are available. And now, I will let Gaurav conclude this. He will talk to you about when SDKs can be used in which context and then a little bit about the future of the SDK.

GAURAV BHAMRE: Thanks, Giulio. So hi. We saw a very good use case here. And I'd like to extend it to a few more on when an SDK can be used. And this demonstrates the art of possible as well. So our friends at Ramboll are exploring the Data Exchange SDK. And they're, as you know, trying to solve the interoperability challenges.

So we saw one use case with dying between Excel, Revit, and ACC. Similarly, we can build connectors between different applications at different design stages irrespective of Autodesk or third-party applications. Here are a few that Ramboll is trying to take a stab at or to move towards more platform-oriented approach and solving the interoperability problem at the same time.

Moving on to the next scenario that we have, that we are seeing from our customers-- next slide, please. So moving on to the next scenario, we have an integration in progress with BIMDeX connector, Plant 3D, and Docs that essentially supports the users on Plant 3D using BIMDeX and ACC Docs and integrate that workflow through our Data Exchange SDK.

Another example of this use case is for third-party applications-- the Bentley application. So one of our customers is also exploring SDK to create a plugin or to create a Data Exchange connector on Bentley Open Roads and essentially tying it to their own native elements or creating native definitions out of Bentley and loading it into Autodesk Docs and making it more interoperable within their ecosystem. So these are a few cases. And most definitely, you can take a stab at the SDK and explore some of your workflows along with the SDK and along with your APIs.

Moving on, we're going to talk about a roadmap for the Data Exchange in general. So overall, we are operating or focusing on three themes for Data Exchange. One is towards adoption, another maturity, and capability. So what this ties into is getting more production-ready workflows for the users, as well as better support through general availability. At the same time, we'll keep enhancing our SDK to support more robust features, like automation, customization, and template creation.

Moving into a little more detail of this roadmap-- so the next step, some of the immediate next steps is supporting the .NET frameworks. And I also will be supporting the latest .NET at the same time also provide the capability to roll back so that you have better support and go next after that. We are planning an extensible data components, which allows you to extend the capabilities of the SDK and then with respect to your specific workflow or your specific implementation needs.

Moving on, later, we are building app connectors so that you don't have to do all the development from the scratch when you are building a connector for a new application. So for example, having an app converter for Bentley or having an app converter for AutoCAD applications will bump up your production or bump up your development of your own connectors or your own integrations so that you can only focus on the workflow specifically that you want to build. And beyond is supporting more languages rather than just .NET. So something that is in bucket is Python and JavaScript as well.

So this is more focused towards the SDK. We have a broader roadmap for Data Exchange in general, which is publicly available on our website, which showcases the released features, released tools for developers, as well as the released connectors, at the same time, in progress connectors. So some things that we already have out today is the .NET SDK along with the samples, the samples which helps you build your own implementations. And then we have GraphQL APIs in public beta as well.

We also have Data Explorer, which kind of helps you visualize your data exchanges and also view the hierarchy of the data that you're sharing. So you can make sure what kind of data you want to share through this ecosystem.

Moving on to some of the items in progress, we are working on supporting ACC data input for data exchanges and then having more robust functionality for ACC viewer around parameters viewing. And there are also some other features in progress for our connectors, which will basically enable better control over your data and geometry once you load it into a specific app.

Along with this, moving on to the next part, these are the items that were in progress. We also have a space for your ideas and your suggestions on this roadmap. So the roadmap actually facilitates adding more ideas or upvoting for any of the ideas that are already there.

So I'd like to take this opportunity and invite you all to visit the public roadmap and share your thoughts around what would you like for us to build in future and where would you like us to focus our energy on. So feel free to visit the public roadmap and upvote for the ideas that you are really looking for. Or also add new ideas where you think we should be focusing our energy.

That kind of wraps up our presentation. Thank you, everyone, for listening in. And have a great day.