TowerSight
TowerSight is a TypeScript/React web application that is built using iModel.js framework. It is a part of bigger solution called OpenTower that serves as a transformation tool for design practices of telecom towers. OpenTower is a fully integrated solution that transforms the design practices of telecom towers by encompassing the entire lifecycle management of tower engineering. From tower analysis to inspection and reality models, TowerSight, as part of OpenTower solution, completes the loop using a tower digital twin, making it easy to modify existing towers and maintain accurate models.
First Impression
Before this project started, I really didn’t know much about web programming. I built some static website using HTML and CSS before but nothing more than that. Along with me, two other developers also work in this project but they didn’t have any experience working with typescript/react either. So upon receiving this project, I felt that I would not be able to achieve it without help from other people. Luckily enough, throughout this project, I met a lot of amazing people at Bentley that helped me develop this app. This blog post really helped me get started.
Feature
In this section, I will give you a glimpse of some features that I worked on. As an iModel.js based project, TowerSight works hand-in-hand with iModel data. So every single feature will somehow related to fetching the iModel data and present it in the proper way.
Table
The main purpose of this feature is to bring the iModel data in a table format, and to use it to interact with other components. While developing this feature, I heavily used this blog post. In this post, the author goes over in details about how to implement a table component with unified selection. However, the table described in the blog is just a plain table that does not sort or filter. In order to accommodate that functionality, I modified the header definition in to such:
The filterable and sortable keys above enable those features. FilterRenderer defines which filter to use. In this case, I’m using the FilterRenderer.MultiSelect. It enables the user to use multiple filter keywords on the table.
Another feature that I want to highlight is a stripedRows. It was not originally in iModel.js, but I contacted one of the developers and he added it for me!
<Table
stripedRows={true}
dataProvider={provider}
onRowsSelected={onRowsSelected}
isRowSelected={isRowSelected}
/>When set to true, this newly implemented property makes the table have alternate colors on every row.
Property List
Similar to the table, property list also brings the iModel data to user but with a different format. However, slightly different than the table, the property list works best for displaying data of a single element.
This image shows how the viewport window interacts with the property list. The property list will show the data based on the selected element in the viewport (highlighted in blue).
Different than the table component, property list unified selection only works one-way, that means, property list can only receive a callback and can’t send a callback. Here below is the complete code that takes care of one-way unified selection:
One type of data that can be fed in as the data source to the property list is PropertyRecord. This code below shows how PropertyRecord can be applied to the PropertyList component.
This iModel.js docs page shows the properties of the PropertyRecords. And for how it actually works, this blog will give a good explanation (the Russion doll analogy) of how the PropertyRecord is structured.
Another function that is used when building the property list is a filterRecords function. This function is helpful when we want to filter out information that we want to show to the user. In the example below, I’m using this filter function to take out all results coming only from the BisCore schema.
if we combine all of the code above, we will have our custom property list!
Future development
Although some work has been done, there’s still much left to develop. I can say that most of the data that needs to be fetched is already there and has been implemented. Now, what is left is the processing part of the data. In the future, the data that is fetched from the iModel will be compared with the existing reality model. We plan to call this process Version Compare. Those differences will be visually examined by the users, and while examining, the system will provide the users with two tables that shows the difference between those two versions so the user will be able to hand-pick and make some changes on the iModel data if necessary.
Another feature that needs to be done is Asset Tagging. This will allow the system to recognize the assets of the reality data automatically using artificial intelligent (AI) technology. At first, user will have to manually give some sample data by tagging the reality components. But as time goes by, AI will pick up that data and learn so it can automatically give the correct tagging.
Last Impression
Although sometimes things didn’t go as smooth, but looking back, I’m proud to see how much I have learned during the development of the project. This project has taught me how TypeScript and React work in general, and how these two technologies work hand-in-hand with iModel.js and other Bentley products. Coming from a desktop background, I feel like there are subtle yet obvious differences when I first started this project. Google has been really helpful since there are a lot of resources for Typescript and React as they are currently very popular. For the iModel.js part, I was able to get the support from the iModel.js support team, which enabled me to push through the challenges and get things accomplished.
