Can WFS-T replace SQL ?

Abstract

Background With the advent of rich internet applications (RIA’s), part of processing has been transferred from the server to the client. However, many geo-spatial applications still require serverside access to a geodatabase to select and manipulate data using SQL. It would be profitable if these actions could be handled by an out of the box serverside component, thus eliminating the need for the development of a custom serverside component. Can OGC standards like WMS and WFS play a role here? Since WFS-T provides select, insert, delete and update methods much like SQL, it was decided to investigate whether the WFS-T implementation specification could replace SQL when developing complex geo-spatial applications. Or is SQL still needed? Method To answer this research question, this approach was tested during the development of several tailor made internet GIS applications: - a wheater and crop growth monitoring system; - a discussion support system for the water domain; - a national cultural heritage portal. Results Filtering and manipulating serverside data by WFS-T using the OpenGIS Filter Encoding Standard (FES) fullfills the needs to a large extent. Almost all of the desired functionality is there. There is one major limitation: FES lacks the ability to define a filter expression based on a joined table. Dependant on the implementation a work around may be available. Xml-schemas support 1-to-many relationships. They can be implemented as a joined table, which as a result can be queried. For larger datasets - a couple of ten thousand records or more - WFS-T tends to end up with a bad performance. Larger datasets should be processed serverside. Downloading large amounts of data and processing them clientside is too time-consuming. Compared to SQL WFS-T has less possibilities to influence the serverside performance. So for performance reasons SQL stays inevitable to handle larger datasets