Re: [JPP-Devel] Modifying BasicFeature to track modifications

2009-04-27 Thread Martin Davis
I see your point, although newly-created BasicFeatures aren't really an issue - they are always dirty by definition. It's just features which have had their attributes modified which are the problem. I'm not totally crazy about this MutableBasicFeature/BasicFeature dichotomy, but it might be w

Re: [JPP-Devel] Modifying BasicFeature to track modifications

2009-04-27 Thread Martin Davis
Larry, can you summarize the proposed change, for the benefit of those who haven't read all 45 posts? (Maybe JUMP needs some sort of RFC mechansim...) I don't understand your comment that "If it was per-feature overhead...". I thought this *was* implemented per-feature? If not, I really don'

Re: [JPP-Devel] Doubt in an openJump feature

2009-04-27 Thread Stefan Steiniger
Hei, you can check out the source code if you want: pls. look into these classes: com.vividsolutions.jump.workbench.ui.cursortool.MeasureTool and here: com.vividsolutions.jump.workbench.ui.cursortool.CoordinateListMetrics if you find something - pls. tell us stefan karthik shravanam wrote: > H

Re: [JPP-Devel] Making JTin Part of the deegree Project

2009-04-27 Thread Sunburned Surveyor
OK. We will let Christopher decide. I might make more sense to keep the code at deegree. SS On Mon, Apr 27, 2009 at 7:56 AM, Andreas Schmitz wrote: > Sunburned Surveyor wrote: > > Hi Landon, > >> I was thinking Christopher might work on JTin from the JPP SVN. When >> he has some working (and tes

Re: [JPP-Devel] Making JTin Part of the deegree Project

2009-04-27 Thread Andreas Schmitz
Sunburned Surveyor wrote: Hi Landon, > I was thinking Christopher might work on JTin from the JPP SVN. When > he has some working (and tested) code we can approach deegree to see > what further work will need to be done to integrate the code as part > of the deegree library? > > Will this work?

Re: [JPP-Devel] Making JTin Part of the deegree Project

2009-04-27 Thread Sunburned Surveyor
I was thinking Christopher might work on JTin from the JPP SVN. When he has some working (and tested) code we can approach deegree to see what further work will need to be done to integrate the code as part of the deegree library? Will this work? The Sunburned Surveyor On Mon, Apr 27, 2009 at 12

Re: [JPP-Devel] Modifying BasicFeature to track modifications

2009-04-27 Thread Sunburned Surveyor
I will do some testing when I get time. If Chris beats me to it as part of his SoC work, he can run some testing with methods he thinks might work best. SS On Mon, Apr 27, 2009 at 6:12 AM, Larry Becker wrote: > What can I say that I haven't already said?  If you have the code I sent > you, I wou

Re: [JPP-Devel] Modifying BasicFeature to track modifications

2009-04-27 Thread Larry Becker
What can I say that I haven't already said? If you have the code I sent you, I would suggest making modifications to it and see if it works. Larry On Fri, Apr 24, 2009 at 5:54 PM, Sunburned Surveyor < sunburned.surve...@gmail.com> wrote: > If we are concerned about memory we might try a single

Re: [JPP-Devel] Making JTin Part of the deegree Project

2009-04-27 Thread Andreas Schmitz
Stefan Steiniger wrote: Hi, > it is wise - I aggree. But I would not promise anything, since > a) JTin does something new and deegree requires I believe certain > stability and testing, and if the respective code stands by itself, and is implemented in the development branch, I don't see any pr

Re: [JPP-Devel] Making JTin Part of the deegree Project

2009-04-27 Thread Andreas Schmitz
Christopher wrote: Hi, > I'll do whatever I need to. Do you have an address for degree's code > repository so I can check out a tree. you can check out the deegree development branch from here: https://wald.intevation.org/svn/deegree/base/trunk Best regards, Andreas -- l a t / l o n GmbH Aen