on the eclipse issue. - leave them in separate projects. - create a project just for your code... - in the build path options for your project add the two projects (jts and jump) - make also changes to the run option:
please have a look here: http://openjump.org/wiki/show/Documentation scroll down to the developer section (especially to "how to use and make own plugins")) most of the stuff should be explained there (i.e. the use of a properties file, which I would recommend) write again if you have problems.. so we do not loose time with that: stefan Sunburned Surveyor wrote: > Chris, > > It looks like you have been busy. > > I will print your e-mail and review it tonight after work. Hopefully I > can respond with comments tomorrow. > > Landon > > On Mon, May 5, 2008 at 12:30 PM, Christopher <[EMAIL PROTECTED]> wrote: >> I spent most of last week continuing my reading about >> the technical aspects of meshes, then spent the latter >> part of the week delving into the OpenJUMP/JTS code >> base to figure out how to best integrate TIN >> functionality. >> >> I have things pretty much squared away in my mind >> about where I'm going with the TIN module and how I'm >> going to get there, but now that I'm beginning to >> start the coding, I have begun to bang my head against >> the eclipse IDE. I've never used eclipse before, and >> I'm finding it impossible to do things that should be >> simple like unite the jts cvs tree and the jump-pilot >> svn tree into a project that I can build, run, and >> modify without breaking dependencies left and right. I >> have everything checked out and in the workspace, but >> can't put it all into one project. And the eclipse >> tutorials aren't helping one bit. I'm close to just >> using a text editor, but in the long run, it would >> make things much easier to use a good IDE and if I can >> get the dependency hell figured out, eclipse would >> make a good IDE. I have a message into >> SunburnedSurveyer to see if we can meet this week and >> do a quick in person eclipse orientation. >> >> So, instead of java interfaces and class stubs, I'll >> lay out in longhand the specifics I have planned. >> >> >> >> tin Package: >> >> TriangulatedIrregularNetwork extends MultiPolygon (I'm >> debating whether or not to directly inherit from >> MultiPolygon or to add more interfaces to create a >> MultiPolygon->Surface->PolygonalSurface->TIN hierarchy >> that is closer to the Simple Features spec) >> >> In order for the TIN code to integrate seamlessly with >> OpenJUMP, the interface to the in-memory >> representation of the TIN should be as compatible as >> possible with the JTS. By making the TIN a >> MultiPolygon with the added restrictions that all >> Polygons are non-overlapping, connected triangles, all >> the code that works with GeometryCollections can be >> made to easily work with TINs. Internally, the TIN >> surface will be represented by a triangle-table which >> is a simplified version of a quad-edge data structure. >> Each record in the table represents a triangle and >> contains the three vertex points and three table keys >> that point to the bordering triangles within the >> triangle table. The vertexes will be stored as raw >> doubles and the lines inferred. When the class is >> queried for a triangle or point, the returned geometry >> object will be created on the fly from the internal >> data structure. If this proves too slow, then it might >> be worth the space tradeoff to store the vertexes as >> Point Objects. This data structure is compact, fast >> and can accomplish anything we would want to do with a >> TIN. >> >> In addition to the inherited GeometryCollection >> methods and the methods specified in the Simple >> Features spec for Surfaces and PolyhedralSurfaces, the >> TIN class should also have TIN specific methods like: >> * extractContourBands: given a height increment and >> baseline (default = 0), return a MultiLineString >> containing the contour bands separated by the given >> height increment. >> * subset: given an envelope or even a linear ring, >> return a TIN that contains all the triangles of the >> current TIN that lie within the given boundary. >> >> I'm still not 100% clear on OpenJUMP's rendering >> pipeline, but it looks like I will implement a new >> instance of >> com.vividsolutions.jump.workbench.ui.renderer.Renderer >> that will work with TINs such that elevation color >> bands and hillshades can be implemented by >> coloring/shading each triangle on the fly. If this >> winds up being too slow, I might have to add >> pre-computed normals to the TIN's triangle-table. >> >> >> >> TinFactory >> For efficiency sake, the TIN should be immutable, thus >> a Factory will be needed to create a TIN fully formed. >> This Factory would be analogous to the GeometryFactory >> class. Various methods would take input lines and >> points and output a fully constructed instance of a >> TriangulatedIrregularNetwork. The first factory I'll >> work on will take a MultiPoint set and use Chew's >> algorithm found in >> org.openjump.core.graph.delauneySimplexInsert. This >> algorithm isn't the fastest, and doesn't deal with >> breaklines, but it is already in the OpenJUMP code >> base and will help to get the TIN pipeline working >> faster. The next factory to be coded will take a >> MultiPoint collection and a MultiLineString collection >> and will use a constrained delaunay triangulation to >> create the TIN. We may want to do a conforming >> delaunay triangulation instead and add steiner points >> on the breaklines in order to not have huge triangles >> next to the breaklines. Steiner points are also the >> reason why the TIN class should contain the copy of >> it's breaklines, because the breaklines in the TIN >> might be different than the breaklines that were >> initially given to the factory (the TIN's breaklines >> would have more points). Later on down the road, I >> would also like to make a TinFactory that takes in a >> MultiLineString of breaklines and a stream of Points, >> then builds up the TIN until the stream closes. This >> will be useful when we move beyond OpenJUMP's in >> memory representation and embrace larger TINs. >> >> >> >> tin.io Package >> >> This package will contain classes that can turn >> various types of input files into MultiPoint / point >> streams and MultiLineString geometry to be input into >> a TinFactory. There will also be classes that can >> export a TIN to a file and then be read it back into a >> TIN class. At first only Well Known Text input and >> output will be implemented. Eventually various DEM >> files will be supported for input and various 3D >> formats supported for input and output (i.e. W3's >> X3D). >> >> >> >> >> tin.viewshed Package >> >> All the papers I've read about viewsheds use a >> separate data structure for the viewshed that is built >> from the TIN. This data structure is then queried. The >> query could be a point or line with the return value >> being a MultiPolygon containing regions that can be >> seen from the input feature. The query could also be >> two features with the return value being a boolean >> indicating whether or not the features are visible >> from each other. The downside to viewsheds is that >> they have a big memory footprint: the most versatile >> data structure has a table for each point that >> contains a boolean value for every other point in the >> TIN indicating if it is visible or not. Because of >> this, viewsheds shouldn't be integrated into the TIN >> class and should only be used when requested. >> >> >> >> >> tin.watershed Package >> >> Much like the viewshed package, separate data >> structures that are built using the TIN will be >> needed. >> >> >> >> >> tin.multitriangulation Package >> >> The classes in this package will implement a >> multi-resolution triangulation model. The MT data >> structure can return a TIN class with a specified >> level of detail. The LOD can be constant over the >> whole surface, or can be higher at specified locations >> and coarser at others. This won't be of much use if >> the TIN can fit in memory, but once the TIN gets >> bigger, a multi-resolution data structure can use a >> file or database backing and return a TIN in a >> resolution that will fit in memory and cover the >> points of interest at the required detail. This might >> wind up being implemented solely within PostGIS/WMS, >> so that OpenJUMP can simply issue a WMS query and >> receive a TIN object as a reply. >> >> >> >> >> Again, sorry for not coming bearing code today. I >> haven't been slacking though; in addition to reading >> more about about meshes and TINs than I ever imagined >> existed and trying to wrap my head around the entire >> OpenJUMP/JTS code base, the code structure laid out >> above is the third or fourth revision I've come up >> with. I think this layout will be the best balance >> between OpenJUMP integration and ability to be used by >> third parties. Previous designs had put more emphasis >> on the TIN library being independent from OpenJUMP, >> but those eventually broke down into a collection of >> bad hacks when I tried to figure out how to integrate >> it into OpenJUMP. I have since decided that OpenJUMP >> will the the primary target and third party use will >> be kept in the back of my mind. I'll try not to make >> life harder than it needs to be for third party >> developers, but when needs conflict, I'm siding with >> the OpenJUMP way. >> >> Comments and suggestions appreciated, >> >> --Christopher >> >> PS I'm posting the meat of this message on the wiki. >> >> >> >> ____________________________________________________________________________________ >> Be a better friend, newshound, and >> know-it-all with Yahoo! Mobile. Try it now. >> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference >> Don't miss this year's exciting event. There's still time to save $100. >> Use priority code J8TL2D2. >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
