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
|
|
|
*
|
|
|
|
|
*
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1996-2000, PostgreSQL, Inc
|
|
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2000-06-05 09:29:25 +02:00
|
|
|
* $Id: geo_decls.h,v 1.28 2000/06/05 07:29:07 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
|
|
|
|
1996-11-10 04:06:38 +01:00
|
|
|
#include "access/attnum.h"
|
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)
|
|
|
|
|
#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
|
1997-09-07 07:04:48 +02:00
|
|
|
#define FPzero(A) (A == 0)
|
|
|
|
|
#define FPnzero(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
|
|
|
|
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 */
|
1997-09-08 04:41:22 +02:00
|
|
|
extern Point *point_in(char *str);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern char *point_out(Point *pt);
|
|
|
|
|
extern bool point_left(Point *pt1, Point *pt2);
|
|
|
|
|
extern bool point_right(Point *pt1, Point *pt2);
|
|
|
|
|
extern bool point_above(Point *pt1, Point *pt2);
|
|
|
|
|
extern bool point_below(Point *pt1, Point *pt2);
|
|
|
|
|
extern bool point_vert(Point *pt1, Point *pt2);
|
|
|
|
|
extern bool point_horiz(Point *pt1, Point *pt2);
|
|
|
|
|
extern bool point_eq(Point *pt1, Point *pt2);
|
1997-09-20 18:25:28 +02:00
|
|
|
extern bool point_ne(Point *pt1, Point *pt2);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern int32 pointdist(Point *p1, Point *p2);
|
|
|
|
|
extern double *point_distance(Point *pt1, Point *pt2);
|
|
|
|
|
extern double *point_slope(Point *pt1, Point *pt2);
|
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
|
|
|
|
1997-09-08 23:56:23 +02:00
|
|
|
extern Point *point(float8 *x, float8 *y);
|
|
|
|
|
extern Point *point_add(Point *p1, Point *p2);
|
|
|
|
|
extern Point *point_sub(Point *p1, Point *p2);
|
|
|
|
|
extern Point *point_mul(Point *p1, Point *p2);
|
|
|
|
|
extern Point *point_div(Point *p1, Point *p2);
|
1997-07-29 18:16:14 +02:00
|
|
|
|
|
|
|
|
/* public lseg routines */
|
1997-09-08 04:41:22 +02:00
|
|
|
extern LSEG *lseg_in(char *str);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern char *lseg_out(LSEG *ls);
|
|
|
|
|
extern bool lseg_intersect(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern bool lseg_parallel(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern bool lseg_perp(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern bool lseg_vertical(LSEG *lseg);
|
|
|
|
|
extern bool lseg_horizontal(LSEG *lseg);
|
|
|
|
|
extern bool lseg_eq(LSEG *l1, LSEG *l2);
|
1998-02-03 17:01:59 +01:00
|
|
|
extern bool lseg_ne(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern bool lseg_lt(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern bool lseg_le(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern bool lseg_gt(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern bool lseg_ge(LSEG *l1, LSEG *l2);
|
1998-05-10 00:44:38 +02:00
|
|
|
extern LSEG *lseg_construct(Point *pt1, Point *pt2);
|
1998-02-03 17:01:59 +01:00
|
|
|
extern double *lseg_length(LSEG *lseg);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern double *lseg_distance(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern Point *lseg_center(LSEG *lseg);
|
|
|
|
|
extern Point *lseg_interpt(LSEG *l1, LSEG *l2);
|
|
|
|
|
extern double *dist_pl(Point *pt, LINE *line);
|
|
|
|
|
extern double *dist_ps(Point *pt, LSEG *lseg);
|
|
|
|
|
extern double *dist_ppath(Point *pt, PATH *path);
|
|
|
|
|
extern double *dist_pb(Point *pt, BOX *box);
|
|
|
|
|
extern double *dist_sl(LSEG *lseg, LINE *line);
|
|
|
|
|
extern double *dist_sb(LSEG *lseg, BOX *box);
|
|
|
|
|
extern double *dist_lb(LINE *line, BOX *box);
|
1998-02-03 17:01:59 +01:00
|
|
|
extern Point *close_lseg(LSEG *l1, LSEG *l2);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern Point *close_pl(Point *pt, LINE *line);
|
|
|
|
|
extern Point *close_ps(Point *pt, LSEG *lseg);
|
|
|
|
|
extern Point *close_pb(Point *pt, BOX *box);
|
|
|
|
|
extern Point *close_sl(LSEG *lseg, LINE *line);
|
|
|
|
|
extern Point *close_sb(LSEG *lseg, BOX *box);
|
1998-02-03 17:01:59 +01:00
|
|
|
extern Point *close_ls(LINE *line, LSEG *lseg);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern Point *close_lb(LINE *line, BOX *box);
|
|
|
|
|
extern bool on_pl(Point *pt, LINE *line);
|
|
|
|
|
extern bool on_ps(Point *pt, LSEG *lseg);
|
|
|
|
|
extern bool on_pb(Point *pt, BOX *box);
|
|
|
|
|
extern bool on_ppath(Point *pt, PATH *path);
|
|
|
|
|
extern bool on_sl(LSEG *lseg, LINE *line);
|
|
|
|
|
extern bool on_sb(LSEG *lseg, BOX *box);
|
|
|
|
|
extern bool inter_sl(LSEG *lseg, LINE *line);
|
|
|
|
|
extern bool inter_sb(LSEG *lseg, BOX *box);
|
|
|
|
|
extern bool inter_lb(LINE *line, BOX *box);
|
1997-07-29 18:16:14 +02:00
|
|
|
|
1998-05-10 00:44:38 +02:00
|
|
|
/* private lseg routines */
|
|
|
|
|
|
|
|
|
|
/* public line routines */
|
|
|
|
|
extern LINE *line_in(char *str);
|
|
|
|
|
extern char *line_out(LINE *line);
|
|
|
|
|
extern Point *line_interpt(LINE *l1, LINE *l2);
|
|
|
|
|
extern double *line_distance(LINE *l1, LINE *l2);
|
|
|
|
|
extern LINE *line_construct_pp(Point *pt1, Point *pt2);
|
|
|
|
|
extern bool line_intersect(LINE *l1, LINE *l2);
|
|
|
|
|
extern bool line_parallel(LINE *l1, LINE *l2);
|
|
|
|
|
extern bool line_perp(LINE *l1, LINE *l2);
|
|
|
|
|
extern bool line_vertical(LINE *line);
|
|
|
|
|
extern bool line_horizontal(LINE *line);
|
|
|
|
|
extern bool line_eq(LINE *l1, LINE *l2);
|
|
|
|
|
|
|
|
|
|
/* private line routines */
|
1997-07-29 18:16:14 +02:00
|
|
|
|
|
|
|
|
/* public box routines */
|
1997-09-08 04:41:22 +02:00
|
|
|
extern BOX *box_in(char *str);
|
1997-09-08 22:59:27 +02:00
|
|
|
extern char *box_out(BOX *box);
|
|
|
|
|
extern bool box_same(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_overlap(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_overleft(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_left(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_right(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_overright(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_contained(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_contain(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_below(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_above(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_lt(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_gt(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_eq(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_le(BOX *box1, BOX *box2);
|
|
|
|
|
extern bool box_ge(BOX *box1, BOX *box2);
|
|
|
|
|
extern Point *box_center(BOX *box);
|
|
|
|
|
extern double *box_area(BOX *box);
|
|
|
|
|
extern double *box_width(BOX *box);
|
|
|
|
|
extern double *box_height(BOX *box);
|
|
|
|
|
extern double *box_distance(BOX *box1, BOX *box2);
|
|
|
|
|
extern Point *box_center(BOX *box);
|
|
|
|
|
extern BOX *box_intersect(BOX *box1, BOX *box2);
|
|
|
|
|
extern LSEG *box_diagonal(BOX *box);
|
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
|
|
|
|
|
|
|
|
/* private routines */
|
1997-07-29 18:16:14 +02:00
|
|
|
|
1997-09-08 22:59:27 +02:00
|
|
|
extern double box_dt(BOX *box1, BOX *box2);
|
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
|
|
|
|
1997-09-08 23:56:23 +02:00
|
|
|
extern BOX *box(Point *p1, Point *p2);
|
|
|
|
|
extern BOX *box_add(BOX *box, Point *p);
|
|
|
|
|
extern BOX *box_sub(BOX *box, Point *p);
|
|
|
|
|
extern BOX *box_mul(BOX *box, Point *p);
|
|
|
|
|
extern BOX *box_div(BOX *box, Point *p);
|
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
|
|
|
|
1997-07-29 18:16:14 +02:00
|
|
|
/* public path routines */
|
1997-09-08 04:41:22 +02:00
|
|
|
extern PATH *path_in(char *str);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern char *path_out(PATH *path);
|
|
|
|
|
extern bool path_n_lt(PATH *p1, PATH *p2);
|
|
|
|
|
extern bool path_n_gt(PATH *p1, PATH *p2);
|
|
|
|
|
extern bool path_n_eq(PATH *p1, PATH *p2);
|
|
|
|
|
extern bool path_n_le(PATH *p1, PATH *p2);
|
|
|
|
|
extern bool path_n_ge(PATH *p1, PATH *p2);
|
|
|
|
|
extern bool path_inter(PATH *p1, PATH *p2);
|
|
|
|
|
extern double *path_distance(PATH *p1, PATH *p2);
|
|
|
|
|
extern double *path_length(PATH *path);
|
|
|
|
|
|
|
|
|
|
extern bool path_isclosed(PATH *path);
|
|
|
|
|
extern bool path_isopen(PATH *path);
|
|
|
|
|
extern int4 path_npoints(PATH *path);
|
|
|
|
|
|
|
|
|
|
extern PATH *path_close(PATH *path);
|
|
|
|
|
extern PATH *path_open(PATH *path);
|
|
|
|
|
extern PATH *path_add(PATH *p1, PATH *p2);
|
|
|
|
|
extern PATH *path_add_pt(PATH *path, Point *point);
|
|
|
|
|
extern PATH *path_sub_pt(PATH *path, Point *point);
|
|
|
|
|
extern PATH *path_mul_pt(PATH *path, Point *point);
|
|
|
|
|
extern PATH *path_div_pt(PATH *path, Point *point);
|
|
|
|
|
|
|
|
|
|
extern Point *path_center(PATH *path);
|
|
|
|
|
extern POLYGON *path_poly(PATH *path);
|
|
|
|
|
|
|
|
|
|
extern PATH *upgradepath(PATH *path);
|
|
|
|
|
extern bool isoldpath(PATH *path);
|
1997-06-03 16:11:28 +02:00
|
|
|
|
|
|
|
|
/* public polygon routines */
|
1996-08-28 03:59:28 +02:00
|
|
|
extern POLYGON *poly_in(char *s);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern char *poly_out(POLYGON *poly);
|
|
|
|
|
extern bool poly_left(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern bool poly_overleft(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern bool poly_right(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern bool poly_overright(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern bool poly_same(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern bool poly_overlap(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern bool poly_contain(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern bool poly_contained(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern bool poly_contain_pt(POLYGON *poly, Point *p);
|
|
|
|
|
extern bool pt_contained_poly(Point *p, POLYGON *poly);
|
|
|
|
|
|
|
|
|
|
extern double *poly_distance(POLYGON *polya, POLYGON *polyb);
|
|
|
|
|
extern int4 poly_npoints(POLYGON *poly);
|
|
|
|
|
extern Point *poly_center(POLYGON *poly);
|
|
|
|
|
extern BOX *poly_box(POLYGON *poly);
|
|
|
|
|
extern PATH *poly_path(POLYGON *poly);
|
1997-09-08 22:59:27 +02:00
|
|
|
extern POLYGON *box_poly(BOX *box);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 23:56:23 +02:00
|
|
|
extern POLYGON *upgradepoly(POLYGON *poly);
|
|
|
|
|
extern POLYGON *revertpoly(POLYGON *poly);
|
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
|
|
|
|
1997-07-29 18:16:14 +02:00
|
|
|
/* private polygon routines */
|
|
|
|
|
|
1997-06-03 16:11:28 +02:00
|
|
|
/* public circle routines */
|
1997-09-08 04:41:22 +02:00
|
|
|
extern CIRCLE *circle_in(char *str);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern char *circle_out(CIRCLE *circle);
|
|
|
|
|
extern bool circle_same(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_overlap(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_overleft(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_left(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_right(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_overright(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_contained(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_contain(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_below(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_above(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
|
|
|
|
|
extern bool circle_eq(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_ne(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_lt(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_gt(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_le(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_ge(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern bool circle_contain_pt(CIRCLE *circle, Point *point);
|
|
|
|
|
extern bool pt_contained_circle(Point *point, CIRCLE *circle);
|
|
|
|
|
extern CIRCLE *circle_add_pt(CIRCLE *circle, Point *point);
|
|
|
|
|
extern CIRCLE *circle_sub_pt(CIRCLE *circle, Point *point);
|
|
|
|
|
extern CIRCLE *circle_mul_pt(CIRCLE *circle, Point *point);
|
|
|
|
|
extern CIRCLE *circle_div_pt(CIRCLE *circle, Point *point);
|
|
|
|
|
extern double *circle_diameter(CIRCLE *circle);
|
|
|
|
|
extern double *circle_radius(CIRCLE *circle);
|
|
|
|
|
extern double *circle_distance(CIRCLE *circle1, CIRCLE *circle2);
|
|
|
|
|
extern double *dist_pc(Point *point, CIRCLE *circle);
|
|
|
|
|
extern double *dist_cpoly(CIRCLE *circle, POLYGON *poly);
|
|
|
|
|
extern Point *circle_center(CIRCLE *circle);
|
|
|
|
|
extern CIRCLE *circle(Point *center, float8 *radius);
|
1997-09-08 22:59:27 +02:00
|
|
|
extern CIRCLE *box_circle(BOX *box);
|
1997-09-08 23:56:23 +02:00
|
|
|
extern BOX *circle_box(CIRCLE *circle);
|
|
|
|
|
extern CIRCLE *poly_circle(POLYGON *poly);
|
|
|
|
|
extern POLYGON *circle_poly(int npts, CIRCLE *circle);
|
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
|
|
|
|
|
|
|
|
/* private routines */
|
1997-09-08 23:56:23 +02:00
|
|
|
extern double *circle_area(CIRCLE *circle);
|
|
|
|
|
extern double circle_dt(CIRCLE *circle1, CIRCLE *circle2);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
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);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 06:40:42 +02:00
|
|
|
#endif /* GEO_DECLS_H */
|
