Thread: 4D Geometry
Please excuse any stupidity, as although I've used postgres for quite some time, this is my first foray into developingfor it. I'm working on converting the geometry stuff in adt to support 4 dimensions. For my own use, I plan onpatching 8.0.3 with the files I edited in the 8.1beta source, right away. I really ownly need the ability to store 4D (Ido all the geometry functions outside of the db), so for the public, I'd really rather do this properly and completely.Since, optimistically, this won't see the light of day until 8.1.X/8.2, there's plenty of time to discuss/debatethings. Any and all questions/comments/criticisms are welcomed and encouraged. Here are my questions. <br /><br/> 1.) Is anyone else currently working on this?<br /><br /> 2.) 75% of the changes were trivial and most of the remaining25% are complications due to the way "line" is implemented. Particularly, the fact that it uses the 2D specificAx + By + C = 0, and not a vector style storage. Obviously, I would have to change the line functions in geo_ops.c,and its spec in pg_type.h, but I've noticed that it only seems to be used internally, so other than those, I can'tsee any other changes that would be necessary. Can anyone, more familiar with the source, think of any good reasonsthat would make them leery of me changing the structure to reflect the parametric form, to say Point *A, Point *B,double p. [Normally, the parameter would be "t", but I call the 4th coordinate "t", so I figured "p" would be a littleless confusing. Also A & B should be a vectors, but I'll get to that in a later question.]<br /><br /> 3.) As itstands now, I added support for the extra dimensions to pair_encode, pair_decode, and pair_count. Do you think that itwould be better to:<br /> a.) leave the original signatures, and use those routines to work with the old style (x,y)coordinates, and setting (z,t) to (0,0), when necessary.<br /> b.) create a new set of functions called quad_encode,quad_decode, and quad_count to work with the new (x,y,z,t) coordinates, and use them in the code. I'm more thinkingof outside stuff, (i.e. libpqxx, etc), that might use/depend on those signatures. I'm not sure if anything does,that's why I'm asking. Also, I'm trying to look ahead for when people that already use the geo types go to upgrade.<br /><br /> 4.) If changing the signatures for these routines presents problems, will the fact that I changed othersignatures to support the additional coordinates, also present any problems?<br /><br /> 5.) As it stands now, I'm justusing the Point structure to denote vectors in component form, and LSEG for stpt-endpt form. Does anyone see any reasonI shouldn't do this. I realize that having a separate VECTOR structure would probably be more readable, and probablymore useful, but it would more than likely be more work initially.<br /><br /> 6.) Are there any objections to breakingup geo_ops.c into separate sources?<br /><br /> 7.) Can anyone think of any issues that I'm missing? <br /><br /><br/><table cellpadding="0" cellspacing="0" width="100%"><tr><td> Chris<br /><br /> --<br /> Sometimes I wonder whetherthe world is being run by smart people who are putting us on or by imbeciles who really mean it. -- Mark Twain </td></tr></table>
On Sun, 2005-09-04 at 21:45 -0700, Paul Ramsey wrote: <blockquote type="CITE"><pre> <font color="#000000">Chris,</font> <font color="#000000">PostGIS already has 4d geometry, though few functions that work with </font> <font color="#000000">that fourth dimension (how far is 8am, in Paris from 4pm in </font> <font color="#000000">London?). Have you checked if there is some room to meet your needs </font> <font color="#000000">with some PostGIS enhancements?</font> </pre></blockquote><br /> I haven't checked it out, but definitely will. However, from your brief description, it appearsthat it uses clock time. If so, that won't meet my needs, as I'm more interested in ordinal time (t=0, t=1, etc).Also, part of the reason for my interest is that my application may need to deal with >4D in the future (if all goeswell), and as we all know, 2D is cute, and fairly straightforward, but it rests upon some assumptions/shortcuts thatjust don't hold, when you start moving to more complex analysis.<br /><br /><blockquote type="CITE"><pre> <font color="#000000">Paul</font> <font color="#000000">On 4-Sep-05, at 6:55 PM, Chris Traylor wrote:</font> <font color="#000000">> Please excuse any stupidity, as although I've used postgres for </font> <font color="#000000">> quite some time, this is my first foray into developing for it. I'm </font> <font color="#000000">> working on converting the geometry stuff in adt to support 4 </font> <font color="#000000">> dimensions. For my own use, I plan on patching 8.0.3 with the files </font> <font color="#000000">> I edited in the 8.1beta source, right away. I really ownly need the </font> <font color="#000000">> ability to store 4D (I do all the geometry functions outside of the </font> <font color="#000000">> db), so for the public, I'd really rather do this properly and </font> <font color="#000000">> completely. Since, optimistically, this won't see the light of day </font> <font color="#000000">> until 8.1.X/8.2, there's plenty of time to discuss/debate things. </font> <font color="#000000">> Any and all questions/comments/criticisms are welcomed and </font> <font color="#000000">> encouraged. Here are my questions.</font> <font color="#000000">></font> <font color="#000000">> 1.) Is anyone else currently working on this?</font> <font color="#000000">></font> <font color="#000000">> 2.) 75% of the changes were trivial and most of the remaining 25% </font> <font color="#000000">> are complications due to the way "line" is implemented. </font> <font color="#000000">> Particularly, the fact that it uses the 2D specific Ax + By + C = </font> <font color="#000000">> 0, and not a vector style storage. Obviously, I would have to </font> <font color="#000000">> change the line functions in geo_ops.c, and its spec in pg_type.h, </font> <font color="#000000">> but I've noticed that it only seems to be used internally, so other </font> <font color="#000000">> than those, I can't see any other changes that would be necessary. </font> <font color="#000000">> Can anyone, more familiar with the source, think of any good </font> <font color="#000000">> reasons that would make them leery of me changing the structure to </font> <font color="#000000">> reflect the parametric form, to say Point *A, Point *B, double p. </font> <font color="#000000">> [Normally, the parameter would be "t", but I call the 4th </font> <font color="#000000">> coordinate "t", so I figured "p" would be a little less confusing. </font> <font color="#000000">> Also A & B should be a vectors, but I'll get to that in a later </font> <font color="#000000">> question.]</font> <font color="#000000">></font> <font color="#000000">> 3.) As it stands now, I added support for the extra dimensions to </font> <font color="#000000">> pair_encode, pair_decode, and pair_count. Do you think that it </font> <font color="#000000">> would be better to:</font> <font color="#000000">> a.) leave the original signatures, and use those routines to </font> <font color="#000000">> work with the old style (x,y) coordinates, and setting (z,t) to </font> <font color="#000000">> (0,0), when necessary.</font> <font color="#000000">> b.) create a new set of functions called quad_encode, </font> <font color="#000000">> quad_decode, and quad_count to work with the new (x,y,z,t) </font> <font color="#000000">> coordinates, and use them in the code. I'm more thinking of outside </font> <font color="#000000">> stuff, (i.e. libpqxx, etc), that might use/depend on those </font> <font color="#000000">> signatures. I'm not sure if anything does, that's why I'm asking. </font> <font color="#000000">> Also, I'm trying to look ahead for when people that already use the </font> <font color="#000000">> geo types go to upgrade.</font> <font color="#000000">></font> <font color="#000000">> 4.) If changing the signatures for these routines presents </font> <font color="#000000">> problems, will the fact that I changed other signatures to support </font> <font color="#000000">> the additional coordinates, also present any problems?</font> <font color="#000000">></font> <font color="#000000">> 5.) As it stands now, I'm just using the Point structure to denote </font> <font color="#000000">> vectors in component form, and LSEG for stpt-endpt form. Does </font> <font color="#000000">> anyone see any reason I shouldn't do this. I realize that having a </font> <font color="#000000">> separate VECTOR structure would probably be more readable, and </font> <font color="#000000">> probably more useful, but it would more than likely be more work </font> <font color="#000000">> initially.</font> <font color="#000000">></font> <font color="#000000">> 6.) Are there any objections to breaking up geo_ops.c into separate </font> <font color="#000000">> sources?</font> <font color="#000000">></font> <font color="#000000">> 7.) Can anyone think of any issues that I'm missing?</font> <font color="#000000">></font> <font color="#000000">></font> <font color="#000000">> Chris</font> <font color="#000000">></font> <font color="#000000">> --</font> <font color="#000000">> Sometimes I wonder whether the world is being run by smart people </font> <font color="#000000">> who are putting us on or by imbeciles who really mean it. -- Mark </font> <font color="#000000">> Twain</font> </pre></blockquote><table cellpadding="0" cellspacing="0" width="100%"><tr><td> Chris<br /><br /> --<br /> Sometimes I wonderwhether the world is being run by smart people who are putting us on or by imbeciles who really mean it. -- Mark Twain</td></tr></table>
Chris Traylor <ctraylor@phalanyx.com> writes:
> 1.) Is anyone else currently working on this?
No, and AFAIR no one has ever even asked for it. I'm a little dubious
about doubling the storage requirements for geometry data and likely
creating backwards-compatibility issues to implement a feature that only
you need. I'd suggest keeping these as separate private types rather
than expecting that a patch to replace the 2D types will be accepted.
regards, tom lane
On Mon, 2005-09-05 at 15:27 -0400, Tom Lane wrote: <blockquote type="CITE"><pre> <font color="#000000">Chris Traylor <<a href="mailto:ctraylor@phalanyx.com">ctraylor@phalanyx.com</a>> writes:</font> <font color="#000000">> 1.) Is anyone else currently working on this?</font> <font color="#000000">No, and AFAIR no one has ever even asked for it. I'm a little dubious</font> <font color="#000000">about doubling the storage requirements for geometry data and likely</font> <font color="#000000">creating backwards-compatibility issues to implement a feature that only</font> <font color="#000000">you need. I'd suggest keeping these as separate private types rather</font> <font color="#000000">than expecting that a patch to replace the 2D types will be accepted.</font> </pre></blockquote><br /> What do you think about making it a configure option, i.e. --enable-4D-geometry (default false)?This way people who don't want/need the extra overhead don't have to deal with it, and those who want to use postgresfor scientific/engineering/animation/etc apps (where 2D doesn't quite cut the mustard) can have it available to them.I was thinking that it would allow a whole new set of applications to take advantage of the fact that postgres providesnative geometric types. After all, you can use just about any db engine to handle geometric data with traditionalsql and stored procedures. The point of the builtins is so you have a standard set of algorithms, and that youdon't have to constantly reinvent the wheel. Like I said in my earlier message, I can patch the source for myself, andgo about my merry way. The geometry portions really don't seem to change very frequently (the differences between 8.0.3,and 8.1beta were minimal), and except for the line stuff, the changes were trivial, so personal maintenance shouldn'tbe a problem. I just thought I'd share my work.:-)<br /><br /><blockquote type="CITE"><pre> <font color="#000000"> regards, tom lane</font> <font color="#000000">---------------------------(end of broadcast)---------------------------</font> <font color="#000000">TIP 4: Have you searched our list archives?</font> <font color="#000000"> <a href="http://archives.postgresql.org">http://archives.</a></font>postgresql.org </pre></blockquote><table cellpadding="0" cellspacing="0" width="100%"><tr><td> Chris<br /><br /> --<br /> Sometimes I wonderwhether the world is being run by smart people who are putting us on or by imbeciles who really mean it. -- Mark Twain</td></tr></table>
Chris Traylor <ctraylor@phalanyx.com> writes:
> On Mon, 2005-09-05 at 15:27 -0400, Tom Lane wrote:
>> I'd suggest keeping these as separate private types rather
>> than expecting that a patch to replace the 2D types will be accepted.
> What do you think about making it a configure option, i.e.
> --enable-4D-geometry (default false)?
Configure options are generally a pain in the neck, particularly if they
cause significant changes in user-visible behavior. What's wrong with
creating separate types instead of changing the behavior of the existing
ones?
regards, tom lane
On Mon, 2005-09-05 at 20:40 -0400, Tom Lane wrote: <blockquote type="CITE"><pre> <font color="#000000">Chris Traylor <<a href="mailto:ctraylor@phalanyx.com">ctraylor@phalanyx.com</a>> writes:</font> <font color="#000000">> On Mon, 2005-09-05 at 15:27 -0400, Tom Lane wrote:</font> <font color="#000000">>> I'd suggest keeping these as separate private types rather</font> <font color="#000000">>> than expecting that a patch to replace the 2D types will be accepted.</font> <font color="#000000">> What do you think about making it a configure option, i.e.</font> <font color="#000000">> --enable-4D-geometry (default false)?</font> <font color="#000000">Configure options are generally a pain in the neck,</font> </pre></blockquote> Granted. Especially, if all the ifdefs start making the source hard to read, but they are a viable compile-timeway to allow the user to make the decision for themselves.<br /><br /><blockquote type="CITE"><pre> <font color="#000000"> particularly if they</font> <font color="#000000">cause significant changes in user-visible behavior.</font> <font color="#000000"> What's wrong with</font> <font color="#000000">creating separate types instead of changing the behavior of the existing</font> <font color="#000000">ones?</font> </pre></blockquote> I'd really rather not write a mirror version of every geometric function, in order to use a private type.<br/><br /><blockquote type="CITE"><pre> <font color="#000000"> regards, tom lane</font> <font color="#000000">---------------------------(end of broadcast)---------------------------</font> <font color="#000000">TIP 6: explain analyze is your friend</font> </pre></blockquote><table cellpadding="0" cellspacing="0" width="100%"><tr><td> Chris<br /><br /> --<br /> Sometimes I wonderwhether the world is being run by smart people who are putting us on or by imbeciles who really mean it. -- Mark Twain</td></tr></table>
Chris Traylor wrote: > > Configure options are generally a pain in the neck, > > Granted. Especially, if all the ifdefs start making the source hard > to read, but they are a viable compile-time way to allow the user to > make the decision for themselves. This missing piece of information here is that 98.6% of our users never compile the source code, so that decision will have to be made by the packager who will always use the option that is acceptable to the plurality of the users. That is why we have removed most feature-related compile-time choices and are very hesitant to add new ones. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Chris Traylor wrote: > >>>Configure options are generally a pain in the neck, >> >>Granted. Especially, if all the ifdefs start making the source hard >>to read, but they are a viable compile-time way to allow the user to >>make the decision for themselves. > > > This missing piece of information here is that 98.6% of our users never > compile the source code, so that decision will have to be made by the > packager who will always use the option that is acceptable to the > plurality of the users. That is why we have removed most > feature-related compile-time choices and are very hesitant to add new > ones. The other point to be made is that every such compile-time option bifurcates the postgres universe into two mutually-incompatible sections. The postgres community has enough of a challenge supporting the one version of the database - there's no point in making things harder. Tim -- ----------------------------------------------- Tim Allen tim@proximity.com.au Proximity Pty Ltd http://www.proximity.com.au/