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.
Im 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 Im 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 shouldnt 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 dont 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 Id 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 were 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
cant 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 shouldnt 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
shouldnt 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. Its 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 surveyors 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
