Re: [HACKERS] [SQL] line datatype
On Tuesday 16 July 2002 04:42 pm, Thomas Lockhart wrote: > > On the other hand, if you want to enter two points why don't you just > > use lseg to begin with? There's not much justification for having a > > separate line type unless it behaves differently ... > They are different. One is infinite in length, the other is finite. > Distances, etc are calculated differently between the two types. For some of my work a type of 'ray' would be nice... :-) But LSEG's usually work OK as long as you specify an endpoint that is far enough away. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SQL] line datatype
> >> No one likes entering an equation. Two points seems the simplest. > > That it does. > On the other hand, if you want to enter two points why don't you just > use lseg to begin with? There's not much justification for having a > separate line type unless it behaves differently ... They are different. One is infinite in length, the other is finite. Distances, etc are calculated differently between the two types. - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [SQL] line datatype
Tom Lane wrote: > Thomas Lockhart <[EMAIL PROTECTED]> writes: > >> No one likes entering an equation. Two points seems the simplest. > > > That it does. > > On the other hand, if you want to enter two points why don't you just > use lseg to begin with? There's not much justification for having a > separate line type unless it behaves differently ... I assume the line type keeps going after the two end points, while lseg doesn't. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] line datatype
Thomas Lockhart <[EMAIL PROTECTED]> writes: >> No one likes entering an equation. Two points seems the simplest. > That it does. On the other hand, if you want to enter two points why don't you just use lseg to begin with? There's not much justification for having a separate line type unless it behaves differently ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] line datatype
Lamar Owen wrote: > On Tuesday 16 July 2002 11:29 am, Thomas Lockhart wrote: > > > > We do need a solution for exact dump/reload of floating-point data, > > > > but I don't see why the lack of it should be reason to disable access > > > > to the LINE type. > > > > I don't understand why dumping the two point values isn't sufficient. > > > Which two point values? LINE is handled as an equation, not as points, > > unlike the LSEG type which has two points. > > > One possibility is to have the external representation *be* the same as > > LSEG, then convert internally. Then we need to decide how to scale those > > points; maybe always using a unit vector is the right thing to do... > > Lines are entered now by specifying two points, anywhere on the line, right? > The internal representation is then slope-intercept? Why not allow either > the 'two-point' entry, or direct entry as slope-intercept? How do we > represent lines now in output? Do we pick two arbitrary points on the line? > If so, I can see Thomas' point here, where the original data entry might have > specified two relatively distant points -- but then there's a precision error > anyway converting to slope-intercept, if indeed that is the internal > representation. So why not dump in slope-intercept form, if that is the > internal representation? Yow, I can see the pain of having slope/intercept and trying to output two points. What if we store line internally as two points, and convert to slope/intercept when needed. That way, it would dump out just as it was entered. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [SQL] line datatype
On Tuesday 16 July 2002 11:29 am, Thomas Lockhart wrote: > > > We do need a solution for exact dump/reload of floating-point data, > > > but I don't see why the lack of it should be reason to disable access > > > to the LINE type. > > I don't understand why dumping the two point values isn't sufficient. > Which two point values? LINE is handled as an equation, not as points, > unlike the LSEG type which has two points. > One possibility is to have the external representation *be* the same as > LSEG, then convert internally. Then we need to decide how to scale those > points; maybe always using a unit vector is the right thing to do... Lines are entered now by specifying two points, anywhere on the line, right? The internal representation is then slope-intercept? Why not allow either the 'two-point' entry, or direct entry as slope-intercept? How do we represent lines now in output? Do we pick two arbitrary points on the line? If so, I can see Thomas' point here, where the original data entry might have specified two relatively distant points -- but then there's a precision error anyway converting to slope-intercept, if indeed that is the internal representation. So why not dump in slope-intercept form, if that is the internal representation? But, you're telling me floats aren't dumpable/restoreable to exactly the same value? () This can't be good. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [SQL] line datatype
... > Well, the \dT documentation used to show line as two points, so I > assumed that was how it was specified. Hmm. And it seems I entered it a few years ago ;) Cut and paste error. At that time the line type was defined but has never had the i/o routines enabled. > No one likes entering an equation. Two points seems the simplest. That it does. - Thomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [SQL] line datatype
Actually... as one with the vested interest... I'm not opposed to entering an equation in one of the basic algebraic forms. Given that line types and line segment types both exist, I'm happy to weigh the cost/benefit between choosing an lseg and entering 2 points, or choosing a line and entering the equation. Are there database functions to translate between a line and a line seg? If so, that would address my only reservation for restricting the line type to an equation. And - to address Tom's continuing concern over casting ;), I have no need for implicit casts in this case. If there are concerns about precision being lost in the translation - As long as what precision can be guaranteed is documented, I have no qualms. If I needed absolute precision I'd create my own line table with numerics, and write my own functions as necessary. The line type to me is there for speed and ease of use, not unlimited precision. On Tuesday, 16, 2002, at 09:38AM, Bruce Momjian <[EMAIL PROTECTED]> wrote: >No one likes entering an equation. Two points seems the simplest. > >-- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SQL] line datatype
Thomas Lockhart wrote: > ... > > > We do need a solution for exact dump/reload of floating-point data, > > > but I don't see why the lack of it should be reason to disable access > > > to the LINE type. > > I don't understand why dumping the two point values isn't sufficient. > > Which two point values? LINE is handled as an equation, not as points, > unlike the LSEG type which has two points. Well, the \dT documentation used to show line as two points, so I assumed that was how it was specified. > One possibility is to have the external representation *be* the same as > LSEG, then convert internally. Then we need to decide how to scale those > points; maybe always using a unit vector is the right thing to do... No one likes entering an equation. Two points seems the simplest. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [SQL] line datatype
... > > We do need a solution for exact dump/reload of floating-point data, > > but I don't see why the lack of it should be reason to disable access > > to the LINE type. > I don't understand why dumping the two point values isn't sufficient. Which two point values? LINE is handled as an equation, not as points, unlike the LSEG type which has two points. One possibility is to have the external representation *be* the same as LSEG, then convert internally. Then we need to decide how to scale those points; maybe always using a unit vector is the right thing to do... - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SQL] line datatype
Tom Lane wrote: > Thomas Lockhart <[EMAIL PROTECTED]> writes: > > The issue is in choosing an external format for LINE which does not lose > > precision during dump/reload. > > Why is this any worse for LINE than for any of the other geometric > types (or for plain floats, for that matter)? > > We do need a solution for exact dump/reload of floating-point data, > but I don't see why the lack of it should be reason to disable access > to the LINE type. I don't understand why dumping the two point values isn't sufficient. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SQL] line datatype
Thomas Lockhart <[EMAIL PROTECTED]> writes: > The issue is in choosing an external format for LINE which does not lose > precision during dump/reload. Why is this any worse for LINE than for any of the other geometric types (or for plain floats, for that matter)? We do need a solution for exact dump/reload of floating-point data, but I don't see why the lack of it should be reason to disable access to the LINE type. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [SQL] line datatype
> 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SQL] line datatype
OK, I have added comments to \dT and SGML docs to mention that 'line' is not implemented. This should help future folks. It would be nice to get the line type working 100%. Thomas says the problem is input/output format. I don't completely understand. --- Tim Hart wrote: > Probably the most succinct explanation would be to copy & paste from the > terminal... > > tjhart=> create table a_line( foo line ); > CREATE > tjhart=> insert into a_line ( foo ) values( '(0,0), (1,1)' ); > ERROR: line not yet implemented > tjhart=> select version(); > version > - > PostgreSQL 7.2.1 on powerpc-apple-darwin5.3, compiled by GCC 2.95.2 > (1 row) > > > The documentation (datatype-geometric.html) indicates both a 'line' type > and an 'lseg' type in the summary table at the top of the page. The same > code above using the type 'lseg' in place of 'line' works just fine. > > Why can I create a table with a column of type 'line' if I can't insert > into it? > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly