1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* geo_decls.h - Declarations for various 2D constructs.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
*
|
2002-06-20 22:29:54 +02:00
|
|
|
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2003-05-13 20:03:08 +02:00
|
|
|
* $Id: geo_decls.h,v 1.40 2003/05/13 18:03:08 tgl Exp $
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
* NOTE
|
1997-09-07 07:04:48 +02:00
|
|
|
* These routines do *not* use the float types from adt/.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* XXX These routines were not written by a numerical analyst.
|
2000-02-17 04:40:02 +01:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* XXX I have made some attempt to flesh out the operators
|
|
|
|
|
* and data types. There are still some more to do. - tgl 97/04/19
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#ifndef GEO_DECLS_H
|
|
|
|
|
#define GEO_DECLS_H
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-06-05 09:29:25 +02:00
|
|
|
#include "fmgr.h"
|
1996-11-10 04:06:38 +01:00
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
/*--------------------------------------------------------------------
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* Useful floating point utilities and constants.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
#define EPSILON 1.0E-06
|
1996-08-28 03:59:28 +02:00
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
#ifdef EPSILON
|
1997-09-07 07:04:48 +02:00
|
|
|
#define FPzero(A) (fabs(A) <= EPSILON)
|
|
|
|
|
#define FPeq(A,B) (fabs((A) - (B)) <= EPSILON)
|
2000-07-30 22:44:02 +02:00
|
|
|
#define FPne(A,B) (fabs((A) - (B)) > EPSILON)
|
1997-09-07 07:04:48 +02:00
|
|
|
#define FPlt(A,B) ((B) - (A) > EPSILON)
|
|
|
|
|
#define FPle(A,B) ((A) - (B) <= EPSILON)
|
|
|
|
|
#define FPgt(A,B) ((A) - (B) > EPSILON)
|
|
|
|
|
#define FPge(A,B) ((B) - (A) <= EPSILON)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
#else
|
2000-07-30 22:44:02 +02:00
|
|
|
#define FPzero(A) ((A) == 0)
|
|
|
|
|
#define FPeq(A,B) ((A) == (B))
|
|
|
|
|
#define FPne(A,B) ((A) != (B))
|
|
|
|
|
#define FPlt(A,B) ((A) < (B))
|
|
|
|
|
#define FPle(A,B) ((A) <= (B))
|
|
|
|
|
#define FPgt(A,B) ((A) > (B))
|
|
|
|
|
#define FPge(A,B) ((A) >= (B))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
#endif
|
1996-08-28 03:59:28 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
#define HYPOT(A, B) sqrt((A) * (A) + (B) * (B))
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* Point - (x,y)
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double x,
|
|
|
|
|
y;
|
1997-09-08 23:56:23 +02:00
|
|
|
} Point;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* LSEG - A straight line, specified by endpoints.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Point p[2];
|
1996-08-28 03:59:28 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
double m; /* precomputed to save time, not in tuple */
|
1997-09-08 23:56:23 +02:00
|
|
|
} LSEG;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* PATH - Specified by vertex points.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int32 size; /* XXX varlena */
|
|
|
|
|
int32 npts;
|
|
|
|
|
int32 closed; /* is this a closed polygon? */
|
|
|
|
|
int32 dummy; /* padding to make it double align */
|
|
|
|
|
Point p[1]; /* variable length array of POINTs */
|
1997-09-08 23:56:23 +02:00
|
|
|
} PATH;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* LINE - Specified by its general equation (Ax+By+C=0).
|
|
|
|
|
* If there is a y-intercept, it is C, which
|
|
|
|
|
* incidentally gives a freebie point on the line
|
|
|
|
|
* (if B=0, then C is the x-intercept).
|
|
|
|
|
* Slope m is precalculated to save time; if
|
|
|
|
|
* the line is not vertical, m == A.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double A,
|
|
|
|
|
B,
|
|
|
|
|
C;
|
1997-07-29 18:16:14 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
double m;
|
1997-09-08 23:56:23 +02:00
|
|
|
} LINE;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* BOX - Specified by two corner points, which are
|
1997-09-07 07:04:48 +02:00
|
|
|
* sorted to save calculation time later.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Point high,
|
|
|
|
|
low; /* corner POINTs */
|
1997-09-08 22:59:27 +02:00
|
|
|
} BOX;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* POLYGON - Specified by an array of doubles defining the points,
|
|
|
|
|
* keeping the number of points and the bounding box for
|
|
|
|
|
* speed purposes.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int32 size; /* XXX varlena */
|
|
|
|
|
int32 npts;
|
|
|
|
|
BOX boundbox;
|
|
|
|
|
Point p[1]; /* variable length array of POINTs */
|
1997-09-08 23:56:23 +02:00
|
|
|
} POLYGON;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
|
* CIRCLE - Specified by a center point and radius.
|
|
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Point center;
|
|
|
|
|
double radius;
|
1997-09-08 23:56:23 +02:00
|
|
|
} CIRCLE;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-06-13 09:35:40 +02:00
|
|
|
/*
|
|
|
|
|
* fmgr interface macros
|
|
|
|
|
*
|
|
|
|
|
* Path and Polygon are toastable varlena types, the others are just
|
|
|
|
|
* fixed-size pass-by-reference types.
|
|
|
|
|
*/
|
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetPointP(X) ((Point *) DatumGetPointer(X))
|
|
|
|
|
#define PointPGetDatum(X) PointerGetDatum(X)
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_POINT_P(n) DatumGetPointP(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_POINT_P(x) return PointPGetDatum(x)
|
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetLsegP(X) ((LSEG *) DatumGetPointer(X))
|
|
|
|
|
#define LsegPGetDatum(X) PointerGetDatum(X)
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_LSEG_P(n) DatumGetLsegP(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_LSEG_P(x) return LsegPGetDatum(x)
|
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetPathP(X) ((PATH *) PG_DETOAST_DATUM(X))
|
|
|
|
|
#define DatumGetPathPCopy(X) ((PATH *) PG_DETOAST_DATUM_COPY(X))
|
|
|
|
|
#define PathPGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
#define PG_GETARG_PATH_P(n) DatumGetPathP(PG_GETARG_DATUM(n))
|
2000-07-29 20:46:12 +02:00
|
|
|
#define PG_GETARG_PATH_P_COPY(n) DatumGetPathPCopy(PG_GETARG_DATUM(n))
|
2001-03-22 05:01:46 +01:00
|
|
|
#define PG_RETURN_PATH_P(x) return PathPGetDatum(x)
|
2000-06-13 09:35:40 +02:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetLineP(X) ((LINE *) DatumGetPointer(X))
|
|
|
|
|
#define LinePGetDatum(X) PointerGetDatum(X)
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_LINE_P(n) DatumGetLineP(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_LINE_P(x) return LinePGetDatum(x)
|
|
|
|
|
|
|
|
|
|
#define DatumGetBoxP(X) ((BOX *) DatumGetPointer(X))
|
|
|
|
|
#define BoxPGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
#define PG_GETARG_BOX_P(n) DatumGetBoxP(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_BOX_P(x) return BoxPGetDatum(x)
|
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetPolygonP(X) ((POLYGON *) PG_DETOAST_DATUM(X))
|
|
|
|
|
#define DatumGetPolygonPCopy(X) ((POLYGON *) PG_DETOAST_DATUM_COPY(X))
|
|
|
|
|
#define PolygonPGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
#define PG_GETARG_POLYGON_P(n) DatumGetPolygonP(PG_GETARG_DATUM(n))
|
2000-07-29 20:46:12 +02:00
|
|
|
#define PG_GETARG_POLYGON_P_COPY(n) DatumGetPolygonPCopy(PG_GETARG_DATUM(n))
|
2001-03-22 05:01:46 +01:00
|
|
|
#define PG_RETURN_POLYGON_P(x) return PolygonPGetDatum(x)
|
2000-06-13 09:35:40 +02:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetCircleP(X) ((CIRCLE *) DatumGetPointer(X))
|
|
|
|
|
#define CirclePGetDatum(X) PointerGetDatum(X)
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_CIRCLE_P(n) DatumGetCircleP(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_CIRCLE_P(x) return CirclePGetDatum(x)
|
|
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/*
|
1997-03-15 00:34:16 +01:00
|
|
|
* in geo_ops.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
1997-07-29 18:16:14 +02:00
|
|
|
|
|
|
|
|
/* public point routines */
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum point_in(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_out(PG_FUNCTION_ARGS);
|
2003-05-09 23:19:50 +02:00
|
|
|
extern Datum point_recv(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_send(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum construct_point(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_left(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_right(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_above(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_below(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_vert(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_horiz(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_eq(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_ne(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_distance(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_slope(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_add(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_sub(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_mul(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum point_div(PG_FUNCTION_ARGS);
|
1997-07-29 18:16:14 +02:00
|
|
|
|
|
|
|
|
/* private routines */
|
1997-09-08 23:56:23 +02:00
|
|
|
extern double point_dt(Point *pt1, Point *pt2);
|
|
|
|
|
extern double point_sl(Point *pt1, Point *pt2);
|
1997-07-29 18:16:14 +02:00
|
|
|
|
|
|
|
|
/* public lseg routines */
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum lseg_in(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_out(PG_FUNCTION_ARGS);
|
2003-05-13 20:03:08 +02:00
|
|
|
extern Datum lseg_recv(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_send(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum lseg_intersect(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_parallel(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_perp(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_vertical(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_horizontal(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_eq(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_ne(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_lt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_le(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_gt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_ge(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_construct(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_length(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_distance(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_center(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum lseg_interpt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum dist_pl(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum dist_ps(PG_FUNCTION_ARGS);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum dist_ppath(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum dist_pb(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum dist_sl(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum dist_sb(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum dist_lb(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum close_lseg(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum close_pl(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum close_ps(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum close_pb(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum close_sl(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum close_sb(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum close_ls(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum close_lb(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum on_pl(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum on_ps(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum on_pb(PG_FUNCTION_ARGS);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum on_ppath(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum on_sl(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum on_sb(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum inter_sl(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum inter_sb(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum inter_lb(PG_FUNCTION_ARGS);
|
1998-05-10 00:44:38 +02:00
|
|
|
|
|
|
|
|
/* public line routines */
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum line_in(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_out(PG_FUNCTION_ARGS);
|
2003-05-13 20:03:08 +02:00
|
|
|
extern Datum line_recv(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_send(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum line_interpt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_distance(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_construct_pp(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_intersect(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_parallel(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_perp(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_vertical(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_horizontal(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum line_eq(PG_FUNCTION_ARGS);
|
1997-07-29 18:16:14 +02:00
|
|
|
|
|
|
|
|
/* public box routines */
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum box_in(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_out(PG_FUNCTION_ARGS);
|
2003-05-13 20:03:08 +02:00
|
|
|
extern Datum box_recv(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_send(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum box_same(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_overlap(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_overleft(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_left(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_right(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_overright(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_contained(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_contain(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_below(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_above(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_lt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_gt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_eq(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_le(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_ge(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_area(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_width(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_height(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_distance(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_center(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_intersect(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_diagonal(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum points_box(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_add(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_sub(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_mul(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_div(PG_FUNCTION_ARGS);
|
2000-07-29 20:46:12 +02:00
|
|
|
|
1997-07-29 18:16:14 +02:00
|
|
|
/* public path routines */
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum path_in(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_out(PG_FUNCTION_ARGS);
|
2003-05-13 20:03:08 +02:00
|
|
|
extern Datum path_recv(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_send(PG_FUNCTION_ARGS);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum path_n_lt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_n_gt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_n_eq(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_n_le(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_n_ge(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_inter(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_distance(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_length(PG_FUNCTION_ARGS);
|
|
|
|
|
|
|
|
|
|
extern Datum path_isclosed(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_isopen(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_npoints(PG_FUNCTION_ARGS);
|
|
|
|
|
|
|
|
|
|
extern Datum path_close(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_open(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_add(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_add_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_sub_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_mul_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_div_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
|
|
|
|
|
extern Datum path_center(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum path_poly(PG_FUNCTION_ARGS);
|
1997-06-03 16:11:28 +02:00
|
|
|
|
|
|
|
|
/* public polygon routines */
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum poly_in(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_out(PG_FUNCTION_ARGS);
|
2003-05-13 20:03:08 +02:00
|
|
|
extern Datum poly_recv(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_send(PG_FUNCTION_ARGS);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum poly_left(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_overleft(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_right(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_overright(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_same(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_overlap(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_contain(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_contained(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_contain_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum pt_contained_poly(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_distance(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_npoints(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_center(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_box(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum poly_path(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_poly(PG_FUNCTION_ARGS);
|
1997-07-29 18:16:14 +02:00
|
|
|
|
1997-06-03 16:11:28 +02:00
|
|
|
/* public circle routines */
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum circle_in(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_out(PG_FUNCTION_ARGS);
|
2003-05-13 20:03:08 +02:00
|
|
|
extern Datum circle_recv(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_send(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum circle_same(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_overlap(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_overleft(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_left(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_right(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_overright(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_contained(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_contain(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_below(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_above(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_eq(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_ne(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_lt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_gt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_le(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_ge(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_contain_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum pt_contained_circle(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_add_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_sub_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_mul_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_div_pt(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_diameter(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_radius(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_distance(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum dist_pc(PG_FUNCTION_ARGS);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum dist_cpoly(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum circle_center(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum cr_circle(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum box_circle(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum circle_box(PG_FUNCTION_ARGS);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum poly_circle(PG_FUNCTION_ARGS);
|
2000-06-13 09:35:40 +02:00
|
|
|
extern Datum circle_poly(PG_FUNCTION_ARGS);
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum circle_area(PG_FUNCTION_ARGS);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
/* support routines for the rtree access method (rtproc.c) */
|
2000-07-30 22:44:02 +02:00
|
|
|
extern Datum rt_box_union(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum rt_box_inter(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum rt_box_size(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum rt_bigbox_size(PG_FUNCTION_ARGS);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum rt_poly_size(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum rt_poly_union(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum rt_poly_inter(PG_FUNCTION_ARGS);
|
|
|
|
|
|
1997-03-15 00:34:16 +01:00
|
|
|
/* geo_selfuncs.c */
|
2000-06-05 09:29:25 +02:00
|
|
|
extern Datum areasel(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum areajoinsel(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum positionsel(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum positionjoinsel(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum contsel(PG_FUNCTION_ARGS);
|
|
|
|
|
extern Datum contjoinsel(PG_FUNCTION_ARGS);
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2001-11-05 18:46:40 +01:00
|
|
|
#endif /* GEO_DECLS_H */
|
