Review of “SQL/SDA: A Query Language for Supporting Spatial Data Analysis and Its Web-Based Implementation” by Hui Lin and Bo Huang Reviewd by Jisu Oh, Shan Huang Course : CSCI8715 Spatial Databases Professor : Shashi Shekhar Motivation and Problems The major characteristics of a Geographical Information System (GIS) from other information systems is the capabilities to handle and analyze spatial data supporting decision making based on geo-referenced data. The Internet has grown so rapidly today and then it has led to an increasing concern over the Web GIS. In this paper, the authors present effective interface to deal with the spatial data analysis functions based on the Web and a query language, SQL/SDA, for those kind of query processing. Even though many Web GIS developer have been tried to access, transmit, retrieve and map to the spatial data and employ the access to spatial analysis functions such as map overlay, buffer, and feature fusion, it’s still not effective and easy for World Wide Web (WWW) client/server environment. And several prior works in terms of query language to support spatial data analysis such as Geo-SAL, which is different from SQL and QUEL, user-defined extensions to SQL by using a macro expander, procedural language as well as cartographic modeling, and Spatially Extended SQLs(SESQL) are more focused on the representation and management of spatial data rather than stepwise analysis of spatial data. So the authors develop SQL/SDA which is well-adapted to the general spatial analysis procedures using current GIS packages. GIS has been used as a tool for spatial analysis but it’s not still used world widely because of the complexity of comprehensive GIS software packages.The purpose of this paper is to propose a spatial query language, called SQL/SDA(Spatial Data Analysis), to support the expression of complicated spatial queries dealing with various spatial analysis problems, for example, finding a land parcel s suitable for growing coffee in Jamaica, within a framework for spatial query language design and development which provided in SQL3/MM and Open GIS SQL. Also authors report a critical factor of the SQL/SDA design is compliance with the general spatial analysis procedure using current GIS packages and compatibility with the SQL design concepts. It’s very important because that relational database language SQL is still a popular database language and its functionalities are valuable. In other words, efficient involving already existing technology to the new development make users to enable to feel familiar with new SQL and interface so that user would be more likely to use them. In summary, this paper provide effective and easy web-based interface to support spatial data analysis with SQL/SDA, incorporating relational database and SQL with Geometry type, given a general spatial analysis procedure of current GIS packages. Major contributions The authors’ main contribution is an attempt to develop web-based interface for spatial data analysis. Especially, easy and intuitive visual interface combined with textual language are necessary for first user and this interface reduce some errors. For example, their control window provide command button to check commands’ grammatical correctness by producing users and all the spatial functions in SQL/SDA are provided in the icons window with proper pictures. However it’s not clear how each windows work with the main text window. And since this interface is not very much different from SQL visual interface such as MS Access, it’s not original idea without dealing with spatial data query. That SQL/SDA incorporates the important derivation functions as well as the spatial relationship and metric functions, revising FROM clause is another contribution in the query language area. The idea of embedding an SQL statement in the FROM clause is easy to understand and use, that is, this language is in a natural language-like style comparing with Macro Language of GIS, which is a kind of procedural language have lots of unstandardizedconcepts and special-purpose functions so that doesn’t employ optimization strategy. Also SQL/SDA present the complicated multistep spatial analysis problems comparing with Spatially Extended SQLs(SESQL) which need complex and redundant query presentation to retrieve same result as SQL/SDA query since only the attributes in the FROM clause can be complied in both the SELECT and WHERE clauses. Although the authors introduce new type of FROM clause, it looks like VIEW, not a new concept. The concept of virtual table which several values from spatial functions are appended to and created during intermediate relation is similar to VIEW. The difference between them is the time when they are produced. It means the authors should have shown how different VIEW and their intermediate table from FROM clause are. Finally, the web-based interface provided in this paper is very clear and can be an origin of visual interface for spatial data analysis. Hybrid model the authors choose also shows us a definite architecture between client and server. According the architecture, client can control over the query execution and server processes query request communicating with both client and SDE. This interface is also using in a real world so that it can be employed in wide applications in the future. Key Concepts 1. Spatial data type & analysis functions in SQL/SDA A basic geometric unit for spatial representation and processing in SQL/SDA is a feature-based model. This model includes both spatial attributes (e.g., coordinates and topological relationships) and non-spatial attributes (e.g., name, type, and size) and represents each feature in the table, which is similar to a table in a Relational Database Management System (RDBMS). In this paper, the authors choose SQL with geometry types to implement spatial feature table. It refers to a SQL environment that has been extended with a set of geometry types.The authors define a set of geometry types: According to geometry types, four groups of spatial functions are defined in SQL/SDA. First group is for property functions: CENTROID, AREA, LENGTH. Functions to test spatial relationships are next and metric functions which calculate distance and direction are third group. Creating a new set of spatial features is the last function, called derivation functions such as VORONOI, BUFFER,