Hello Nacho,
you are right. These strange characters prevents OJ from working
with this server.
I patched my local source copy of OJ
com.vividsolutions.wms.WMService#initialize() to resolve the problem:
...
PushbackInputStream fake = new PushbackInputStream(inp);
int x;
while ((x = fake.read())
Hello Sascha:
2007/5/29, Sascha L. Teichmann <[EMAIL PROTECTED]>:
I think it would be better to contact the server's owner to
remove the characters in front of the XML document. Any other
comments?
I've contacted with Sitga Administrators and they say that It's a generic
problem of Geomedia
Thanks for submitting the patch Sascha.
The Sunburned Surveyor
On 5/26/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> Done.
>
> I stumbled across this issue while i was reviewing and
> and testing the thread stuff.
>
> - Sascha
>
> Stefan Steiniger schrieb:
> > Hei Sascha,
> >
> > please co
Sascha,
You wrote: "As I pointed out earlier having a ChangeLog would
be nice to document motivations and backgrounds for a change. Simply
generating a ChangeLog out of the commit messages is convenient but
it does not uncover the true potential of such a 'log' file."
I agree, and I use small tex
Michael,
I think most of our PostGIs/PostgreSQL code has been "abandoned" in
some sense. I don't know that you will be able to find an active
developer that is very familiar with this code. I think any
improvements you could make to this code would be welcome.
The Sunburned Surveyor
On 5/27/07,
Michael wrote: "I did not do much comparisons between jump versions
but identified
several bottlenecks in zoombar code and just committed an optimized
version :
1 - I prevent the renderer to display invisible layers as wireframes
during mouse dragging
2 - I used Larry's coordinate's decimator to re
Michael,
You wrote: "Another bug with the memory-release problem appears when
you remove a layer from the LayerNamePanel while this layer as an open
table view :
the view stay opened, and the memory is not released, even after the
table view is closed."
It sounds like the model for the Layer's a
Sacha,
I have been unable to keep up with all of the great work that you and
Michael Michaud have been doing on OpenJUMP during the last couple of
weeks. :]
I think we would definitely be interested in having the ability to
render WMS layers as from SVG instead of as an image in OpenJUMP.
However
SS,
I didn't find it necessary to do special (i.e. wireframe) rendering
when doing mouse wheel zooming since worse case render times are now
so short in SkyJUMP, and anyway the renderer doesn't block the UI,
whereas the zoombar renderer is modal and blocking. Mouse wheel
zooming works even in
Michael,
Without a reference to the layer in RenderManager, what would
prevent the memory from being released? I can't find anything wrong
with the way that InfoModel.dispose() is working. Can you do some
more magic with jhat do determine the answer?
regards,
Larry
On 5/29/07, Sunburned Sur
Hello Guys,
1. How can I bring tabular data from a database to
openjump ?
2. Can the JoinTablePlugIn be used to join tabular
data from a database or dbase table ?
3. Can tables be linked together instead of being
joined ? I think this feature will be needed to handle
one to many relationships
Hello Guys,
My questions is to Geoffrey Roy and all users of his
chart plugin.
1. Can stand alone charts be created for a layers
attributes using this plugin ? i.e. charts that are
not drawn on features.
2. If not are they plans to implement this
functionality ?
3. Are they other chart plugi
All,
I've been looking at the existing database and file plugins and the
com.vividsolutions.jump.io.datasource.DataSource class and from what I
can tell there is a one to one relationship between a layer and a data
source.
What I would like to do for some of the file and database based data
sourc
Paul,
Look at the DataStore architecture in JUMP 1.2 - it does exactly what
you're asking for, I think.
Paul Austin wrote:
> All,
>
> I've been looking at the existing database and file plugins and the
> com.vividsolutions.jump.io.datasource.DataSource class and from what I
> can tell there is a
Hi Paul,
As usual, you are interested in many of the same things that I am.
The single DataSource multiple layer concept is currently only
implemented in WMS and MrSID (which is based on WMSLayer) and you
actually end up with only a single layer in JUMP, but you can manage
it as multiples.
Sk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Roman!
Roman Isitua schrieb:
> Hello Guys,
>
> My questions is to Geoffrey Roy and all users of his
> chart plugin.
>
> 1. Can stand alone charts be created for a layers
> attributes using this plugin ? i.e. charts that are
> not drawn on featur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry, it wasn't my intention to break out of the thread.
I made a little c&p mistake ..
- - Sascha
Roman Isitua schrieb:
> Hello Guys,
>
> My questions is to Geoffrey Roy and all users of his
> chart plugin.
>
> 1. Can stand alone charts be creat
Hi Larry,
I've just downloaded SkyJump and seen how the DataStores work and it
looks as if it is roughly what I'm looking for.
I notice that when you save the Project to a .jmp file that the
connection information is duplicated for each layer. Does this mean
that each layer will connect direc
Paul,
The issue we are having with DataStore is that precisely what you
are referring to. Each layer is trying to do its own connection in a
separate thread to the server and Oracle is running out of
connections. Some kind of connection pooling would probably solve
this problem, but we haven'
SS,
Sunburned Surveyor schrieb:
> Sascha,
>
> You wrote: "As I pointed out earlier having a ChangeLog would
> be nice to document motivations and backgrounds for a change. Simply
> generating a ChangeLog out of the commit messages is convenient but
> it does not uncover the true potential of such
Larry Becker a écrit :
>SS,
>
> I didn't find it necessary to do special (i.e. wireframe) rendering
>when doing mouse wheel zooming since worse case render times are now
>so short in SkyJUMP, and anyway the renderer doesn't block the UI,
>whereas the zoombar renderer is modal and blocking. Mous
Larry,
I did not yet go through the code.
Could you reproduce the problem I discribed ?
I'll try to play with jhat again by the end of the week.
Michaël
Larry Becker a écrit :
>Michael,
>
> Without a reference to the layer in RenderManager, what would
>prevent the memory from being released?
Hi Michaël,
It does seem like we are overly rich in zoom tools. With the
addition of mouse wheel zooming, the basic zoom tool is still the most
flexible. As a user, I like RealTime zoom sometimes because the
others are too coarse and I need to fine tune the zoom quickly.
regards,
Larry
On 5/
Sunburned Surveyor a écrit :
>One way to fix this would be not to allow Layers to be removed when
>their attribute table is open. (Or to warn the user that the attribute
>table will be closed when the Layer is removed.)
>
>Any thoughts on this guys?
>
>The Sunburned Surveyor
>
>P.S. - Michael, cou
SS,
Sunburned Surveyor schrieb:
> [...]
> I think we would definitely be interested in having the ability to
> render WMS layers as from SVG instead of as an image in OpenJUMP.
> However, I think we might benefit from the creation of an "unstable"
> or development branch in the OpenJUMP CVS were w
Oops, I just tried to reproduce the problem and couldn't. Are you
certain that you aren't getting fooled by the infamous status bar
committed memory display? You need to check it in Help About to see
the real story.
regards,
Larry
On 5/29/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> Larry,
Sascha,
I agree with your comments. Let me talk to Stefan about this. I think
creating a development branch of the CVS shouldn't be too much of a
problem. I don't know a lot about CVS, but as long as it was fairly
simple to move things from the unstable branch to the stable branch I
think this wou
Larry Becker a écrit :
>Oops, I just tried to reproduce the problem and couldn't. Are you
>certain that you aren't getting fooled by the infamous status bar
>committed memory display? You need to check it in Help About to see
>the real story.
>
>
I should say 'Oops', I don't know how I missed
One of the topics discussed in an earlier thread today was code format
standards or code style standards.Using tools that will allow us to
automatically enforce a coding standard was suggested. Using these
tools to convert existing source code from other JUMP "brands" to our
style for OpenJUMP was
I wanted to address another topic from the thread earlier today. I
think cleaning up the import statements in OpenJUMP, especially if
this could be done in an automated fashion, is a great idea for some
of the reasons that have already been mentioned.
It seems there might be some concern about thi
Here's my 2c worth.
I agree that we shouldn't reqire a standard which is onerous for
developers that aren't using a particular IDE.
I also agree that the curly brace position issue is not worth wasting
time over. Much better to spend the time doing better Javadoc.
Variable naming is also pr
I may have a little something to add to this discussion, although I
don't know how helpful it would be. :]
A while back a company had hired me to do some work on one of the
PostGIS Drivers. It sounds like they wanted something related to what
Paul and Larry are discussing. They wanted to be able t
Martin,
See my comments below.
Martin wrote: "Naming of
methods, classes and packages is more visible (in increasing importance)
- articulating some policies here might be helpful."
You make a good point here. I prefix all of my interfaces with a
capital "I", all of my exceptions with the prefix
Larry asked an interesting statement from a thread on our mailing list
today. It had to do with OpenJUMP's maturity as a program.
I thought this was a question worthy of a short blog post. If you are
interested you can read my answer to Larry's question here:
http://openjump.blogspot.com/
The Su
Sunburned Surveyor wrote:
> Martin,
>
> See my comments below.
>
> Martin wrote: "Naming of
> methods, classes and packages is more visible (in increasing importance)
> - articulating some policies here might be helpful."
>
> You make a good point here. I prefix all of my interfaces with a
> capi
Rant on Martin.
LOL
Larry
On 5/29/07, Martin Davis <[EMAIL PROTECTED]> wrote:
>
>
> Sunburned Surveyor wrote:
> > Martin,
> >
> > See my comments below.
> >
> > Martin wrote: "Naming of
> > methods, classes and packages is more visible (in increasing importance)
> > - articulating some policies h
Martin,
Please see my comments below.
Martin wrote: "Well, now we're getting closer to the bone... As tools
have improved
I've found myself using name prefixes in fewer and fewer situations.
All the IDEs I've used in the last 6 yrs can easily tell you whether
something is a class or an interface
Dear Roma and Others
For JumptChart the data that is collected to prepare charts is a table -
numerical attribute data x features. This implies that a single chart
is created for each feature (polygon, line or point) in the layer. No
manipulations on the attribute data is possible - this must
38 matches
Mail list logo
