[net.database] INGRES for geographic applications

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