Thanks for these informations. Martin! :-)
I agree with you. Not all kind of data will profit
from this. Large polygon layers and maybe lines too.
Some heuristics have to be applied here.
Implying some spatial coherency, a cache of say the
last 35,000 visited vertices as a basis
of comparison lea
Another huge memory saving can be done by using String.intern() on
string objects as they are immutable anyway. I think the latest VM's do
some garbage collection on the intern cache so it's not a bad thing to do.
Paul
Martin Davis wrote:
> I'm almost 100% sure that JUMP treats Coordinate objec
I'm almost 100% sure that JUMP treats Coordinate objects as immutable
(at least in the core code. I do know that at least one plugin I wrote
changes the Coordinates in Geometries - my bad!). I think this should
be a firm design principle of JUMP - it's simply not worth the risk to
mutate Coor
Just for curiosity:
When I load a larger polygon shapefile (burlulc)
I recognized that the geometries share a lot of
common vertices. In case of the burlulc layer
over 1,500,000.
They are represented by com.vividsolutions.jts.geom.Coordinate
objects. If a shapefile gets loaded a new Coordinate obj
Okay, I've commit it.
The new thread Larry started recently will be a better
place for the other issue.
Thanks for all your patience! :)
Kind regards,
Sascha
Michaël Michaud schrieb:
>> if you both vote for a commit, then commit
>> (from my perspective Michael would be the other person for an
Hi Larry,
this definitely a step into the right direction. :-)
Using the event/display thread to serialize the
renderers in the non-interactive mode is a good idea.
Your code looks fine but I will think about the
consequences (blocking GUI, etc.). Of course I
will test it, too. ;-)
Regards, Sasc
The purpose of this thread is to document a problem with RenderManager
and to propose solutions.
The good news:
RenderManager is optimized for the most responsive interactive GUI
experience. It uses multiple threads, image caching, and timed
refresh operations to ensure that the user's percepti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi guys,
Seeing Edgar's post about another matter brought my mind to a user's
question/request...
I wonder why Edgar's excellent work on the coordinate transformation
plugin hasn't yet been incorporated into the core... :O
That user was right on one
This conversation has been great and has really helped me understand
the difference between the GPL and LGPL licenses.
I imagine that an important distinction between JUMP and GeoTools/UDig
is the fact that JUMP is released under the GPL and can't be
"sucked-in" by proprietary software.
The Sunbu
Right. It is the dependency that matters. JUMP depends on JTS. JTS
doesn't depend on JUMP.
And lawyers aren't always a bad thing. Some might say that the threat
of layers is the only thing that keeps GPL code free. I might release
some code under "Larry's license" but it would not be backed u
Simple.. as jump is derived from jts and jts LGPL does not enforce a
type of license for the derived work... this is what makes it the Lesser
GPL.. it declares the use of libraries to "/work that uses the Library/"
and excepts it from the derivation rule. see
http://en.wikipedia.org/wiki/LGPL
Hello all,
unfortunately separating the code is not enough too allow a new license.
At a quick glance i only found only this
http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCLinkingOverControlledInterface
And to my knowledge the GPL enforces itself on derived work (incl.
inheritance, use
Hi SS,
If JTS used JUMP then it would need to be under GPL.
GPL software such as JUMP can use non-GPL components such as JTS.
The rule (I think is) if you have an application that uses GPL
components, those components which utilize GPL components must also be GPL.
I think a general good guidin
http://www.foss4g2007.org/
June 29 is the close of the Call for Presentations for FOSS4G (Free
and Open Source Software for Geospatial). If you plan on giving a 25
minute presentation at FOSS4G, make sure you get your abstract in
before the deadline!
http://www.foss4g2007.org/presentations/
So how is it JTS can be released under the LGPL is JUMP uses it?
Doesn't JUMP's GPL infect JTS?
Or is JTS released under both the GPL and LGPL? Or does releasing JTS
under the LGPL meet the "viral" requirement of the GPL?
The Sunburned Surveyor
On 6/22/07, Edgar Soldin <[EMAIL PROTECTED]> wrote:
>Better yet... java has methods to determine the platform being used...
>so it's just a matter of calling the right apps for the current
>platform...
You are correct Pedro. I will put this on my TODO list.
regards,
Larry Becker
On 6/21/07, Pedro Doria Meunier <[EMAIL PROTECTED]> wrote:
> -B
> mhm... actually
> it is not just our decission if we use external libs. I use one which is
> now only available for 1.5
>
> stefan
Yes, of course one can not renounce to a needed functionality just to stay
compatible with 1.4.
Just be sure to do it only if there's no other (or no easy) way to do
mhm... actually
it is not just our decission if we use external libs. I use one which is
now only available for 1.5
stefan
P.Rizzi Ag.Mobilità Ambiente wrote:
> I think you should separate developer concerns from user concerns.
>
> For developers, I think 1.5 or even 1.6 could be OK for _comp
Sunburned Surveyor wrote:
>Martin,
>
>Thanks for this great clarification. I believe in my particular case I
>will have to release the converter code under the GPL, since I will be
>linking directly to JUMP code to do the conversion.
>
>I'll have to consider how important it is to use GPL for othe
I think you should separate developer concerns from user concerns.
For developers, I think 1.5 or even 1.6 could be OK for _compiling_.
Users may still have 1.4 installed and I wouldn't force them to upgrade
just because of _running_ OJ.
Since generics and the like are onyl syntactic sugar, y
20 matches
Mail list logo
