1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* geo_ops.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* 2D geometric operations
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2002-06-20 22:29:54 +02:00
|
|
|
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2002-07-16 05:30:27 +02:00
|
|
|
* $Header: /cvsroot/pgsql/src/backend/utils/adt/geo_ops.c,v 1.63 2002/07/16 03:30:27 momjian Exp $
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include <math.h>
|
1997-07-29 18:08:18 +02:00
|
|
|
#include <limits.h>
|
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
|
|
|
#include <float.h>
|
|
|
|
#include <ctype.h>
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1996-11-03 07:54:38 +01:00
|
|
|
#include "postgres.h"
|
|
|
|
|
1997-03-15 00:21:12 +01:00
|
|
|
#include "utils/geo_decls.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifndef PI
|
|
|
|
#define PI 3.1415926536
|
|
|
|
#endif
|
|
|
|
|
1997-09-20 18:22:31 +02:00
|
|
|
/*
|
|
|
|
* Internal routines
|
|
|
|
*/
|
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
static int point_inside(Point *p, int npts, Point *plist);
|
1997-09-08 04:41:22 +02:00
|
|
|
static int lseg_crossing(double x, double y, double px, double py);
|
|
|
|
static BOX *box_construct(double x1, double x2, double y1, double y2);
|
1997-09-08 22:59:27 +02:00
|
|
|
static BOX *box_copy(BOX *box);
|
|
|
|
static BOX *box_fill(BOX *result, double x1, double x2, double y1, double y2);
|
2000-07-30 22:44:02 +02:00
|
|
|
static bool box_ov(BOX *box1, BOX *box2);
|
1997-09-08 22:59:27 +02:00
|
|
|
static double box_ht(BOX *box);
|
|
|
|
static double box_wd(BOX *box);
|
1997-09-08 23:56:23 +02:00
|
|
|
static double circle_ar(CIRCLE *circle);
|
|
|
|
static CIRCLE *circle_copy(CIRCLE *circle);
|
|
|
|
static LINE *line_construct_pm(Point *pt, double m);
|
2000-07-30 22:44:02 +02:00
|
|
|
static void line_construct_pts(LINE *line, Point *pt1, Point *pt2);
|
|
|
|
static bool lseg_intersect_internal(LSEG *l1, LSEG *l2);
|
1997-09-08 23:56:23 +02:00
|
|
|
static double lseg_dt(LSEG *l1, LSEG *l2);
|
2000-07-30 22:44:02 +02:00
|
|
|
static bool on_ps_internal(Point *pt, LSEG *lseg);
|
1997-09-08 23:56:23 +02:00
|
|
|
static void make_bound_box(POLYGON *poly);
|
1998-09-01 05:29:17 +02:00
|
|
|
static bool plist_same(int npts, Point *p1, Point *p2);
|
1997-09-08 04:41:22 +02:00
|
|
|
static Point *point_construct(double x, double y);
|
1997-09-08 23:56:23 +02:00
|
|
|
static Point *point_copy(Point *pt);
|
|
|
|
static int single_decode(char *str, float8 *x, char **ss);
|
1997-09-08 04:41:22 +02:00
|
|
|
static int single_encode(float8 x, char *str);
|
1997-09-08 23:56:23 +02:00
|
|
|
static int pair_decode(char *str, float8 *x, float8 *y, char **s);
|
1997-09-08 04:41:22 +02:00
|
|
|
static int pair_encode(float8 x, float8 y, char *str);
|
|
|
|
static int pair_count(char *s, char delim);
|
1997-09-08 23:56:23 +02:00
|
|
|
static int path_decode(int opentype, int npts, char *str, int *isopen, char **ss, Point *p);
|
|
|
|
static char *path_encode(bool closed, int npts, Point *pt);
|
|
|
|
static void statlseg_construct(LSEG *lseg, Point *pt1, Point *pt2);
|
1997-09-08 22:59:27 +02:00
|
|
|
static double box_ar(BOX *box);
|
2000-07-30 22:44:02 +02:00
|
|
|
static void box_cn(Point *center, BOX *box);
|
1997-09-08 23:56:23 +02:00
|
|
|
static Point *interpt_sl(LSEG *lseg, LINE *line);
|
2000-07-30 22:44:02 +02:00
|
|
|
static bool has_interpt_sl(LSEG *lseg, LINE *line);
|
|
|
|
static double dist_pl_internal(Point *pt, LINE *line);
|
|
|
|
static double dist_ps_internal(Point *pt, LSEG *lseg);
|
|
|
|
static Point *line_interpt_internal(LINE *l1, LINE *l2);
|
1997-08-19 23:40:56 +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
|
|
|
|
|
|
|
/*
|
|
|
|
* Delimiters for input and output strings.
|
|
|
|
* LDELIM, RDELIM, and DELIM are left, right, and separator delimiters, respectively.
|
|
|
|
* LDELIM_EP, RDELIM_EP are left and right delimiters for paths with endpoints.
|
|
|
|
*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
#define LDELIM '('
|
|
|
|
#define RDELIM ')'
|
|
|
|
#define DELIM ','
|
|
|
|
#define LDELIM_EP '['
|
|
|
|
#define RDELIM_EP ']'
|
|
|
|
#define LDELIM_C '<'
|
|
|
|
#define RDELIM_C '>'
|
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
|
|
|
|
|
|
|
/* Maximum number of output digits printed */
|
|
|
|
#define P_MAXDIG DBL_DIG
|
|
|
|
#define P_MAXLEN (2*(P_MAXDIG+7)+1)
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static int digits8 = P_MAXDIG;
|
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
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Geometric data types are composed of points.
|
|
|
|
* This code tries to support a common format throughout the data types,
|
1997-09-07 07:04:48 +02:00
|
|
|
* to allow for more predictable usage and data type conversion.
|
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
|
|
|
* The fundamental unit is the point. Other units are line segments,
|
1997-09-07 07:04:48 +02:00
|
|
|
* open paths, boxes, closed paths, and polygons (which should be considered
|
|
|
|
* non-intersecting closed paths).
|
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
|
|
|
*
|
|
|
|
* Data representation is as follows:
|
1997-09-07 07:04:48 +02:00
|
|
|
* point: (x,y)
|
|
|
|
* line segment: [(x1,y1),(x2,y2)]
|
|
|
|
* box: (x1,y1),(x2,y2)
|
|
|
|
* open path: [(x1,y1),...,(xn,yn)]
|
|
|
|
* closed path: ((x1,y1),...,(xn,yn))
|
|
|
|
* polygon: ((x1,y1),...,(xn,yn))
|
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
|
|
|
*
|
|
|
|
* For boxes, the points are opposite corners with the first point at the top right.
|
|
|
|
* For closed paths and polygons, the points should be reordered to allow
|
1997-09-07 07:04:48 +02:00
|
|
|
* fast and correct equality comparisons.
|
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 perhaps points in complex shapes should be reordered internally
|
1997-09-07 07:04:48 +02:00
|
|
|
* to allow faster internal operations, but should keep track of input order
|
|
|
|
* and restore that order for text output - tgl 97/01/16
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
static int
|
1997-09-08 23:56:23 +02:00
|
|
|
single_decode(char *str, float8 *x, char **s)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
char *cp;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!PointerIsValid(str))
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *str))
|
1997-09-07 07:04:48 +02:00
|
|
|
str++;
|
|
|
|
*x = strtod(str, &cp);
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
2000-07-30 22:44:02 +02:00
|
|
|
printf("single_decode- (%x) try decoding %s to %g\n", (cp - str), str, *x);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
if (cp <= str)
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
cp++;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (s != NULL)
|
|
|
|
*s = cp;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return TRUE;
|
1998-02-26 05:46:47 +01:00
|
|
|
} /* single_decode() */
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
static int
|
|
|
|
single_encode(float8 x, char *str)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
sprintf(str, "%.*g", digits8, x);
|
1998-09-01 05:29:17 +02:00
|
|
|
return TRUE;
|
1998-02-26 05:46:47 +01:00
|
|
|
} /* single_encode() */
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
static int
|
1997-09-08 23:56:23 +02:00
|
|
|
pair_decode(char *str, float8 *x, float8 *y, char **s)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int has_delim;
|
|
|
|
char *cp;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
if (!PointerIsValid(str))
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *str))
|
1997-09-07 07:04:48 +02:00
|
|
|
str++;
|
|
|
|
if ((has_delim = (*str == LDELIM)))
|
|
|
|
str++;
|
|
|
|
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *str))
|
1997-09-07 07:04:48 +02:00
|
|
|
str++;
|
|
|
|
*x = strtod(str, &cp);
|
|
|
|
if (cp <= str)
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
cp++;
|
|
|
|
if (*cp++ != DELIM)
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
cp++;
|
|
|
|
*y = strtod(cp, &str);
|
|
|
|
if (str <= cp)
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *str))
|
1997-09-07 07:04:48 +02:00
|
|
|
str++;
|
|
|
|
if (has_delim)
|
|
|
|
{
|
|
|
|
if (*str != RDELIM)
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
1997-09-07 07:04:48 +02:00
|
|
|
str++;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *str))
|
1997-09-07 07:04:48 +02:00
|
|
|
str++;
|
|
|
|
}
|
|
|
|
if (s != NULL)
|
|
|
|
*s = str;
|
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
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return TRUE;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
static int
|
|
|
|
pair_encode(float8 x, float8 y, char *str)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
sprintf(str, "%.*g,%.*g", digits8, x, digits8, y);
|
1998-09-01 05:29:17 +02:00
|
|
|
return TRUE;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
static int
|
1997-09-08 23:56:23 +02:00
|
|
|
path_decode(int opentype, int npts, char *str, int *isopen, char **ss, Point *p)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int depth = 0;
|
|
|
|
char *s,
|
|
|
|
*cp;
|
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
s = str;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
|
|
|
if ((*isopen = (*s == LDELIM_EP)))
|
|
|
|
{
|
|
|
|
/* no open delimiter allowed? */
|
|
|
|
if (!opentype)
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
1997-09-07 07:04:48 +02:00
|
|
|
depth++;
|
|
|
|
s++;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
else if (*s == LDELIM)
|
|
|
|
{
|
|
|
|
cp = (s + 1);
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
cp++;
|
|
|
|
if (*cp == LDELIM)
|
|
|
|
{
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1997-09-07 07:04:48 +02:00
|
|
|
/* nested delimiters with only one point? */
|
|
|
|
if (npts <= 1)
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
1997-09-25 16:09:04 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
depth++;
|
|
|
|
s = cp;
|
|
|
|
}
|
|
|
|
else if (strrchr(s, LDELIM) == s)
|
|
|
|
{
|
|
|
|
depth++;
|
|
|
|
s = cp;
|
|
|
|
}
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
|
|
|
if (!pair_decode(s, &(p->x), &(p->y), &s))
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (*s == DELIM)
|
|
|
|
s++;
|
|
|
|
p++;
|
1997-09-05 20:13:45 +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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
while (depth > 0)
|
|
|
|
{
|
|
|
|
if ((*s == RDELIM)
|
|
|
|
|| ((*s == RDELIM_EP) && (*isopen) && (depth == 1)))
|
|
|
|
{
|
|
|
|
depth--;
|
|
|
|
s++;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
|
|
|
}
|
|
|
|
else
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
*ss = s;
|
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return TRUE;
|
1998-02-26 05:46:47 +01:00
|
|
|
} /* path_decode() */
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static char *
|
1997-09-08 23:56:23 +02:00
|
|
|
path_encode(bool closed, int npts, Point *pt)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1998-01-07 19:47:07 +01:00
|
|
|
char *result = palloc(npts * (P_MAXLEN + 3) + 2);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
char *cp;
|
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
cp = result;
|
|
|
|
switch (closed)
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
case TRUE:
|
|
|
|
*cp++ = LDELIM;
|
|
|
|
break;
|
|
|
|
case FALSE:
|
|
|
|
*cp++ = LDELIM_EP;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
1997-09-07 07:04:48 +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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
|
|
|
*cp++ = LDELIM;
|
|
|
|
if (!pair_encode(pt->x, pt->y, cp))
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "Unable to format path");
|
1997-09-07 07:04:48 +02:00
|
|
|
cp += strlen(cp);
|
|
|
|
*cp++ = RDELIM;
|
|
|
|
*cp++ = DELIM;
|
|
|
|
pt++;
|
|
|
|
}
|
|
|
|
cp--;
|
|
|
|
switch (closed)
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
case TRUE:
|
|
|
|
*cp++ = RDELIM;
|
|
|
|
break;
|
|
|
|
case FALSE:
|
|
|
|
*cp++ = RDELIM_EP;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
*cp = '\0';
|
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
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
1998-02-26 05:46:47 +01:00
|
|
|
} /* path_encode() */
|
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
|
|
|
|
|
|
|
/*-------------------------------------------------------------
|
|
|
|
* pair_count - count the number of points
|
|
|
|
* allow the following notation:
|
|
|
|
* '((1,2),(3,4))'
|
|
|
|
* '(1,3,2,4)'
|
|
|
|
* require an odd number of delim characters in the string
|
|
|
|
*-------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static int
|
|
|
|
pair_count(char *s, char delim)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int ndelim = 0;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
while ((s = strchr(s, delim)) != NULL)
|
|
|
|
{
|
|
|
|
ndelim++;
|
|
|
|
s++;
|
|
|
|
}
|
1998-09-01 05:29:17 +02:00
|
|
|
return (ndelim % 2) ? ((ndelim + 1) / 2) : -1;
|
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-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for two-dimensional boxes.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Formatting and conversion routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_in - convert a string to internal form.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* External format: (two corners of box)
|
|
|
|
* "(f8, f8), (f8, f8)"
|
|
|
|
* also supports the older style "(f8, f8, f8, f8)"
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
|
|
|
BOX *box = (BOX *) palloc(sizeof(BOX));
|
1997-09-08 04:41:22 +02:00
|
|
|
int isopen;
|
|
|
|
char *s;
|
|
|
|
double x,
|
|
|
|
y;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if ((!path_decode(FALSE, 2, str, &isopen, &s, &(box->high)))
|
|
|
|
|| (*s != '\0'))
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad box external representation '%s'", str);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* reorder corners if necessary... */
|
|
|
|
if (box->high.x < box->low.x)
|
|
|
|
{
|
|
|
|
x = box->high.x;
|
|
|
|
box->high.x = box->low.x;
|
|
|
|
box->low.x = x;
|
|
|
|
}
|
|
|
|
if (box->high.y < box->low.y)
|
|
|
|
{
|
|
|
|
y = box->high.y;
|
|
|
|
box->high.y = box->low.y;
|
|
|
|
box->low.y = y;
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(box);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_out - convert a box to external form.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(-1, 2, &(box->high)));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_construct - fill in a new box.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-08 04:41:22 +02:00
|
|
|
static BOX *
|
1997-09-07 07:04:48 +02:00
|
|
|
box_construct(double x1, double x2, double y1, double y2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *result = (BOX *) palloc(sizeof(BOX));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return box_fill(result, x1, x2, y1, y2);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/* box_fill - fill in a given box struct
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-08 04:41:22 +02:00
|
|
|
static BOX *
|
1997-09-08 22:59:27 +02:00
|
|
|
box_fill(BOX *result, double x1, double x2, double y1, double y2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (x1 > x2)
|
|
|
|
{
|
|
|
|
result->high.x = x1;
|
|
|
|
result->low.x = x2;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
result->high.x = x2;
|
|
|
|
result->low.x = x1;
|
|
|
|
}
|
|
|
|
if (y1 > y2)
|
|
|
|
{
|
|
|
|
result->high.y = y1;
|
|
|
|
result->low.y = y2;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
result->high.y = y2;
|
|
|
|
result->low.y = y1;
|
|
|
|
}
|
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_copy - copy a box
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-08 04:41:22 +02:00
|
|
|
static BOX *
|
1997-09-08 22:59:27 +02:00
|
|
|
box_copy(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
BOX *result = (BOX *) palloc(sizeof(BOX));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
memcpy((char *) result, (char *) box, sizeof(BOX));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relational operators for BOXes.
|
|
|
|
* <, >, <=, >=, and == are based on box area.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_same - are two boxes identical?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_same(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(box1->high.x, box2->high.x) &&
|
|
|
|
FPeq(box1->low.x, box2->low.x) &&
|
|
|
|
FPeq(box1->high.y, box2->high.y) &&
|
|
|
|
FPeq(box1->low.y, box2->low.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_overlap - does box1 overlap box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_overlap(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(box_ov(box1, box2));
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
box_ov(BOX *box1, BOX *box2)
|
|
|
|
{
|
|
|
|
return ((FPge(box1->high.x, box2->high.x) &&
|
|
|
|
FPle(box1->low.x, box2->high.x)) ||
|
|
|
|
(FPge(box2->high.x, box1->high.x) &&
|
|
|
|
FPle(box2->low.x, box1->high.x)))
|
2001-10-25 07:50:21 +02:00
|
|
|
&&
|
|
|
|
((FPge(box1->high.y, box2->high.y) &&
|
|
|
|
FPle(box1->low.y, box2->high.y)) ||
|
|
|
|
(FPge(box2->high.y, box1->high.y) &&
|
|
|
|
FPle(box2->low.y, box1->high.y)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_overleft - is the right edge of box1 to the left of
|
|
|
|
* the right edge of box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* This is "less than or equal" for the end of a time range,
|
|
|
|
* when time ranges are stored as rectangles.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_overleft(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(box1->high.x, box2->high.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_left - is box1 strictly left of box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_left(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(box1->high.x, box2->low.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_right - is box1 strictly right of box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_right(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(box1->low.x, box2->high.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_overright - is the left edge of box1 to the right of
|
|
|
|
* the left edge of box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* This is "greater than or equal" for time ranges, when time ranges
|
|
|
|
* are stored as rectangles.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_overright(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box1->low.x, box2->low.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_contained - is box1 contained by box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_contained(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(box1->high.x, box2->high.x) &&
|
|
|
|
FPge(box1->low.x, box2->low.x) &&
|
|
|
|
FPle(box1->high.y, box2->high.y) &&
|
|
|
|
FPge(box1->low.y, box2->low.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_contain - does box1 contain box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_contain(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box1->high.x, box2->high.x) &&
|
|
|
|
FPle(box1->low.x, box2->low.x) &&
|
|
|
|
FPge(box1->high.y, box2->high.y) &&
|
|
|
|
FPle(box1->low.y, box2->low.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_positionop -
|
|
|
|
* is box1 entirely {above,below} box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_below(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(box1->high.y, box2->low.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_above(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box1->low.y, box2->high.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_relop - is area(box1) relop area(box2), within
|
|
|
|
* our accuracy constraint?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_lt(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_gt(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_le(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_ge(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* "Arithmetic" operators on boxes.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_area - returns the area of the box.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_area(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(box_ar(box));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_width - returns the width of the box
|
|
|
|
* (horizontal magnitude).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_width(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(box->high.x - box->low.x);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_height - returns the height of the box
|
|
|
|
* (vertical magnitude).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_height(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(box->high.y - box->low.y);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_distance - returns the distance between the
|
|
|
|
* center points of two boxes.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
Point a,
|
|
|
|
b;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
box_cn(&a, box1);
|
|
|
|
box_cn(&b, box2);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(HYPOT(a.x - b.x, a.y - b.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_center - returns the center point of the box.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_center(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *result = (Point *) palloc(sizeof(Point));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
box_cn(result, box);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_ar - returns the area of the box.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static double
|
1997-09-08 22:59:27 +02:00
|
|
|
box_ar(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return box_wd(box) * box_ht(box);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/* box_cn - stores the centerpoint of the box into *center.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
box_cn(Point *center, BOX *box)
|
|
|
|
{
|
|
|
|
center->x = (box->high.x + box->low.x) / 2.0;
|
|
|
|
center->y = (box->high.y + box->low.y) / 2.0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_wd - returns the width (length) of the box
|
|
|
|
* (horizontal magnitude).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static double
|
1997-09-08 22:59:27 +02:00
|
|
|
box_wd(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return box->high.x - box->low.x;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_ht - returns the height of the box
|
|
|
|
* (vertical magnitude).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static double
|
1997-09-08 22:59:27 +02:00
|
|
|
box_ht(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return box->high.y - box->low.y;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Funky operations.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_intersect -
|
|
|
|
* returns the overlapping portion of two boxes,
|
|
|
|
* or NULL if they do not intersect.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_intersect(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
BOX *result;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!box_ov(box1, box2))
|
|
|
|
PG_RETURN_NULL();
|
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-30 22:44:02 +02:00
|
|
|
result = (BOX *) palloc(sizeof(BOX));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->high.x = Min(box1->high.x, box2->high.x);
|
|
|
|
result->low.x = Max(box1->low.x, box2->low.x);
|
|
|
|
result->high.y = Min(box1->high.y, box2->high.y);
|
|
|
|
result->low.y = Max(box1->low.y, box2->low.y);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_diagonal -
|
|
|
|
* returns a line segment which happens to be the
|
|
|
|
* positive-slope diagonal of "box".
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_diagonal(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
LSEG *result = (LSEG *) palloc(sizeof(LSEG));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
statlseg_construct(result, &box->high, &box->low);
|
|
|
|
|
|
|
|
PG_RETURN_LSEG_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D lines.
|
|
|
|
** Lines are not intended to be used as ADTs per se,
|
|
|
|
** but their ops are useful tools for other ADT ops. Thus,
|
|
|
|
** there are few relops.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_in(PG_FUNCTION_ARGS)
|
1998-05-10 00:39:55 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef ENABLE_LINE_TYPE
|
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
|
|
|
#endif
|
1998-05-10 00:39:55 +02:00
|
|
|
LINE *line;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
1998-08-16 06:06:55 +02:00
|
|
|
#ifdef ENABLE_LINE_TYPE
|
2002-07-16 05:30:27 +02:00
|
|
|
/* when fixed, modify "not implemented", catalog/pg_type.h and SGML */
|
1998-05-10 00:39:55 +02:00
|
|
|
LSEG lseg;
|
|
|
|
int isopen;
|
|
|
|
char *s;
|
1998-09-01 06:40:42 +02:00
|
|
|
|
1998-05-10 00:39:55 +02:00
|
|
|
if ((!path_decode(TRUE, 2, str, &isopen, &s, &(lseg.p[0])))
|
|
|
|
|| (*s != '\0'))
|
|
|
|
elog(ERROR, "Bad line external representation '%s'", str);
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
line = (LINE *) palloc(sizeof(LINE));
|
|
|
|
line_construct_pts(line, &lseg.p[0], &lseg.p[1]);
|
1998-05-10 00:39:55 +02:00
|
|
|
#else
|
|
|
|
elog(ERROR, "line not yet implemented");
|
|
|
|
line = NULL;
|
|
|
|
#endif
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_LINE_P(line);
|
|
|
|
}
|
1998-05-10 00:39:55 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_out(PG_FUNCTION_ARGS)
|
1998-05-10 00:39:55 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef ENABLE_LINE_TYPE
|
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
#endif
|
1998-09-01 06:40:42 +02:00
|
|
|
char *result;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
1998-08-16 06:06:55 +02:00
|
|
|
#ifdef ENABLE_LINE_TYPE
|
2002-07-16 05:30:27 +02:00
|
|
|
/* when fixed, modify "not implemented", catalog/pg_type.h and SGML */
|
1998-09-01 06:40:42 +02:00
|
|
|
LSEG lseg;
|
|
|
|
|
1998-05-10 00:39:55 +02:00
|
|
|
if (FPzero(line->B))
|
|
|
|
{ /* vertical */
|
|
|
|
/* use "x = C" */
|
|
|
|
result->A = -1;
|
|
|
|
result->B = 0;
|
|
|
|
result->C = pt1->x;
|
|
|
|
#ifdef GEODEBUG
|
2000-07-30 22:44:02 +02:00
|
|
|
printf("line_out- line is vertical\n");
|
1998-05-10 00:39:55 +02:00
|
|
|
#endif
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1998-05-10 00:39:55 +02:00
|
|
|
result->m = DBL_MAX;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
}
|
|
|
|
else if (FPzero(line->A))
|
|
|
|
{ /* horizontal */
|
|
|
|
/* use "x = C" */
|
|
|
|
result->A = 0;
|
|
|
|
result->B = -1;
|
|
|
|
result->C = pt1->y;
|
|
|
|
#ifdef GEODEBUG
|
2000-07-30 22:44:02 +02:00
|
|
|
printf("line_out- line is horizontal\n");
|
1998-05-10 00:39:55 +02:00
|
|
|
#endif
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1998-05-10 00:39:55 +02:00
|
|
|
result->m = 0.0;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (FPzero(line->A)) /* horizontal? */
|
1998-05-10 00:39:55 +02:00
|
|
|
{
|
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
else if (FPzero(line->B)) /* vertical? */
|
1998-05-10 00:39:55 +02:00
|
|
|
{
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return path_encode(TRUE, 2, (Point *) &(ls->p[0]));
|
1998-05-10 00:39:55 +02:00
|
|
|
#else
|
|
|
|
elog(ERROR, "line not yet implemented");
|
|
|
|
result = NULL;
|
|
|
|
#endif
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CSTRING(result);
|
|
|
|
}
|
1998-05-10 00:39:55 +02:00
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Conversion routines from one line formula to internal.
|
|
|
|
* Internal form: Ax+By+C=0
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1998-05-10 00:39:55 +02:00
|
|
|
/* line_construct_pm()
|
|
|
|
* point-slope
|
|
|
|
*/
|
1998-10-26 02:05:07 +01:00
|
|
|
static LINE *
|
1997-09-08 23:56:23 +02:00
|
|
|
line_construct_pm(Point *pt, double m)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *result = (LINE *) palloc(sizeof(LINE));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* use "mx - y + yinter = 0" */
|
|
|
|
result->A = m;
|
|
|
|
result->B = -1.0;
|
2000-04-12 19:17:23 +02:00
|
|
|
if (m == DBL_MAX)
|
1999-12-21 18:01:44 +01:00
|
|
|
result->C = pt->y;
|
|
|
|
else
|
|
|
|
result->C = pt->y - m * pt->x;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1997-09-07 07:04:48 +02:00
|
|
|
result->m = m;
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/*
|
|
|
|
* Fill already-allocated LINE struct from two points on the line
|
1998-05-10 00:39:55 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
static void
|
|
|
|
line_construct_pts(LINE *line, Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPeq(pt1->x, pt2->x))
|
|
|
|
{ /* vertical */
|
|
|
|
/* use "x = C" */
|
2000-07-30 22:44:02 +02:00
|
|
|
line->A = -1;
|
|
|
|
line->B = 0;
|
|
|
|
line->C = pt1->x;
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
2000-07-30 22:44:02 +02:00
|
|
|
line->m = DBL_MAX;
|
|
|
|
#endif
|
|
|
|
#ifdef GEODEBUG
|
|
|
|
printf("line_construct_pts- line is vertical\n");
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else if (FPeq(pt1->y, pt2->y))
|
|
|
|
{ /* horizontal */
|
2001-10-13 19:40:24 +02:00
|
|
|
/* use "y = C" */
|
2000-07-30 22:44:02 +02:00
|
|
|
line->A = 0;
|
|
|
|
line->B = -1;
|
|
|
|
line->C = pt1->y;
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
2000-07-30 22:44:02 +02:00
|
|
|
line->m = 0.0;
|
|
|
|
#endif
|
|
|
|
#ifdef GEODEBUG
|
|
|
|
printf("line_construct_pts- line is horizontal\n");
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* use "mx - y + yinter = 0" */
|
2000-07-30 22:44:02 +02:00
|
|
|
line->A = (pt2->y - pt1->y) / (pt2->x - pt1->x);
|
|
|
|
line->B = -1.0;
|
|
|
|
line->C = pt1->y - line->A * pt1->x;
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
2000-07-30 22:44:02 +02:00
|
|
|
line->m = line->A;
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
|
|
|
#ifdef GEODEBUG
|
2000-07-30 22:44:02 +02:00
|
|
|
printf("line_construct_pts- line is neither vertical nor horizontal (diffs x=%.*g, y=%.*g\n",
|
1997-09-07 07:04:48 +02:00
|
|
|
digits8, (pt2->x - pt1->x), digits8, (pt2->y - pt1->y));
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* line_construct_pp()
|
|
|
|
* two points
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
line_construct_pp(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
LINE *result = (LINE *) palloc(sizeof(LINE));
|
|
|
|
|
|
|
|
line_construct_pts(result, pt1, pt2);
|
|
|
|
PG_RETURN_LINE_P(result);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relative position routines.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_intersect(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
PG_RETURN_BOOL(!DatumGetBool(DirectFunctionCall2(line_parallel,
|
|
|
|
LinePGetDatum(l1),
|
|
|
|
LinePGetDatum(l2))));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_parallel(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(l1->m, l2->m));
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPzero(l1->B))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(l2->B));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(l2->A, l1->A * (l2->B / l1->B)));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_perp(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1997-09-07 07:04:48 +02:00
|
|
|
if (l1->m)
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(l2->m / l1->m, -1.0));
|
1997-09-07 07:04:48 +02:00
|
|
|
else if (l2->m)
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(l1->m / l2->m, -1.0));
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPzero(l1->A))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(l2->B));
|
1997-09-07 07:04:48 +02:00
|
|
|
else if (FPzero(l1->B))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(l2->A));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(((l1->A * l2->B) / (l1->B * l2->A)), -1.0));
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_vertical(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPzero(line->B));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_horizontal(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(line->A));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
line_eq(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
double k;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
if (!FPzero(l2->A))
|
|
|
|
k = l1->A / l2->A;
|
|
|
|
else if (!FPzero(l2->B))
|
|
|
|
k = l1->B / l2->B;
|
|
|
|
else if (!FPzero(l2->C))
|
|
|
|
k = l1->C / l2->C;
|
|
|
|
else
|
|
|
|
k = 1.0;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(l1->A, k * l2->A) &&
|
|
|
|
FPeq(l1->B, k * l2->B) &&
|
|
|
|
FPeq(l1->C, k * l2->C));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Line arithmetic routines.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1998-05-10 00:39:55 +02:00
|
|
|
/* line_distance()
|
|
|
|
* Distance between two lines.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_distance(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
float8 result;
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *tmp;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
if (!DatumGetBool(DirectFunctionCall2(line_parallel,
|
|
|
|
LinePGetDatum(l1),
|
|
|
|
LinePGetDatum(l2))))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(0.0);
|
|
|
|
if (FPzero(l1->B)) /* vertical? */
|
|
|
|
PG_RETURN_FLOAT8(fabs(l1->C - l2->C));
|
|
|
|
tmp = point_construct(0.0, l1->C);
|
|
|
|
result = dist_pl_internal(tmp, l2);
|
|
|
|
PG_RETURN_FLOAT8(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
/* line_interpt()
|
|
|
|
* Point where two lines l1, l2 intersect (if any)
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_interpt(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
Point *result;
|
|
|
|
|
|
|
|
result = line_interpt_internal(l1, l2);
|
|
|
|
|
|
|
|
if (result == NULL)
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal version of line_interpt
|
|
|
|
*
|
|
|
|
* returns a NULL pointer if no intersection point
|
|
|
|
*/
|
|
|
|
static Point *
|
|
|
|
line_interpt_internal(LINE *l1, LINE *l2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
|
|
|
double x,
|
|
|
|
y;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/*
|
2001-03-22 05:01:46 +01:00
|
|
|
* NOTE: if the lines are identical then we will find they are
|
|
|
|
* parallel and report "no intersection". This is a little weird, but
|
|
|
|
* since there's no *unique* intersection, maybe it's appropriate
|
|
|
|
* behavior.
|
2000-07-30 22:44:02 +02:00
|
|
|
*/
|
|
|
|
if (DatumGetBool(DirectFunctionCall2(line_parallel,
|
|
|
|
LinePGetDatum(l1),
|
|
|
|
LinePGetDatum(l2))))
|
1998-09-01 05:29:17 +02:00
|
|
|
return NULL;
|
2000-07-30 22:44:02 +02:00
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
2000-07-30 22:44:02 +02:00
|
|
|
if (FPzero(l1->B)) /* l1 vertical? */
|
1997-09-07 07:04:48 +02:00
|
|
|
result = point_construct(l2->m * l1->C + l2->C, l1->C);
|
2000-07-30 22:44:02 +02:00
|
|
|
else if (FPzero(l2->B)) /* l2 vertical? */
|
1997-09-07 07:04:48 +02:00
|
|
|
result = point_construct(l1->m * l2->C + l1->C, l2->C);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
x = (l1->C - l2->C) / (l2->A - l1->A);
|
|
|
|
result = point_construct(x, l1->m * x + l1->C);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (FPzero(l1->B)) /* l1 vertical? */
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
x = l1->C;
|
|
|
|
y = (l2->A * x + l2->C);
|
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
else if (FPzero(l2->B)) /* l2 vertical? */
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
x = l2->C;
|
|
|
|
y = (l1->A * x + l1->C);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
x = (l1->C - l2->C) / (l2->A - l1->A);
|
|
|
|
y = (l1->A * x + l1->C);
|
|
|
|
}
|
|
|
|
result = point_construct(x, y);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("line_interpt- lines are A=%.*g, B=%.*g, C=%.*g, A=%.*g, B=%.*g, C=%.*g\n",
|
|
|
|
digits8, l1->A, digits8, l1->B, digits8, l1->C, digits8, l2->A, digits8, l2->B, digits8, l2->C);
|
|
|
|
printf("line_interpt- lines intersect at (%.*g,%.*g)\n", digits8, x, digits8, y);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-07-30 22:44:02 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D paths (sequences of line segments, also
|
|
|
|
** called `polylines').
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** This is not a general package for geometric paths,
|
|
|
|
** which of course include polygons; the emphasis here
|
|
|
|
** is on (for example) usefulness in wire layout.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* String to path / path to string conversion.
|
|
|
|
* External format:
|
|
|
|
* "((xcoord, ycoord),... )"
|
|
|
|
* "[(xcoord, ycoord),... ]"
|
|
|
|
* "(xcoord, ycoord),... "
|
|
|
|
* "[xcoord, ycoord,... ]"
|
|
|
|
* Also support older format:
|
|
|
|
* "(closed, npts, xcoord, ycoord,... )"
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
PATH *path;
|
|
|
|
int isopen;
|
|
|
|
char *s;
|
|
|
|
int npts;
|
|
|
|
int size;
|
|
|
|
int depth = 0;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if ((npts = pair_count(str, ',')) <= 0)
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad path external representation '%s'", str);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
s = str;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
1997-06-03 16:01:22 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* skip single leading paren */
|
|
|
|
if ((*s == LDELIM) && (strrchr(s, LDELIM) == s))
|
|
|
|
{
|
|
|
|
s++;
|
|
|
|
depth++;
|
|
|
|
}
|
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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
size = offsetof(PATH, p[0]) +sizeof(path->p[0]) * npts;
|
2000-07-30 22:44:02 +02:00
|
|
|
path = (PATH *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
path->size = size;
|
|
|
|
path->npts = npts;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if ((!path_decode(TRUE, npts, s, &isopen, &s, &(path->p[0])))
|
|
|
|
&& (!((depth == 0) && (*s == '\0'))) && !((depth >= 1) && (*s == RDELIM)))
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad path external representation '%s'", str);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
path->closed = (!isopen);
|
1997-06-03 16:01:22 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
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
|
|
|
PG_RETURN_CSTRING(path_encode(path->closed, path->npts, path->p));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relational operators.
|
|
|
|
* These are based on the path cardinality,
|
|
|
|
* as stupid as that sounds.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* Better relops and access methods coming soon.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_lt(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(p1->npts < p2->npts);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_gt(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(p1->npts > p2->npts);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(p1->npts == p2->npts);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_le(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(p1->npts <= p2->npts);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_ge(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(p1->npts >= p2->npts);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Conversion operators.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_isclosed(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
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
|
|
|
PG_RETURN_BOOL(path->closed);
|
|
|
|
}
|
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
|
|
|
Datum
|
|
|
|
path_isopen(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
PG_RETURN_BOOL(!path->closed);
|
2000-07-29 20:46:12 +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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_npoints(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
1997-06-03 16:01:22 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_INT32(path->npts);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_close(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
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
|
|
|
path->closed = TRUE;
|
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
|
|
|
PG_RETURN_PATH_P(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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_open(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
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
|
|
|
path->closed = FALSE;
|
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
|
|
|
PG_RETURN_PATH_P(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
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* path_inter -
|
1997-09-07 07:04:48 +02:00
|
|
|
* Does p1 intersect p2 at any point?
|
|
|
|
* Use bounding boxes for a quick (O(n)) check, then do a
|
|
|
|
* O(n^2) iterative edge check.
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_inter(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
BOX b1,
|
|
|
|
b2;
|
|
|
|
int i,
|
|
|
|
j;
|
|
|
|
LSEG seg1,
|
|
|
|
seg2;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2001-10-13 19:40:24 +02:00
|
|
|
if (p1->npts <= 0 || p2->npts <= 0)
|
|
|
|
PG_RETURN_BOOL(false);
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
b1.high.x = b1.low.x = p1->p[0].x;
|
|
|
|
b1.high.y = b1.low.y = p1->p[0].y;
|
|
|
|
for (i = 1; i < p1->npts; i++)
|
|
|
|
{
|
|
|
|
b1.high.x = Max(p1->p[i].x, b1.high.x);
|
|
|
|
b1.high.y = Max(p1->p[i].y, b1.high.y);
|
|
|
|
b1.low.x = Min(p1->p[i].x, b1.low.x);
|
|
|
|
b1.low.y = Min(p1->p[i].y, b1.low.y);
|
|
|
|
}
|
|
|
|
b2.high.x = b2.low.x = p2->p[0].x;
|
|
|
|
b2.high.y = b2.low.y = p2->p[0].y;
|
|
|
|
for (i = 1; i < p2->npts; i++)
|
|
|
|
{
|
|
|
|
b2.high.x = Max(p2->p[i].x, b2.high.x);
|
|
|
|
b2.high.y = Max(p2->p[i].y, b2.high.y);
|
|
|
|
b2.low.x = Min(p2->p[i].x, b2.low.x);
|
|
|
|
b2.low.y = Min(p2->p[i].y, b2.low.y);
|
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!box_ov(&b1, &b2))
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/* pairwise check lseg intersections */
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < p1->npts; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int iprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (i > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = i - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2001-10-13 19:40:24 +02:00
|
|
|
if (!p1->closed)
|
|
|
|
continue;
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = p1->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < p2->npts; j++)
|
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int jprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (j > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
jprev = j - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p2->closed)
|
|
|
|
continue;
|
2001-10-25 07:50:21 +02:00
|
|
|
jprev = p2->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
statlseg_construct(&seg1, &p1->p[iprev], &p1->p[i]);
|
|
|
|
statlseg_construct(&seg2, &p2->p[jprev], &p2->p[j]);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (lseg_intersect_internal(&seg1, &seg2))
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if we dropped through, no two segs intersected */
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* path_distance()
|
|
|
|
* This essentially does a cartesian product of the lsegs in the
|
2000-07-30 22:44:02 +02:00
|
|
|
* two paths, and finds the min distance between any two lsegs
|
1998-02-03 16:55:58 +01:00
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
2000-07-30 22:44:02 +02:00
|
|
|
float8 min = 0.0; /* initialize to keep compiler quiet */
|
2001-10-13 19:40:24 +02:00
|
|
|
bool have_min = false;
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 tmp;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i,
|
|
|
|
j;
|
|
|
|
LSEG seg1,
|
|
|
|
seg2;
|
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
|
|
|
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < p1->npts; i++)
|
2000-07-29 20:46:12 +02:00
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int iprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (i > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = i - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p1->closed)
|
|
|
|
continue;
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = p1->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < p2->npts; j++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int jprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (j > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
jprev = j - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p2->closed)
|
|
|
|
continue;
|
2001-10-25 07:50:21 +02:00
|
|
|
jprev = p2->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
statlseg_construct(&seg1, &p1->p[iprev], &p1->p[i]);
|
|
|
|
statlseg_construct(&seg2, &p2->p[jprev], &p2->p[j]);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
tmp = DatumGetFloat8(DirectFunctionCall2(lseg_distance,
|
|
|
|
LsegPGetDatum(&seg1),
|
2001-03-22 05:01:46 +01:00
|
|
|
LsegPGetDatum(&seg2)));
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!have_min || tmp < min)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
min = tmp;
|
|
|
|
have_min = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
if (!have_min)
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_NULL();
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(min);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* "Arithmetic" operations.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_length(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
2001-10-13 19:40:24 +02:00
|
|
|
float8 result = 0.0;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int iprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (i > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = i - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!path->closed)
|
|
|
|
continue;
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = path->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
result += point_dt(&path->p[iprev], &path->p[i]);
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D points.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* String to point, point to string conversion.
|
|
|
|
* External format:
|
|
|
|
* "(x,y)"
|
|
|
|
* "x,y"
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *point;
|
|
|
|
double x,
|
|
|
|
y;
|
|
|
|
char *s;
|
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-30 22:44:02 +02:00
|
|
|
if (!pair_decode(str, &x, &y, &s) || (*s != '\0'))
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad point external representation '%s'", str);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
point = (Point *) palloc(sizeof(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
point->x = x;
|
|
|
|
point->y = y;
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(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
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(-1, 1, pt));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static Point *
|
1997-09-07 07:04:48 +02:00
|
|
|
point_construct(double x, double y)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *result = (Point *) palloc(sizeof(Point));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = x;
|
|
|
|
result->y = y;
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static Point *
|
1997-09-08 23:56:23 +02:00
|
|
|
point_copy(Point *pt)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!PointerIsValid(pt))
|
1998-09-01 05:29:17 +02:00
|
|
|
return NULL;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = pt->x;
|
|
|
|
result->y = pt->y;
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relational operators for Points.
|
|
|
|
* Since we do have a sense of coordinates being
|
|
|
|
* "equal" to a given accuracy (point_vert, point_horiz),
|
|
|
|
* the other ops must preserve that sense. This means
|
|
|
|
* that results may, strictly speaking, be a lie (unless
|
|
|
|
* EPSILON = 0.0).
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_left(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(pt1->x, pt2->x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_right(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(pt1->x, pt2->x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_above(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(pt1->y, pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_below(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(pt1->y, pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_vert(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(pt1->x, pt2->x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_horiz(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(pt1->y, pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(pt1->x, pt2->x) && FPeq(pt1->y, pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_ne(PG_FUNCTION_ARGS)
|
1997-09-20 18:22:31 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPne(pt1->x, pt2->x) || FPne(pt1->y, pt2->y));
|
1997-09-20 18:22:31 +02:00
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* "Arithmetic" operators on points.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(HYPOT(pt1->x - pt2->x, pt1->y - pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
double
|
1997-09-08 23:56:23 +02:00
|
|
|
point_dt(Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-02-03 16:55:58 +01:00
|
|
|
#ifdef GEODEBUG
|
1998-02-26 05:46:47 +01:00
|
|
|
printf("point_dt- segment (%f,%f),(%f,%f) length is %f\n",
|
|
|
|
pt1->x, pt1->y, pt2->x, pt2->y, HYPOT(pt1->x - pt2->x, pt1->y - pt2->y));
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
1998-09-01 05:29:17 +02:00
|
|
|
return HYPOT(pt1->x - pt2->x, pt1->y - pt2->y);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_slope(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(point_sl(pt1, pt2));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
double
|
1997-09-08 23:56:23 +02:00
|
|
|
point_sl(Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
return (FPeq(pt1->x, pt2->x)
|
1997-09-07 07:04:48 +02:00
|
|
|
? (double) DBL_MAX
|
|
|
|
: (pt1->y - pt2->y) / (pt1->x - pt2->x));
|
1996-07-09 08:22:35 +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
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D line segments.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* String to lseg, lseg to string conversion.
|
|
|
|
* External forms: "[(x1, y1), (x2, y2)]"
|
|
|
|
* "(x1, y1), (x2, y2)"
|
|
|
|
* "x1, y1, x2, y2"
|
|
|
|
* closed form ok "((x1, y1), (x2, y2))"
|
|
|
|
* (old form) "(x1, y1, x2, y2)"
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
LSEG *lseg;
|
|
|
|
int isopen;
|
|
|
|
char *s;
|
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-30 22:44:02 +02:00
|
|
|
lseg = (LSEG *) palloc(sizeof(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if ((!path_decode(TRUE, 2, str, &isopen, &s, &(lseg->p[0])))
|
|
|
|
|| (*s != '\0'))
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad lseg external representation '%s'", str);
|
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
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1997-09-07 07:04:48 +02:00
|
|
|
lseg->m = point_sl(&lseg->p[0], &lseg->p[1]);
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_LSEG_P(lseg);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *ls = PG_GETARG_LSEG_P(0);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(FALSE, 2, (Point *) &(ls->p[0])));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* lseg_construct -
|
1997-09-07 07:04:48 +02:00
|
|
|
* form a LSEG from two Points.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_construct(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
LSEG *result = (LSEG *) palloc(sizeof(LSEG));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->p[0].x = pt1->x;
|
|
|
|
result->p[0].y = pt1->y;
|
|
|
|
result->p[1].x = pt2->x;
|
|
|
|
result->p[1].y = pt2->y;
|
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
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1997-09-07 07:04:48 +02:00
|
|
|
result->m = point_sl(pt1, pt2);
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_LSEG_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* like lseg_construct, but assume space already allocated */
|
1997-09-07 07:04:48 +02:00
|
|
|
static void
|
1997-09-08 23:56:23 +02:00
|
|
|
statlseg_construct(LSEG *lseg, Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
lseg->p[0].x = pt1->x;
|
|
|
|
lseg->p[0].y = pt1->y;
|
|
|
|
lseg->p[1].x = pt2->x;
|
|
|
|
lseg->p[1].y = pt2->y;
|
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
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1997-09-07 07:04:48 +02:00
|
|
|
lseg->m = point_sl(pt1, pt2);
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_length(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(point_dt(&lseg->p[0], &lseg->p[1]));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relative position routines.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
** find intersection of the two lines, and see if it falls on
|
1996-07-09 08:22:35 +02:00
|
|
|
** both segments.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_intersect(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(lseg_intersect_internal(l1, l2));
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
lseg_intersect_internal(LSEG *l1, LSEG *l2)
|
|
|
|
{
|
|
|
|
LINE ln;
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *interpt;
|
|
|
|
bool retval;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
line_construct_pts(&ln, &l2->p[0], &l2->p[1]);
|
|
|
|
interpt = interpt_sl(l1, &ln);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (interpt != NULL && on_ps_internal(interpt, l2))
|
|
|
|
retval = true; /* interpt on l1 and l2 */
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
2000-07-30 22:44:02 +02:00
|
|
|
retval = false;
|
1998-09-01 05:29:17 +02:00
|
|
|
return retval;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_parallel(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(l1->m, l2->m));
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(point_sl(&l1->p[0], &l1->p[1]),
|
|
|
|
point_sl(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* lseg_perp()
|
|
|
|
* Determine if two line segments are perpendicular.
|
|
|
|
*
|
|
|
|
* This code did not get the correct answer for
|
1998-02-26 05:46:47 +01:00
|
|
|
* '((0,0),(0,1))'::lseg ?-| '((0,0),(1,0))'::lseg
|
1998-02-03 16:55:58 +01:00
|
|
|
* So, modified it to check explicitly for slope of vertical line
|
1998-02-26 05:46:47 +01:00
|
|
|
* returned by point_sl() and the results seem better.
|
1998-02-03 16:55:58 +01:00
|
|
|
* - thomas 1998-01-31
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_perp(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
double m1,
|
|
|
|
m2;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
m1 = point_sl(&(l1->p[0]), &(l1->p[1]));
|
|
|
|
m2 = point_sl(&(l2->p[0]), &(l2->p[1]));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
#ifdef GEODEBUG
|
1998-02-26 05:46:47 +01:00
|
|
|
printf("lseg_perp- slopes are %g and %g\n", m1, m2);
|
1998-02-03 16:55:58 +01:00
|
|
|
#endif
|
|
|
|
if (FPzero(m1))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(m2, DBL_MAX));
|
1998-02-03 16:55:58 +01:00
|
|
|
else if (FPzero(m2))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(m1, DBL_MAX));
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(m1 / m2, -1.0));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_vertical(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(lseg->p[0].x, lseg->p[1].x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_horizontal(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(lseg->p[0].y, lseg->p[1].y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(l1->p[0].x, l2->p[0].x) &&
|
|
|
|
FPeq(l1->p[1].y, l2->p[1].y) &&
|
|
|
|
FPeq(l1->p[0].x, l2->p[0].x) &&
|
|
|
|
FPeq(l1->p[1].y, l2->p[1].y));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_ne(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(!FPeq(l1->p[0].x, l2->p[0].x) ||
|
|
|
|
!FPeq(l1->p[1].y, l2->p[1].y) ||
|
|
|
|
!FPeq(l1->p[0].x, l2->p[0].x) ||
|
|
|
|
!FPeq(l1->p[1].y, l2->p[1].y));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
lseg_lt(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(point_dt(&l1->p[0], &l1->p[1]),
|
|
|
|
point_dt(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_le(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(point_dt(&l1->p[0], &l1->p[1]),
|
|
|
|
point_dt(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_gt(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(point_dt(&l1->p[0], &l1->p[1]),
|
|
|
|
point_dt(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_ge(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(point_dt(&l1->p[0], &l1->p[1]),
|
|
|
|
point_dt(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Line arithmetic routines.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* lseg_distance -
|
1997-09-07 07:04:48 +02:00
|
|
|
* If two segments don't intersect, then the closest
|
|
|
|
* point will be from one of the endpoints to the other
|
|
|
|
* segment.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(lseg_dt(l1, l2));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* lseg_dt()
|
|
|
|
* Distance between two line segments.
|
|
|
|
* Must check both sets of endpoints to ensure minimum distance is found.
|
|
|
|
* - thomas 1998-02-01
|
|
|
|
*/
|
1997-08-19 23:40:56 +02:00
|
|
|
static double
|
1997-09-08 23:56:23 +02:00
|
|
|
lseg_dt(LSEG *l1, LSEG *l2)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
double result,
|
|
|
|
d;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (lseg_intersect_internal(l1, l2))
|
1998-09-01 05:29:17 +02:00
|
|
|
return 0.0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
d = dist_ps_internal(&l1->p[0], l2);
|
|
|
|
result = d;
|
|
|
|
d = dist_ps_internal(&l1->p[1], l2);
|
|
|
|
result = Min(result, d);
|
|
|
|
d = dist_ps_internal(&l2->p[0], l1);
|
|
|
|
result = Min(result, d);
|
|
|
|
d = dist_ps_internal(&l2->p[1], l1);
|
|
|
|
result = Min(result, d);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_center(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result->x = (lseg->p[0].x - lseg->p[1].x) / 2.0;
|
|
|
|
result->y = (lseg->p[0].y - lseg->p[1].y) / 2.0;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* lseg_interpt -
|
1997-09-07 07:04:48 +02:00
|
|
|
* Find the intersection point of two segments (if any).
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_interpt(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE tmp1,
|
|
|
|
tmp2;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/*
|
|
|
|
* Find the intersection of the appropriate lines, if any.
|
|
|
|
*/
|
|
|
|
line_construct_pts(&tmp1, &l1->p[0], &l1->p[1]);
|
|
|
|
line_construct_pts(&tmp2, &l2->p[0], &l2->p[1]);
|
|
|
|
result = line_interpt_internal(&tmp1, &tmp2);
|
|
|
|
if (!PointerIsValid(result))
|
|
|
|
PG_RETURN_NULL();
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/*
|
2001-03-22 05:01:46 +01:00
|
|
|
* If the line intersection point isn't within l1 (or equivalently
|
|
|
|
* l2), there is no valid segment intersection point at all.
|
2000-07-30 22:44:02 +02:00
|
|
|
*/
|
|
|
|
if (!on_ps_internal(result, l1) ||
|
|
|
|
!on_ps_internal(result, l2))
|
|
|
|
PG_RETURN_NULL();
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/*
|
|
|
|
* If there is an intersection, then check explicitly for matching
|
2001-03-22 05:01:46 +01:00
|
|
|
* endpoints since there may be rounding effects with annoying lsb
|
|
|
|
* residue. - tgl 1997-07-09
|
2000-07-30 22:44:02 +02:00
|
|
|
*/
|
|
|
|
if ((FPeq(l1->p[0].x, l2->p[0].x) && FPeq(l1->p[0].y, l2->p[0].y)) ||
|
|
|
|
(FPeq(l1->p[0].x, l2->p[1].x) && FPeq(l1->p[0].y, l2->p[1].y)))
|
|
|
|
{
|
|
|
|
result->x = l1->p[0].x;
|
|
|
|
result->y = l1->p[0].y;
|
|
|
|
}
|
|
|
|
else if ((FPeq(l1->p[1].x, l2->p[0].x) && FPeq(l1->p[1].y, l2->p[0].y)) ||
|
2001-03-22 05:01:46 +01:00
|
|
|
(FPeq(l1->p[1].x, l2->p[1].x) && FPeq(l1->p[1].y, l2->p[1].y)))
|
2000-07-30 22:44:02 +02:00
|
|
|
{
|
|
|
|
result->x = l1->p[1].x;
|
|
|
|
result->y = l1->p[1].y;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for position comparisons of differently-typed
|
|
|
|
** 2D objects.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* dist_
|
|
|
|
* Minimum distance from one object to another.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_pl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(dist_pl_internal(pt, line));
|
|
|
|
}
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
static double
|
|
|
|
dist_pl_internal(Point *pt, LINE *line)
|
|
|
|
{
|
|
|
|
return (line->A * pt->x + line->B * pt->y + line->C) /
|
2001-10-25 07:50:21 +02:00
|
|
|
HYPOT(line->A, line->B);
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_ps(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(dist_ps_internal(pt, lseg));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
static double
|
|
|
|
dist_ps_internal(Point *pt, LSEG *lseg)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double m; /* slope of perp. */
|
|
|
|
LINE *ln;
|
2000-07-30 22:44:02 +02:00
|
|
|
double result,
|
|
|
|
tmpdist;
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *ip;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Construct a line perpendicular to the input segment
|
|
|
|
* and through the input point
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
if (lseg->p[1].x == lseg->p[0].x)
|
|
|
|
m = 0;
|
|
|
|
else if (lseg->p[1].y == lseg->p[0].y)
|
|
|
|
{ /* slope is infinite */
|
|
|
|
m = (double) DBL_MAX;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
m = ((lseg->p[0].y - lseg->p[1].y) / (lseg->p[1].x - lseg->p[0].x));
|
|
|
|
ln = line_construct_pm(pt, m);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("dist_ps- line is A=%g B=%g C=%g from (point) slope (%f,%f) %g\n",
|
|
|
|
ln->A, ln->B, ln->C, pt->x, pt->y, m);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
|
|
|
|
2002-05-14 20:16:51 +02:00
|
|
|
/*
|
|
|
|
* Calculate distance to the line segment
|
|
|
|
* or to the endpoints of the segment.
|
|
|
|
*/
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* intersection is on the line segment? */
|
|
|
|
if ((ip = interpt_sl(lseg, ln)) != NULL)
|
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
result = point_dt(pt, ip);
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("dist_ps- distance is %f to intersection point is (%f,%f)\n",
|
2000-07-30 22:44:02 +02:00
|
|
|
result, ip->x, ip->y);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
/* intersection is not on line segment */
|
|
|
|
result = point_dt(pt, &lseg->p[0]);
|
|
|
|
tmpdist = point_dt(pt, &lseg->p[1]);
|
|
|
|
if (tmpdist < result)
|
|
|
|
result = tmpdist;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
** Distance from a point to a path
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
dist_ppath(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
PATH *path = PG_GETARG_PATH_P(1);
|
|
|
|
float8 result = 0.0; /* keep compiler quiet */
|
2001-10-13 19:40:24 +02:00
|
|
|
bool have_min = false;
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 tmp;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
LSEG lseg;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
switch (path->npts)
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
case 0:
|
2001-10-13 19:40:24 +02:00
|
|
|
/* no points in path? then result is undefined... */
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_NULL();
|
1997-09-08 04:41:22 +02:00
|
|
|
case 1:
|
2001-10-13 19:40:24 +02:00
|
|
|
/* one point in path? then get distance between two points... */
|
2000-07-30 22:44:02 +02:00
|
|
|
result = point_dt(pt, &path->p[0]);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* make sure the path makes sense... */
|
|
|
|
Assert(path->npts > 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* the distance from a point to a path is the smallest
|
|
|
|
* distance from the point to any of its constituent segments.
|
|
|
|
*/
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
1997-09-08 04:41:22 +02:00
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int iprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (i > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = i - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!path->closed)
|
|
|
|
continue;
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = path->npts - 1; /* include the closure
|
|
|
|
* segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
statlseg_construct(&lseg, &path->p[iprev], &path->p[i]);
|
2000-07-30 22:44:02 +02:00
|
|
|
tmp = dist_ps_internal(pt, &lseg);
|
2001-10-13 19:40:24 +02:00
|
|
|
if (!have_min || tmp < result)
|
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
result = tmp;
|
2001-10-13 19:40:24 +02:00
|
|
|
have_min = true;
|
|
|
|
}
|
1997-09-08 04:41:22 +02:00
|
|
|
}
|
|
|
|
break;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_pb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
|
|
|
float8 result;
|
2002-05-14 20:16:51 +02:00
|
|
|
Point *near;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-05-14 20:16:51 +02:00
|
|
|
near = DatumGetPointP(DirectFunctionCall2(close_pb,
|
|
|
|
PointPGetDatum(pt),
|
|
|
|
BoxPGetDatum(box)));
|
|
|
|
result = point_dt(near, 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
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_sl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
|
|
|
float8 result,
|
|
|
|
d2;
|
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-30 22:44:02 +02:00
|
|
|
if (has_interpt_sl(lseg, line))
|
|
|
|
result = 0.0;
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
result = dist_pl_internal(&lseg->p[0], line);
|
|
|
|
d2 = dist_pl_internal(&lseg->p[1], line);
|
|
|
|
/* XXX shouldn't we take the min not max? */
|
|
|
|
if (d2 > result)
|
1997-09-07 07:04:48 +02:00
|
|
|
result = d2;
|
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_sb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *tmp;
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum result;
|
|
|
|
|
|
|
|
tmp = DatumGetPointP(DirectFunctionCall2(close_sb,
|
|
|
|
LsegPGetDatum(lseg),
|
|
|
|
BoxPGetDatum(box)));
|
|
|
|
result = DirectFunctionCall2(dist_pb,
|
|
|
|
PointPGetDatum(tmp),
|
|
|
|
BoxPGetDatum(box));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_DATUM(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_lb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef NOT_USED
|
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-05-14 20:16:51 +02:00
|
|
|
/* need to think about this one for a while */
|
2000-07-30 22:44:02 +02:00
|
|
|
elog(ERROR, "dist_lb not implemented");
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_NULL();
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
dist_cpoly(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(1);
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 result;
|
|
|
|
float8 d;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
LSEG seg;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
if (point_inside(&(circle->center), poly->npts, poly->p) != 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("dist_cpoly- center inside of polygon\n");
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_FLOAT8(0.0);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* initialize distance with segment between first and last points */
|
|
|
|
seg.p[0].x = poly->p[0].x;
|
|
|
|
seg.p[0].y = poly->p[0].y;
|
|
|
|
seg.p[1].x = poly->p[poly->npts - 1].x;
|
|
|
|
seg.p[1].y = poly->p[poly->npts - 1].y;
|
2000-07-30 22:44:02 +02:00
|
|
|
result = dist_ps_internal(&circle->center, &seg);
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
2000-07-29 20:46:12 +02:00
|
|
|
printf("dist_cpoly- segment 0/n distance is %f\n", result);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* check distances for other segments */
|
|
|
|
for (i = 0; (i < poly->npts - 1); i++)
|
|
|
|
{
|
|
|
|
seg.p[0].x = poly->p[i].x;
|
|
|
|
seg.p[0].y = poly->p[i].y;
|
|
|
|
seg.p[1].x = poly->p[i + 1].x;
|
|
|
|
seg.p[1].y = poly->p[i + 1].y;
|
2000-07-30 22:44:02 +02:00
|
|
|
d = dist_ps_internal(&circle->center, &seg);
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
2000-07-29 20:46:12 +02:00
|
|
|
printf("dist_cpoly- segment %d distance is %f\n", (i + 1), d);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-07-29 20:46:12 +02:00
|
|
|
if (d < result)
|
|
|
|
result = d;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
result -= circle->radius;
|
|
|
|
if (result < 0)
|
|
|
|
result = 0;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* interpt_
|
|
|
|
* Intersection point of objects.
|
|
|
|
* We choose to ignore the "point" of intersection between
|
|
|
|
* lines and boxes, since there are typically two.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/* Get intersection point of lseg and line; returns NULL if no intersection */
|
1997-09-08 04:41:22 +02:00
|
|
|
static Point *
|
1997-09-08 23:56:23 +02:00
|
|
|
interpt_sl(LSEG *lseg, LINE *line)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE tmp;
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *p;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
line_construct_pts(&tmp, &lseg->p[0], &lseg->p[1]);
|
|
|
|
p = line_interpt_internal(&tmp, line);
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("interpt_sl- segment is (%.*g %.*g) (%.*g %.*g)\n",
|
|
|
|
digits8, lseg->p[0].x, digits8, lseg->p[0].y, digits8, lseg->p[1].x, digits8, lseg->p[1].y);
|
|
|
|
printf("interpt_sl- segment becomes line A=%.*g B=%.*g C=%.*g\n",
|
2000-07-30 22:44:02 +02:00
|
|
|
digits8, tmp.A, digits8, tmp.B, digits8, tmp.C);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
if (PointerIsValid(p))
|
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("interpt_sl- intersection point is (%.*g %.*g)\n", digits8, p->x, digits8, p->y);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-07-30 22:44:02 +02:00
|
|
|
if (on_ps_internal(p, lseg))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("interpt_sl- intersection point is on segment\n");
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
p = NULL;
|
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return p;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/* variant: just indicate if intersection point exists */
|
|
|
|
static bool
|
|
|
|
has_interpt_sl(LSEG *lseg, LINE *line)
|
|
|
|
{
|
|
|
|
Point *tmp;
|
|
|
|
|
|
|
|
tmp = interpt_sl(lseg, line);
|
|
|
|
if (tmp)
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* close_
|
|
|
|
* Point of closest proximity between objects.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* close_pl -
|
|
|
|
* The intersection point of a perpendicular of the line
|
|
|
|
* through the point.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_pl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
|
|
|
LINE *tmp;
|
|
|
|
double invm;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPeq(line->A, -1.0) && FPzero(line->B))
|
|
|
|
{ /* vertical */
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-07-30 22:44:02 +02:00
|
|
|
if (FPzero(line->B)) /* vertical? */
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
result->x = line->C;
|
|
|
|
result->y = pt->y;
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
if (FPzero(line->A)) /* horizontal? */
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
result->x = pt->x;
|
|
|
|
result->y = line->C;
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
/* drop a perpendicular and find the intersection point */
|
1999-02-21 04:49:55 +01:00
|
|
|
#ifdef NOT_USED
|
1997-09-07 07:04:48 +02:00
|
|
|
invm = -1.0 / line->m;
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
/* invert and flip the sign on the slope to get a perpendicular */
|
|
|
|
invm = line->B / line->A;
|
|
|
|
tmp = line_construct_pm(pt, invm);
|
2000-07-30 22:44:02 +02:00
|
|
|
result = line_interpt_internal(tmp, line);
|
|
|
|
Assert(result != NULL);
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* close_ps()
|
|
|
|
* Closest point on line segment to specified point.
|
|
|
|
* Take the closest endpoint if the point is left, right,
|
1998-02-26 05:46:47 +01:00
|
|
|
* above, or below the segment, otherwise find the intersection
|
|
|
|
* point of the segment and its perpendicular through the point.
|
1998-02-03 16:55:58 +01:00
|
|
|
*
|
|
|
|
* Some tricky code here, relying on boolean expressions
|
1998-02-26 05:46:47 +01:00
|
|
|
* evaluating to only zero or one to use as an array index.
|
1998-09-01 06:40:42 +02:00
|
|
|
* bug fixes by gthaker@atl.lmco.com; May 1, 1998
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_ps(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
|
|
|
Point *result = NULL;
|
1997-09-08 04:41:22 +02:00
|
|
|
LINE *tmp;
|
|
|
|
double invm;
|
|
|
|
int xh,
|
|
|
|
yh;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-08-15 08:45:10 +02:00
|
|
|
#ifdef GEODEBUG
|
|
|
|
printf("close_sp:pt->x %f pt->y %f\nlseg(0).x %f lseg(0).y %f lseg(1).x %f lseg(1).y %f\n",
|
2000-07-30 22:44:02 +02:00
|
|
|
pt->x, pt->y, lseg->p[0].x, lseg->p[0].y,
|
|
|
|
lseg->p[1].x, lseg->p[1].y);
|
1998-08-15 08:45:10 +02:00
|
|
|
#endif
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/* xh (or yh) is the index of upper x( or y) end point of lseg */
|
|
|
|
/* !xh (or !yh) is the index of lower x( or y) end point of lseg */
|
1997-09-07 07:04:48 +02:00
|
|
|
xh = lseg->p[0].x < lseg->p[1].x;
|
|
|
|
yh = lseg->p[0].y < lseg->p[1].y;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
if (FPeq(lseg->p[0].x, lseg->p[1].x)) /* vertical? */
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
|
|
|
#ifdef GEODEBUG
|
1998-02-26 05:46:47 +01:00
|
|
|
printf("close_ps- segment is vertical\n");
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1998-05-10 00:39:55 +02:00
|
|
|
/* first check if point is below or above the entire lseg. */
|
|
|
|
if (pt->y < lseg->p[!yh].y)
|
1998-09-01 06:40:42 +02:00
|
|
|
result = point_copy(&lseg->p[!yh]); /* below the lseg */
|
1998-05-10 00:39:55 +02:00
|
|
|
else if (pt->y > lseg->p[yh].y)
|
1998-09-01 06:40:42 +02:00
|
|
|
result = point_copy(&lseg->p[yh]); /* above the lseg */
|
1998-05-10 00:39:55 +02:00
|
|
|
if (result != NULL)
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1998-05-10 00:39:55 +02:00
|
|
|
|
|
|
|
/* point lines along (to left or right) of the vertical lseg. */
|
1998-09-01 06:40:42 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1998-02-03 16:55:58 +01:00
|
|
|
result->x = lseg->p[0].x;
|
|
|
|
result->y = pt->y;
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
2001-03-22 05:01:46 +01:00
|
|
|
else if (FPeq(lseg->p[0].y, lseg->p[1].y)) /* horizontal? */
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
|
|
|
#ifdef GEODEBUG
|
1998-02-26 05:46:47 +01:00
|
|
|
printf("close_ps- segment is horizontal\n");
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1998-05-10 00:39:55 +02:00
|
|
|
/* first check if point is left or right of the entire lseg. */
|
|
|
|
if (pt->x < lseg->p[!xh].x)
|
1998-09-01 06:40:42 +02:00
|
|
|
result = point_copy(&lseg->p[!xh]); /* left of the lseg */
|
1998-05-10 00:39:55 +02:00
|
|
|
else if (pt->x > lseg->p[xh].x)
|
1998-09-01 06:40:42 +02:00
|
|
|
result = point_copy(&lseg->p[xh]); /* right of the lseg */
|
1998-05-10 00:39:55 +02:00
|
|
|
if (result != NULL)
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1998-05-10 00:39:55 +02:00
|
|
|
|
|
|
|
/* point lines along (at top or below) the horiz. lseg. */
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1998-02-03 16:55:58 +01:00
|
|
|
result->x = pt->x;
|
|
|
|
result->y = lseg->p[0].y;
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 06:40:42 +02:00
|
|
|
/*
|
|
|
|
* vert. and horiz. cases are down, now check if the closest point is
|
|
|
|
* one of the end points or someplace on the lseg.
|
|
|
|
*/
|
1998-05-10 00:39:55 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
invm = -1.0 / point_sl(&(lseg->p[0]), &(lseg->p[1]));
|
1998-09-01 06:40:42 +02:00
|
|
|
tmp = line_construct_pm(&lseg->p[!yh], invm); /* lower edge of the
|
|
|
|
* "band" */
|
|
|
|
if (pt->y < (tmp->A * pt->x + tmp->C))
|
|
|
|
{ /* we are below the lower edge */
|
|
|
|
result = point_copy(&lseg->p[!yh]); /* below the lseg, take
|
|
|
|
* lower end pt */
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef GEODEBUG
|
|
|
|
printf("close_ps below: tmp A %f B %f C %f m %f\n",
|
2001-03-22 05:01:46 +01:00
|
|
|
tmp->A, tmp->B, tmp->C, tmp->m);
|
2000-07-30 22:44:02 +02:00
|
|
|
#endif
|
|
|
|
PG_RETURN_POINT_P(result);
|
1998-05-10 00:39:55 +02:00
|
|
|
}
|
1998-09-01 06:40:42 +02:00
|
|
|
tmp = line_construct_pm(&lseg->p[yh], invm); /* upper edge of the
|
|
|
|
* "band" */
|
|
|
|
if (pt->y > (tmp->A * pt->x + tmp->C))
|
|
|
|
{ /* we are below the lower edge */
|
|
|
|
result = point_copy(&lseg->p[yh]); /* above the lseg, take
|
|
|
|
* higher end pt */
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef GEODEBUG
|
|
|
|
printf("close_ps above: tmp A %f B %f C %f m %f\n",
|
2001-03-22 05:01:46 +01:00
|
|
|
tmp->A, tmp->B, tmp->C, tmp->m);
|
2000-07-30 22:44:02 +02:00
|
|
|
#endif
|
|
|
|
PG_RETURN_POINT_P(result);
|
1998-05-10 00:39:55 +02:00
|
|
|
}
|
|
|
|
|
1998-09-01 06:40:42 +02:00
|
|
|
/*
|
|
|
|
* at this point the "normal" from point will hit lseg. The closet
|
|
|
|
* point will be somewhere on the lseg
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
tmp = line_construct_pm(pt, invm);
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef GEODEBUG
|
|
|
|
printf("close_ps- tmp A %f B %f C %f m %f\n",
|
2001-03-22 05:01:46 +01:00
|
|
|
tmp->A, tmp->B, tmp->C, tmp->m);
|
2000-07-30 22:44:02 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
result = interpt_sl(lseg, tmp);
|
2000-07-30 22:44:02 +02:00
|
|
|
Assert(result != NULL);
|
|
|
|
#ifdef GEODEBUG
|
|
|
|
printf("close_ps- result.x %f result.y %f\n", result->x, result->y);
|
|
|
|
#endif
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
1998-08-15 08:45:10 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* close_lseg()
|
|
|
|
* Closest point to l1 on l2.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_lseg(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
Point *result = NULL;
|
|
|
|
Point point;
|
|
|
|
double dist;
|
2000-07-30 22:44:02 +02:00
|
|
|
double d;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
d = dist_ps_internal(&l1->p[0], l2);
|
|
|
|
dist = d;
|
|
|
|
memcpy(&point, &l1->p[0], sizeof(Point));
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if ((d = dist_ps_internal(&l1->p[1], l2)) < dist)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
|
|
|
memcpy(&point, &l1->p[1], sizeof(Point));
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if ((d = dist_ps_internal(&l2->p[0], l1)) < dist)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
result = DatumGetPointP(DirectFunctionCall2(close_ps,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&l2->p[0]),
|
2000-07-30 22:44:02 +02:00
|
|
|
LsegPGetDatum(l1)));
|
|
|
|
memcpy(&point, result, sizeof(Point));
|
|
|
|
result = DatumGetPointP(DirectFunctionCall2(close_ps,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&point),
|
2000-07-30 22:44:02 +02:00
|
|
|
LsegPGetDatum(l2)));
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if ((d = dist_ps_internal(&l2->p[1], l1)) < dist)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
result = DatumGetPointP(DirectFunctionCall2(close_ps,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&l2->p[1]),
|
2000-07-30 22:44:02 +02:00
|
|
|
LsegPGetDatum(l1)));
|
|
|
|
memcpy(&point, result, sizeof(Point));
|
|
|
|
result = DatumGetPointP(DirectFunctionCall2(close_ps,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&point),
|
2000-07-30 22:44:02 +02:00
|
|
|
LsegPGetDatum(l2)));
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (result == NULL)
|
2000-07-30 22:44:02 +02:00
|
|
|
result = point_copy(&point);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* close_pb()
|
|
|
|
* Closest point on or in box to specified point.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_pb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
LSEG lseg,
|
|
|
|
seg;
|
|
|
|
Point point;
|
|
|
|
double dist,
|
2000-07-30 22:44:02 +02:00
|
|
|
d;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (DatumGetBool(DirectFunctionCall2(on_pb,
|
|
|
|
PointPGetDatum(pt),
|
|
|
|
BoxPGetDatum(box))))
|
|
|
|
PG_RETURN_POINT_P(pt);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* pairwise check lseg distances */
|
|
|
|
point.x = box->low.x;
|
|
|
|
point.y = box->high.y;
|
|
|
|
statlseg_construct(&lseg, &box->low, &point);
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d = dist_ps_internal(pt, &lseg);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
statlseg_construct(&seg, &box->high, &point);
|
2000-07-30 22:44:02 +02:00
|
|
|
if ((d = dist_ps_internal(pt, &seg)) < dist)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
1998-02-26 05:46:47 +01:00
|
|
|
memcpy(&lseg, &seg, sizeof(lseg));
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
point.x = box->high.x;
|
|
|
|
point.y = box->low.y;
|
|
|
|
statlseg_construct(&seg, &box->low, &point);
|
2000-07-30 22:44:02 +02:00
|
|
|
if ((d = dist_ps_internal(pt, &seg)) < dist)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
1998-02-26 05:46:47 +01:00
|
|
|
memcpy(&lseg, &seg, sizeof(lseg));
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
statlseg_construct(&seg, &box->high, &point);
|
2000-07-30 22:44:02 +02:00
|
|
|
if ((d = dist_ps_internal(pt, &seg)) < dist)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
1998-02-26 05:46:47 +01:00
|
|
|
memcpy(&lseg, &seg, sizeof(lseg));
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_DATUM(DirectFunctionCall2(close_ps,
|
|
|
|
PointPGetDatum(pt),
|
|
|
|
LsegPGetDatum(&lseg)));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* close_sl()
|
|
|
|
* Closest point on line to line segment.
|
|
|
|
*
|
|
|
|
* XXX THIS CODE IS WRONG
|
|
|
|
* The code is actually calculating the point on the line segment
|
1998-02-26 05:46:47 +01:00
|
|
|
* which is backwards from the routine naming convention.
|
1998-02-03 16:55:58 +01:00
|
|
|
* Copied code to new routine close_ls() but haven't fixed this one yet.
|
|
|
|
* - thomas 1998-01-31
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_sl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
2000-07-30 22:44:02 +02:00
|
|
|
float8 d1,
|
|
|
|
d2;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result = interpt_sl(lseg, line);
|
|
|
|
if (result)
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
d1 = dist_pl_internal(&lseg->p[0], line);
|
|
|
|
d2 = dist_pl_internal(&lseg->p[1], line);
|
1997-09-07 07:04:48 +02:00
|
|
|
if (d1 < d2)
|
|
|
|
result = point_copy(&lseg->p[0]);
|
|
|
|
else
|
|
|
|
result = point_copy(&lseg->p[1]);
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* close_ls()
|
|
|
|
* Closest point on line segment to line.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_ls(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
Point *result;
|
2000-07-30 22:44:02 +02:00
|
|
|
float8 d1,
|
|
|
|
d2;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
result = interpt_sl(lseg, line);
|
|
|
|
if (result)
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
d1 = dist_pl_internal(&lseg->p[0], line);
|
|
|
|
d2 = dist_pl_internal(&lseg->p[1], line);
|
1998-02-03 16:55:58 +01:00
|
|
|
if (d1 < d2)
|
|
|
|
result = point_copy(&lseg->p[0]);
|
|
|
|
else
|
|
|
|
result = point_copy(&lseg->p[1]);
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* close_sb()
|
|
|
|
* Closest point on or in box to line segment.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_sb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
Point point;
|
|
|
|
LSEG bseg,
|
|
|
|
seg;
|
|
|
|
double dist,
|
|
|
|
d;
|
|
|
|
|
|
|
|
/* segment intersects box? then just return closest point to center */
|
2000-07-30 22:44:02 +02:00
|
|
|
if (DatumGetBool(DirectFunctionCall2(inter_sb,
|
|
|
|
LsegPGetDatum(lseg),
|
|
|
|
BoxPGetDatum(box))))
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
box_cn(&point, box);
|
|
|
|
PG_RETURN_DATUM(DirectFunctionCall2(close_ps,
|
|
|
|
PointPGetDatum(&point),
|
|
|
|
LsegPGetDatum(lseg)));
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* pairwise check lseg distances */
|
|
|
|
point.x = box->low.x;
|
|
|
|
point.y = box->high.y;
|
|
|
|
statlseg_construct(&bseg, &box->low, &point);
|
|
|
|
dist = lseg_dt(lseg, &bseg);
|
|
|
|
|
|
|
|
statlseg_construct(&seg, &box->high, &point);
|
|
|
|
if ((d = lseg_dt(lseg, &seg)) < dist)
|
|
|
|
{
|
|
|
|
dist = d;
|
|
|
|
memcpy(&bseg, &seg, sizeof(bseg));
|
|
|
|
}
|
|
|
|
|
|
|
|
point.x = box->high.x;
|
|
|
|
point.y = box->low.y;
|
|
|
|
statlseg_construct(&seg, &box->low, &point);
|
|
|
|
if ((d = lseg_dt(lseg, &seg)) < dist)
|
|
|
|
{
|
|
|
|
dist = d;
|
|
|
|
memcpy(&bseg, &seg, sizeof(bseg));
|
|
|
|
}
|
|
|
|
|
|
|
|
statlseg_construct(&seg, &box->high, &point);
|
|
|
|
if ((d = lseg_dt(lseg, &seg)) < dist)
|
|
|
|
{
|
|
|
|
dist = d;
|
|
|
|
memcpy(&bseg, &seg, sizeof(bseg));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* OK, we now have the closest line segment on the box boundary */
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_DATUM(DirectFunctionCall2(close_lseg,
|
|
|
|
LsegPGetDatum(lseg),
|
|
|
|
LsegPGetDatum(&bseg)));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_lb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef NOT_USED
|
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
|
|
|
#endif
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* think about this one for a while */
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "close_lb not implemented");
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_NULL();
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* on_
|
|
|
|
* Whether one object lies completely within another.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* on_pl -
|
1997-09-07 07:04:48 +02:00
|
|
|
* Does the point satisfy the equation?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
on_pl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(line->A * pt->x + line->B * pt->y + line->C));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* on_ps -
|
1997-09-07 07:04:48 +02:00
|
|
|
* Determine colinearity by detecting a triangle inequality.
|
1997-07-29 18:08:18 +02:00
|
|
|
* This algorithm seems to behave nicely even with lsb residues - tgl 1997-07-09
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
on_ps(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(on_ps_internal(pt, lseg));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
static bool
|
|
|
|
on_ps_internal(Point *pt, LSEG *lseg)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
return FPeq(point_dt(pt, &lseg->p[0]) + point_dt(pt, &lseg->p[1]),
|
|
|
|
point_dt(&lseg->p[0], &lseg->p[1]));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
on_pb(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(pt->x <= box->high.x && pt->x >= box->low.x &&
|
|
|
|
pt->y <= box->high.y && pt->y >= box->low.y);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* on_ppath -
|
|
|
|
* Whether a point lies within (on) a polyline.
|
|
|
|
* If open, we have to (groan) check each segment.
|
1997-07-29 18:08:18 +02:00
|
|
|
* (uses same algorithm as for point intersecting segment - tgl 1997-07-09)
|
1997-09-07 07:04:48 +02:00
|
|
|
* If closed, we use the old O(n) ray method for point-in-polygon.
|
|
|
|
* The ray is horizontal, from pt out to the right.
|
|
|
|
* Each segment that crosses the ray counts as an
|
|
|
|
* intersection; note that an endpoint or edge may touch
|
|
|
|
* but not cross.
|
|
|
|
* (we can do p-in-p in lg(n), but it takes preprocessing)
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
on_ppath(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
PATH *path = PG_GETARG_PATH_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
int i,
|
|
|
|
n;
|
|
|
|
double a,
|
|
|
|
b;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-10-29 19:11:28 +01:00
|
|
|
/*-- OPEN --*/
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!path->closed)
|
1998-10-29 19:11:28 +01:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
n = path->npts - 1;
|
|
|
|
a = point_dt(pt, &path->p[0]);
|
|
|
|
for (i = 0; i < n; i++)
|
|
|
|
{
|
|
|
|
b = point_dt(pt, &path->p[i + 1]);
|
|
|
|
if (FPeq(a + b,
|
|
|
|
point_dt(&path->p[i], &path->p[i + 1])))
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1997-09-07 07:04:48 +02:00
|
|
|
a = b;
|
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
1998-10-29 19:11:28 +01:00
|
|
|
/*-- CLOSED --*/
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(point_inside(pt, path->npts, path->p) != 0);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
on_sl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(DatumGetBool(DirectFunctionCall2(on_pl,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&lseg->p[0]),
|
|
|
|
LinePGetDatum(line))) &&
|
2000-07-30 22:44:02 +02:00
|
|
|
DatumGetBool(DirectFunctionCall2(on_pl,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&lseg->p[1]),
|
|
|
|
LinePGetDatum(line))));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
on_sb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(DatumGetBool(DirectFunctionCall2(on_pb,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&lseg->p[0]),
|
|
|
|
BoxPGetDatum(box))) &&
|
2000-07-30 22:44:02 +02:00
|
|
|
DatumGetBool(DirectFunctionCall2(on_pb,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&lseg->p[1]),
|
|
|
|
BoxPGetDatum(box))));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* inter_
|
|
|
|
* Whether one object intersects another.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
inter_sl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(has_interpt_sl(lseg, line));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* inter_sb()
|
|
|
|
* Do line segment and box intersect?
|
|
|
|
*
|
|
|
|
* Segment completely inside box counts as intersection.
|
|
|
|
* If you want only segments crossing box boundaries,
|
1998-02-26 05:46:47 +01:00
|
|
|
* try converting box to path first.
|
1998-02-03 16:55:58 +01:00
|
|
|
*
|
|
|
|
* Optimize for non-intersection by checking for box intersection first.
|
|
|
|
* - thomas 1998-01-30
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
inter_sb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
BOX lbox;
|
|
|
|
LSEG bseg;
|
2000-07-30 22:44:02 +02:00
|
|
|
Point point;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
lbox.low.x = Min(lseg->p[0].x, lseg->p[1].x);
|
|
|
|
lbox.low.y = Min(lseg->p[0].y, lseg->p[1].y);
|
|
|
|
lbox.high.x = Max(lseg->p[0].x, lseg->p[1].x);
|
|
|
|
lbox.high.y = Max(lseg->p[0].y, lseg->p[1].y);
|
|
|
|
|
|
|
|
/* nothing close to overlap? then not going to intersect */
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!box_ov(&lbox, box))
|
|
|
|
PG_RETURN_BOOL(false);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* an endpoint of segment is inside box? then clearly intersects */
|
2000-07-30 22:44:02 +02:00
|
|
|
if (DatumGetBool(DirectFunctionCall2(on_pb,
|
|
|
|
PointPGetDatum(&lseg->p[0]),
|
|
|
|
BoxPGetDatum(box))) ||
|
|
|
|
DatumGetBool(DirectFunctionCall2(on_pb,
|
|
|
|
PointPGetDatum(&lseg->p[1]),
|
|
|
|
BoxPGetDatum(box))))
|
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* pairwise check lseg intersections */
|
|
|
|
point.x = box->low.x;
|
|
|
|
point.y = box->high.y;
|
|
|
|
statlseg_construct(&bseg, &box->low, &point);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (lseg_intersect_internal(&bseg, lseg))
|
|
|
|
PG_RETURN_BOOL(true);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
statlseg_construct(&bseg, &box->high, &point);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (lseg_intersect_internal(&bseg, lseg))
|
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
point.x = box->high.x;
|
|
|
|
point.y = box->low.y;
|
|
|
|
statlseg_construct(&bseg, &box->low, &point);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (lseg_intersect_internal(&bseg, lseg))
|
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
statlseg_construct(&bseg, &box->high, &point);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (lseg_intersect_internal(&bseg, lseg))
|
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* if we dropped through, no two segs intersected */
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
|
|
|
}
|
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
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* inter_lb()
|
|
|
|
* Do line and box intersect?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
inter_lb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
LSEG bseg;
|
|
|
|
Point p1,
|
|
|
|
p2;
|
|
|
|
|
|
|
|
/* pairwise check lseg intersections */
|
|
|
|
p1.x = box->low.x;
|
|
|
|
p1.y = box->low.y;
|
|
|
|
p2.x = box->low.x;
|
|
|
|
p2.y = box->high.y;
|
|
|
|
statlseg_construct(&bseg, &p1, &p2);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (has_interpt_sl(&bseg, line))
|
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
p1.x = box->high.x;
|
|
|
|
p1.y = box->high.y;
|
|
|
|
statlseg_construct(&bseg, &p1, &p2);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (has_interpt_sl(&bseg, line))
|
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
p2.x = box->high.x;
|
|
|
|
p2.y = box->low.y;
|
|
|
|
statlseg_construct(&bseg, &p1, &p2);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (has_interpt_sl(&bseg, line))
|
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
p1.x = box->low.x;
|
|
|
|
p1.y = box->low.y;
|
|
|
|
statlseg_construct(&bseg, &p1, &p2);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (has_interpt_sl(&bseg, line))
|
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* if we dropped through, no intersection */
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*------------------------------------------------------------------
|
|
|
|
* The following routines define a data type and operator class for
|
1997-09-07 07:04:48 +02:00
|
|
|
* POLYGONS .... Part of which (the polygon's bounding box) is built on
|
1996-07-09 08:22:35 +02:00
|
|
|
* top of the BOX data type.
|
|
|
|
*
|
|
|
|
* make_bound_box - create the bounding box for the input polygon
|
|
|
|
*------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* Make the smallest bounding box for the given polygon.
|
|
|
|
*---------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static void
|
1997-09-08 23:56:23 +02:00
|
|
|
make_bound_box(POLYGON *poly)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
double x1,
|
|
|
|
y1,
|
|
|
|
x2,
|
|
|
|
y2;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
if (poly->npts > 0)
|
|
|
|
{
|
|
|
|
x2 = x1 = poly->p[0].x;
|
|
|
|
y2 = y1 = poly->p[0].y;
|
|
|
|
for (i = 1; i < poly->npts; i++)
|
|
|
|
{
|
|
|
|
if (poly->p[i].x < x1)
|
|
|
|
x1 = poly->p[i].x;
|
|
|
|
if (poly->p[i].x > x2)
|
|
|
|
x2 = poly->p[i].x;
|
|
|
|
if (poly->p[i].y < y1)
|
|
|
|
y1 = poly->p[i].y;
|
|
|
|
if (poly->p[i].y > y2)
|
|
|
|
y2 = poly->p[i].y;
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
box_fill(&(poly->boundbox), x1, x2, y1, y2);
|
|
|
|
}
|
|
|
|
else
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "Unable to create bounding box for empty polygon");
|
1996-07-09 08:22:35 +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
|
|
|
* poly_in - read in the polygon from a string specification
|
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* External format:
|
|
|
|
* "((x0,y0),...,(xn,yn))"
|
|
|
|
* "x0,y0,...,xn,yn"
|
|
|
|
* also supports the older style "(x1,...,xn,y1,...yn)"
|
1996-07-09 08:22:35 +02:00
|
|
|
*------------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
int npts;
|
|
|
|
int size;
|
|
|
|
int isopen;
|
|
|
|
char *s;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if ((npts = pair_count(str, ',')) <= 0)
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad polygon external representation '%s'", str);
|
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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
size = offsetof(POLYGON, p[0]) +sizeof(poly->p[0]) * npts;
|
2000-07-29 20:46:12 +02:00
|
|
|
poly = (POLYGON *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-18 22:22:58 +02:00
|
|
|
MemSet((char *) poly, 0, size); /* zero any holes */
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->size = size;
|
|
|
|
poly->npts = npts;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if ((!path_decode(FALSE, npts, str, &isopen, &s, &(poly->p[0])))
|
|
|
|
|| (*s != '\0'))
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad polygon external representation '%s'", str);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
make_bound_box(poly);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* poly_out - convert internal POLYGON representation to the
|
|
|
|
* character string format "((f8,f8),...,(f8,f8))"
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
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
|
|
|
PG_RETURN_CSTRING(path_encode(TRUE, poly->npts, poly->p));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A strictly left of polygon B? i.e. is
|
|
|
|
* the right most point of A left of the left most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_left(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
result = polya->boundbox.high.x < polyb->boundbox.low.x;
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree
|
|
|
|
* indexes
|
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A overlapping or left of polygon B? i.e. is
|
|
|
|
* the left most point of A left of the right most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_overleft(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.low.x <= polyb->boundbox.high.x;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree
|
|
|
|
* indexes
|
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A strictly right of polygon B? i.e. is
|
|
|
|
* the left most point of A right of the right most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_right(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.low.x > polyb->boundbox.high.x;
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree
|
|
|
|
* indexes
|
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A overlapping or right of polygon B? i.e. is
|
|
|
|
* the right most point of A right of the left most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_overright(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
result = polya->boundbox.high.x > polyb->boundbox.low.x;
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree
|
|
|
|
* indexes
|
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A the same as polygon B? i.e. are all the
|
|
|
|
* points the same?
|
1997-07-29 18:08:18 +02:00
|
|
|
* Check all points for matches in both forward and reverse
|
1997-09-07 07:04:48 +02:00
|
|
|
* direction since polygons are non-directional and are
|
|
|
|
* closed shapes.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_same(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (polya->npts != polyb->npts)
|
2000-12-09 00:57:03 +01:00
|
|
|
result = false;
|
|
|
|
else
|
|
|
|
result = plist_same(polya->npts, polya->p, polyb->p);
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree
|
|
|
|
* indexes
|
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
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-12-09 00:57:03 +01:00
|
|
|
PG_RETURN_BOOL(result);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
|
|
|
* Determine if polygon A overlaps polygon B by determining if
|
|
|
|
* their bounding boxes overlap.
|
2000-07-29 20:46:12 +02:00
|
|
|
*
|
|
|
|
* XXX ought to do a more correct check?
|
1996-07-09 08:22:35 +02:00
|
|
|
*-----------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_overlap(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
result = box_ov(&polya->boundbox, &polyb->boundbox);
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree
|
|
|
|
* indexes
|
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*-----------------------------------------------------------------
|
2000-07-29 20:46:12 +02:00
|
|
|
* Determine if polygon A contains polygon B.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-----------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_contain(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
/*
|
|
|
|
* Quick check to see if bounding box is contained.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
if (DatumGetBool(DirectFunctionCall2(box_contain,
|
|
|
|
BoxPGetDatum(&polya->boundbox),
|
|
|
|
BoxPGetDatum(&polyb->boundbox))))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-12-09 00:57:03 +01:00
|
|
|
result = true; /* assume true for now */
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < polyb->npts; i++)
|
|
|
|
{
|
|
|
|
if (point_inside(&(polyb->p[i]), polya->npts, &(polya->p[0])) == 0)
|
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#if GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("poly_contain- point (%f,%f) not in polygon\n", polyb->p[i].x, polyb->p[i].y);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-12-09 00:57:03 +01:00
|
|
|
result = false;
|
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
}
|
2000-12-09 00:57:03 +01:00
|
|
|
if (result)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-12-09 00:57:03 +01:00
|
|
|
for (i = 0; i < polya->npts; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-12-09 00:57:03 +01:00
|
|
|
if (point_inside(&(polya->p[i]), polyb->npts, &(polyb->p[0])) == 1)
|
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#if GEODEBUG
|
2000-12-09 00:57:03 +01:00
|
|
|
printf("poly_contain- point (%f,%f) in polygon\n", polya->p[i].x, polya->p[i].y);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-12-09 00:57:03 +01:00
|
|
|
result = false;
|
|
|
|
break;
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
2000-12-09 00:57:03 +01:00
|
|
|
else
|
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#if GEODEBUG
|
2000-12-09 00:57:03 +01:00
|
|
|
printf("poly_contain- bound box ((%f,%f),(%f,%f)) not inside ((%f,%f),(%f,%f))\n",
|
|
|
|
polyb->boundbox.low.x, polyb->boundbox.low.y, polyb->boundbox.high.x, polyb->boundbox.high.y,
|
|
|
|
polya->boundbox.low.x, polya->boundbox.low.y, polya->boundbox.high.x, polya->boundbox.high.y);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-12-09 00:57:03 +01:00
|
|
|
result = false;
|
|
|
|
}
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree
|
|
|
|
* indexes
|
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Determine if polygon A is contained by polygon B by determining
|
1996-07-09 08:22:35 +02:00
|
|
|
* if A's bounding box is contained by B's bounding box.
|
|
|
|
*-----------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_contained(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum polya = PG_GETARG_DATUM(0);
|
|
|
|
Datum polyb = PG_GETARG_DATUM(1);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_DATUM(DirectFunctionCall2(poly_contain, polyb, polya));
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* poly_contain_pt()
|
|
|
|
* Test to see if the point is inside the polygon.
|
|
|
|
* Code adapted from integer-based routines in
|
1997-09-07 07:04:48 +02:00
|
|
|
* Wn: A Server for the HTTP
|
|
|
|
* File: wn/image.c
|
|
|
|
* Version 1.15.1
|
|
|
|
* Copyright (C) 1995 <by John Franks>
|
1997-07-29 18:08:18 +02:00
|
|
|
* (code offered for use by J. Franks in Linux Journal letter.)
|
|
|
|
*/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_contain_pt(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
2000-07-29 20:46:12 +02:00
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(point_inside(p, poly->npts, poly->p) != 0);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
pt_contained_poly(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
Point *p = PG_GETARG_POINT_P(0);
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(point_inside(p, poly->npts, poly->p) != 0);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_distance(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
#ifdef NOT_USED
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-07-29 20:46:12 +02:00
|
|
|
#endif
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
elog(ERROR, "poly_distance not implemented");
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_NULL();
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D points.
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
construct_point(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
float8 x = PG_GETARG_FLOAT8(0);
|
|
|
|
float8 y = PG_GETARG_FLOAT8(1);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(point_construct(x, y));
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_add(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
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-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = (p1->x + p2->x);
|
|
|
|
result->y = (p1->y + p2->y);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_sub(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
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-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = (p1->x - p2->x);
|
|
|
|
result->y = (p1->y - p2->y);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_mul(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
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-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = (p1->x * p2->x) - (p1->y * p2->y);
|
|
|
|
result->y = (p1->x * p2->y) + (p1->y * p2->x);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_div(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
|
|
|
double div;
|
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-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
div = (p2->x * p2->x) + (p2->y * p2->y);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (div == 0.0)
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "point_div: divide by 0.0 error");
|
1997-08-22 01:57:00 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = ((p1->x * p2->x) + (p1->y * p2->y)) / div;
|
|
|
|
result->y = ((p2->x * p1->y) - (p2->y * p1->x)) / div;
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D boxes.
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
points_box(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(box_construct(p1->x, p2->x, p1->y, p2->y));
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_add(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(box_construct((box->high.x + p->x),
|
|
|
|
(box->low.x + p->x),
|
|
|
|
(box->high.y + p->y),
|
|
|
|
(box->low.y + p->y)));
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_sub(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(box_construct((box->high.x - p->x),
|
|
|
|
(box->low.x - p->x),
|
|
|
|
(box->high.y - p->y),
|
|
|
|
(box->low.y - p->y)));
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_mul(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
BOX *result;
|
|
|
|
Point *high,
|
|
|
|
*low;
|
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-30 22:44:02 +02:00
|
|
|
high = DatumGetPointP(DirectFunctionCall2(point_mul,
|
|
|
|
PointPGetDatum(&box->high),
|
|
|
|
PointPGetDatum(p)));
|
|
|
|
low = DatumGetPointP(DirectFunctionCall2(point_mul,
|
|
|
|
PointPGetDatum(&box->low),
|
|
|
|
PointPGetDatum(p)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result = box_construct(high->x, low->x, high->y, low->y);
|
2000-07-30 22:44:02 +02:00
|
|
|
|
|
|
|
PG_RETURN_BOX_P(result);
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_div(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
BOX *result;
|
|
|
|
Point *high,
|
|
|
|
*low;
|
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-30 22:44:02 +02:00
|
|
|
high = DatumGetPointP(DirectFunctionCall2(point_div,
|
|
|
|
PointPGetDatum(&box->high),
|
|
|
|
PointPGetDatum(p)));
|
|
|
|
low = DatumGetPointP(DirectFunctionCall2(point_div,
|
|
|
|
PointPGetDatum(&box->low),
|
|
|
|
PointPGetDatum(p)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result = box_construct(high->x, low->x, high->y, low->y);
|
2000-07-30 22:44:02 +02:00
|
|
|
|
|
|
|
PG_RETURN_BOX_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D paths.
|
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_add()
|
|
|
|
* Concatenate two paths (only if they are both open).
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_add(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
PATH *result;
|
|
|
|
int size;
|
|
|
|
int i;
|
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
|
|
|
if (p1->closed || p2->closed)
|
|
|
|
PG_RETURN_NULL();
|
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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
size = offsetof(PATH, p[0]) +sizeof(p1->p[0]) * (p1->npts + p2->npts);
|
2000-07-29 20:46:12 +02:00
|
|
|
result = (PATH *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->size = size;
|
|
|
|
result->npts = (p1->npts + p2->npts);
|
|
|
|
result->closed = p1->closed;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < p1->npts; i++)
|
|
|
|
{
|
|
|
|
result->p[i].x = p1->p[i].x;
|
|
|
|
result->p[i].y = p1->p[i].y;
|
|
|
|
}
|
|
|
|
for (i = 0; i < p2->npts; i++)
|
|
|
|
{
|
|
|
|
result->p[i + p1->npts].x = p2->p[i].x;
|
|
|
|
result->p[i + p1->npts].y = p2->p[i].y;
|
|
|
|
}
|
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
|
|
|
PG_RETURN_PATH_P(result);
|
|
|
|
}
|
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_add_pt()
|
2000-07-29 20:46:12 +02:00
|
|
|
* Translation operators.
|
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
|
|
|
Datum
|
|
|
|
path_add_pt(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
path->p[i].x += point->x;
|
|
|
|
path->p[i].y += point->y;
|
1997-09-07 07:04:48 +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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_sub_pt(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
path->p[i].x -= point->x;
|
|
|
|
path->p[i].y -= point->y;
|
1997-09-07 07:04:48 +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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(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
|
|
|
|
|
|
|
/* path_mul_pt()
|
|
|
|
* Rotation and scaling operators.
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_mul_pt(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *p;
|
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
p = DatumGetPointP(DirectFunctionCall2(point_mul,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&path->p[i]),
|
2000-07-30 22:44:02 +02:00
|
|
|
PointPGetDatum(point)));
|
2000-07-29 20:46:12 +02:00
|
|
|
path->p[i].x = p->x;
|
|
|
|
path->p[i].y = p->y;
|
1997-09-07 07:04:48 +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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_div_pt(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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *p;
|
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
p = DatumGetPointP(DirectFunctionCall2(point_div,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&path->p[i]),
|
2000-07-30 22:44:02 +02:00
|
|
|
PointPGetDatum(point)));
|
2000-07-29 20:46:12 +02:00
|
|
|
path->p[i].x = p->x;
|
|
|
|
path->p[i].y = p->y;
|
1997-09-07 07:04:48 +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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(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
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_center(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
#ifdef NOT_USED
|
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
|
|
|
#endif
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "path_center not implemented");
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_NULL();
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
int size;
|
|
|
|
int i;
|
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
|
|
|
/* This is not very consistent --- other similar cases return NULL ... */
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!path->closed)
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "Open path cannot be converted to 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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
size = offsetof(POLYGON, p[0]) +sizeof(poly->p[0]) * path->npts;
|
2000-07-29 20:46:12 +02:00
|
|
|
poly = (POLYGON *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->size = size;
|
|
|
|
poly->npts = path->npts;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
|
|
|
poly->p[i].x = path->p[i].x;
|
|
|
|
poly->p[i].y = path->p[i].y;
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
make_bound_box(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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
1997-06-03 16:01:22 +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
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D polygons.
|
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
|
|
|
Datum
|
|
|
|
poly_npoints(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
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
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
|
|
|
PG_RETURN_INT32(poly->npts);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_center(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum result;
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *circle;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
circle = DatumGetCircleP(DirectFunctionCall1(poly_circle,
|
|
|
|
PolygonPGetDatum(poly)));
|
2000-07-30 22:44:02 +02:00
|
|
|
result = DirectFunctionCall1(circle_center,
|
|
|
|
CirclePGetDatum(circle));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_DATUM(result);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_box(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
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
if (poly->npts < 1)
|
|
|
|
PG_RETURN_NULL();
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
box = box_copy(&poly->boundbox);
|
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
|
|
|
PG_RETURN_BOX_P(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
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-05-06 09:27:51 +02:00
|
|
|
/* box_poly()
|
|
|
|
* Convert a box to a polygon.
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
box_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
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
int size;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* map four corners of the box to a polygon */
|
2001-03-22 05:01:46 +01:00
|
|
|
size = offsetof(POLYGON, p[0]) +sizeof(poly->p[0]) * 4;
|
2000-07-29 20:46:12 +02:00
|
|
|
poly = (POLYGON *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->size = size;
|
|
|
|
poly->npts = 4;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->p[0].x = box->low.x;
|
|
|
|
poly->p[0].y = box->low.y;
|
|
|
|
poly->p[1].x = box->low.x;
|
|
|
|
poly->p[1].y = box->high.y;
|
|
|
|
poly->p[2].x = box->high.x;
|
|
|
|
poly->p[2].y = box->high.y;
|
|
|
|
poly->p[3].x = box->high.x;
|
|
|
|
poly->p[3].y = box->low.y;
|
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
|
|
|
box_fill(&poly->boundbox, box->high.x, box->low.x,
|
|
|
|
box->high.y, box->low.y);
|
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
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_path(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
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
PATH *path;
|
|
|
|
int size;
|
|
|
|
int i;
|
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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
size = offsetof(PATH, p[0]) +sizeof(path->p[0]) * poly->npts;
|
2000-07-29 20:46:12 +02:00
|
|
|
path = (PATH *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
path->size = size;
|
|
|
|
path->npts = poly->npts;
|
|
|
|
path->closed = TRUE;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < poly->npts; i++)
|
|
|
|
{
|
|
|
|
path->p[i].x = poly->p[i].x;
|
|
|
|
path->p[i].y = poly->p[i].y;
|
|
|
|
}
|
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
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
1997-06-03 16:01:22 +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
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for circles.
|
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
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Formatting and conversion routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_in - convert a string to internal form.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* External format: (center and radius of circle)
|
|
|
|
* "((f8,f8)<f8>)"
|
|
|
|
* also supports quick entry style "(f8,f8,f8)"
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_in(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *circle;
|
|
|
|
char *s,
|
|
|
|
*cp;
|
|
|
|
int depth = 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
circle = (CIRCLE *) palloc(sizeof(CIRCLE));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
s = str;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
|
|
|
if ((*s == LDELIM_C) || (*s == LDELIM))
|
|
|
|
{
|
|
|
|
depth++;
|
|
|
|
cp = (s + 1);
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
cp++;
|
|
|
|
if (*cp == LDELIM)
|
|
|
|
s = cp;
|
1997-09-05 20:13:45 +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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!pair_decode(s, &circle->center.x, &circle->center.y, &s))
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad circle external representation '%s'", str);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
if (*s == DELIM)
|
|
|
|
s++;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
|
|
|
|
|
|
|
if ((!single_decode(s, &circle->radius, &s)) || (circle->radius < 0))
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad circle external representation '%s'", str);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
while (depth > 0)
|
|
|
|
{
|
|
|
|
if ((*s == RDELIM)
|
|
|
|
|| ((*s == RDELIM_C) && (depth == 1)))
|
|
|
|
{
|
|
|
|
depth--;
|
|
|
|
s++;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
|
|
|
}
|
|
|
|
else
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad circle external representation '%s'", str);
|
1997-09-05 20:13:45 +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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (*s != '\0')
|
1998-01-05 17:40:20 +01:00
|
|
|
elog(ERROR, "Bad circle external representation '%s'", str);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_out - convert a circle to external form.
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_out(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
char *result;
|
|
|
|
char *cp;
|
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
|
|
|
|
1998-01-07 19:47:07 +01:00
|
|
|
result = palloc(3 * (P_MAXLEN + 1) + 3);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
cp = result;
|
|
|
|
*cp++ = LDELIM_C;
|
|
|
|
*cp++ = LDELIM;
|
|
|
|
if (!pair_encode(circle->center.x, circle->center.y, cp))
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "Unable to format 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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
cp += strlen(cp);
|
|
|
|
*cp++ = RDELIM;
|
|
|
|
*cp++ = DELIM;
|
|
|
|
if (!single_encode(circle->radius, cp))
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "Unable to format 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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
cp += strlen(cp);
|
|
|
|
*cp++ = RDELIM_C;
|
|
|
|
*cp = '\0';
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CSTRING(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relational operators for CIRCLEs.
|
|
|
|
* <, >, <=, >=, and == are based on circle area.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circles identical?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_same(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(circle1->radius, circle2->radius) &&
|
|
|
|
FPeq(circle1->center.x, circle2->center.x) &&
|
|
|
|
FPeq(circle1->center.y, circle2->center.y));
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_overlap - does circle1 overlap circle2?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_overlap(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(point_dt(&circle1->center, &circle2->center),
|
|
|
|
circle1->radius + circle2->radius));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_overleft - is the right edge of circle1 to the left of
|
|
|
|
* the right edge of circle2?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_overleft(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle((circle1->center.x + circle1->radius),
|
|
|
|
(circle2->center.x + circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_left - is circle1 strictly left of circle2?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_left(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle((circle1->center.x + circle1->radius),
|
|
|
|
(circle2->center.x - circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_right - is circle1 strictly right of circle2?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_right(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge((circle1->center.x - circle1->radius),
|
|
|
|
(circle2->center.x + circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_overright - is the left edge of circle1 to the right of
|
|
|
|
* the left edge of circle2?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_overright(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge((circle1->center.x - circle1->radius),
|
|
|
|
(circle2->center.x - circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_contained - is circle1 contained by circle2?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_contained(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle((point_dt(&circle1->center, &circle2->center) + circle1->radius), circle2->radius));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_contain - does circle1 contain circle2?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_contain(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle((point_dt(&circle1->center, &circle2->center) + circle2->radius), circle1->radius));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_positionop -
|
|
|
|
* is circle1 entirely {above,below} circle2?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_below(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(circle1->center.y + circle1->radius,
|
|
|
|
circle2->center.y - circle2->radius));
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_above(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(circle1->center.y - circle1->radius,
|
|
|
|
circle2->center.y + circle2->radius));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_relop - is area(circle1) relop area(circle2), within
|
|
|
|
* our accuracy constraint?
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_eq(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
circle_ne(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPne(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_lt(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_gt(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_le(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPle(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
circle_ge(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* "Arithmetic" operators on circles.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static CIRCLE *
|
1997-09-08 23:56:23 +02:00
|
|
|
circle_copy(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
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *result;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!PointerIsValid(circle))
|
|
|
|
return NULL;
|
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-30 22:44:02 +02:00
|
|
|
result = (CIRCLE *) palloc(sizeof(CIRCLE));
|
|
|
|
memcpy((char *) result, (char *) circle, sizeof(CIRCLE));
|
1998-09-01 05:29:17 +02:00
|
|
|
return result;
|
2000-07-30 22:44:02 +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_add_pt()
|
|
|
|
* Translation operator.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_add_pt(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *result;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result = circle_copy(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->center.x += point->x;
|
|
|
|
result->center.y += point->y;
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_sub_pt(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *result;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result = circle_copy(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->center.x -= point->x;
|
|
|
|
result->center.y -= point->y;
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
|
|
|
}
|
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_mul_pt()
|
|
|
|
* Rotation and scaling operators.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_mul_pt(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *result;
|
|
|
|
Point *p;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result = circle_copy(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
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
p = DatumGetPointP(DirectFunctionCall2(point_mul,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&circle->center),
|
2000-07-30 22:44:02 +02:00
|
|
|
PointPGetDatum(point)));
|
1997-09-07 07:04:48 +02:00
|
|
|
result->center.x = p->x;
|
|
|
|
result->center.y = p->y;
|
|
|
|
result->radius *= HYPOT(point->x, point->y);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
|
|
|
}
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_div_pt(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *result;
|
|
|
|
Point *p;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result = circle_copy(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
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
p = DatumGetPointP(DirectFunctionCall2(point_div,
|
2001-03-22 05:01:46 +01:00
|
|
|
PointPGetDatum(&circle->center),
|
2000-07-30 22:44:02 +02:00
|
|
|
PointPGetDatum(point)));
|
1997-09-07 07:04:48 +02:00
|
|
|
result->center.x = p->x;
|
|
|
|
result->center.y = p->y;
|
|
|
|
result->radius /= HYPOT(point->x, point->y);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_area - returns the area of the 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
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_area(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(circle_ar(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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_diameter - returns the diameter of the 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
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_diameter(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(2 * circle->radius);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_radius - returns the radius of the 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
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_radius(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(circle->radius);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_distance - returns the distance between
|
|
|
|
* two circles.
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_distance(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
float8 result;
|
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-30 22:44:02 +02:00
|
|
|
result = point_dt(&circle1->center, &circle2->center)
|
|
|
|
- (circle1->radius + circle2->radius);
|
|
|
|
if (result < 0)
|
|
|
|
result = 0;
|
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
1997-04-25 20:40:50 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_contain_pt(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
|
|
|
double d;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
d = point_dt(&circle->center, point);
|
|
|
|
PG_RETURN_BOOL(d <= circle->radius);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
pt_contained_circle(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *point = PG_GETARG_POINT_P(0);
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
|
|
|
|
double d;
|
|
|
|
|
|
|
|
d = point_dt(&circle->center, point);
|
|
|
|
PG_RETURN_BOOL(d <= circle->radius);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* dist_pc - returns the distance between
|
|
|
|
* a point and a circle.
|
1997-04-25 20:40:50 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_pc(PG_FUNCTION_ARGS)
|
1997-04-25 20:40:50 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *point = PG_GETARG_POINT_P(0);
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
|
|
|
|
float8 result;
|
1997-04-25 20:40:50 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = point_dt(point, &circle->center) - circle->radius;
|
|
|
|
if (result < 0)
|
|
|
|
result = 0;
|
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_center - returns the center point of the 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
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_center(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
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-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = circle->center.x;
|
|
|
|
result->y = circle->center.y;
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_ar - returns the area of the 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
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static double
|
1997-09-08 23:56:23 +02:00
|
|
|
circle_ar(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
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return PI * (circle->radius * circle->radius);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Conversion operators.
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
cr_circle(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
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *center = PG_GETARG_POINT_P(0);
|
|
|
|
float8 radius = PG_GETARG_FLOAT8(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *result;
|
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-30 22:44:02 +02:00
|
|
|
result = (CIRCLE *) palloc(sizeof(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->center.x = center->x;
|
|
|
|
result->center.y = center->y;
|
2000-07-30 22:44:02 +02:00
|
|
|
result->radius = radius;
|
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-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
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-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_box(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
BOX *box;
|
|
|
|
double delta;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
box = (BOX *) palloc(sizeof(BOX));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
delta = circle->radius / sqrt(2.0);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
box->high.x = circle->center.x + delta;
|
|
|
|
box->low.x = circle->center.x - delta;
|
|
|
|
box->high.y = circle->center.y + delta;
|
|
|
|
box->low.y = circle->center.y - delta;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(box);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
/* box_circle()
|
|
|
|
* Convert a box to a circle.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_circle(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *circle;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
circle = (CIRCLE *) palloc(sizeof(CIRCLE));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
circle->center.x = (box->high.x + box->low.x) / 2;
|
|
|
|
circle->center.y = (box->high.y + box->low.y) / 2;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
circle->radius = point_dt(&circle->center, &box->high);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(circle);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-06-13 09:35:40 +02:00
|
|
|
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
|
|
|
{
|
2000-06-13 09:35:40 +02:00
|
|
|
int32 npts = PG_GETARG_INT32(0);
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
int size;
|
|
|
|
int i;
|
|
|
|
double angle;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPzero(circle->radius) || (npts < 2))
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "Unable to convert circle to 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
|
|
|
|
1997-09-08 23:56:23 +02:00
|
|
|
size = offsetof(POLYGON, p[0]) +(sizeof(poly->p[0]) * npts);
|
2000-06-13 09:35:40 +02:00
|
|
|
poly = (POLYGON *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-18 22:22:58 +02:00
|
|
|
MemSet((char *) poly, 0, size); /* zero any holes */
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->size = size;
|
|
|
|
poly->npts = npts;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
|
|
|
angle = i * (2 * PI / npts);
|
|
|
|
poly->p[i].x = circle->center.x - (circle->radius * cos(angle));
|
|
|
|
poly->p[i].y = circle->center.y + (circle->radius * sin(angle));
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
make_bound_box(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
|
|
|
|
2000-06-13 09:35:40 +02:00
|
|
|
PG_RETURN_POLYGON_P(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-09-07 07:04:48 +02:00
|
|
|
/* poly_circle - convert polygon to 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
|
|
|
*
|
|
|
|
* XXX This algorithm should use weighted means of line segments
|
1997-09-07 07:04:48 +02:00
|
|
|
* rather than straight average values of points - tgl 97/01/21.
|
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
|
|
|
Datum
|
|
|
|
poly_circle(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
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *circle;
|
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (poly->npts < 2)
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "Unable to convert polygon to 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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
circle = (CIRCLE *) palloc(sizeof(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
circle->center.x = 0;
|
|
|
|
circle->center.y = 0;
|
|
|
|
circle->radius = 0;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < poly->npts; i++)
|
|
|
|
{
|
|
|
|
circle->center.x += poly->p[i].x;
|
|
|
|
circle->center.y += poly->p[i].y;
|
|
|
|
}
|
|
|
|
circle->center.x /= poly->npts;
|
|
|
|
circle->center.y /= poly->npts;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < poly->npts; i++)
|
|
|
|
circle->radius += point_dt(&poly->p[i], &circle->center);
|
|
|
|
circle->radius /= poly->npts;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPzero(circle->radius))
|
2000-01-15 03:59:43 +01:00
|
|
|
elog(ERROR, "Unable to convert polygon to 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
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_CIRCLE_P(circle);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Private routines for multiple types.
|
1997-07-29 18:08:18 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
#define HIT_IT INT_MAX
|
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
static int
|
1998-09-01 05:29:17 +02:00
|
|
|
point_inside(Point *p, int npts, Point *plist)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double x0,
|
|
|
|
y0;
|
|
|
|
double px,
|
|
|
|
py;
|
|
|
|
int i;
|
|
|
|
double x,
|
|
|
|
y;
|
|
|
|
int cross,
|
|
|
|
crossnum;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We calculate crossnum, which is twice the crossing number of a
|
|
|
|
* ray from the origin parallel to the positive X axis.
|
|
|
|
* A coordinate change is made to move the test point to the origin.
|
|
|
|
* Then the function lseg_crossing() is called to calculate the crossnum of
|
|
|
|
* one segment of the translated polygon with the ray which is the
|
|
|
|
* positive X-axis.
|
|
|
|
*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
crossnum = 0;
|
|
|
|
i = 0;
|
|
|
|
if (npts <= 0)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
x0 = plist[0].x - p->x;
|
|
|
|
y0 = plist[0].y - p->y;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
px = x0;
|
|
|
|
py = y0;
|
|
|
|
for (i = 1; i < npts; i++)
|
|
|
|
{
|
|
|
|
x = plist[i].x - p->x;
|
|
|
|
y = plist[i].y - p->y;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if ((cross = lseg_crossing(x, y, px, py)) == HIT_IT)
|
|
|
|
return 2;
|
|
|
|
crossnum += cross;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
px = x;
|
|
|
|
py = y;
|
|
|
|
}
|
|
|
|
if ((cross = lseg_crossing(x0, y0, px, py)) == HIT_IT)
|
|
|
|
return 2;
|
1997-07-29 18:08:18 +02:00
|
|
|
crossnum += cross;
|
1997-09-07 07:04:48 +02:00
|
|
|
if (crossnum != 0)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* lseg_crossing()
|
|
|
|
* The function lseg_crossing() returns +2, or -2 if the segment from (x,y)
|
|
|
|
* to previous (x,y) crosses the positive X-axis positively or negatively.
|
|
|
|
* It returns +1 or -1 if one endpoint is on this ray, or 0 if both are.
|
|
|
|
* It returns 0 if the ray and the segment don't intersect.
|
|
|
|
* It returns HIT_IT if the segment contains (0,0)
|
|
|
|
*/
|
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
static int
|
1997-09-07 07:04:48 +02:00
|
|
|
lseg_crossing(double x, double y, double px, double py)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double z;
|
|
|
|
int sgn;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* If (px,py) = (0,0) and not first call we have already sent HIT_IT */
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPzero(y))
|
|
|
|
{
|
|
|
|
if (FPzero(x))
|
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return HIT_IT;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else if (FPgt(x, 0))
|
|
|
|
{
|
|
|
|
if (FPzero(py))
|
1998-09-01 05:29:17 +02:00
|
|
|
return FPgt(px, 0) ? 0 : HIT_IT;
|
|
|
|
return FPlt(py, 0) ? 1 : -1;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{ /* x < 0 */
|
|
|
|
if (FPzero(py))
|
1998-09-01 05:29:17 +02:00
|
|
|
return FPlt(px, 0) ? 0 : HIT_IT;
|
|
|
|
return 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* Now we know y != 0; set sgn to sign of y */
|
|
|
|
sgn = (FPgt(y, 0) ? 1 : -1);
|
|
|
|
if (FPzero(py))
|
1998-09-01 05:29:17 +02:00
|
|
|
return FPlt(px, 0) ? 0 : sgn;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPgt((sgn * py), 0))
|
|
|
|
{ /* y and py have same sign */
|
1998-09-01 05:29:17 +02:00
|
|
|
return 0;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{ /* y and py have opposite signs */
|
|
|
|
if (FPge(x, 0) && FPgt(px, 0))
|
1998-09-01 05:29:17 +02:00
|
|
|
return 2 * sgn;
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPlt(x, 0) && FPle(px, 0))
|
1998-09-01 05:29:17 +02:00
|
|
|
return 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
z = (x - px) * y - (y - py) * x;
|
|
|
|
if (FPzero(z))
|
1998-09-01 05:29:17 +02:00
|
|
|
return HIT_IT;
|
|
|
|
return FPgt((sgn * z), 0) ? 0 : 2 * sgn;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static bool
|
1998-09-01 05:29:17 +02:00
|
|
|
plist_same(int npts, Point *p1, Point *p2)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int i,
|
|
|
|
ii,
|
|
|
|
j;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/* find match for first point */
|
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
|
|
|
if ((FPeq(p2[i].x, p1[0].x))
|
|
|
|
&& (FPeq(p2[i].y, p1[0].y)))
|
|
|
|
{
|
|
|
|
|
|
|
|
/* match found? then look forward through remaining points */
|
|
|
|
for (ii = 1, j = i + 1; ii < npts; ii++, j++)
|
|
|
|
{
|
|
|
|
if (j >= npts)
|
|
|
|
j = 0;
|
|
|
|
if ((!FPeq(p2[j].x, p1[ii].x))
|
|
|
|
|| (!FPeq(p2[j].y, p1[ii].y)))
|
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("plist_same- %d failed forward match with %d\n", j, ii);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("plist_same- ii = %d/%d after forward match\n", ii, npts);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
if (ii == npts)
|
1998-09-01 05:29:17 +02:00
|
|
|
return TRUE;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
/* match not found forwards? then look backwards */
|
|
|
|
for (ii = 1, j = i - 1; ii < npts; ii++, j--)
|
|
|
|
{
|
|
|
|
if (j < 0)
|
|
|
|
j = (npts - 1);
|
|
|
|
if ((!FPeq(p2[j].x, p1[ii].x))
|
|
|
|
|| (!FPeq(p2[j].y, p1[ii].y)))
|
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("plist_same- %d failed reverse match with %d\n", j, ii);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("plist_same- ii = %d/%d after reverse match\n", ii, npts);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
if (ii == npts)
|
1998-09-01 05:29:17 +02:00
|
|
|
return TRUE;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1998-09-01 05:29:17 +02:00
|
|
|
return FALSE;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|