QGIS Plugin implemented in MAPLIBRE / MAPBOX (Browser)

A special shout-out to Vladimir Vukocic, who developed and owns the FTTH analysis on the desktop platform. His work has been a valuable reference and inspiration for understanding the underlying algorithm.

What I learned in college is that QGIS is a desktop geospatial platform for manipulating geospatial data, with the advantage of having QGIS plugins that provide specific tools or analyses. Now, there is a need to make a QGIS plugin available in the browser. It is a hefty challenge to utilize the exact same QGIS plugin in a browser environment. The black box here is the algorithm behind it, with the additional challenge that I could not find any library in modern JavaScript packages or Python that is ready to use. Therefore, I am doing my research on how exactly I could implement this.

After some time and looking at my findings, I ended up with two options. The first option is having Python QGIS images installed and then using merely the FTTH analysis, but it comes at the price of an utterly heavy and long setup time, which would cost a lot in production. The second approach is understanding how the algorithm works from a desktop QGIS repository. I decided on the second option. Now, there are two things in mind: how this FTTH works and how I can design the system for this analysis and adapt it to my current architecture.

FTTH analysis UI in Geodashboard

I found that the FTTH analysis algorithm consists of calculating distances and implementing the loss signal equation. Distance plays a major role in determining the loss signal value (decibel). Here are the checkpoints after learning the algorithm:

• It utilizes the Kruskal and Bellman-Ford algorithms
• Prepare road data and make sure the intersections are separated
• Prepare the network data by converting road data into shaft–node network data
• Create a virtual shaft
• Create a linear distance calculation when the target is outside the road data
• Return the shortest path and the loss signal value
• Users can export the route and the information into a feature layer

Therefore, in order to facilitate this analysis, a geospatial analysis extension is required. Here are my considerations on how I could implement it.

1st approach: In my current architecture, I already have a backend that connects to a database, a worker, and a direct queuing system that interacts directly with the database. Then, I would create another worker that could handle this FTTH analysis workflow. To facilitate the geospatial analysis, we would have a GDAL image installed in the worker. All the geospatial analysis from creating points, routing, and loss signal calculation based on distance would be handled there. The worker would be served through a backend endpoint, and once a request is made, it would be added to the queue messages.

2nd approach: Create a new service that serves solely for this FTTH analysis by creating a FastAPI service and using PostGIS and pgRouting extensions. The frontend could then reach this endpoint for routing and loss signal values. To facilitate data import, there would be another endpoint in the same image.

After analyzing the situation, the worker approach utilizes GDAL, but there is a concern that it would already be under heavy load, and the consideration of needing a flexible to create a network set data. Therefore, I decided to go with the second approach. It is not as seamless to bring a QGIS plugin to the browser as ArcGIS does with their plugins, which they provide through ArcPy and then implement in ArcGIS JS. Looking how QGIS would develop in the future, it is a rare case indeed to have a QGIS plugin in browser.

[embed]