Skip site navigation (1) Skip section navigation (2)

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

From: "Barry Sanford" <barry(dot)sanford(at)trimjoist(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #4551: Implementation of the "line" type..
Date: 2008-11-28 13:31:51
Message-ID: 200811281331.mASDVpLC004003@wwwmaster.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-bugs
The following bug has been logged online:

Bug reference:      4551
Logged by:          Barry Sanford
Email address:      barry(dot)sanford(at)trimjoist(dot)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

Responses

pgsql-bugs by date

Next:From: Peter EisentrautDate: 2008-11-28 14:57:55
Subject: Re: BUG #4551: Implementation of the "line" type..
Previous:From: SushilDate: 2008-11-27 12:27:34
Subject: Re: executing SELECT xmlelement(name foo); causes "server closed the connection unexpectedly" Error

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group