Re: 4D Geometry

On Sun, 2005-09-04 at 21:45 -0700, Paul Ramsey wrote:

> Chris,
>
> PostGIS already has 4d geometry, though few functions that work with
> that fourth dimension (how far is 8am, in Paris from 4pm in
> London?). Have you checked if there is some room to meet your needs
> with some PostGIS enhancements?

I haven't checked it out, but definitely will. However, from your brief
description, it appears that 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 goes well), and as we all know, 2D
is cute, and fairly straightforward, but it rests upon some
assumptions/shortcuts that just don't hold, when you start moving to
more complex analysis.

>
> Paul
>
> On 4-Sep-05, at 6:55 PM, Chris Traylor wrote:
>
> > Please excuse any stupidity, as although I've used postgres for
> > quite some time, this is my first foray into developing for it. I'm
> > working on converting the geometry stuff in adt to support 4
> > dimensions. For my own use, I plan on patching 8.0.3 with the files
> > I edited in the 8.1beta source, right away. I really ownly need the
> > ability to store 4D (I do 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/debate things.
> > Any and all questions/comments/criticisms are welcomed and
> > encouraged. Here are my questions.
> >
> > 1.) Is anyone else currently working on this?
> >
> > 2.) 75% of the changes were trivial and most of the remaining 25%
> > are complications due to the way "line" is implemented.
> > Particularly, the fact that it uses the 2D specific Ax + 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't see any other changes that would be necessary.
> > Can anyone, more familiar with the source, think of any good
> > reasons that 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 little less confusing.
> > Also A & B should be a vectors, but I'll get to that in a later
> > question.]
> >
> > 3.) As it stands now, I added support for the extra dimensions to
> > pair_encode, pair_decode, and pair_count. Do you think that it
> > would be better to:
> > 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.
> > 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 thinking of 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.
> >
> > 4.) If changing the signatures for these routines presents
> > problems, will the fact that I changed other signatures to support
> > the additional coordinates, also present any problems?
> >
> > 5.) As it stands now, I'm just using the Point structure to denote
> > vectors in component form, and LSEG for stpt-endpt form. Does
> > anyone see any reason I shouldn't do this. I realize that having a
> > separate VECTOR structure would probably be more readable, and
> > probably more useful, but it would more than likely be more work
> > initially.
> >
> > 6.) Are there any objections to breaking up geo_ops.c into separate
> > sources?
> >
> > 7.) Can anyone think of any issues that I'm missing?
> >
> >
> > Chris
> >
> > --
> > Sometimes I wonder whether the world is being run by smart people
> > who are putting us on or by imbeciles who really mean it. -- Mark
> > Twain

Chris

--
Sometimes I wonder whether the world is being run by smart people who
are putting us on or by imbeciles who really mean it. -- Mark Twain