Following is an interleaved reply...
--- Landon Blake <[EMAIL PROTECTED]> wrote:
Before I respond to your comments, let me ask you a
question:
Did you turn in your student application yet?
Yes I have.
You wrote: " I planning on first writing code that
can read, write
and display TIN files."
I would split this up similarly. I would say that we
need code to read
TIN files, write TIN files, create TIN files from
other data sources,
display TIN files, and produce data products from
TIN files. I'm
thinking we could encapsulate this in the following
package structure:
net.surveyos.sourceforge.jtin: Contains classes to
represent a TIN and
its elements. This would include objects like a TIN
face, a TIN face
edge, a TIN Breakline, TIN Boundaries, and a TIN
Point.
A TIN surface is simply a subcategory of
PolyhedralSurface.
Quoting the OpenGIS Simple Features spec:
"A PolyhedralSurface is a contiguous collection of
polygons, which share common boundary segments. For
each pair of polygons that "touch", the common
boundary shall be expressible as a finite collection
of LineStrings. Each such LineString shall be part of
the boundary of at most 2 Polygon patches. A TIN
(triangulated irregular network) is a
PolyhedralSurface consisting only of Triangle patches.
In order to incorporate breaklines and boundaries, I
think a TIN should be a Feature that contains a
PolyhedralSurface as its main element with the
breaklines and boundaries as LineStrings that overlap
certain triangle edges.
I'm trying to think of what will be best for OpenJUMP
in the long run. By slightly expanding the core in
order to implement Surfaces, full 3D functionality
becomes rather easy. I fully intend to heavily
leverage the existing codebase and make any additions
as seamless and invisible as possible. At heart I'm a
stereotypical "lazy" programmer who loves code reuse,
object inheritance, and overflowing standard
libraries. :)
net.surveyos.sourceforge.jtin.io: Contains classes
to read and write TIN
files.
net.surveyos.sourceforge.jtin.create: Contains
classes to create TIN
objects from source data that is not a TIN file.
I think jtin.create should be merged into jtin.io.
Conversion should be automatic, if you ask for a TIN
from a DEM file you shouldn't have to go through any
more steps than necessary.
net.surveyos.sourceforge.jtin.display: Contains
classes to display a TIN
in 2D and 3D.
This should be taken care of in the same way
LineString or Point are displayed. I don't think it
should be a separate class/package.
net.surveyos.sourceforge.jtin.contours: Contains
classes to represent
and generate contours and contour labels.
Good idea, but I'd put it down the list, to be
implemented as time allows.
net.surveyos.sourceforge.jtin.hillshade: Contains
classes to represent
and generate hillshades.
Hillshades should be part of the display code. Once
the jump to 3D data storage, manipulation and display
is made, things like this become simple. In the case
of hillshades, simply move the light source. We could
have a plug-in that allows you to choose the time and
date and see the shadow cast by the sun at that
altitude. Even simpler, we could have a Sun plug-in
cursor tool that turns the mouse cursor into the light
source so that when you move your mouse around, the
shadows cast by the terrain will move in sync.
I would put this type of functionality high on the
"time allows" queue.
Other possible packages might include:
net.surveyos.sourceforge.jtin.volumes: Contains
classes to calculate the
volumes between two TINs.
TINs are 2D surfaces. What would we be using as the
base in order to measure volume? Sea level? The lowest
point on the TIN border? The center of the Earth?
Selectable from all the above?
Is this kind of functionality needed by the surveying
community? Since we're dealing with connected polygons
and not curves, it should be fairly easy to implement
(ie no 3d calculus). I think it should be a method in
the TIN class not a whole class/package of its own.
net.surveyos.sourceforge.jtin.query: Contains
classes that allow a TIN
to be queried.
What kind of queering are you thinking about and why
can't they be get* methods within the TIN class?
net.surveyos.sourceforge.jtin.topology: Classes to
represent and manage
the topology of a TIN.
Again, this functionality sounds like it should be
represented by methods in the TIN class itself.
What kind of topology modification would you like to
be able to do?
net.surveyos.sourceforge.jtin.watershed: Classes to
generate watersheds
and perform watershed analysis using a TIN.
This is a great idea. Mathematically, it shouldn't be
too hard to classify watersheds based on the normals
of the triangles composing the TIN.
I would put this task about midway in the "time
allows" column.
I think we need to separate two different components
here.
The first component is used to represent the
different building blocks
of a TIN. I already mentioned some of these: TIN
Point, Tin Face, TIN
Face Edge.
I would say that a TIN Point is nothing more than a
Point, a TIN Face nothing more than a Polygon, and a
TIN Face Edge is nothing more than a LinearRing. We
shouldn't be defining new data types when JTS or
SimpleFeatures already defines them.
The second component is what is needed to display a
TIN in Swing.
These two components shouldn't be mixed. OpenJUMP
already follows this
methodology. Feature Geometries are not stored as
Java2D graphics. They
are stored as JTS Geometry objects. When OpenJUMP
renders a Layer the
JTS Geometries contained by the Layer's features are
converted to
Java2DGraphics and then painted on the screen.
3D display should be functionally identical to 2D
display. Instead of converting to Java2DGraphics, the
JTS Geometries would be converted to OpenGL then sent
to a GLJPanel which should interface seamlessly with
other swing components.
I strongly believe that we should tap into the power
of JTS. JTS has the
ability to store a Z ordinate for its Geometry
objects. We can represent
a TIN Point as a JTS Point, a TIN Face as a JTS
Polygon, and a TIN Face
Edge as a JTS LineString. This will allow us to do
two (2) things right
out of the box. First, it will allow us to tap into
all of the great
algorithms and data structures that are in JTS. We
don't want to write
this stuff from scratch. Secondly, it would allow us
to easily render a
2D view of a TIN in OpenJUMP's existing rendering
system, without any
modifications. That is a great thing.
I fully agree. It's wonderful to hear that JTS already
works with z coordinates. That will make life much,
much, easier.
It seems like you already have some experience in 3D
display, and that
this is an area that interests you. Here is a
suggestion:
I can bang out some simple TIN elements that use JTS
Geometries to
represent their shape and location.
You can write the code that converts the JTS
geometries into objects
suitable for display using Java OpenGL bindings. You
can then write a
Swing component that displays the TIN in 3D. This
could serve as a basis
for future display of 3D objects in OpenJUMP.
We can then work on the code that creates the TIN
elements from
different sources.
This will be a good beginning to a testing suite.
Before this happens though, I think there should first
be work done to create the internal data structures
for TINs and the Surfaces they depend on. Only when
that is done should work begin on translating TINs
into OpenGL commands. This is partially compensation
for the learning curve necessary to get inside the
OpenJUMP codebase: once I got the foundation under my
belt, everything else becomes clearer.
Speaking of test suites, does OpenJUMP use unit
testing or any other standardized testing procedure?
I guess this depends on your perspective. DEM is a
common elevation data
format, but in my profession almost all of our
surface models are
constructed from point data, usually stored in CSV
files. But my
surveying background taints my perspective somewhat.
We can tackle this
problem later. I can always write CSV support later.
This is the beauty of OpenSource software: developers
and users are very tightly coupled :)
I was looking through the glasses of a programmer and
GIS monkey, not from a surveyor's perspective.
We should make things as file agnostic as possible:
adding new file types that can be read into an
internal TIN format should be simple and
straightforward.
--Christopher
____________________________________________________________________________________
No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo! users and friends.
http://tc.deals.yahoo.com/tc/blockbuster/text1.com
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
