Re: [HACKERS] Indexing for geographic objects? - Mailing list pgsql-general

Franck Martin wrote:
>
> It seems that your code is exactly what I want.
>
> I have already created geographical objects which contains MBR(Minimum
> Bounding Rectangle) in their structure, so it is a question of rewriting
> your code to change the access to the cube structure to the MBR structure
> inside my geoobject. (cf http://fmaps.sourceforge.net/) Look in the CVS for
> latest. I have been slack lately on the project, but I'm not forgetting it.
>
> Quickly I ran through the code, and I think your cube is strictly speaking a
> box, which also a MBR.
>
> However I didn't see the case of intersection, which is the main question
> when you want to display object that are visible inside a box.
>
> I suppose your code is under GPL, and you have no problem for me to use it,
> providing I put your name and credits somewhere.

It would be much better if it were under the standard PostgreSQL license
and
if it is included in the standard distribution.

As Tom said, working Gist would be a great feature.

Now if only someone would write the regression tests ;)

BTW, the regression tests for pl/pgsql seem to be somewhat sparse as
well,
missing at least some types of loops, possibly more.

> Franck Martin
> Database Development Officer
> SOPAC South Pacific Applied Geoscience Commission
> Fiji
> E-mail: franck@sopac.org
> Web site: http://www.sopac.org/
>
> This e-mail is intended for its recipients only. Do not forward this e-mail
> without approval. The views expressed in this e-mail may not be necessarily
> the views of SOPAC.
>
> -----Original Message-----
> From: selkovjr@mcs.anl.gov [mailto:selkovjr@mcs.anl.gov]
> Sent: Saturday, 25 November 2000 8:56
> To: Franck Martin
> Subject: Re: [HACKERS] Indexing for geographic objects?
>
> It is probably possible to hook up an extension directly with the
> R-tree methods available in postgres -- if you stare at the code long
> enough and figure how to use the correct strategies. I chose an easier
> path years ago and I am still satisfied with the results. Check out
> the GiST -- a general access method built on top of R-tree to provide
> a user-friendly interface to it and to allow indexing of more abstract
> types, for which straight R-tree is not directly applicable.
>
> I have a small set of complete data types, of which a couple
> illustrate the use of GiST indexing with the geometrical objects, in:
>
> http://wit.mcs.anl.gov/~selkovjr/pg_extensions/
>
> If you are using a pre-7.0 postrgres, grab the file contrib.tgz,
> otherwise take contrib-7.0.tgz. The difference is insignificant, but
> the pre-7.0 version will not fit the current schema. Unpack the source
> into postgresql-*/contrib and follow instructions in the README
> files. The types of interest for you will be seg and cube. You will
> find pointers to the original sources and docs in the CREDITS section
> of the README file. I also have a version of the original example code
> in pggist-patched.tgz, but I did not check if it works with current
> postgres. It should not be difficult to fix it if it doesn't -- the
> recent development in the optimizer area made certain things
> unnecessary.
>
> You might want to check out a working example of the segment data type at:
>
> http://wit.mcs.anl.gov/EMP/indexing.html
>
> (search the page for 'KM')
>
> I will be glad to help, but I would also recommend to send more
> sophisticated questions to Joe Hellerstein, the leader of the original
> postgres team that developed GiST. He was very helpful whenever I
> turned to him during the early stages of my data type project.
>
> --Gene