> 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
