# A GeoNode-Based Platform for an Effective Exploitation of Advanced DInSAR Measurements
## 4 GeoNode Modifications for the Advanced DInSAR Processing Results Integration
The choice of the PERL programming language was determined by the fact that it is an interpreted language optimized for scanning text files and extracting information from them. Moreover, PERL is extendable through the Comprehensive Perl Archive Network (CPAN) [104] modules, providing many powerful extensions to the standard library, such as, for example, DBI [105] for database interface and PERL threads modules that we have extensively used in this work. Figure 5: Sample text file showing the exploited DInSAR results data format; note that the metadata and deformation measurements are highlighted. We further remark that the deformation measurements are loaded into the PostgreSQL/PostGIS geodatabase as polygon centered at the SBAS-DInSAR coordinates for each pixel, with an area representing the average extension of the SAR pixel (see Figure 7). With this regard, we remark that for sake of simplicity these polygons have been deliberately selected as symmetric although they may be modified to account for the typically non symmetric characteristics of the SAR pixels [24]. After uploading the DInSAR data in the PostgreSQL/PostGIS geodatabase, the data are further imported in Geoserver, by using the Geoserver REST API [106], applying a customized Styled Layer Descriptor (SLD) [107] to the mean velocity deformation map in order to highlight, with a color palette, the mean deformation velocity values on the investigated area (see Figure 7). Figure 6: Flow chart of the uploading information procedure. Figure 7: Polygons representing the imaged (coherent) SAR pixels; note that the color of each polygon is associated to its mean deformation velocity value. Moreover, in the highlighted squared rectangle the color palette is presented. We underline that in our case we assumed that the mean velocity is the key parameter to be shown because it well represents the average deforming behavior of the area but, in principle, a different product included in the metadata could be shown. Moreover, an updating procedure to refresh the already existing layer in the geodatabase, has also been implemented. This is similar to the uploading procedure described above, with the distinctive feature that, in this case, a set of tables related to the area under investigation already exists. In particular, the adopted strategy for updating an existing layer consists in emptying the tables content related to the time-series information and modifying the table structure by adding new columns to store new deformation measurements. Considering that GeoNode provides permissions policy, the choice to empty the table content instead of cancelling the tables preserves the users permissions on the data. The next step of the modified GeoNode platform is the data synchronization between the Geoserver and the GeoNode webGIS interface (GeoExplorer), by using the GeoNode Management Commands _updatelayers_[108] which is essential for the visualization of the uploaded DInSAR measurements. Indeed, the visualization process of these data is not trivial, due to their huge amount to be displayed. To overcome this issue we use GeoWebCache, a Java web application, to cache the generated map tiles in order to accelerate and optimize the map image delivery. In particularly, we specifically chose to build for each dataset all the tiles before the data visualization in the GeoNode webGIS interface, by using the GeoWebCache REST API [109] to boost the performance of the map visualization (see Figure 8). Another very relevant aspect, that has been already mentioned in the previous sections, is that the analysis of the advanced DInSAR processing results requires not only a space, but also a time representation. Although the SDI structures via the WMTS protocol [110] support time-dimension for visualizing and querying temporal information, we had to implement a dedicated functionality in PHP due to the relation schema of the geodatabase table we designed, according to the peculiarity of the data to be handled (see Table 1).