Thread: BUG #4551: Implementation of the "line" type..

BUG #4551: Implementation of the "line" type..

From
"Barry Sanford"
Date:
The following bug has been logged online:

Bug reference:      4551
Logged by:          Barry Sanford
Email address:      barry.sanford@trimjoist.com
PostgreSQL version: 8.3
Operating system:   OS X
Description:        Implementation of the "line" type..
Details:

My company does structural analysis of architectural elements.  We are
presently investigating the rewriting of our internal software to store its
data in a database in lieu of the the current file document system.  In
looking at PostgreSQL, I noticed that you have various geometric data types
as standard.  However, I was somewhat surprised that you are attempting to
implement the 'line' type via a two point scheme.  While this is okay for
line segments, it totally sucks for infinite lines in a plane or space.  For
2D lines, you need to simply provide a type with 3 numbers.  These 3 numbers
are to a line, what the 2 numbers (X & Y) are to a point.  Any 2D line can
be expressed in standard form:

Ax + By = C

The three values A, B, & C, identify a unique line in the same way as X & Y
identify a unique point.  Also, just as 3D point is expressed as (X,Y,Z), a
3D line can be expressed in terms of (A,B,C,D) where:

Ax + By + Cz = D

In our software we have infinite lines that are defined as:

- Horizontal thru a point
- Vertical thru a point
- Through a point at a give angle (+/- PI/2)
- Through a point parallel to another line
- Through a point perpendicular to another line
- Offset a certain distance from another line
- Through two points

In all these cases, the resultant line is easily expressed (in 5 lines of
code or less) in the form (A,B,C) for not only graphic output, but for
additional calculations, such as section areas, polygon edges,
intersections, etc.

PLEASE DO NOT IMPLEMENT AN INFINITE AS (X1,Y1) (X2,Y2)!!!  Such an storage
scheme would involve always converting a line definition to two points
before storage, and an opposite conversion after reading - totally
inefficient and ineffective. Even if you did, what if the two points were
coincident??  The only invalid case for the (A,B,C) notation of an infinite
line would be the case where all three were 0.  That is, at least one of the
constants (A, B, or C) must be non-zero.

Thanks,
Barry Sanford

Re: BUG #4551: Implementation of the "line" type..

From
Peter Eisentraut
Date:
On Friday 28 November 2008 15:31:51 Barry Sanford wrote:
> looking at PostgreSQL, I noticed that you have various geometric data types
> as standard.  However, I was somewhat surprised that you are attempting to
> implement the 'line' type via a two point scheme.  While this is okay for
> line segments, it totally sucks for infinite lines in a plane or space.

Well, it's the way Euclid defined it.  (Yes, PostgreSQL is really
old ... ;-) )

No really, the built-in geometry types are considered kind of legacy.  If you
want to deal with something more modern, you may want to look into PostGIS.

Re: BUG #4551: Implementation of the "line" type..

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> No really, the built-in geometry types are considered kind of legacy.  If you
> want to deal with something more modern, you may want to look into PostGIS.

Or, if you want to fix them, feel free to submit a patch.  But there is
no one among the current group of developers who seems to have any
interest in re-implementing those types.

            regards, tom lane

Re: BUG #4551: Implementation of the "line" type..

From
John R Pierce
Date:
Peter Eisentraut wrote:
> No really, the built-in geometry types are considered kind of legacy.



Indeed, I was reviewing the postgres 'history' on the website the other
day, and noted that stuff was put in Postgres *BEFORE* it was SQL.