postgresql/contrib/earthdistance/README.earthdistance
Bruce Momjian 24bebf0b72 I have included fixes to declare some floating point constants as double
instead of int, change the calculation method to use the haversine
formula
which is more accurrate for short distances, added a grant to public for
geo_distance and added a regression test.

I will resubmit the earth distance stuff based on cube after 7.3 is
released.

Bruno Wolff III
2002-09-20 03:47:22 +00:00

42 lines
1.7 KiB
Plaintext

---------------------------------------------------------------------
I corrected a bug in the geo_distance code where two double constants
were declared as int. I changed the distance function to use the
haversine formula which is more accurate for small distances.
I added a regression test to the package. I added a grant statement
to give execute access for geo_distance to public.
Bruno Wolff III
September 2002
---------------------------------------------------------------------
Date: Wed, 1 Apr 1998 15:19:32 -0600 (CST)
From: Hal Snyder <hal@vailsys.com>
To: vmehr@ctp.com
Subject: [QUESTIONS] Re: Spatial data, R-Trees
> From: Vivek Mehra <vmehr@ctp.com>
> Date: Wed, 1 Apr 1998 10:06:50 -0500
> Am just starting out with PostgreSQL and would like to learn more about
> the spatial data handling ablilities of postgreSQL - in terms of using
> R-tree indexes, user defined types, operators and functions.
>
> Would you be able to suggest where I could find some code and SQL to
> look at to create these?
Here's the setup for adding an operator '<@>' to give distance in
statute miles between two points on the earth's surface. Coordinates
are in degrees. Points are taken as (longitude, latitude) and not vice
versa as longitude is closer to the intuitive idea of x-axis and
latitude to y-axis.
There's C source, Makefile for FreeBSD, and SQL for installing and
testing the function.
Let me know if anything looks fishy!
A note on testing C extensions - it seems not enough to drop a function
and re-create it - if I change a function, I have to stop and restart
the backend for the new version to be seen. I guess it would be too
messy to track which functions are added from a .so and do a dlclose
when the last one is dropped.