Figure 1. A web browser displays initial state and updated results after images arrive and are processed on the server automatically.

To run the frontend in IDL, in contrast, it is not necessary to set up a web server. Talking to the GSF server directly, the IDL client behaves similarly and displays the same content as the web browser-based client (Figure 2).

Figure 2. IDL client displays initial state and updated results after images arrive and are processed on the server automatically.

Although working well and serving the purpose, most people are likely to point out that using IDL client requires a license. Developing IDL applications (IDL tasks as well as IDL clients) indeed requires a license. However, using an IDL client running with the IDL Virtual Machine does not. To do this, the end user would download the .sav file of the IDL client and use it on any machine that can talk to the backend server, for free.

Note the IDL VM does have a splash screen that must be dismissed. For users who would like to not have this splash screen, such as for critical operational usage, IDL runtime licenses remove the splash screen and also allow users to use IDL ‘execute’ function to call external code.

To sum up, to develop code – frontend UI or backend processing – you need an IDL license. To run code for free, you need to create a .sav file and the end user downloads the virtual machine. To either distribute a license with your application or have the user not dismiss the splash screen and or if you need to call external code, an IDL Runtime license is needed. For widely distributed operational applications that need a runtime, your IDL account manager can work on bulk pricing.

Let’s walk through another example. Below is a project where NV5 Geospatial built an IDL User Interface (UI) and analytics tool for Australian Bureau of Meteorology's Tsunami (AusBOM) Decision Support Tool (DST). AusBOM DST is used operationally to assess whether a tsunami is likely to hit Australia or the Indian Ocean region. If it is assessed that a tsunami is likely, the DST aggregates necessary information and generates appropriate warnings.

The NV5 Geospatial Solutions Delivery team supported the original development of this application and then provided upgrades and service-support to the DST as their needs evolved. More information can be found in the article “IDL Programming Language is Engine Behind Australian Tsunami Decision Tool.”

Figure 3. The DST (v11.1) used in training mode for assessing the tsunami threat to Australia caused by an earthquake of magnitude 8.6 off the west coast of South Island, New Zealand.

As shown in Figure 3, the IDL UI of DST has many features to serve operational workflows. DST users in AusBOM are retrained every time a new release is deployed. If DST moved to the enterprise with a browser-based client (note: this is simply an idea and does not imply in anyway about Bureau's inclination towards such an idea), its UI should work with features that are very similar to the desktop UI. One prototyping example is shown as Figure 4. Even though the core functions of the DST could be modified to IDL tasks working on a backend server, the web-based client would need to be developed from scratch and a map server would need to be set up for DST to operate as a web application.

Alternatively, a future enterprise DST can go with an IDL client, which will have almost the same look-and-feel UI as currently in operational use. The IDL client itself can display map-related information just as the desktop DST does. There’s no need to set up a map server. However, at the backend a database server would need to be added. This eliminates local file writing, such as writing the event log in JSON files (a prototype example shown in Figure 5), and warning transmission log in .sav files that are currently implemented in the desktop DST.

This change is one of the “must-be-done” items for the DST to go enterprise. It will ultimately manage synchronizing event logs, bulletin counters, and product generation for multiple users simultaneously using the DST. Currently in the desktop DST, the synchronizations are handled by file-locking and merging local files with remote files, which takes care of occasional dual users simultaneously using DST.

Of course, other issues may need to be addressed for the IDL client to run successfully on any machine. The NV5 Solutions Delivery team can support assessing and performing code changes. For the DIY crowd, online documentation and tech support may provide the resources to make needed changes to the original IDL application.

On the backend, running IDL or ENVI tasks on GSF does require a license. If performance degrades when the number of IDL client users increase, you may need to scale up GSF by running the tasks on multiple nodes with a license on each node, which is beyond the scope of this article. More information about GSF can be found here.

Let’s recap before wrapping up this topic. It’s worth considering IDL client UI as an option when converting IDL legacy desktop applications to enterprise applications. The main reasons to use the IDL UI for this are:

1. No license is required to run IDL client in the IDL Virtual Machine.

2. Significant portions of the desktop application code can most likely be reused in developing its enterprise version.

3. Training costs for application users may be much less because the application UI may stay the same. Frontend users will likely not notice any changes.

4. If a browser-based client UI becomes necessary later, it should be easy to replace the IDL client because no changes are needed on GSF at the backend.

Figure 4. Prototyping example for browser-based UI of enterprise DST.

Figure 5. Prototyping example for IDL client UI of enterprise DST after JSON files were replaced with a MySQL database table for DST event log.

The IDL Task framework can ultimately make it easy to convert legacy code to be accessible via a webserver by using GSF. An IDL client can be distributed at no cost, or at a minimal cost, to access the backend applications on a desktop or virtual desktop. The same code can be reused if you want to develop a web application, saving time in rearchitecting working code for a different environment. As data volumes increase, cloud storage use grows, and the need for desktop analytic code needs to move to server environments, IDL has flexible “right sizing” to fit your need and budget.