• Accurate Data Capture & Tracking
  Ensuring the app reliably records detailed bowling metrics like delivery type, count, and intensity without manual errors poses a challenge, especially in a real-time sports environment.

• Scalability & Performance
  As user adoption grows, maintaining app performance and scalability will be critical, particularly during peak usage times. Designing a backend that can handle large volumes of data efficiently is essential.

• User Engagement & Retention
  Encouraging consistent use of the app among bowlers can be challenging. Building features that foster community interaction, personalized plans, and gamified challenges will be crucial to retaining users.

• Cross-Platform Compatibility
  Delivering a seamless user experience across both iOS and Android devices requires rigorous testing to address device-specific issues, screen resolutions, and performance variations.

• Challenge 1: High Computational Demand: The WRF model’s capacity to produce highly detailed meteorological datasets necessitates extensive computational power, which made running it on the customer’s existing local infrastructure impractical. The challenge was to find a solution that could efficiently handle large-scale data generation with optimum costing.
  • Solution: This challenge was met by implementing an AWS-based high-performance computing (HPC) cluster, specifically AWS ParallelCluster, which provided the necessary computational resources to run the WRF model efficiently. The jobs on ParallelCluster were created and managed dynamically using AWS Stepfunction and AWS Lambda by utilizing Slurm APIs
• Challenge 2: User Experience and Commercialization: To monetize their meteorological data, the customer needed to create an accessible, user-friendly portal where external users could easily select regions, adjust data resolution, and purchase datasets. The portal needed to be intuitive, efficient, and fully capable of handling secure transactions, which was essential for the success of the customer’s business model.
  • Solution: The customer addressed this challenge by developing a web-based portal using AWS Amplify, integrated with AWS WAF and Shield for security, and managed via Amazon API Gateway. This platform provided a seamless user experience, enabling external customers to effortlessly interact with the system, select their data parameters, and complete purchases, thereby facilitating the commercialization of their datasets and enhancing revenue streams.

We collated data from multiple council region and helped to get this stored on AWS layer. When a user  buys the report, then the risk calculation logic goes through several datasets in ArcGIS server to calculate the risks for different hazards, then combine those results along with the expert advise from the Landcheck engineers and returns the result by generating a PDF. This was taking a huge amount of time when done at the go. 

• • Complex calculations are required for each hazard which involves data coming from different ArcGIS feature layers. In addition to this, an image for each hazard is also created combining multiple hazard layers from ArcGIS map server. All of these calculation were taking a lot of time in generating the report. In order to resolve this, we moved all the hazard calculation logic in a separate component, which gets triggered through an event. In this we optimized the code to perform each hazard calculation on separate thread. Also, we offloaded some of the GIS calculations to ArcGIS server, and access it with ArcGIS APIs. These changes reduced the time report creation time to just few minutes.
• Testing of the application with multiple addresses and users who were experts in their domain was a challenge.
  • The data was quite complicated to understand and we relied on the Landcheck’s engineers to inform us what the expected result was. We did cover a lot of suburbs and did test close to 600 properties so we could be sure it is working as expected. However there were outliers and cases which did not work as expected and had to invest a fair bit of time to resolve those. 
• ArcGIS integration was an issue as all the data from different Parcel and Linz layers had to be collated on the AWS ArcGIS server so we could get the information from a single source for multiple cities and suburb region
  • This data was complicated to load and we had applied layers in terms of images and legends to display the data on the report side for an end user to easily interpret  the results. 

• To transfer the data from the LinkedIn app was a challenge as the APIs were not available.
  • We had to use UI Path instead.
• We needed the authentication to be stored centrall but it had to be encrpypted so it is not misused. 
  • Data was stored in a UIpath Key store where after storing it was not visible.