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
|
|
|
*
|
2014-01-07 22:05:30 +01:00
|
|
|
* Portions Copyright (c) 1996-2014, 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
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/utils/adt/geo_ops.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
2002-09-05 02:43:07 +02:00
|
|
|
#include "postgres.h"
|
|
|
|
|
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
|
|
|
|
2003-05-09 23:19:50 +02:00
|
|
|
#include "libpq/pqformat.h"
|
2002-11-08 18:37:52 +01:00
|
|
|
#include "utils/builtins.h"
|
1997-03-15 00:21:12 +01:00
|
|
|
#include "utils/geo_decls.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-11-08 19:32:47 +01:00
|
|
|
#ifndef M_PI
|
|
|
|
#define M_PI 3.14159265358979323846
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
|
|
|
|
2002-11-08 19:32:47 +01:00
|
|
|
|
1997-09-20 18:22:31 +02:00
|
|
|
/*
|
|
|
|
* Internal routines
|
|
|
|
*/
|
|
|
|
|
2014-05-06 18:12:18 +02:00
|
|
|
enum path_delim
|
|
|
|
{
|
|
|
|
PATH_NONE, PATH_OPEN, PATH_CLOSED
|
|
|
|
};
|
2013-07-09 04:42:39 +02:00
|
|
|
|
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);
|
2013-07-09 04:42:39 +02:00
|
|
|
static char *path_encode(enum path_delim path_delim, int npts, Point *pt);
|
1997-09-08 23:56:23 +02:00
|
|
|
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);
|
2009-07-28 11:48:00 +02:00
|
|
|
static bool lseg_inside_poly(Point *a, Point *b, POLYGON *poly, int start);
|
2010-02-26 03:01:40 +01:00
|
|
|
static Point *lseg_interpt_internal(LSEG *l1, LSEG *l2);
|
2014-12-15 16:02:49 +01:00
|
|
|
static double dist_ppoly_internal(Point *pt, POLYGON *poly);
|
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
|
|
|
|
2002-11-08 18:37:52 +01:00
|
|
|
/* Maximum number of characters printed by pair_encode() */
|
2009-09-11 21:17:04 +02:00
|
|
|
/* ...+3+7 : 3 accounts for extra_float_digits max value */
|
|
|
|
#define P_MAXLEN (2*(DBL_DIG+3+7)+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
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
int ndig = DBL_DIG + extra_float_digits;
|
2002-11-08 18:37:52 +01:00
|
|
|
|
|
|
|
if (ndig < 1)
|
|
|
|
ndig = 1;
|
|
|
|
|
|
|
|
sprintf(str, "%.*g", ndig, 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
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
int ndig = DBL_DIG + extra_float_digits;
|
2002-11-08 18:37:52 +01:00
|
|
|
|
|
|
|
if (ndig < 1)
|
|
|
|
ndig = 1;
|
|
|
|
|
|
|
|
sprintf(str, "%.*g,%.*g", ndig, x, ndig, 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 *
|
2013-07-09 04:42:39 +02:00
|
|
|
path_encode(enum path_delim path_delim, int npts, Point *pt)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2002-08-30 01:05:44 +02:00
|
|
|
int size = npts * (P_MAXLEN + 3) + 2;
|
|
|
|
char *result;
|
1997-09-08 04:41:22 +02:00
|
|
|
char *cp;
|
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-08-30 01:05:44 +02:00
|
|
|
/* Check for integer overflow */
|
|
|
|
if ((size - 2) / npts != (P_MAXLEN + 3))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
2002-08-30 01:05:44 +02:00
|
|
|
|
|
|
|
result = palloc(size);
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
cp = result;
|
2013-07-09 04:42:39 +02:00
|
|
|
switch (path_delim)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_CLOSED:
|
1997-09-08 04:41:22 +02:00
|
|
|
*cp++ = LDELIM;
|
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_OPEN:
|
1997-09-08 04:41:22 +02:00
|
|
|
*cp++ = LDELIM_EP;
|
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_NONE:
|
1997-09-08 04:41:22 +02:00
|
|
|
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))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
2003-09-29 02:05:25 +02:00
|
|
|
errmsg("could not format \"path\" value")));
|
2003-07-27 06:53:12 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
cp += strlen(cp);
|
|
|
|
*cp++ = RDELIM;
|
|
|
|
*cp++ = DELIM;
|
|
|
|
pt++;
|
|
|
|
}
|
|
|
|
cp--;
|
2013-07-09 04:42:39 +02:00
|
|
|
switch (path_delim)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_CLOSED:
|
1997-09-08 04:41:22 +02:00
|
|
|
*cp++ = RDELIM;
|
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_OPEN:
|
1997-09-08 04:41:22 +02:00
|
|
|
*cp++ = RDELIM_EP;
|
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_NONE:
|
1997-09-08 04:41:22 +02:00
|
|
|
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'))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type box: \"%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
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(PATH_NONE, 2, &(box->high)));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* box_recv - converts external binary format to box
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
BOX *box;
|
|
|
|
double x,
|
|
|
|
y;
|
|
|
|
|
|
|
|
box = (BOX *) palloc(sizeof(BOX));
|
|
|
|
|
|
|
|
box->high.x = pq_getmsgfloat8(buf);
|
|
|
|
box->high.y = pq_getmsgfloat8(buf);
|
|
|
|
box->low.x = pq_getmsgfloat8(buf);
|
|
|
|
box->low.y = pq_getmsgfloat8(buf);
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
|
|
|
|
PG_RETURN_BOX_P(box);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* box_send - converts box to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, box->high.x);
|
|
|
|
pq_sendfloat8(&buf, box->high.y);
|
|
|
|
pq_sendfloat8(&buf, box->low.x);
|
|
|
|
pq_sendfloat8(&buf, box->low.y);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
2013-02-09 00:26:08 +01:00
|
|
|
return (FPle(box1->low.x, box2->high.x) &&
|
|
|
|
FPle(box2->low.x, box1->high.x) &&
|
|
|
|
FPle(box1->low.y, box2->high.y) &&
|
|
|
|
FPle(box2->low.y, box1->high.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +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
|
2005-06-24 22:53:34 +02:00
|
|
|
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);
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
PG_RETURN_BOOL(FPlt(box1->high.x, box2->low.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* box_overleft - is the right edge of box1 at or left of
|
|
|
|
* the right edge of box2?
|
|
|
|
*
|
|
|
|
* 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
|
2005-06-24 22:53:34 +02:00
|
|
|
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);
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
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_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
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* box_overright - is the left edge of box1 at or right of
|
1997-09-07 07:04:48 +02:00
|
|
|
* 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
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* box_below - is box1 strictly below box2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_below(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(box1->high.y, box2->low.y));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* box_overbelow - is the upper edge of box1 at or below
|
|
|
|
* the upper edge of box2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_overbelow(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(box1->high.y, box2->high.y));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* box_above - is box1 strictly above box2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_above(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(box1->low.y, box2->high.y));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* box_overabove - is the lower edge of box1 at or above
|
|
|
|
* the lower edge of box2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_overabove(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box1->low.y, box2->low.y));
|
|
|
|
}
|
|
|
|
|
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?
|
2005-06-24 22:53:34 +02:00
|
|
|
*
|
|
|
|
* box_below_eq and box_above_eq are obsolete versions that (probably
|
|
|
|
* erroneously) accept the equal-boundaries case. Since these are not
|
|
|
|
* in sync with the box_left and box_right code, they are deprecated and
|
|
|
|
* not supported in the PG 8.1 rtree operator class extension.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
2005-06-24 22:53:34 +02:00
|
|
|
box_below_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(FPle(box1->high.y, box2->low.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
2005-06-24 22:53:34 +02:00
|
|
|
box_above_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(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.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
2013-10-09 07:09:18 +02:00
|
|
|
static bool
|
|
|
|
line_decode(const char *str, LINE *line)
|
|
|
|
{
|
|
|
|
char *tail;
|
|
|
|
|
|
|
|
while (isspace((unsigned char) *str))
|
|
|
|
str++;
|
|
|
|
if (*str++ != '{')
|
|
|
|
return false;
|
|
|
|
line->A = strtod(str, &tail);
|
|
|
|
if (tail <= str)
|
|
|
|
return false;
|
|
|
|
str = tail;
|
|
|
|
while (isspace((unsigned char) *str))
|
|
|
|
str++;
|
|
|
|
if (*str++ != DELIM)
|
|
|
|
return false;
|
|
|
|
line->B = strtod(str, &tail);
|
|
|
|
if (tail <= str)
|
|
|
|
return false;
|
|
|
|
str = tail;
|
|
|
|
while (isspace((unsigned char) *str))
|
|
|
|
str++;
|
|
|
|
if (*str++ != DELIM)
|
|
|
|
return false;
|
|
|
|
line->C = strtod(str, &tail);
|
|
|
|
if (tail <= str)
|
|
|
|
return false;
|
|
|
|
str = tail;
|
|
|
|
while (isspace((unsigned char) *str))
|
|
|
|
str++;
|
|
|
|
if (*str++ != '}')
|
|
|
|
return false;
|
|
|
|
while (isspace((unsigned char) *str))
|
|
|
|
str++;
|
|
|
|
if (*str)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
1998-05-10 00:39:55 +02:00
|
|
|
LINE *line;
|
|
|
|
LSEG lseg;
|
|
|
|
int isopen;
|
|
|
|
char *s;
|
1998-09-01 06:40:42 +02:00
|
|
|
|
2013-10-09 07:09:18 +02:00
|
|
|
line = (LINE *) palloc(sizeof(LINE));
|
|
|
|
|
|
|
|
if (path_decode(TRUE, 2, str, &isopen, &s, &(lseg.p[0])) && *s == '\0')
|
|
|
|
{
|
|
|
|
if (FPeq(lseg.p[0].x, lseg.p[1].x) && FPeq(lseg.p[0].y, lseg.p[1].y))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid line specification: must be two distinct points")));
|
|
|
|
|
|
|
|
line_construct_pts(line, &lseg.p[0], &lseg.p[1]);
|
|
|
|
}
|
|
|
|
else if (line_decode(str, line))
|
|
|
|
{
|
|
|
|
if (FPzero(line->A) && FPzero(line->B))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid line specification: A and B cannot both be zero")));
|
|
|
|
}
|
|
|
|
else
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type line: \"%s\"", str)));
|
1998-05-10 00:39:55 +02:00
|
|
|
|
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
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
2013-10-09 07:09:18 +02:00
|
|
|
int ndig = DBL_DIG + extra_float_digits;
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2013-10-09 07:09:18 +02:00
|
|
|
if (ndig < 1)
|
|
|
|
ndig = 1;
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2013-10-22 13:04:41 +02:00
|
|
|
PG_RETURN_CSTRING(psprintf("{%.*g,%.*g,%.*g}", ndig, line->A, ndig, line->B, ndig, line->C));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* line_recv - converts external binary format to line
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
line_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2014-05-06 18:12:18 +02:00
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
2013-10-09 07:09:18 +02:00
|
|
|
LINE *line;
|
|
|
|
|
|
|
|
line = (LINE *) palloc(sizeof(LINE));
|
|
|
|
|
|
|
|
line->A = pq_getmsgfloat8(buf);
|
|
|
|
line->B = pq_getmsgfloat8(buf);
|
|
|
|
line->C = pq_getmsgfloat8(buf);
|
|
|
|
|
|
|
|
PG_RETURN_LINE_P(line);
|
2003-05-13 20:03:08 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* line_send - converts line to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
line_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2013-10-09 07:09:18 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, line->A);
|
|
|
|
pq_sendfloat8(&buf, line->B);
|
|
|
|
pq_sendfloat8(&buf, line->C);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
2003-05-13 20:03:08 +02:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2000-04-12 19:17:23 +02:00
|
|
|
if (m == DBL_MAX)
|
2010-11-10 22:51:39 +01:00
|
|
|
{
|
|
|
|
/* vertical - use "x = C" */
|
|
|
|
result->A = -1;
|
|
|
|
result->B = 0;
|
|
|
|
result->C = pt->x;
|
|
|
|
}
|
1999-12-21 18:01:44 +01:00
|
|
|
else
|
2010-11-10 22:51:39 +01:00
|
|
|
{
|
|
|
|
/* use "mx - y + yinter = 0" */
|
|
|
|
result->A = m;
|
|
|
|
result->B = -1.0;
|
1999-12-21 18:01:44 +01:00
|
|
|
result->C = pt->y - m * pt->x;
|
2010-11-10 22:51:39 +01:00
|
|
|
}
|
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;
|
|
|
|
#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;
|
|
|
|
#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;
|
2013-10-25 21:55:15 +02:00
|
|
|
/* on some platforms, the preceding expression tends to produce -0 */
|
|
|
|
if (line->C == 0.0)
|
|
|
|
line->C = 0.0;
|
1997-07-29 18:08:18 +02:00
|
|
|
#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",
|
2002-11-08 18:37:52 +01:00
|
|
|
DBL_DIG, (pt2->x - pt1->x), DBL_DIG, (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);
|
|
|
|
|
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);
|
|
|
|
|
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
|
|
|
/*
|
2005-10-15 04:49:52 +02: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
|
|
|
|
|
|
|
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",
|
2002-11-08 18:37:52 +01:00
|
|
|
DBL_DIG, l1->A, DBL_DIG, l1->B, DBL_DIG, l1->C, DBL_DIG, l2->A, DBL_DIG, l2->B, DBL_DIG, l2->C);
|
|
|
|
printf("line_interpt- lines intersect at (%.*g,%.*g)\n", DBL_DIG, x, DBL_DIG, 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
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2004-05-26 20:35:51 +02:00
|
|
|
Datum
|
|
|
|
path_area(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2004-08-29 07:07:03 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
|
|
|
double area = 0.0;
|
|
|
|
int i,
|
|
|
|
j;
|
2004-05-26 20:35:51 +02:00
|
|
|
|
|
|
|
if (!path->closed)
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
2004-08-29 07:07:03 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
2004-05-26 20:35:51 +02:00
|
|
|
j = (i + 1) % path->npts;
|
|
|
|
area += path->p[i].x * path->p[j].y;
|
|
|
|
area -= path->p[i].y * path->p[j].x;
|
|
|
|
}
|
|
|
|
|
|
|
|
area *= 0.5;
|
|
|
|
PG_RETURN_FLOAT8(area < 0.0 ? -area : area);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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;
|
2014-02-17 15:33:31 +01:00
|
|
|
int base_size;
|
1997-09-08 04:41:22 +02:00
|
|
|
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)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type path: \"%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
|
|
|
|
2014-02-17 15:33:31 +01:00
|
|
|
base_size = sizeof(path->p[0]) * npts;
|
2014-05-06 18:12:18 +02:00
|
|
|
size = offsetof(PATH, p[0]) +base_size;
|
2014-02-17 15:33:31 +01:00
|
|
|
|
|
|
|
/* Check for integer overflow */
|
|
|
|
if (base_size / npts != sizeof(path->p[0]) || size <= base_size)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
|
|
|
|
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
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(path, size);
|
1997-09-07 07:04:48 +02:00
|
|
|
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])))
|
2005-10-15 04:49:52 +02:00
|
|
|
&& (!((depth == 0) && (*s == '\0'))) && !((depth >= 1) && (*s == RDELIM)))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type path: \"%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);
|
2008-04-12 00:52:05 +02:00
|
|
|
/* prevent instability in unused pad bytes */
|
|
|
|
path->dummy = 0;
|
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
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(path->closed ? PATH_CLOSED : PATH_OPEN, path->npts, path->p));
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* path_recv - converts external binary format to path
|
|
|
|
*
|
|
|
|
* External representation is closed flag (a boolean byte), int32 number
|
|
|
|
* of points, and the points.
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
path_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
PATH *path;
|
|
|
|
int closed;
|
|
|
|
int32 npts;
|
|
|
|
int32 i;
|
|
|
|
int size;
|
|
|
|
|
|
|
|
closed = pq_getmsgbyte(buf);
|
|
|
|
npts = pq_getmsgint(buf, sizeof(int32));
|
2007-12-18 01:04:08 +01:00
|
|
|
if (npts <= 0 || npts >= (int32) ((INT_MAX - offsetof(PATH, p[0])) / sizeof(Point)))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid number of points in external \"path\" value")));
|
2003-05-13 20:03:08 +02:00
|
|
|
|
|
|
|
size = offsetof(PATH, p[0]) +sizeof(path->p[0]) * npts;
|
|
|
|
path = (PATH *) palloc(size);
|
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(path, size);
|
2003-05-13 20:03:08 +02:00
|
|
|
path->npts = npts;
|
|
|
|
path->closed = (closed ? 1 : 0);
|
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston. We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.
Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary. In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc. Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix. In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.
Back-patch to all supported branches.
2011-04-27 19:58:36 +02:00
|
|
|
/* prevent instability in unused pad bytes */
|
|
|
|
path->dummy = 0;
|
2003-05-13 20:03:08 +02:00
|
|
|
|
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
|
|
|
path->p[i].x = pq_getmsgfloat8(buf);
|
|
|
|
path->p[i].y = pq_getmsgfloat8(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* path_send - converts path to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
path_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
int32 i;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendbyte(&buf, path->closed ? 1 : 0);
|
|
|
|
pq_sendint(&buf, path->npts, sizeof(int32));
|
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
|
|
|
pq_sendfloat8(&buf, path->p[i].x);
|
|
|
|
pq_sendfloat8(&buf, path->p[i].y);
|
|
|
|
}
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
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),
|
2005-10-15 04:49:52 +02: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'))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type point: \"%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
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(PATH_NONE, 1, pt));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-09 23:19:50 +02:00
|
|
|
/*
|
|
|
|
* point_recv - converts external binary format to point
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
point_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
Point *point;
|
|
|
|
|
|
|
|
point = (Point *) palloc(sizeof(Point));
|
|
|
|
point->x = pq_getmsgfloat8(buf);
|
|
|
|
point->y = pq_getmsgfloat8(buf);
|
|
|
|
PG_RETURN_POINT_P(point);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* point_send - converts point to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
point_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, pt->x);
|
|
|
|
pq_sendfloat8(&buf, pt->y);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
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",
|
2005-10-15 04:49:52 +02:00
|
|
|
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'))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type lseg: \"%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
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(PATH_OPEN, 2, (Point *) &(ls->p[0])));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* lseg_recv - converts external binary format to lseg
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
lseg_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
LSEG *lseg;
|
|
|
|
|
|
|
|
lseg = (LSEG *) palloc(sizeof(LSEG));
|
|
|
|
|
|
|
|
lseg->p[0].x = pq_getmsgfloat8(buf);
|
|
|
|
lseg->p[0].y = pq_getmsgfloat8(buf);
|
|
|
|
lseg->p[1].x = pq_getmsgfloat8(buf);
|
|
|
|
lseg->p[1].y = pq_getmsgfloat8(buf);
|
|
|
|
|
|
|
|
#ifdef NOT_USED
|
|
|
|
lseg->m = point_sl(&lseg->p[0], &lseg->p[1]);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
PG_RETURN_LSEG_P(lseg);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* lseg_send - converts lseg to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
lseg_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *ls = PG_GETARG_LSEG_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, ls->p[0].x);
|
|
|
|
pq_sendfloat8(&buf, ls->p[0].y);
|
|
|
|
pq_sendfloat8(&buf, ls->p[1].x);
|
|
|
|
pq_sendfloat8(&buf, ls->p[1].y);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
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) &&
|
2002-11-29 20:25:33 +01:00
|
|
|
FPeq(l1->p[0].y, l2->p[0].y) &&
|
|
|
|
FPeq(l1->p[1].x, l2->p[1].x) &&
|
2000-07-30 22:44:02 +02:00
|
|
|
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) ||
|
2002-11-29 20:25:33 +01:00
|
|
|
!FPeq(l1->p[0].y, l2->p[0].y) ||
|
|
|
|
!FPeq(l1->p[1].x, l2->p[1].x) ||
|
2000-07-30 22:44:02 +02:00
|
|
|
!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
|
|
|
|
2002-12-30 03:18:29 +01: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
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
static Point *
|
2009-07-28 11:48:00 +02:00
|
|
|
lseg_interpt_internal(LSEG *l1, LSEG *l2)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
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))
|
2009-07-28 11:48:00 +02:00
|
|
|
return NULL;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/*
|
2005-10-15 04:49:52 +02: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))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
pfree(result);
|
|
|
|
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)) ||
|
2005-10-15 04:49:52 +02: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
|
|
|
}
|
|
|
|
|
2009-07-28 11:48:00 +02:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* lseg_interpt -
|
|
|
|
* Find the intersection point of two segments (if any).
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
lseg_interpt(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
Point *result;
|
2010-02-26 03:01:40 +01:00
|
|
|
|
2009-07-28 11:48:00 +02:00
|
|
|
result = lseg_interpt_internal(l1, l2);
|
|
|
|
if (!PointerIsValid(result))
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
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
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a point to a line
|
|
|
|
*/
|
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)
|
|
|
|
{
|
2013-10-09 07:09:18 +02:00
|
|
|
return fabs((line->A * pt->x + line->B * pt->y + line->C) /
|
|
|
|
HYPOT(line->A, line->B));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a point to a lseg
|
|
|
|
*/
|
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
|
|
|
|
2009-06-23 18:25:02 +02:00
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* Construct a line perpendicular to the input segment and through the
|
|
|
|
* input point
|
2009-06-23 18:25:02 +02:00
|
|
|
*/
|
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)
|
2009-06-23 18:25:02 +02:00
|
|
|
m = (double) DBL_MAX; /* slope is infinite */
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
2009-06-23 18:25:02 +02:00
|
|
|
m = (lseg->p[0].x - lseg->p[1].x) / (lseg->p[1].y - lseg->p[0].y);
|
1997-09-07 07:04:48 +02:00
|
|
|
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
|
|
|
/*
|
2009-06-23 18:25:02 +02:00
|
|
|
* Calculate distance to the line segment or to the nearest endpoint of
|
|
|
|
* the segment.
|
2002-05-14 20:16:51 +02:00
|
|
|
*/
|
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)
|
|
|
|
{
|
2009-06-23 18:25:02 +02:00
|
|
|
/* yes, so use distance to the intersection point */
|
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
|
|
|
|
{
|
2009-06-23 18:25:02 +02:00
|
|
|
/* no, so use distance to the nearer endpoint */
|
2000-07-30 22:44:02 +02:00
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-12-15 16:02:49 +01:00
|
|
|
* Distance from a point to a path
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
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);
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* the distance from a point to a path is the smallest distance
|
|
|
|
* from the point to any of its constituent segments.
|
1997-09-08 04:41:22 +02:00
|
|
|
*/
|
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;
|
2005-10-15 04:49:52 +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
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a point to a box
|
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a lseg to a line
|
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a lseg to a box
|
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a line to a box
|
|
|
|
*/
|
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 */
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("function \"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
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a circle to a polygon
|
|
|
|
*/
|
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;
|
2014-12-15 16:02:49 +01:00
|
|
|
|
|
|
|
/* calculate distance to center, and subtract radius */
|
|
|
|
result = dist_ppoly_internal(&circle->center, poly);
|
|
|
|
|
|
|
|
result -= circle->radius;
|
|
|
|
if (result < 0)
|
|
|
|
result = 0;
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Distance from a point to a polygon
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_ppoly(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *point = PG_GETARG_POINT_P(0);
|
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(1);
|
|
|
|
float8 result;
|
|
|
|
|
|
|
|
result = dist_ppoly_internal(point, poly);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
static double
|
|
|
|
dist_ppoly_internal(Point *pt, POLYGON *poly)
|
|
|
|
{
|
|
|
|
float8 result;
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 d;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
LSEG seg;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
if (point_inside(pt, poly->npts, poly->p) != 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
2014-12-15 16:02:49 +01:00
|
|
|
printf("dist_ppoly_internal- point 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;
|
2014-12-15 16:02:49 +01:00
|
|
|
result = dist_ps_internal(pt, &seg);
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
2014-12-15 16:02:49 +01:00
|
|
|
printf("dist_ppoly_internal- 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;
|
2014-12-15 16:02:49 +01:00
|
|
|
d = dist_ps_internal(pt, &seg);
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
2014-12-15 16:02:49 +01:00
|
|
|
printf("dist_ppoly_internal- 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
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
return 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
|
|
|
* 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",
|
2002-11-08 18:37:52 +01:00
|
|
|
DBL_DIG, lseg->p[0].x, DBL_DIG, lseg->p[0].y, DBL_DIG, lseg->p[1].x, DBL_DIG, lseg->p[1].y);
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("interpt_sl- segment becomes line A=%.*g B=%.*g C=%.*g\n",
|
2002-11-08 18:37:52 +01:00
|
|
|
DBL_DIG, tmp.A, DBL_DIG, tmp.B, DBL_DIG, 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
|
2002-11-08 18:37:52 +01:00
|
|
|
printf("interpt_sl- intersection point is (%.*g %.*g)\n", DBL_DIG, p->x, DBL_DIG, 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));
|
|
|
|
|
|
|
|
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 */
|
2013-10-09 07:09:18 +02:00
|
|
|
|
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
|
|
|
/*
|
2005-10-15 04:49:52 +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-09-01 06:40:42 +02:00
|
|
|
*/
|
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 */
|
2005-10-15 04:49:52 +02:00
|
|
|
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 */
|
2005-10-15 04:49:52 +02:00
|
|
|
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
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* at this point the "normal" from point will hit lseg. The closet point
|
|
|
|
* will be somewhere on the lseg
|
1998-09-01 06:40:42 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
2009-08-27 17:59:22 +02:00
|
|
|
if (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,
|
2005-10-15 04:49:52 +02: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,
|
2005-10-15 04:49:52 +02:00
|
|
|
PointPGetDatum(&point),
|
2000-07-30 22:44:02 +02:00
|
|
|
LsegPGetDatum(l2)));
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2009-08-27 17:59:22 +02:00
|
|
|
if (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,
|
2005-10-15 04:49:52 +02: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,
|
2005-10-15 04:49:52 +02: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);
|
2009-08-27 17:59:22 +02:00
|
|
|
dist = 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
|
|
|
{
|
2013-10-09 07:09:18 +02:00
|
|
|
#ifdef NOT_USED
|
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);
|
2013-10-09 07:09:18 +02:00
|
|
|
#endif
|
|
|
|
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("function \"close_sl\" not implemented")));
|
|
|
|
|
|
|
|
PG_RETURN_NULL();
|
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 */
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("function \"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
|
|
|
}
|
|
|
|
|
2010-01-14 17:31:09 +01:00
|
|
|
Datum
|
2010-02-26 03:01:40 +01:00
|
|
|
box_contain_pt(PG_FUNCTION_ARGS)
|
2010-01-14 17:31:09 +01:00
|
|
|
{
|
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *pt = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(pt->x <= box->high.x && pt->x >= box->low.x &&
|
|
|
|
pt->y <= box->high.y && pt->y >= box->low.y);
|
|
|
|
}
|
|
|
|
|
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,
|
2005-10-15 04:49:52 +02:00
|
|
|
PointPGetDatum(&lseg->p[0]),
|
|
|
|
LinePGetDatum(line))) &&
|
2000-07-30 22:44:02 +02:00
|
|
|
DatumGetBool(DirectFunctionCall2(on_pl,
|
2005-10-15 04:49:52 +02: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,
|
2005-10-15 04:49:52 +02:00
|
|
|
PointPGetDatum(&lseg->p[0]),
|
2001-03-22 05:01:46 +01:00
|
|
|
BoxPGetDatum(box))) &&
|
2000-07-30 22:44:02 +02:00
|
|
|
DatumGetBool(DirectFunctionCall2(on_pb,
|
2005-10-15 04:49:52 +02:00
|
|
|
PointPGetDatum(&lseg->p[1]),
|
2001-03-22 05:01:46 +01:00
|
|
|
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
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("cannot 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;
|
2014-02-17 15:33:31 +01:00
|
|
|
int base_size;
|
1997-09-08 04:41:22 +02:00
|
|
|
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)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type polygon: \"%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
|
|
|
|
2014-02-17 15:33:31 +01:00
|
|
|
base_size = sizeof(poly->p[0]) * npts;
|
2014-05-06 18:12:18 +02:00
|
|
|
size = offsetof(POLYGON, p[0]) +base_size;
|
2014-02-17 15:33:31 +01:00
|
|
|
|
|
|
|
/* Check for integer overflow */
|
|
|
|
if (base_size / npts != sizeof(poly->p[0]) || size <= base_size)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
|
|
|
|
2002-11-13 01:39:48 +01:00
|
|
|
poly = (POLYGON *) palloc0(size); /* zero any holes */
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
1997-09-07 07:04:48 +02:00
|
|
|
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'))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type polygon: \"%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
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(PATH_CLOSED, poly->npts, poly->p));
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* poly_recv - converts external binary format to polygon
|
|
|
|
*
|
|
|
|
* External representation is int32 number of points, and the points.
|
|
|
|
* We recompute the bounding box on read, instead of trusting it to
|
|
|
|
* be valid. (Checking it would take just as long, so may as well
|
|
|
|
* omit it from external representation.)
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
poly_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
2003-08-04 02:43:34 +02:00
|
|
|
POLYGON *poly;
|
2003-05-13 20:03:08 +02:00
|
|
|
int32 npts;
|
|
|
|
int32 i;
|
|
|
|
int size;
|
|
|
|
|
|
|
|
npts = pq_getmsgint(buf, sizeof(int32));
|
2007-12-18 01:04:08 +01:00
|
|
|
if (npts <= 0 || npts >= (int32) ((INT_MAX - offsetof(POLYGON, p[0])) / sizeof(Point)))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid number of points in external \"polygon\" value")));
|
2003-05-13 20:03:08 +02:00
|
|
|
|
|
|
|
size = offsetof(POLYGON, p[0]) +sizeof(poly->p[0]) * npts;
|
|
|
|
poly = (POLYGON *) palloc0(size); /* zero any holes */
|
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
2003-05-13 20:03:08 +02:00
|
|
|
poly->npts = npts;
|
|
|
|
|
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
|
|
|
poly->p[i].x = pq_getmsgfloat8(buf);
|
|
|
|
poly->p[i].y = pq_getmsgfloat8(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
make_bound_box(poly);
|
|
|
|
|
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* poly_send - converts polygon to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
poly_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
2003-05-13 20:03:08 +02:00
|
|
|
StringInfoData buf;
|
|
|
|
int32 i;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendint(&buf, poly->npts, sizeof(int32));
|
|
|
|
for (i = 0; i < poly->npts; i++)
|
|
|
|
{
|
|
|
|
pq_sendfloat8(&buf, poly->p[i].x);
|
|
|
|
pq_sendfloat8(&buf, poly->p[i].y);
|
|
|
|
}
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
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
|
2005-06-24 22:53:34 +02:00
|
|
|
* the right most point of A at or left of the right most point
|
1996-07-09 08:22:35 +02:00
|
|
|
* 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;
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
result = polya->boundbox.high.x <= polyb->boundbox.high.x;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
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
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
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
|
2005-06-24 22:53:34 +02:00
|
|
|
* the left most point of A at or right of the left most point
|
1996-07-09 08:22:35 +02:00
|
|
|
* 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
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
result = polya->boundbox.low.x >= polyb->boundbox.low.x;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2005-06-24 22:53:34 +02:00
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A strictly below polygon B? i.e. is
|
|
|
|
* the upper most point of A below the lower most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
|
|
|
Datum
|
|
|
|
poly_below(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.high.y < polyb->boundbox.low.y;
|
2000-12-09 00:57:03 +01:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A overlapping or below polygon B? i.e. is
|
|
|
|
* the upper most point of A at or below the upper most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
|
|
|
Datum
|
|
|
|
poly_overbelow(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.high.y <= polyb->boundbox.high.y;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2005-06-24 22:53:34 +02:00
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A strictly above polygon B? i.e. is
|
|
|
|
* the lower most point of A above the upper most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
|
|
|
Datum
|
|
|
|
poly_above(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.low.y > polyb->boundbox.high.y;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2005-06-24 22:53:34 +02:00
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A overlapping or above polygon B? i.e. is
|
|
|
|
* the lower most point of A at or above the lower most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
|
|
|
Datum
|
|
|
|
poly_overabove(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.low.y >= polyb->boundbox.low.y;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2005-06-24 22:53:34 +02: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
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
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
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
2010-02-26 03:01:40 +01:00
|
|
|
* Determine if polygon A overlaps polygon B
|
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
|
|
|
|
2009-07-28 11:48:00 +02:00
|
|
|
/* Quick check by bounding box */
|
2010-02-26 03:01:40 +01:00
|
|
|
result = (polya->npts > 0 && polyb->npts > 0 &&
|
|
|
|
box_ov(&polya->boundbox, &polyb->boundbox)) ? true : false;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* Brute-force algorithm - try to find intersected edges, if so then
|
|
|
|
* polygons are overlapped else check is one polygon inside other or not
|
|
|
|
* by testing single point of them.
|
2009-07-28 11:48:00 +02:00
|
|
|
*/
|
|
|
|
if (result)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
int ia,
|
|
|
|
ib;
|
|
|
|
LSEG sa,
|
|
|
|
sb;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
/* Init first of polya's edge with last point */
|
|
|
|
sa.p[0] = polya->p[polya->npts - 1];
|
|
|
|
result = false;
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
for (ia = 0; ia < polya->npts && result == false; ia++)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
/* Second point of polya's edge is a current one */
|
2009-07-28 11:48:00 +02:00
|
|
|
sa.p[1] = polya->p[ia];
|
|
|
|
|
|
|
|
/* Init first of polyb's edge with last point */
|
|
|
|
sb.p[0] = polyb->p[polyb->npts - 1];
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
for (ib = 0; ib < polyb->npts && result == false; ib++)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
sb.p[1] = polyb->p[ib];
|
|
|
|
result = lseg_intersect_internal(&sa, &sb);
|
|
|
|
sb.p[0] = sb.p[1];
|
|
|
|
}
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
/*
|
|
|
|
* move current endpoint to the first point of next edge
|
2009-07-28 11:48:00 +02:00
|
|
|
*/
|
|
|
|
sa.p[0] = sa.p[1];
|
|
|
|
}
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
if (result == false)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
result = (point_inside(polya->p, polyb->npts, polyb->p)
|
|
|
|
||
|
|
|
|
point_inside(polyb->p, polya->npts, polya->p));
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
}
|
2000-12-09 00:57:03 +01:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
2009-07-28 11:48:00 +02:00
|
|
|
/*
|
|
|
|
* Tests special kind of segment for in/out of polygon.
|
|
|
|
* Special kind means:
|
2010-02-26 03:01:40 +01:00
|
|
|
* - point a should be on segment s
|
|
|
|
* - segment (a,b) should not be contained by s
|
2009-07-28 11:48:00 +02:00
|
|
|
* Returns true if:
|
2010-02-26 03:01:40 +01:00
|
|
|
* - segment (a,b) is collinear to s and (a,b) is in polygon
|
|
|
|
* - segment (a,b) s not collinear to s. Note: that doesn't
|
|
|
|
* mean that segment is in polygon!
|
|
|
|
*/
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
static bool
|
|
|
|
touched_lseg_inside_poly(Point *a, Point *b, LSEG *s, POLYGON *poly, int start)
|
|
|
|
{
|
|
|
|
/* point a is on s, b is not */
|
2010-02-26 03:01:40 +01:00
|
|
|
LSEG t;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
t.p[0] = *a;
|
|
|
|
t.p[1] = *b;
|
2010-02-26 03:01:40 +01:00
|
|
|
|
|
|
|
#define POINTEQ(pt1, pt2) (FPeq((pt1)->x, (pt2)->x) && FPeq((pt1)->y, (pt2)->y))
|
|
|
|
if (POINTEQ(a, s->p))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
if (on_ps_internal(s->p + 1, &t))
|
|
|
|
return lseg_inside_poly(b, s->p + 1, poly, start);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
2010-02-26 03:01:40 +01:00
|
|
|
else if (POINTEQ(a, s->p + 1))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
if (on_ps_internal(s->p, &t))
|
2009-07-28 11:48:00 +02:00
|
|
|
return lseg_inside_poly(b, s->p, poly, start);
|
|
|
|
}
|
2010-02-26 03:01:40 +01:00
|
|
|
else if (on_ps_internal(s->p, &t))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
return lseg_inside_poly(b, s->p, poly, start);
|
|
|
|
}
|
2010-02-26 03:01:40 +01:00
|
|
|
else if (on_ps_internal(s->p + 1, &t))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
return lseg_inside_poly(b, s->p + 1, poly, start);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
return true; /* may be not true, but that will check later */
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns true if segment (a,b) is in polygon, option
|
2010-02-26 03:01:40 +01:00
|
|
|
* start is used for optimization - function checks
|
2009-07-28 11:48:00 +02:00
|
|
|
* polygon's edges started from start
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
lseg_inside_poly(Point *a, Point *b, POLYGON *poly, int start)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
LSEG s,
|
|
|
|
t;
|
|
|
|
int i;
|
|
|
|
bool res = true,
|
|
|
|
intersection = false;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
t.p[0] = *a;
|
|
|
|
t.p[1] = *b;
|
2010-02-26 03:01:40 +01:00
|
|
|
s.p[0] = poly->p[(start == 0) ? (poly->npts - 1) : (start - 1)];
|
2009-07-28 11:48:00 +02:00
|
|
|
|
2010-11-15 03:03:48 +01:00
|
|
|
for (i = start; i < poly->npts && res; i++)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
Point *interpt;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
s.p[1] = poly->p[i];
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
if (on_ps_internal(t.p, &s))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
if (on_ps_internal(t.p + 1, &s))
|
|
|
|
return true; /* t is contained by s */
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
/* Y-cross */
|
2010-02-26 03:01:40 +01:00
|
|
|
res = touched_lseg_inside_poly(t.p, t.p + 1, &s, poly, i + 1);
|
|
|
|
}
|
|
|
|
else if (on_ps_internal(t.p + 1, &s))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
/* Y-cross */
|
2010-02-26 03:01:40 +01:00
|
|
|
res = touched_lseg_inside_poly(t.p + 1, t.p, &s, poly, i + 1);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
2010-02-26 03:01:40 +01:00
|
|
|
else if ((interpt = lseg_interpt_internal(&t, &s)) != NULL)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* segments are X-crossing, go to check each subsegment
|
|
|
|
*/
|
|
|
|
|
|
|
|
intersection = true;
|
2010-02-26 03:01:40 +01:00
|
|
|
res = lseg_inside_poly(t.p, interpt, poly, i + 1);
|
2009-07-28 11:48:00 +02:00
|
|
|
if (res)
|
2010-02-26 03:01:40 +01:00
|
|
|
res = lseg_inside_poly(t.p + 1, interpt, poly, i + 1);
|
2009-07-28 11:48:00 +02:00
|
|
|
pfree(interpt);
|
|
|
|
}
|
|
|
|
|
|
|
|
s.p[0] = s.p[1];
|
|
|
|
}
|
|
|
|
|
|
|
|
if (res && !intersection)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
Point p;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* if X-intersection wasn't found then check central point of tested
|
|
|
|
* segment. In opposite case we already check all subsegments
|
2009-07-28 11:48:00 +02:00
|
|
|
*/
|
2010-02-26 03:01:40 +01:00
|
|
|
p.x = (t.p[0].x + t.p[1].x) / 2.0;
|
2009-07-28 11:48:00 +02:00
|
|
|
p.y = (t.p[0].y + t.p[1].y) / 2.0;
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
res = point_inside(&p, poly->npts, poly->p);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
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-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
/*
|
|
|
|
* Quick check to see if bounding box is contained.
|
|
|
|
*/
|
2009-07-28 11:48:00 +02:00
|
|
|
if (polya->npts > 0 && polyb->npts > 0 &&
|
2010-02-26 03:01:40 +01:00
|
|
|
DatumGetBool(DirectFunctionCall2(box_contain,
|
|
|
|
BoxPGetDatum(&polya->boundbox),
|
|
|
|
BoxPGetDatum(&polyb->boundbox))))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
int i;
|
|
|
|
LSEG s;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
s.p[0] = polyb->p[polyb->npts - 1];
|
|
|
|
result = true;
|
|
|
|
|
2010-11-15 03:03:48 +01:00
|
|
|
for (i = 0; i < polyb->npts && result; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2009-07-28 11:48:00 +02:00
|
|
|
s.p[1] = polyb->p[i];
|
2010-02-26 03:01:40 +01:00
|
|
|
result = lseg_inside_poly(s.p, s.p + 1, polya, 0);
|
2009-07-28 11:48:00 +02:00
|
|
|
s.p[0] = s.p[1];
|
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
|
|
|
|
{
|
|
|
|
result = false;
|
|
|
|
}
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
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
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
2005-06-24 22:53:34 +02:00
|
|
|
* Determine if polygon A is contained by polygon B
|
1996-07-09 08:22:35 +02:00
|
|
|
*-----------------------------------------------------------------*/
|
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
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* Just switch the arguments and pass it off to poly_contain */
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_DATUM(DirectFunctionCall2(poly_contain, polyb, polya));
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
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
|
|
|
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("function \"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)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DIVISION_BY_ZERO),
|
|
|
|
errmsg("division by zero")));
|
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;
|
2002-08-30 01:05:44 +02:00
|
|
|
int size,
|
|
|
|
base_size;
|
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
|
|
|
|
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
|
|
|
|
2002-08-30 01:05:44 +02:00
|
|
|
base_size = sizeof(p1->p[0]) * (p1->npts + p2->npts);
|
2002-09-04 22:31:48 +02:00
|
|
|
size = offsetof(PATH, p[0]) +base_size;
|
2002-08-30 01:05:44 +02:00
|
|
|
|
|
|
|
/* Check for integer overflow */
|
|
|
|
if (base_size / sizeof(p1->p[0]) != (p1->npts + p2->npts) ||
|
|
|
|
size <= base_size)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
2002-08-30 01:05:44 +02:00
|
|
|
|
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
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(result, size);
|
1997-09-07 07:04:48 +02:00
|
|
|
result->npts = (p1->npts + p2->npts);
|
|
|
|
result->closed = p1->closed;
|
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston. We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.
Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary. In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc. Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix. In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.
Back-patch to all supported branches.
2011-04-27 19:58:36 +02:00
|
|
|
/* prevent instability in unused pad bytes */
|
|
|
|
result->dummy = 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 < 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,
|
2005-10-15 04:49:52 +02: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,
|
2005-10-15 04:49:52 +02: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
|
|
|
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("function \"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)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("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
|
|
|
|
2014-02-17 15:33:31 +01:00
|
|
|
/*
|
|
|
|
* Never overflows: the old size fit in MaxAllocSize, and the new size is
|
|
|
|
* just a small constant larger.
|
|
|
|
*/
|
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
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
1997-09-07 07:04:48 +02:00
|
|
|
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
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
1997-09-07 07:04:48 +02:00
|
|
|
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
|
|
|
|
2014-02-17 15:33:31 +01:00
|
|
|
/*
|
|
|
|
* Never overflows: the old size fit in MaxAllocSize, and the new size is
|
|
|
|
* smaller by a small constant.
|
|
|
|
*/
|
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
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(path, size);
|
1997-09-07 07:04:48 +02:00
|
|
|
path->npts = poly->npts;
|
|
|
|
path->closed = TRUE;
|
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston. We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.
Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary. In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc. Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix. In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.
Back-patch to all supported branches.
2011-04-27 19:58:36 +02:00
|
|
|
/* prevent instability in unused pad bytes */
|
|
|
|
path->dummy = 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++)
|
|
|
|
{
|
|
|
|
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))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type circle: \"%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))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type circle: \"%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
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type circle: \"%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')
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("invalid input syntax for type circle: \"%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
|
|
|
|
2002-11-08 18:37:52 +01:00
|
|
|
result = palloc(2 * P_MAXLEN + 6);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
2003-09-29 02:05:25 +02:00
|
|
|
errmsg("could not format \"circle\" value")));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
2003-09-29 02:05:25 +02:00
|
|
|
errmsg("could not format \"circle\" value")));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* circle_recv - converts external binary format to circle
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
circle_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
CIRCLE *circle;
|
|
|
|
|
|
|
|
circle = (CIRCLE *) palloc(sizeof(CIRCLE));
|
|
|
|
|
|
|
|
circle->center.x = pq_getmsgfloat8(buf);
|
|
|
|
circle->center.y = pq_getmsgfloat8(buf);
|
|
|
|
circle->radius = pq_getmsgfloat8(buf);
|
|
|
|
|
|
|
|
if (circle->radius < 0)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
|
2003-09-29 02:05:25 +02:00
|
|
|
errmsg("invalid radius in external \"circle\" value")));
|
2003-05-13 20:03:08 +02:00
|
|
|
|
|
|
|
PG_RETURN_CIRCLE_P(circle);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* circle_send - converts circle to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
circle_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, circle->center.x);
|
|
|
|
pq_sendfloat8(&buf, circle->center.y);
|
|
|
|
pq_sendfloat8(&buf, circle->radius);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* circle_overleft - is the right edge of circle1 at or left of
|
1997-09-07 07:04:48 +02:00
|
|
|
* 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);
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
PG_RETURN_BOOL(FPlt((circle1->center.x + circle1->radius),
|
2000-07-30 22:44:02 +02:00
|
|
|
(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);
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
PG_RETURN_BOOL(FPgt((circle1->center.x - circle1->radius),
|
2000-07-30 22:44:02 +02:00
|
|
|
(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
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* circle_overright - is the left edge of circle1 at or right of
|
1997-09-07 07:04:48 +02:00
|
|
|
* 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
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-07-01 21:19:05 +02:00
|
|
|
/* circle_below - is circle1 strictly 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);
|
|
|
|
|
2005-07-01 21:19:05 +02:00
|
|
|
PG_RETURN_BOOL(FPlt((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
|
|
|
}
|
|
|
|
|
2005-07-01 21:19:05 +02:00
|
|
|
/* circle_above - is circle1 strictly above circle2?
|
|
|
|
*/
|
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);
|
|
|
|
|
2005-07-01 21:19:05 +02:00
|
|
|
PG_RETURN_BOOL(FPgt((circle1->center.y - circle1->radius),
|
|
|
|
(circle2->center.y + circle2->radius)));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* circle_overbelow - is the upper edge of circle1 at or below
|
|
|
|
* the upper edge of circle2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
circle_overbelow(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
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)));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* circle_overabove - is the lower edge of circle1 at or above
|
|
|
|
* the lower edge of circle2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
circle_overabove(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
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,
|
2005-10-15 04:49:52 +02: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,
|
2005-10-15 04:49:52 +02: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
|
|
|
{
|
2002-11-08 19:32:47 +01:00
|
|
|
return M_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;
|
2002-08-30 01:05:44 +02:00
|
|
|
int base_size,
|
|
|
|
size;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
double angle;
|
2002-11-08 19:32:47 +01:00
|
|
|
double anglestep;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2003-07-27 06:53:12 +02:00
|
|
|
if (FPzero(circle->radius))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2005-10-15 04:49:52 +02:00
|
|
|
errmsg("cannot convert circle with radius zero to polygon")));
|
2003-07-27 06:53:12 +02:00
|
|
|
|
|
|
|
if (npts < 2)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("must request at least 2 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
|
|
|
|
2002-08-30 01:05:44 +02:00
|
|
|
base_size = sizeof(poly->p[0]) * npts;
|
2002-09-04 22:31:48 +02:00
|
|
|
size = offsetof(POLYGON, p[0]) +base_size;
|
2002-08-30 01:05:44 +02:00
|
|
|
|
|
|
|
/* Check for integer overflow */
|
|
|
|
if (base_size / npts != sizeof(poly->p[0]) || size <= base_size)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
2002-08-30 01:05:44 +02:00
|
|
|
|
2002-11-13 01:39:48 +01:00
|
|
|
poly = (POLYGON *) palloc0(size); /* zero any holes */
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
1997-09-07 07:04:48 +02:00
|
|
|
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
|
|
|
|
2002-11-08 19:32:47 +01:00
|
|
|
anglestep = (2.0 * M_PI) / npts;
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
2002-11-08 19:32:47 +01:00
|
|
|
angle = i * anglestep;
|
1997-09-07 07:04:48 +02:00
|
|
|
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
|
|
|
|
2014-02-24 18:24:00 +01:00
|
|
|
if (poly->npts < 1)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("cannot convert empty 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
|
|
|
|
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
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
2006-06-26 14:32:42 +02:00
|
|
|
/*
|
2007-03-06 00:29:14 +01:00
|
|
|
* Test to see if the point is inside the polygon, returns 1/0, or 2 if
|
|
|
|
* the point is on the polygon.
|
|
|
|
* Code adapted but not copied from integer-based routines in WN: A
|
|
|
|
* Server for the HTTP
|
2006-06-26 14:32:42 +02:00
|
|
|
* version 1.15.1, file wn/image.c
|
|
|
|
* http://hopf.math.northwestern.edu/index.html
|
|
|
|
* Description of algorithm: http://www.linuxjournal.com/article/2197
|
2007-03-06 00:29:14 +01:00
|
|
|
* http://www.linuxjournal.com/article/2029
|
2006-06-26 14:32:42 +02:00
|
|
|
*/
|
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
#define POINT_ON_POLYGON INT_MAX
|
1997-07-29 18:08:18 +02:00
|
|
|
|
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;
|
2007-03-06 00:29:14 +01:00
|
|
|
double prev_x,
|
|
|
|
prev_y;
|
|
|
|
int i = 0;
|
1997-09-08 04:41:22 +02:00
|
|
|
double x,
|
|
|
|
y;
|
2007-11-15 22:14:46 +01:00
|
|
|
int cross,
|
|
|
|
total_cross = 0;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (npts <= 0)
|
|
|
|
return 0;
|
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute first polygon point relative to single point */
|
1997-09-07 07:04:48 +02:00
|
|
|
x0 = plist[0].x - p->x;
|
|
|
|
y0 = plist[0].y - p->y;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
prev_x = x0;
|
|
|
|
prev_y = y0;
|
|
|
|
/* loop over polygon points and aggregate total_cross */
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 1; i < npts; i++)
|
|
|
|
{
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute next polygon point relative to single point */
|
1997-09-07 07:04:48 +02:00
|
|
|
x = plist[i].x - p->x;
|
|
|
|
y = plist[i].y - p->y;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute previous to current point crossing */
|
|
|
|
if ((cross = lseg_crossing(x, y, prev_x, prev_y)) == POINT_ON_POLYGON)
|
1997-09-07 07:04:48 +02:00
|
|
|
return 2;
|
2007-03-06 00:29:14 +01:00
|
|
|
total_cross += cross;
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
prev_x = x;
|
|
|
|
prev_y = y;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2007-03-06 00:29:14 +01:00
|
|
|
|
|
|
|
/* now do the first point */
|
|
|
|
if ((cross = lseg_crossing(x0, y0, prev_x, prev_y)) == POINT_ON_POLYGON)
|
1997-09-07 07:04:48 +02:00
|
|
|
return 2;
|
2007-03-06 00:29:14 +01:00
|
|
|
total_cross += cross;
|
|
|
|
|
|
|
|
if (total_cross != 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
return 1;
|
|
|
|
return 0;
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* lseg_crossing()
|
2007-03-06 00:29:14 +01:00
|
|
|
* Returns +/-2 if line segment crosses the positive X-axis in a +/- direction.
|
|
|
|
* Returns +/-1 if one point is on the positive X-axis.
|
|
|
|
* Returns 0 if both points are on the positive X-axis, or there is no crossing.
|
|
|
|
* Returns POINT_ON_POLYGON if the segment contains (0,0).
|
|
|
|
* Wow, that is one confusing API, but it is used above, and when summed,
|
|
|
|
* can tell is if a point is in a polygon.
|
1997-07-29 18:08:18 +02:00
|
|
|
*/
|
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
static int
|
2007-03-06 00:29:14 +01:00
|
|
|
lseg_crossing(double x, double y, double prev_x, double prev_y)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double z;
|
2007-03-06 00:29:14 +01:00
|
|
|
int y_sign;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPzero(y))
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* y == 0, on X axis */
|
|
|
|
if (FPzero(x)) /* (x,y) is (0,0)? */
|
2007-03-06 00:29:14 +01:00
|
|
|
return POINT_ON_POLYGON;
|
1997-09-07 07:04:48 +02:00
|
|
|
else if (FPgt(x, 0))
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* x > 0 */
|
|
|
|
if (FPzero(prev_y)) /* y and prev_y are zero */
|
2007-03-06 00:29:14 +01:00
|
|
|
/* prev_x > 0? */
|
|
|
|
return FPgt(prev_x, 0) ? 0 : POINT_ON_POLYGON;
|
|
|
|
return FPlt(prev_y, 0) ? 1 : -1;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* x < 0, x not on positive X axis */
|
2007-03-06 00:29:14 +01:00
|
|
|
if (FPzero(prev_y))
|
|
|
|
/* prev_x < 0? */
|
|
|
|
return FPlt(prev_x, 0) ? 0 : POINT_ON_POLYGON;
|
1998-09-01 05:29:17 +02:00
|
|
|
return 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* y != 0 */
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute y crossing direction from previous point */
|
|
|
|
y_sign = FPgt(y, 0) ? 1 : -1;
|
|
|
|
|
|
|
|
if (FPzero(prev_y))
|
|
|
|
/* previous point was on X axis, so new point is either off or on */
|
|
|
|
return FPlt(prev_x, 0) ? 0 : y_sign;
|
|
|
|
else if (FPgt(y_sign * prev_y, 0))
|
|
|
|
/* both above or below X axis */
|
2007-11-15 22:14:46 +01:00
|
|
|
return 0; /* same sign */
|
2007-03-06 00:29:14 +01:00
|
|
|
else
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* y and prev_y cross X-axis */
|
2007-03-06 00:29:14 +01:00
|
|
|
if (FPge(x, 0) && FPgt(prev_x, 0))
|
|
|
|
/* both non-negative so cross positive X-axis */
|
|
|
|
return 2 * y_sign;
|
|
|
|
if (FPlt(x, 0) && FPle(prev_x, 0))
|
|
|
|
/* both non-positive so do not cross positive X-axis */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* x and y cross axises, see URL above point_inside() */
|
|
|
|
z = (x - prev_x) * y - (y - prev_y) * x;
|
|
|
|
if (FPzero(z))
|
|
|
|
return POINT_ON_POLYGON;
|
|
|
|
return FPgt((y_sign * z), 0) ? 0 : 2 * y_sign;
|
|
|
|
}
|
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
|
|
|
}
|
2010-08-03 23:21:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
* Determine the hypotenuse.
|
|
|
|
*
|
|
|
|
* If required, x and y are swapped to make x the larger number. The
|
|
|
|
* traditional formula of x^2+y^2 is rearranged to factor x outside the
|
|
|
|
* sqrt. This allows computation of the hypotenuse for significantly
|
|
|
|
* larger values, and with a higher precision than when using the naive
|
|
|
|
* formula. In particular, this cannot overflow unless the final result
|
|
|
|
* would be out-of-range.
|
|
|
|
*
|
|
|
|
* sqrt( x^2 + y^2 ) = sqrt( x^2( 1 + y^2/x^2) )
|
|
|
|
* = x * sqrt( 1 + y^2/x^2 )
|
|
|
|
* = x * sqrt( 1 + y/x * y/x )
|
|
|
|
*
|
|
|
|
* It is expected that this routine will eventually be replaced with the
|
|
|
|
* C99 hypot() function.
|
|
|
|
*
|
|
|
|
* This implementation conforms to IEEE Std 1003.1 and GLIBC, in that the
|
|
|
|
* case of hypot(inf,nan) results in INF, and not NAN.
|
|
|
|
*-----------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
double
|
|
|
|
pg_hypot(double x, double y)
|
|
|
|
{
|
|
|
|
double yx;
|
|
|
|
|
|
|
|
/* Handle INF and NaN properly */
|
|
|
|
if (isinf(x) || isinf(y))
|
|
|
|
return get_float8_infinity();
|
|
|
|
|
|
|
|
if (isnan(x) || isnan(y))
|
|
|
|
return get_float8_nan();
|
|
|
|
|
|
|
|
/* Else, drop any minus signs */
|
|
|
|
x = fabs(x);
|
|
|
|
y = fabs(y);
|
|
|
|
|
|
|
|
/* Swap x and y if needed to make x the larger one */
|
|
|
|
if (x < y)
|
|
|
|
{
|
|
|
|
double temp = x;
|
|
|
|
|
|
|
|
x = y;
|
|
|
|
y = temp;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If y is zero, the hypotenuse is x. This test saves a few cycles in
|
|
|
|
* such cases, but more importantly it also protects against
|
|
|
|
* divide-by-zero errors, since now x >= y.
|
|
|
|
*/
|
|
|
|
if (y == 0.0)
|
|
|
|
return x;
|
|
|
|
|
|
|
|
/* Determine the hypotenuse */
|
|
|
|
yx = y / x;
|
|
|
|
return x * sqrt(1.0 + (yx * yx));
|
|
|
|
}
|