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
|
|
|
*
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 1994, Regents of the University of California
|
|
|
|
|
*
|
1997-06-03 16:11:28 +02:00
|
|
|
* $Id: geo_decls.h,v 1.5 1997/06/03 14:10:32 thomas Exp $
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
* NOTE
|
|
|
|
|
* These routines do *not* use the float types from adt/.
|
|
|
|
|
*
|
|
|
|
|
* XXX These routines were not written by a numerical analyst.
|
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
|
|
|
* 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
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef GEO_DECLS_H
|
|
|
|
|
#define GEO_DECLS_H
|
|
|
|
|
|
1996-11-10 04:06:38 +01:00
|
|
|
#include "access/attnum.h"
|
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
/*#ifndef FmgrIncluded -- seems like always included. (it's FMgrIncluded) AY */
|
|
|
|
|
|
|
|
|
|
/*--------------------------------------------------------------------
|
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
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#define EPSILON 1.0E-06
|
|
|
|
|
|
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
|
1996-08-28 03:59:28 +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
|
|
|
|
|
#define FPzero(A) (A == 0)
|
|
|
|
|
#define FPeq(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)
|
|
|
|
|
#endif
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
#define HYPOT(A, B) sqrt((A) * (A) + (B) * (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
|
|
|
* Memory management.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
#define PALLOC(SIZE) palloc(SIZE)
|
|
|
|
|
#define PFREE(P) pfree(P)
|
|
|
|
|
#define PALLOCTYPE(TYPE) (TYPE *) PALLOC(sizeof(TYPE))
|
|
|
|
|
|
|
|
|
|
/*#endif !FmgrIncluded */
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
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
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
typedef struct {
|
|
|
|
|
double x, y;
|
|
|
|
|
} Point;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
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
|
|
|
* LSEG - A straight line, specified by endpoints.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
typedef struct {
|
|
|
|
|
Point p[2];
|
|
|
|
|
|
|
|
|
|
double m; /* precomputed to save time, not in tuple */
|
|
|
|
|
} LSEG;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
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
|
|
|
* PATH - Specified by vertex points.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
typedef struct {
|
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
|
|
|
int32 size; /* XXX varlena */
|
1996-08-28 03:59:28 +02:00
|
|
|
int32 npts;
|
|
|
|
|
int32 closed; /* is this a closed polygon? */
|
|
|
|
|
int32 dummy; /* padding to make it double align */
|
1997-05-06 09:24:42 +02:00
|
|
|
Point p[1]; /* variable length array of POINTs */
|
1996-08-28 03:59:28 +02:00
|
|
|
} PATH;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
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
|
|
|
* 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
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
typedef struct {
|
|
|
|
|
double A, B, C;
|
|
|
|
|
double m;
|
|
|
|
|
} LINE;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
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
|
|
|
|
|
* sorted to save calculation time later.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
typedef struct {
|
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 high, low; /* corner POINTs */
|
1996-08-28 03:59:28 +02:00
|
|
|
} 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
|
|
|
* 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
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
typedef struct {
|
|
|
|
|
int32 size; /* XXX varlena */
|
|
|
|
|
int32 npts;
|
|
|
|
|
BOX boundbox;
|
1997-05-06 09:24:42 +02:00
|
|
|
Point p[1]; /* variable length array of POINTs */
|
1996-08-28 03:59:28 +02:00
|
|
|
} POLYGON;
|
|
|
|
|
|
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.
|
|
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
typedef struct {
|
|
|
|
|
Point center;
|
|
|
|
|
double radius;
|
|
|
|
|
} CIRCLE;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
/*
|
1997-03-15 00:34:16 +01:00
|
|
|
* in geo_ops.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
|
|
|
|
extern BOX *box_in(char *str);
|
|
|
|
|
extern char *box_out(BOX *box);
|
|
|
|
|
extern BOX *box_construct(double x1, double x2, double y1, double y2);
|
|
|
|
|
extern BOX *box_fill(BOX *result, double x1, double x2, double y1, double y2);
|
|
|
|
|
extern BOX *box_copy(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
|
|
|
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);
|
1996-08-28 03:59:28 +02:00
|
|
|
extern double *box_area(BOX *box);
|
|
|
|
|
extern double *box_length(BOX *box);
|
|
|
|
|
extern double *box_height(BOX *box);
|
|
|
|
|
extern double *box_distance(BOX *box1, BOX *box2);
|
|
|
|
|
extern Point *box_center(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
|
|
|
extern BOX *box_intersect(BOX *box1, BOX *box2);
|
|
|
|
|
extern LSEG *box_diagonal(BOX *box);
|
|
|
|
|
|
|
|
|
|
/* private routines */
|
1996-08-28 03:59:28 +02:00
|
|
|
extern double box_ar(BOX *box);
|
|
|
|
|
extern double box_ln(BOX *box);
|
|
|
|
|
extern double box_ht(BOX *box);
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
extern LINE *line_construct_pm(Point *pt, double m);
|
|
|
|
|
extern LINE *line_construct_pp(Point *pt1, Point *pt2);
|
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
|
|
|
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);
|
1996-08-28 03:59:28 +02:00
|
|
|
extern double *line_distance(LINE *l1, LINE *l2);
|
|
|
|
|
extern Point *line_interpt(LINE *l1, LINE *l2);
|
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
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
extern PATH *path_in(char *str);
|
|
|
|
|
extern char *path_out(PATH *path);
|
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
|
|
|
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);
|
1996-08-28 03:59:28 +02:00
|
|
|
extern double *path_distance(PATH *p1, PATH *p2);
|
|
|
|
|
extern double *path_length(PATH *path);
|
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
|
|
|
|
|
|
|
|
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 POLYGON *path_poly(PATH *path);
|
1997-06-03 16:11:28 +02:00
|
|
|
extern PATH *upgradepath(PATH *path);
|
|
|
|
|
extern bool isoldpath(PATH *path);
|
|
|
|
|
|
|
|
|
|
/* private routines */
|
|
|
|
|
extern double path_ln(PATH *path);
|
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-06-03 16:11:28 +02:00
|
|
|
/* public point routines */
|
1996-08-28 03:59:28 +02:00
|
|
|
extern Point *point_in(char *str);
|
|
|
|
|
extern char *point_out(Point *pt);
|
|
|
|
|
extern Point *point_construct(double x, double y);
|
|
|
|
|
extern Point *point_copy(Point *pt);
|
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
|
|
|
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);
|
|
|
|
|
extern int32 pointdist(Point *p1, Point *p2);
|
1996-08-28 03:59:28 +02:00
|
|
|
extern double *point_distance(Point *pt1, Point *pt2);
|
|
|
|
|
extern double *point_slope(Point *pt1, Point *pt2);
|
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 */
|
|
|
|
|
extern double point_dt(Point *pt1, Point *pt2);
|
1996-08-28 03:59:28 +02:00
|
|
|
extern double point_sl(Point *pt1, Point *pt2);
|
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
|
|
|
|
|
|
|
|
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-06-03 16:11:28 +02:00
|
|
|
/* public lseg routines */
|
1996-08-28 03:59:28 +02:00
|
|
|
extern LSEG *lseg_in(char *str);
|
|
|
|
|
extern char *lseg_out(LSEG *ls);
|
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
|
|
|
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);
|
1996-08-28 03:59:28 +02:00
|
|
|
extern double *lseg_distance(LSEG *l1, LSEG *l2);
|
|
|
|
|
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_ppth(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);
|
|
|
|
|
extern Point *interpt_sl(LSEG *lseg, LINE *line);
|
|
|
|
|
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);
|
|
|
|
|
extern Point *close_lb(LINE *line, 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
|
|
|
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);
|
|
|
|
|
|
|
|
|
|
/* private routines */
|
|
|
|
|
extern LSEG *lseg_construct(Point *pt1, Point *pt2);
|
|
|
|
|
extern void statlseg_construct(LSEG *lseg, Point *pt1, Point *pt2);
|
|
|
|
|
extern double lseg_dt(LSEG *l1, LSEG *l2);
|
1996-08-28 03:59:28 +02:00
|
|
|
extern void make_bound_box(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-06-03 16:11:28 +02:00
|
|
|
/* public polygon routines */
|
1996-08-28 03:59:28 +02:00
|
|
|
extern POLYGON *poly_in(char *s);
|
|
|
|
|
extern char *poly_out(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
|
|
|
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 int4 poly_npoints(POLYGON *poly);
|
|
|
|
|
extern BOX *poly_box(POLYGON *poly);
|
|
|
|
|
extern PATH *poly_path(POLYGON *poly);
|
|
|
|
|
extern POLYGON *box_poly(BOX *box);
|
1997-06-03 16:11:28 +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-06-03 16:11:28 +02:00
|
|
|
/* public circle routines */
|
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
|
|
|
extern CIRCLE *circle_in(char *str);
|
|
|
|
|
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 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_area(CIRCLE *circle);
|
|
|
|
|
extern double *circle_diameter(CIRCLE *circle);
|
|
|
|
|
extern double *circle_radius(CIRCLE *circle);
|
|
|
|
|
extern double *circle_distance(CIRCLE *circle1, CIRCLE *circle2);
|
1997-04-25 20:40:50 +02:00
|
|
|
extern double *dist_pc(Point *point, 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
|
|
|
extern Point *circle_center(CIRCLE *circle);
|
|
|
|
|
extern CIRCLE *circle(Point *center, float8 *radius);
|
|
|
|
|
extern CIRCLE *poly_circle(POLYGON *poly);
|
|
|
|
|
extern POLYGON *circle_poly(int npts, CIRCLE *circle);
|
|
|
|
|
|
|
|
|
|
/* private routines */
|
|
|
|
|
extern double circle_ar(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 */
|
1996-11-10 04:06:38 +01:00
|
|
|
extern float64 areasel(Oid opid, Oid relid, AttrNumber attno,
|
|
|
|
|
char *value, int32 flag);
|
|
|
|
|
extern float64 areajoinsel(Oid opid, Oid relid, AttrNumber attno,
|
|
|
|
|
char *value, int32 flag);
|
|
|
|
|
extern float64 leftsel(Oid opid, Oid relid, AttrNumber attno,
|
|
|
|
|
char *value, int32 flag);
|
|
|
|
|
extern float64 leftjoinsel(Oid opid, Oid relid, AttrNumber attno,
|
|
|
|
|
char *value, int32 flag);
|
|
|
|
|
extern float64 contsel(Oid opid, Oid relid, AttrNumber attno,
|
|
|
|
|
char *value, int32 flag);
|
|
|
|
|
extern float64 contjoinsel(Oid opid, Oid relid, AttrNumber attno,
|
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
|
|
|
char *value, int32 flag);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
#endif /* GEO_DECLS_H */
|
