Hei Guys, sorry for not having a look on this topic so far. But one thing may be to include Martin David' expertise in this discussion since he presented on last FOSS4G:
http://lin-ear-th-inking.blogspot.com/2007/05/geotec-2007-presentation-on-watershed.html I also have the slides. Stefan Paul Austin 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 <http://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
