From: Sunburned Surveyor <[EMAIL PROTECTED]>
I must say that Chris took an interesting approach to the
design of
JTin, and one that was a lot different from the approach I
would have
taken. However, I think Chris' design will be much
quicker and more
memory efficient. His professional programming background
is evident
in the work. I tend to get lazy when I program, creating
objects for
every little thing. JTin looks like it was written by a C
programmer.
All the data structures are concise and fairly low-level.
Concise, quick, and memory efficient are what I was aiming for.
Also note that in order to get running code quickly, I’m adding functionality
to the ImmutableTin and TinFace classes as I need them. For instance, one of
these days, I’m going to add Iterator functionality to
TriangularIrregularNetwork in order to access TinFaces, but I haven’t needed it
yet.
Here are some of my questions and comments for Chris:
- I like that the TinFace objects, braklines, and
boundaries in
ImmutableTin points to a common Coordinate array to
eliminated
duplicated Coordinate references.
Did you think about using a CoordinateSequence instead of
a Coordinate array?
I thought about CoordinateSequence, but all I really needed was a private array of
Coordinates, so I went the KISS route. Also from the code I was reading, it looked
like JTS & JUMP was moving away from CoordinateSequences. It should be simple
to change it if it would help things.
- Why did we choose STRtree and not QuadTree for the
spatial index? I
know very little about both classes, and STRtree may indeed
be the
better choice. Maybe Martin Davis will
take a few minutes to educate me.
It’s faster and I don’t need QuadTree’s ability to change nodes given the
class’s immutable goal.
- Is the int in the first element of the int[][] triTable
argument for
the ImmutableTin class constructor the identifier of the
Tin Face,
while the in in the
second element is the ID of the vertex?
The TriTable is an array of six ints, each int is an index value to a point
array. The first three ints are indexes to the point array and denote the
vertexes of the triangle. The second three ints are indexes to the face array
and denote neighbors to the given TIN.
Also note that there could be other constructors made. I wrote this one with
the .jtf file in mind. As long as all the internal datastructors (faces,
breaklines, borders, etc) are written out from data given to the constructor,
it can still be an immutable TIN class.
- I'm not sure about storing the nieghbor TinFaces in
the actual
TinFace object. I almost wonder if having a separate class
to manage
TIN topology would be better.
For example, how do you set references to a TinFace
object's
neighbors when creating the first TinFace in an
ImmutableTin? I guess
you could go back and set the
neighbors for each TinFace after the TIN was constructed,
but it
looks like your only constructor for this class requires
int arguments
identifying the neighbors.
You probably have good reason for this design, I just
didn't pick up on it.
I’m thinking much of the analysis functions (hydrology, viewsheds, contour bands, etc) will be traversing the TIN at the face level. In other words given a TinFace, an algorithm will compute something using the TinFace’s data, then will decide what if any neighbors it should go to next in order to continue the computation.
- Let's get that JTF format documented in JTFLayout
class into an
external document, prefereably PDF or HTML. We can then
introduce the
rest of the FOSS GIS community to the format. This will
encourage
broad adoption of the format.
Check out jtin/doc/JTF_file_description.odt. There’s still a couple of updates
I want to finalize before I let it into the wild. First is how to deal with
triangles at a border or TIN edge and what is entered for their edge neighbor
field. One way (what I’m doing now) is to just set the index to -1 thus being
an illegal index, thus being next to a border. The other way is to link to a
neighboring triangle along the border that this triangle shares a vertex with.
Some algorithms I’ve read about make heavy use of such links. Also (if I
haven’t done it already), I need to add a disclaimer that all data is stored
big endian.
--Christopher
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
