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

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:

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.

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 postgres for 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 provides native geometric
types. After all, you can use just about any db engine to handle
geometric data with traditional sql and stored procedures. The point of
the builtins is so you have a standard set of algorithms, and that you
don't have to constantly reinvent the wheel. Like I said in my earlier
message, I can patch the source for myself, and go 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't
be a problem. I just thought I'd share my work.:-)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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 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:

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,

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.

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?

I'd really rather not write a mirror version of every geometric
function, in order to use a private type.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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 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/