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-07-29 20:46:12 +02:00
|
|
|
* $Id: geo_decls.h,v 1.30 2000/07/29 18:46:05 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
|
|
|
|
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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#define DatumGetPointP(X) ((Point *) DatumGetPointer(X))
|
|
|
|
|
#define PointPGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
#define PG_GETARG_POINT_P(n) DatumGetPointP(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_POINT_P(x) return PointPGetDatum(x)
|
|
|
|
|
|
|
|
|
|
#define DatumGetLsegP(X) ((LSEG *) DatumGetPointer(X))
|
|
|
|
|
#define LsegPGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
#define PG_GETARG_LSEG_P(n) DatumGetLsegP(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_LSEG_P(x) return LsegPGetDatum(x)
|
|
|
|
|
|
2000-07-29 20:46:12 +02: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))
|
|
|
|
|
#define PG_GETARG_PATH_P_COPY(n) DatumGetPathPCopy(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_PATH_P(x) return PathPGetDatum(x)
|
2000-06-13 09:35:40 +02:00
|
|
|
|
|
|
|
|
#define DatumGetLineP(X) ((LINE *) DatumGetPointer(X))
|
|
|
|
|
#define LinePGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
#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)
|
|
|
|
|
|
2000-07-29 20:46:12 +02: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))
|
|
|
|
|
#define PG_GETARG_POLYGON_P_COPY(n) DatumGetPolygonPCopy(PG_GETARG_DATUM(n))
|
|
|
|
|
#define PG_RETURN_POLYGON_P(x) return PolygonPGetDatum(x)
|
2000-06-13 09:35:40 +02:00
|
|
|
|
|
|
|
|
#define DatumGetCircleP(X) ((CIRCLE *) DatumGetPointer(X))
|
|
|
|
|
#define CirclePGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
#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 */
|
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);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum dist_ppath(PG_FUNCTION_ARGS);
|
1997-09-08 23:56:23 +02:00
|
|
|
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);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum on_ppath(PG_FUNCTION_ARGS);
|
1997-09-08 23:56:23 +02:00
|
|
|
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);
|
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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
/* private routines */
|
|
|
|
|
extern double box_dt(BOX *box1, BOX *box2);
|
|
|
|
|
|
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);
|
|
|
|
|
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);
|
|
|
|
|
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 */
|
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);
|
2000-07-29 20:46:12 +02:00
|
|
|
extern Datum dist_cpoly(PG_FUNCTION_ARGS);
|
1997-09-08 23:56:23 +02:00
|
|
|
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);
|
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);
|
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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
/* support routines for the rtree access method (rtproc.c) */
|
|
|
|
|
extern BOX *rt_box_union(BOX *a, BOX *b);
|
|
|
|
|
extern BOX *rt_box_inter(BOX *a, BOX *b);
|
|
|
|
|
extern void rt_box_size(BOX *a, float *size);
|
|
|
|
|
extern void rt_bigbox_size(BOX *a, float *size);
|
|
|
|
|
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);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 06:40:42 +02:00
|
|
|
#endif /* GEO_DECLS_H */
|
