Below is some of the discussion I have been having with our Summer of Code student about integrating TIN support into OpenJUMP. I'm sending it here so other OpenJUMP programmers have an opportunity to offer suggestions on the library design if they wish. We all know I'm not a Java programming expert, and I know that both Chris and I will appreciate practical advice on the design of the library and on its integration into OpenJUMP.
The Sunburned Surveyor ---------- Forwarded message ---------- From: Landon Blake <[EMAIL PROTECTED]> Date: Fri, Mar 28, 2008 at 1:45 PM Subject: RE: JTin Folder Created On SurveyOS Repository To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Chris, Before I respond to your comments, let me ask you a question: Did you turn in your student application yet? 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. 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. net.surveyos.sourceforge.jtin.display: Contains classes to display a TIN in 2D and 3D. net.surveyos.sourceforge.jtin.contours: Contains classes to represent and generate contours and contour labels. net.surveyos.sourceforge.jtin.hillshade: Contains classes to represent and generate hillshades. Other possible packages might include: net.surveyos.sourceforge.jtin.volumes: Contains classes to calculate the volumes between two TINs. net.surveyos.sourceforge.jtin.query: Contains classes that allow a TIN to be queried. net.surveyos.sourceforge.jtin.topology: Classes to represent and manage the topology of a TIN. net.surveyos.sourceforge.jtin.watershed: Classes to generate watersheds and perform watershed analysis using a TIN. You wrote: " In order to internally store and manipulate a TIN surface, a large enough foundation of 3D data structures will need to be written that a basic 3D display of the TIN surface will be straight forward. This will require doing a bit of work writing 3D extensions to the Geometry classes and adding the various Surface classes laid out in OpenGIS simple features v1.2.0 specification." 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. 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. 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. 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. You wrote: " Regarding TIN creation, shouldn't we spend time writing a program that will build a TIN surface from a common format like USGS DEM files instead of 1-off CSV files that no one else uses?" 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. You wrote: "Is there some sort of standardized way in OpenJUMP to store contour lines?" Nope. OpenJUMP doesn't currently work with Contour lines. That's part of the reason I was interested in TINs. I think I would like to see support for Contours as just regular 2D vector data first, and then perhaps as intelligent objects later. (Actually, all we need to do to enable "intelligent contours" in OpenJUMP is to have the attribute data of the Controur features follow a standard schema. Then contour plug-ins could add the special functionality based on this schema. You wrote: "Internally, it will probably wind up simply being a method that takes a set of points in 3-space and returns a surface of triangles created using Delaunay triangulation." This makes sense. I don't know if creating the TIN faces using the Delaunay algorithm would allow us to incorporate TIN boundaries and breaklines. This would be important to me, but again, I speak from a surveyor's perspective. This is good discussion. Thanks, Landon P.S. - I'm going to forward this e-mail to the JPP Developer list in case other OpenJUMP programmers want to comment. -----Original Message----- From: Christopher [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 6:43 PM To: Landon Blake Subject: Re: JTin Folder Created On SurveyOS Repository --- Landon Blake <[EMAIL PROTECTED]> wrote: > I set up a folder for our TIN library code on my > SourceForge Subversion > Repository. I threw some quick and dirty interfaces > in a couple of > packages there, which may help you get started. Feel > free to modify > things as you see fit. Thanks, I'll check them out. > I haven't really given a lot of thought to how our > library will be > shaped and interact with OpenJUMP, but here is one > idea: > > The main engine in the library will accept and parse > two (2) CSV files. > The first will contains points on the surface. The > second will contain > points that form breaklines or surface boundaries. > The engine will parse > these two (2) CSV files and create a TIN object from > them. The client > code can then interact with this TIN object. Once > created, a TIN can be > written to a text file. This will be a list of > triangular faces. It > would make sense to include a parser for this file > of faces, as this > will be quicker than reconstructing a TIN from point > data all the time. > We only need to do those calculations once for each > TIN. ediately. I planning on first writing code that can read, write and display TIN files. In order to internally store and manipulate a TIN surface, a large enough foundation of 3D data structures will need to be written that a basic 3D display of the TIN surface will be straight forward. This will require doing a bit of work writing 3D extensions to the Geometry classes and adding the various Surface classes laid out in OpenGIS simple features v1.2.0 specification. After a bit more reading regarding possible 3D display functionality, I've found out that Java3d won't mix cleanly with the existing 2D visualization or SWING. Instead, I'll need to use JOGL (Java OpenGL bindings). I still will try to leverage javax.vecmath as much as possible. It's just as well, I have a bit of OpenGL programming experience (in C), Java3D has more features than a GIS program will ever need, and those features come with a complexity cost that was leaving me scratching my head trying to figure out how to reconcile several fundamental conflicts between OpenJUMP and Java3D. Check out http://weblogs.java.net/blog/campbell/archive/2006/10/easy_2d3d_mixin.ht ml to see an example of 2D & 3D intermixing in a SWING environment. Regarding TIN creation, shouldn't we spend time writing a program that will build a TIN surface from a common format like USGS DEM files instead of 1-off CSV files that no one else uses? Is there some sort of standardized way in OpenJUMP to store contour lines? That could also be a good source of data to create TIN surfaces from. Internally, it will probably wind up simply being a method that takes a set of points in 3-space and returns a surface of triangles created using Delaunay triangulation. Anyway, that's my current thinking, --Christopher DeMars ________________________________________________________________________ ____________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs Warning: Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately. ------------------------------------------------------------------------- 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
