Paul, Thanks for welcoming Chris and getting involved. I hope to respond to his e-mail, but I won't get to it tomorrow. I have the feeling Chris will be a great addition to our team. His programming experience is was more extensive than my own.
The Sunburned Surveyor On Mon, Mar 31, 2008 at 10:58 AM, Paul Austin <[EMAIL PROTECTED]> wrote: > Christopher, > > Here is some code I started to create a TIN API. > > http://rsiaf.googlecode.com/svn/rs-gis-core/trunk/src/main/java/com/revolsys/gis/tin/ > > It works well for the case where you just have DEM points but there are some > issues when you start introducing breaklines. The problems come down to > dealing with cases where you have very thin slivers of triangles created > when a breakline is very close to an edge of a traingle. You will need to > look into a precision model to slightly adjust the path the breaklines take > to sometimes follow edges of the triangles once you get to the point where > say one edge of the triangle is < 1m in length. > > In general when building a TIN you can add points to it and lines to it. The > approach I took was to first add the points and lines and do the triangle > creation at the end, which worked out faster and easier. Once all the points > and lines are added you then build the trainagles by using the points and > all the vertices's of the lines. Do this using Delaney triangulation. Then > go back and add in the hard edges for the breaklines. With this approach if > you want to add more points or lines you need to rebuild the TIN. > > You may want to split it into two interfaces/classes > > TinBuilder { > add(Coordinate c); > add(Point p); > add(LineString l); > // plus list versions (e.g. add(List<Coordinate) coords) or array > add(Coordinate[] coords) ) > Tin generate(); > } > > Tin { > double getElevation(Coordinate c); > : > : > } > > Anyway that's enough thoughts for now, there will need to be extra methods > on the TIN to get triangles by bounding box, calculate the elevation fro a > geometry returning a new geometry with calculated z-values and also ones to > return lines for a given height which you could then use to create a > smoothed contour line. > > > Paul > > > > Paul Austin > President/CEO > Revolution Systems Inc. > > +1 (604) 288-4304 x201 > www.revolsys.com > > Christopher wrote: > > --- Paul Austin <[EMAIL PROTECTED]> wrote: > > Christopher, > > Welcome aboard, glad to see someone working on this. > > I'm > going to write a longer email later but one of > the things we should > > consider is splitting the model and operations for > the TIN itself from > the > visualization and IO code. So the TIN model > should not be dependent > on > anything in JUMP so it could be used in other > projects. > > Paul > > I tried to send off a longish reply to Landon and this > list, but it never > showed up on the list, so I'm > resending it. > > I agree that TIN related > functions not be dependent on > any display code. > > --Christopher > > > > > 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 > > > > ____________________________________________________________________________________ > OMG, > Sweet deal for Yahoo! users/friends:Get A Month of Blockbuster Total Access, > No Cost. W00t > > http://tc.deals.yahoo.com/tc/blockbuster/text2.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 > > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- 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
