M. J. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71-- 85, March-April 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....the 9 intersection [EDH94] In [Ege94] SpatialSQL, a spatial query and presentation language, was introduced. Other proposals for query languages based on SQL can be found in [Goh89, Ooi90] An analysis of the issues regarding the use of SQL extensions for GIS query and presentation is given in [Ege92], which concludes that there are two major deficiencies of such languages: a) the difficulty of incorporating graphical display and specification into SQL; b) the lack of support with the relational framework for aspects such as knowledge and metadata queries. Due to the shortcomings and ....

Egenhofer, M. Why Not SQL!. International Journal of Geographic Information Systems, 6 (2), 1992.

....the ability to do real time animation is limited. To make the animation of spatiotemporal objects more efficient, we propose to use a separate data model just for the display purposes (the decoupling of retrieval and display was postulated in the context of spatial query languages by Egenhofer [8, 9]) For linear constraint databases, this model is a natural generalization of the spaghetti data model [18] called the parametric spaghetti data model (introduced in [5] The basic modelling construct of the latter model is a parametric polygon. Using parametric polygons the conversion from an ....

M. Egenhofer. Why not SQL! International Journal of Geographic Information Systems, 6(2):71--85, 1992.

....planned to include mechanisms allowing the users to define their own data types and operations. Others are applying the object oriented paradigm to define a query language that incorporates geographical and temporal aspects (Heytens and Secchi, 1993) More material on this subject can be found in Egenhofer, 1991, 1992, Vijlbrief and van Oosterom, 1992, Huang and Svensson, 1993, and Boursier and Mainguenaud, 1992. The remainder of this paper is organized as follows. In section 2 we briefly discuss data modeling in general, and how a model can be defined at different levels of abstraction. In section 3 we ....

Egenhofer, M. J. (1992), Why not SQL!, International Journal of Geographical Information Systems, 6(2):71--85.

....language that can be composed of words from geographic domain dictionaries and thesauruses using a structured editor. The SQL style user interfaces for dynamic maps are not human centered systems because of the necessity of users knowledge for database schemata and query language grammars [7] [10], 11] Our approach adopts the combinations of only natural words stored in knowledge bases, including dictionaries, thesauruses and rule bases, for geographic applications to describe ad hoc queries where components are some words, ad 2 IEICE TRANS. FUNDAMENTALS, VOL. E00 X, NO. x x 1996 Fig. ....

M. J. Egenhofer, "Why not SQL", Int'l Journal of Geographic Information Systems, Vol. 6, No. 2, pp. 71 -- 85, 1992.

....times, it is also used to interact with an objectoriented database (e.g. Deux, O. et. al 1990] Thus it is often proposed to use it with a spatial database as well (e.g. Aref and Samet 1991a; Gadia 1993; Roussopoulos et al. 1988; Scholl and Voisard 1992] Note that it has been argued (e.g. [Egenhofer 1992]) that SQL is the wrong approach. These arguments are based on the inability to refer to the results of previous operations or on how the output is to be displayed. Similarly, selection by pointing is difficult to achieve. The problem is that SQL is primarily a means to retrieve from a tabular ....

Egenhofer, M. J. 1992. Why not SQL! International Journal of Geographical Information Systems, 6, 2 (March--April), 71--85.

....by extensible relational or object oriented dbms embedding the spatial dimen5 sion in the system. The formulation of spatial queries is directly supported in the extensible query language. Relational databases do not provide an adequate underlying model to support most types of geographic data [Ege92] the use of tables with fixed number of attributes does not allow flexibility in the management of georeferenced data, nor the incremental development of applications. Thus, researchers have directed their attention to new architectures. New architectures rely on extensible relational (e.g. ....

M. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71--86, 1992.

....are not provided by standard relational dbms. Thus, special data handlers have been developed to interact with the stored relations and allow the management and display of georeferenced data. Relational databases do not provide an adequate underlying model to support most types of geographic data [Ege92]: the use of tables with fixed number of attributes does not allow flexibility in the management of georeferenced data, nor the incremental development of applications. Thus, researchers have directed their attention to new architectures: extensible relational, object oriented or rulebased systems ....

M. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71--86, 1992.

....relationships between entities. The interface language should be powerful enough to express a query involving both spatial and aspatial components. Structured Query Language (SQL) is by far the most popular query language but lacks constructs needed to express queries based on spatial attributes [Egenhofer 92] We have retained the template structure of SQL and introduced the operators that reflect the GIS nature of a query. For example, consider a typical query like Which are the states in INDIA through which the river GANGA flows . We need to specify entity classes state, country and river, ....

EGENHOFER M.J., 1992, Why not SQL ?, International Journal of Geographic Information Systems , 6(2), 71-85.

....we show here that the great majority of existing gis user interfaces uses the hybrid solution. 4.1 Textual Query Languages Most textual query languages are based on extensions of SQL, in order to allow processing spatial relationships. The unsuitability of this approach is discussed in [Ege92] The following shortcomings are pointed out: ffl difficulties of incorporating spatial concepts of graphical specification and display into an sql (flat table) framework; ffl the lack of power of the relational model to support qualitative answers, knowledge and metadata queries. Ege92] ....

....in [Ege92] The following shortcomings are pointed out: ffl difficulties of incorporating spatial concepts of graphical specification and display into an sql (flat table) framework; ffl the lack of power of the relational model to support qualitative answers, knowledge and metadata queries. Ege92] points out that any spatial sql extension is a short term solution for an interactive gis query language. It is claimed that the extensions to sql fail to provide a real gis query language, and that they transfer to the programmer the burden of simulating spatial concepts. Figure 7 shows a ....

M. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71--86, 1992.

....One can note from these examples that the syntax for expressing complex queries is really declarative and concise. Unfortunately, it is also very complex and distant from the conventional user mental model. End users of gis are not expected to understand the proposed syntax. 4.1. 7 Egenhofer [Ege92] In [Ege92] Egenhofer provides several arguments showing the inappropriateness of sql as a framework for high level gis query languages. It is an interesting point of view, if we take in account that the author proposed different sql extensions as a solution for this problem (see sections 4.1.1 ....

....note from these examples that the syntax for expressing complex queries is really declarative and concise. Unfortunately, it is also very complex and distant from the conventional user mental model. End users of gis are not expected to understand the proposed syntax. 4.1. 7 Egenhofer [Ege92] In [Ege92] Egenhofer provides several arguments showing the inappropriateness of sql as a framework for high level gis query languages. It is an interesting point of view, if we take in account that the author proposed different sql extensions as a solution for this problem (see sections 4.1.1 and ....

M. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71--86, 1992.

....framework. Normally, a relational data model cannot represent spatial data in an efficient and useful form. The reason for this is that a relational system returns only quantitative data, such as lists of tuples, and not qualitative data, such as topological connectedness, proximity, or overlap [6]. Our solution to this apparent mismatch between the topological nature of spatial data and the relational form of was to encode the spatial data in a form which permitted both storage in relational tables and manipulation via 2 Spatial Interface for Efficient Relational Retrieval and Analysis, ....

M. J. Egenhofer. Why not SQL! International Journal of Geographic Information Science (IJGIS), 6(2):71--85, 1992.

....at which they formally define semantics of the extensions; ffl their syntactic implementations; and ffl the degree to which they comply to standardized SQL structure. Examples of these geo SQL dialects include GRAL [16] GEO SAL [37] GEO QUEL [6] and Query by Pictorial Example [10] Egenhofer [12] argues that relational model is, by its own nature, not suitable for geographic data handling and efforts to modify the relational model and SQL in order to make them support geographic data do not meet reasonable success and, on the other hand, leads to unnecessary complexities. 4.5 ....

M. J. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71--85, 1992.

....visualizations of the same data so that users can switch between several data displays of the same georeferenced entities. 5.1 Textual queries: extended SQL Different extensions have been proposed to sql to transform it into a spatial language. The unsuitability of this approach is discussed in [18]. The following shortcomings are pointed out: ffl difficulties of incorporating spatial concepts of graphical specification and display into an sql (flat table) framework; ffl the lack of power of the relational model to support qualitative answers, knowledge and metadata queries. 18] points ....

....in [18] The following shortcomings are pointed out: ffl difficulties of incorporating spatial concepts of graphical specification and display into an sql (flat table) framework; ffl the lack of power of the relational model to support qualitative answers, knowledge and metadata queries. [18] points out that any spatial sql extension is a short term solution for an interactive gis query language. It is claimed that the extensions to sql fail to provide a real gis query language, and that they transfer to the programmer the burden of simulating spatial concepts. Nevertheless, a ....

M. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71-- 86, 1992.

.... mechanisms [MP94] ffl textual query languages; and ffl interactive manipulation of geographic elements Most textual query languages are based on extensions of relational query languages such as sql (e.g. Gut88, Goh89, PZ91, Ooi90, Lor91] The disadvantages of this approach are pointed out in [Ege92] Other textual query mechanisms usually rely on extending object oriented query languages with spatial processing methods (e.g. SV92] Some recent results exploit the use of natural language in queries, for restricted application domains (e.g. Wan94] Some gis querying mechanisms allow ....

M. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71--86, 1992.

....sketching paradigm. This section reviews relevant approaches in these fields. 2.1. Spatial Query Languages Query languages for geographic databases and geographic information systems are either complex macro languages or extensions of SQL. There exists a large variety of Spatial SQL dialects [7, 28, 32, 47]. Such SQL extensions are relevant to Spatial Query by Sketch, because they provide the means for accessing geographic databases and retrieving data from a database. Most critical is the support for spatial relations. Many SQL dialects include some notions of spatial relations, however, the ....

M. Egenhofer, "Why not SQL!," International Journal of Geographical Information Systems, vol. 6, no. 2, pp. 71-85, 1992.

....paradigm. This section reviews relevant approaches in these fields. 2.1. Spatial Query Languages Query languages for geographic databases and geographic information systems are either complex macro languages, or extensions of SQL. There is a large variety of Spatial SQL dialects, see Egenhofer [5] for an overview. Such SQL extensions are relevant to Spatial Query by Sketch because they provide the means for accessing geographic databases and retrieving data from a database. Most critical is the support for spatial relations. Many SQL dialects include some notions of spatial relations, ....

M. Egenhofer, "Why not SQL!," International Journal of Geographical Information Systems, vol. 6, no. 2, pp. 71-85, 1992.

No context found.

M. J. Egenhofer. Why not SQL! International Journal of Geographical Information Systems, 6(2):71-- 85, March-April 1992.

No context found.

M. J. Egenhofer, "Why not SQL", Int'l Journal of Geographic Information Systems, Vol. 6, No. 2, pp. 71 -- 85, 1992.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC