Re: [JPP-Devel] Joining tabular data to a layer's attribute.

[Stefan Steiniger]

Roman Isitua wrote:

> Hello Guys,
>  
> The application i am working on requires loading tabular data from 
> different database
> systems e.g SQLServer, Oracle. This data changes very frequently 
> and is mainly numeric. Reading a table from a database is easy but how 
> can I join such data to a layer's attributes. This would have been 
> easy if the data was in postgresql, in such a case, one can easily use 
> an SQL join statement.  My questions are:
>  
> 1. How can I join tabular data read from a database system like sql 
> server to a layer's attribute ?
>
no idea

> 2. Are they plans in the future to enable OPENJUMP read/write data to 
> other database systems ?

other than what? OJ can write to Postgis (see sourceforge webpage)
somehow... but we dont have a concrete dev-plan. If you wish read/write 
to other databases you may need to find a sponsor and ask one of the 
companies to develop such an access.

stefan

>  
> Roman
>
> Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user 
> panel 
> 
>  
> and lay it on us.
>
>
>
>-
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>
>
>
>___
>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 DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] A new ThreadQueue ...

[Larry Becker]

OK Sascha, you win.  I see your point.  Your logic is inescapable
about the defaultRendering ThreadQueue.  My only defense is that my
code will not produce the correct raster without the while (default
queue has running threads) check.  WMS Layers (only) will be missing.

Regarding the ArrayIndexOutOfBoundsException - that only occurred when
I introduced mouse wheel zooming which has the effect of overloading
the event queue with zoom events.  Of course, the potential was there
for it to happen before, it was just very unlikely.

I do appreciate your mathematical rigor, and arguing with you served
the very useful purpose (for me) of getting to know you better.  I
hope to argue with you again on some other topic.  ;-) I find
arguments among programmers to be a good way of vetting a design, and
I never take it personally.  I hope you don't either.

regards,
Larry



On 5/31/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> Hi Larry,
>
> Larry Becker schrieb:
> > Hi Sascha,
> >
> >   Only potentially, but practically speaking my code is blocking the
> > GUI thread, and there is nothing running to put more jobs on the
> > queue.  The while loop in processQueue will keep maxRunningThreads
> > running untill the queue begins to empty.  When is empty, there are no
> > more render jobs to process.
>
> This is wrong. Say you have enqueued three jobs.
> The defaultRendering ThreadQueue is limited to one Thread running
> so all threads are working one after each other. After the first
> job has endend, the one and only Thread brings the counter to zero
> because this if the only thread working on the jobs. But there are
> two more in the queue. It is not important if the GUI thread is
> blocked. There are two jobs more to do. And more problems arrive
> if you have jobs that are _not_ in the default rendering ThreadQueue
> like WMS. They are rendered in truly parallel way with a second
> thread. Your 'while (default queue has running threads) sleep(time)'
> loop don't test this second queue.
>
> BTW: Didn't you mention that you place a
> try { ... } catch (ArrayIndexOutOfBoundsException ex) { ...}
> workaround in your SkyJUMP code? Have you ever thought about
> the reasons? Looking at the code of OJ I didn't find this
> 'improvement' ...
>
> >   This has been an interesting discussion, but we could go back and
> > forth like this forever.  I admit that you know Threads very well, and
> > that your design appears to be better.  I'm simply saying that JUMP
> > ThreadQueue is not as bad as you are making it out to be, and that it
> > has been working perfectly fine for years now.  Could it be improved?
> > Of course, Jon's comments show he was constantly seeking improvements
> > to it.  I am just cautious about replacing a critical section of code
> > without adequate testing.  Give me a well tested "bad" design over an
> > untested good design any day.
>
> I totally agree with you. Never touch a running system. But the system
> is not running very well here. Nobody wrote code in the past that needs
> precise reliability in this thread issues. This has changed.
> And as you say: It's a critical portion of the code. For this kinds
> of code I demand 'nearly' (*) mathematical correctness. And talking
> about business: I have a customer here how stumbled into this concrete
> thread trap. Now I can show him my analysis and my enhancements and how
> the issue is able to be fixed. I can send him a patch set against OJ to
> make his private copy work. But I prefer to fix the problem at the root
> and discuss it with the OJ team.
>
> > Don't get me wrong, I do appreciate your hard work and contribution.
> > I just need a little more time to test.
>
> This why are talking about and I'm willing to give you this time. :-)
>
> > regards,
> > Larry
>
>
> (*) Having in mind Knuth's famous quotation about correctness proves and
> tests.
>
> Regards,
>   Sascha
>
> >
> > On 5/30/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> >> Hi Larry,
> >>
> >> the magic word here is 'critical region'
> >> Have a look a the finally block.
> >> Assume the setRunningThreads(getRunningThreads() - 1) call
> >> was executed and the counter went to zero. This is done in Thread A.
> >> And now directly comes a context switch to your code
> >> in Thread B. Your if statement thinks that there are no
> >> jobs any more -> Your loop ends. Context switch back to Thread A.
> >> Now the processQueue() call is executed and potentially a
> >> new thread is started because the queue is not empty.
> >> Counter is zero but queue not empty.
> >> Thread programming is delicate, isn't it?
> >>
> >> - Sascha
> >>
> >>
> >> Larry Becker schrieb:
> >>> Hi Sascha,
> >>>
> >>>   I do not see the difference.  It seems to me that when a task is
> >>> finished, the runningThreads count is decremented as in:
> >>>
> >>> try {
> >>> runnable.run();
> >>> } finally {
> >>> setRunningThreads(getRunni

[JPP-Devel] Question about special renderers...

[Sunburned Surveyor]

Larry Becker helped me figure out why Strings were getting passed as
ContentIDs in OpenJUMP's rendering code. It turns out there are
special renderers that need to be given a chance to paint on the
LayerViewPanel everytime the LayerViewPanel.paintComponent() or
LayerViewPanel.repaint() methods are called. For example, you have the
FeatureSelectionRenderer, the BackgroundRenderer and a couple of
others.

These renderers operate a little differently that the "standard" Layer
renderer. This is because they always need to be given the change to
paint. (The Layer renderer only needs to paint if the active task
contains Layer objects.) The JUMP developers used an interesting
"trick" to accomplish this. They added Strings to the list of
ContentIDs stored in each RenderingManager. (These Strings are added
in the RenderingManager's constructor.) A special renderer is then
associated with each of these Strings. (For example, the
FeatureSelectionRenderer is associated with the String "SELECTION".)
Since the Strings are permanent residents of the ContentIDs list, the
special renderers are always given a chance to paint.

I want to change this system slightly to work with my pluggable
rendering system. I will still add Strings to the ContentIDs list, but
I will delegate the creation and return of the special renderers to
implementations of my IRendererFactoryTool interface. This will
preserve consistency and will also allow us to custimize things like
background, grid, or selection rendering without recompiling
OpenJUMP's source code?

Does anyone see any problems with this idea?

The Sunburned Surveyor

(I won't be commiting any of these changes to the OpenJUMP CVS.) :]

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Question about special renderers...

[Michaël Michaud]

Hi,

Sorry, I have worked with some parts of some renderers, but I have not a 
sufficient knowledge of the whole rendering system to have an opinion 
about the way to improve it or even the necessity to do it.
I just can tell that making things modular and plugguble seems good to 
me but don't know how it should be done.
Hope someone else can give better advice as I'm sure it is a very 
important part of the application.

Michaël

Sunburned Surveyor a écrit :

>Larry Becker helped me figure out why Strings were getting passed as
>ContentIDs in OpenJUMP's rendering code. It turns out there are
>special renderers that need to be given a chance to paint on the
>LayerViewPanel everytime the LayerViewPanel.paintComponent() or
>LayerViewPanel.repaint() methods are called. For example, you have the
>FeatureSelectionRenderer, the BackgroundRenderer and a couple of
>others.
>
>These renderers operate a little differently that the "standard" Layer
>renderer. This is because they always need to be given the change to
>paint. (The Layer renderer only needs to paint if the active task
>contains Layer objects.) The JUMP developers used an interesting
>"trick" to accomplish this. They added Strings to the list of
>ContentIDs stored in each RenderingManager. (These Strings are added
>in the RenderingManager's constructor.) A special renderer is then
>associated with each of these Strings. (For example, the
>FeatureSelectionRenderer is associated with the String "SELECTION".)
>Since the Strings are permanent residents of the ContentIDs list, the
>special renderers are always given a chance to paint.
>
>I want to change this system slightly to work with my pluggable
>rendering system. I will still add Strings to the ContentIDs list, but
>I will delegate the creation and return of the special renderers to
>implementations of my IRendererFactoryTool interface. This will
>preserve consistency and will also allow us to custimize things like
>background, grid, or selection rendering without recompiling
>OpenJUMP's source code?
>
>Does anyone see any problems with this idea?
>
>The Sunburned Surveyor
>
>(I won't be commiting any of these changes to the OpenJUMP CVS.) :]
>
>-
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>___
>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 DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel