Hei Christopher thanks for your outline :) I actually have not that much background knowledge to evaluate if what you do propose is good, but I guess you know it better. But modularity is always a plus and documentation is sufficient. However.. a good rule is to always start with a simple model and extend it later. I.e. one could also make first all in one and then introduce modularity later.
btw. Today I just stumbled across this article that has been published this month: "Sweep-line algorithm for constrained Delaunay triangulation" http://www.informaworld.com/openurl?genre=article&issn=1365%2d8816&volume=22&issue=4&spage=449 If there is need I can send it to you. Note, that it is a 2D algorithm (brwosing the article shortly). I actually have needs too for 2D CDT's.. in map generalization. cheers stefan Christopher wrote: > Sorry for the radio silence, I've been a thinking > philosopher not an eating philosopher. I can only hope > a fork and food are there when I need them ;) > > I've been reading the papers of the computational > geometry "heros" and thinking of an overall framework > for the TIN side of things. I just got my copy of > "Foundations of Multidimensional and Metric Data > Structures" by Hanan Samet yesterday and it is already > proving a valuable resource. > > Broadly speaking, I want to structure the TIN > import/creation side as a serial chain. Each node in > the stream would either gather statistics about the > stream flowing through it, alter the input stream into > an changed version of the current type of stream, or > alter the input stream into a different kind of output > stream altogether. > > Suppose we had defined streams of DataSource (file, > database, WMS, etc), Geometry, Point, LineString, > GeometryCollection, and TINface. Then we can have a > bunch of small modules that process these streams in > different ways that can then themselves be combined in > different ways given the need. For instance, one > module could take an I/O stream from a USGS NED .bif > elevation file then output a stream of Points. Another > module could take a stream of Points, perform a simple > random insertion Delaunly algorithm, then output a > stream of TINfaces. The final module down the line > would take the TINfaces and output an instance of a > TIN. An alternate final module could take save the TIN > to a file or even a database. > > Some benefits of this structure include: > * being able to use the same module in very different > types of chains. > * modules in each layer (ie you could have different > Delaunly algorithms for PointStream -> TINface > transition) could be easily swapped around, making > this a great research platform. > * by using Paul's JCSP lib, the different nodes on a > stream could be run concurrently allowing for > wonderful scaling on today's multi-core, > multi-processor machines. > * it should work equally well for a small NED data set > imported into memory or a huge raw LIDAR DEM file > saved into a PostGIS database. > > Right now, I'm reading my eyes out and trying to > figure out what kind of streams and data structures > will be needed to be able handle any kind of TIN > importation tasks might be needed by anyone, anywhere, > in any java GIS project. I also have finals going on, > so don't expect any worknig code in the next week or > so. > > As far as future funding, I'm going forward as if > everything will go through fine and no checks will > bounce. I'll probably still work on the project if > something goes wrong, but the manhours will be much > less given that I'll have to find other work for the > summer. > > --Christopher > > > > --- Sunburned Surveyor <[EMAIL PROTECTED]> > wrote: > >> Paul, >> >> Thanks for the link on JSR-275. That looks very >> interesting, and >> surprisingly simple. I just skimmed through the >> introduction of the >> JavaWorld article, but I will read it in more detail >> this weekend. I >> think I can incorporate it into the code I'm already >> working on. >> >> Stefan and Chris, >> >> >> I explained to Chris the conditions that must be met >> before we are >> accepted. I think he has a good understanding of >> these. It seemed from >> our early e-mails that he was eager to move forward. >> Stefan is correct >> in that we do not have a gaurantee of acceptance or >> payment from >> Chris' work. He would be working as a volunteer like >> the rest of us >> for the time being. >> >> The Sunburned Surveyor >> >> On Fri, Apr 11, 2008 at 11:31 AM, Stefan Steiniger >> <[EMAIL PROTECTED]> wrote: >>> Question.. is Chris accepted, i.e. will he get a >> grant by GSofC? >>> Otherwise it is his decision to work on it or not >>> >>> stefan > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ------------------------------------------------------------------------- > 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
