mohan@ihuxf.UUCP (Palat) (09/22/85)
INGRES for geographic applications Not long ago, there was a geographic interface to the INGRES query language QUEL called GEO-QUEL. It was a front end to INGRES that allowed one to manipulate geographic data using INGRES. This interface treated all geographic data (including maps) as relations. A few graphics commands were also provided to display maps etc. Does anyone know whether this system is being used or was used in any commercial application? Or was it just a research product that never made it in the real world? In any case, I have never found INGRES to be suitable for geographic applications. The speed of operation in an INGRES environment is considerably slower than that of many special purpose systems such as, say, ARC/INFO(tm). This is a serious drawback in many geographic applications that support interactive query and display capabilities and require real-time manipulation of the usually voluminous geographic data. Again, treating geographic data (which is usually continuous) as relations in an INGRES database may not be the most efficient approach to handling this type of data. Thirdly, the ability of a database manager like INGRES to perform complex spatial operations such as containment and adjacency is very restricted. Any thoughts on this??? MOHAN PALAT AT&T Network Systems (ihnp4!ihuxf!mohan)
larry@ucbingres.ARPA (Larry Rowe) (09/24/85)
In article <2703@ihuxf.UUCP> mohan@ihuxf.UUCP (Palat) writes: > > INGRES for geographic applications > > Not long ago, there was a geographic interface to the > INGRES query language QUEL called GEO-QUEL. It was a > front end to INGRES that allowed one to manipulate geographic > data using INGRES. This interface treated all > geographic data (including maps) as relations. A few > graphics commands were also provided to display maps etc. > Does anyone know whether this system is being used or was > used in any commercial application? Or was it just a research > product that never made it in the real world? Geoquel was a research prototype used only at berkeley. > In any case, I have never found INGRES to be suitable for > geographic applications. The speed of operation in an INGRES > environment is considerably slower than that of many special purpose > systems such as, say, ARC/INFO(tm). This is a serious drawback in > many geographic applications that support interactive query > and display capabilities and require real-time manipulation > of the usually voluminous geographic data. > Again, treating geographic data (which is usually continuous) > as relations in an INGRES database may not be the most efficient > approach to handling this type of data. You are right. the tabular view of the data was too slow. that's one of the reasons geoquel was never distributed. > Thirdly, the ability of a database manager like INGRES to perform > complex spatial operations such as containment and adjacency > is very restricted. You are right. that is why we have been investigating the inclusion of abstract datatypes into a general database manager here at berkeley. i believe the public domain version of university ingres (version 8) available on one of the usenix tapes has the abstract datatype facilities that mike stonebraker and some students implemented and experimented with. larry rowe