Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!ucbingres!larry
From: larry@ucbingres.ARPA (Larry Rowe)
Newsgroups: net.database
Subject: Re: INGRES for geographic applications
Message-ID: <104@ucbingres.ARPA>
Date: Tue, 24-Sep-85 16:22:47 EDT
Article-I.D.: ucbingre.104
Posted: Tue Sep 24 16:22:47 1985
Date-Received: Thu, 26-Sep-85 06:37:24 EDT
References: <2703@ihuxf.UUCP>
Sender: usenet@ucbvax.ARPA
Reply-To: larry@ucbingres.UUCP (Larry Rowe)
Distribution: net
Organization: University of California, Berkeley
Lines: 42

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


Brought to you by Super Global Mega Corp .com