Received: from myst.fourpalms.org (golem.fourpalms.org [64.3.68.148])
	by postgresql.org (Postfix) with ESMTP id 3A834474E71
	for <pgsql-hackers@postgresql.org>;
	Tue, 16 Jul 2002 06:59:46 -0400 (EDT)
Received: from fourpalms.org (localhost.localdomain [127.0.0.1])
	by myst.fourpalms.org (Postfix) with ESMTP
	id B17D226C976; Mon, 15 Jul 2002 23:10:34 -0700 (PDT)
Message-ID: <3D33B8D5.D8A2E1CE@fourpalms.org>
Date: Mon, 15 Jul 2002 23:10:29 -0700
From: Thomas Lockhart <lockhart@fourpalms.org>
Organization: PostgreSQL Inc.
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.8-34.1mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tim Hart <tjhart@mac.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] line datatype
References: <200207160333.g6G3Xnc22777@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Archive-Number: 200207/634
X-Sequence-Number: 25008

> It would be nice to get the line type working 100%.  Thomas says the
> problem is input/output format.  I don't completely understand.

The issue is in choosing an external format for LINE which does not lose
precision during dump/reload. Internally, LINE is described by a formula
which is likely subject to problems with limited precision for some line
orientations.

Does anyone have a suggestion (perhaps drawn from another GIS package)
for representing lines? We already have this implemented internally, and
the algorithms are used to support other data types; the only unresolved
issue is in how to input the values.

                   - Thomas