Enhancement: Preserving (and taking into account) 3D information in geometry transformations

[pcaillou]

Describe which enhancement/addition to GAMA you would like to see:

Geometry transformations in GAMA (like scaling, translation, buffering), as they are
based on the JTS code, do not take 3D information into account. As a result, a scaling
of a geometry will correctly change the XY dimensions, but not the Z one. Same for
translation. 

I've tried to find a 3D AffineTransform class that would work with JTS geometries,
but I could not find any. Neither GeoLatte nor GeoTools provide such classes (or I
did not search correctly).

Please comment if you have information about this enhancement. 

Original issue reported on code.google.com by alexis.drogoul on 2014-01-01 04:23:56

[pcaillou]

Just for information, Repast Symphony uses the NASA worldwind lib for 3D management
(http://worldwind.arc.nasa.gov/java/), but I have no idea of what is possible to do
with these tools.

Original issue reported on code.google.com by patrick.taillandier on 2014-01-01 14:00:32

[pcaillou]

I had also taken a quick look at this library, but it seems to be merely oriented towards
visualization. There is, however, a chance that I adapt Java3D Transform3D class to
JTS. It does not seem to complicated at first glance.

Original issue reported on code.google.com by alexis.drogoul on 2014-01-01 14:09:20

[pcaillou]

I have implemented AffineTransform3D to handle scaling and rotations (only around the
Z axis for the moment, as GAML does not yet provide a way to express other rotations,
but it would easy by defining an operator that would take either a point or three angles),
and made sure that GamaPoint were now used all over the code to represent the coordinates
of JTS geometries (no more "NaN" z ordinates !). Translation is also implemented correctly
in the three dimensions. All the other JTS operations (like buffering) are a bit more
tricky to implement, as they involve code buried inside JTS (and quite impossible to
specialize). However, they *might* work with 3D coordinates if they do not make assumptions
about dealing with 2D ones. I will test them one by one to be sure...

Original issue reported on code.google.com by alexis.drogoul on 2014-01-02 18:25:33

[pcaillou]

In the current state of GAMA, where most of the geometrical transformations are supported
by JTS, it is almost impossible to do more than what is done now (which mainly consists
in making sure that 3D information is not lost). I close this issue, then, but feel
free to open new ones on specific 3D features. 

Original issue reported on code.google.com by alexis.drogoul on 2014-01-05 17:40:36

[pcaillou]

Just to be sure when you say "I have implemented AffineTransform3D to handle scaling
and rotations" what does it means? Can you specify the syntax in GAML. 

In opengl there is not problem to translate, rotate and scale in any 3D direction but
only for the display. If we want to use it in the model it's a different question.

We could have(maybe it's already the case) something like

draw geometry scale:{x,y,z} rotate:{x,y,z,angle};

Original issue reported on code.google.com by agrignard on 2014-01-05 19:43:03

[pcaillou]

There is no syntax, yet, in GAML, to access scaling and rotation in 3D. Rotation (shape
rotated_by xxx) only occurs around the z-axis, but correctly preserves the z ordinate
(it was not the case before). Scaling (shape scaled_by xxx, shape * xxx, shape scaled_to
{x, y, z}) applies to the three ordinates. The first ones by defining a coefficient,
the second by defining the desired 3D envelope to which the shape should fit.

I have added "shape scaled_by {x, y, z}" as it was quite simple to do (applies a possibly
different coefficient to all 3 axes), but I am wondering how to define rotated_by.
Maybe "rotated_by {ax, ay, az}" would be the best and more coherent way to define it,
where ax, ay and az represent the angles around the three axes (i.e., ax = angle for
the rotation in the yz plan, ay = angle for the xz plan, az = angle for the xy plan).
Tell me if it is the case and I will implement it. 

Just as a side note: my goal, right now, is to slowly, but surely, remove or deprecate
the overuse of facets in statement like draw: , and use operators instead (e.g. instead
of "draw shape rotate: xxx at: yyy scale: zzz", use draw ((shape rotated_by xxx) translated_to
yyy) scaled_by zzz)). The functional semantics of operators is, in my opinion, much
clearer — and more in phase with the rest of the language. 

Original issue reported on code.google.com by alexis.drogoul on 2014-01-06 01:01:09

[pcaillou]

Two possibility for the syntax of the rotation:

1. rotated_by {ax, ay, az}

but in opengl they use (and I guess there is a reason)

2. rotated_by{angle,x,y,z} 

angle: Specifies the angle of rotation, in degrees.
x,y,z: Specify the x, y, and z coordinates of a vector, respectively.

I think the first one in more intuitive but we can propose the both (for the opengl
user).

I agree also to remove step by step all the facet and replace them by operator if it's
more coherent with the rest of the language.

Original issue reported on code.google.com by agrignard on 2014-01-06 08:59:34