Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 exptools; site ihuxf.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!ihuxf!mohan
From: mohan@ihuxf.UUCP (Palat)
Newsgroups: net.database
Subject: INGRES for geographic applications
Message-ID: <2703@ihuxf.UUCP>
Date: Sun, 22-Sep-85 15:44:03 EDT
Article-I.D.: ihuxf.2703
Posted: Sun Sep 22 15:44:03 1985
Date-Received: Mon, 23-Sep-85 02:44:28 EDT
Distribution: net
Organization: AT&T Bell Laboratories
Lines: 32


	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)


Brought to you by Super Global Mega Corp .com