The slides would be great. Did he release any sample code under the L/GPL? --Christopher
--- Stefan Steiniger <[EMAIL PROTECTED]> wrote: > 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. > >> > >> Im trying to think of what will be best for > OpenJUMP > === message truncated === ____________________________________________________________________________________ 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
