I want to point out a small problem with actual
translation of OJ in other languages: When OJ starts
it automatically sets on my language (Italian).
I know how to go back in English (startup script)in
order to use the wiki help.
But probabily many users (expecially Finnic, Spanish
and Italian) wil
Hi,
I build Postgis layers with BeanShell Script.
What is the better way to build layer with java code?
I try :
- build pgSD with common properties (Host, database, user, password)
- pgQuery = new PostGISDataSourceQuery(new
PostGISDataSource(),query,layerName);
- Update pgSD properties (tabl
Hei Eric,
Uwe agrees to put the postgis plugin on the svn.
for the rest - because I never used maven - can you simple outline the
directory structure on the SVN. So I have a better image what you want
to do.
stefan
Eric Lemesre wrote:
> Hi Stefan,
>
> I am a newbee ;-) ,
>
> I like maven conc
have you tried to use the layer\add Datastore laye function?
It uses the Framework developed lately by Vividsolutions
As far as i know there is on the projet sigle website also an SQL Query
plugin
as i am not familar with Databases, maybe someone else can help
stefan
Eric Lemesre wrote:
> Hi,
Hi,
Recent work with Extract Layers by Geometry Type, and improving OpenJump's
support for very large selections, has convinced me that JUMP needs a
mechanism for dealing with subsets of large layers. Although the selection
mechanism is very flexible, it is very expensive in terms of memory and
simple solution and well thought :)
we should go for
stefan
Larry Becker wrote:
> Hi,
>
> Recent work with Extract Layers by Geometry Type, and improving
> OpenJump's support for very large selections, has convinced me that
> JUMP needs a mechanism for dealing with subsets of large layers.
This sounds like a great solution Larry, but I was wondering if you
might be able to confirm why selection requires more memory than a
fence.
Is it because when you use "selection" a bunch of Java collections are
created, whereas when you use a fence, you are just creating a
geometry? Is it becaus
Hi,
The better way seem to be
LayerManager.addLayer(Catagory, LayerName,
FeatureCollection).setDataSourceQuery(DataSourceQuery)
If we forget the datasourcequery nothing is saved in project file.
@+
Eric
2007/10/8, Stefan Steiniger <[EMAIL PROTECTED]>:
>
> have you tried to use the layer\add Da
Hi SS,
I agree that the problem with selection is the large collections being
generated. "Parts" are only part of the problem and it is a bit late to
stop supporting this capability. Optimizations are always possible, but
only if you have a clear understanding of what you are optimizing and us
Larry,
Thanks for the comments. I agree it is always hard to "rip out"
functionality that has been supported for a long time. I only thought
it might be better to spend the time fixing the real problem than
coming up with an alternative selection mechanism.
However, you may indeed be correct. Mak
I wonder if it is worth discussing whether or not there will be a
reasonable and practical limit to the size of data that we will try to
support in OpenJUMP. (For example, a maximum of 1,000 layers and
2,000,000 features.)
I realize this is a little tricky, because each computer will be able
to ha
Hi Larry,
May be I did not understand your solution, but I think like SS, that
selecting with a fence is not a general solution for the selection
problem. A selection can be the result of a query or any set of features
without any particular spatial relationship.
I wonder why collections contai
Hi Giuseppe,
I just want to point out another method to change OJ language (at least
for window users).
You can change the regional parameters (in the windows configuration
panel) to the language you choose (ex. english), start OpenJUMP, and
then, if you want, come back to your original setting
>I did it in MSDOS using a group of folder associated
>to OJ root: every folder (IT, DE, EN, ec)had the same
>startup script file (OpenJUMP.bat) but with different
>language option (one with Duser.language=it, another
>with Duser.language=De, etc).
Perhaps Peppe's use case can be handled by simpl
Hi Michaël,
The fence is not a general selection solution. It is a very specialized
one. With my new Extract Layer in Fence plugin, I can create smaller
subsets of the million point layer in seconds. Selection will not do this
at all.
I am unable to select a million points without an out o
Michael,
I can offer a tiny bit of insight into OpenJUMP's selection code. What
I'm about to tell you is part of what I hope to document about the
selection system when I'm done squishing bugs on my Super Select Tool.
OpenJUMP uses collections and something called a CollectionMap quite
extensivel
Larry wrote: " The fence is not a general selection solution. It is a
very specialized one. With my new Extract Layer in Fence plugin, I
can create smaller subsets of the million point layer in seconds.
Selection will not do this at all."
Understood. You are building a special tool for a special
>Understood. You are building a special tool for a special
>circumstance. There is nothing wrong with that as long as we keep it
>as a plug-in. I only spoke up before because I thought we were talking
>about integrating this into the core as a major "selection
>alternative". Thank you for clearing
Just when I thought that I had it figured out. :]
Larry wrote: "The best practice would then be to use the fence for
very large contiguous areas of features, the selection for small to
large sets of any features, and a source layer for all features on a
layer."
It makes a lot more sense when you
I did some more work on the "Edit" top-level menu functions today
after work, although I'm not quite finished. I changed some of bold
funtion names on the wiki to match the actual English menu command in
OpenJUMP. I also touched up some sentence fragments and
past/present/future tense usage.
I jus
I have a couple questions about the dialog box for the "Select by
type" plug-in. Actually, I really need to just ask permission for a
couple of changes to the English strings. :]
I'd like to change the title of the dialog for the plug-in from
"SelectByTypePlugIn" to "Select by Geometry" or "Select
Hi SS,
Good catch. SelectByTypePlugin is one of mine. The cryptic dialog name
is caused by a common problem with plugins, forgetting to override the
getName() method. I can fix it by having it return the same string that
appears on the menu. Is that sufficient? Anything else will require a n
I think that will be just fine Larry. Do you have any problem with me
changing the last check box label for the English translation?
SS
On 10/8/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> Hi SS,
>
> Good catch. SelectByTypePlugin is one of mine. The cryptic dialog name
> is caused by a comm
23 matches
Mail list logo
