Re: [JPP-Devel] Streamlining Java2DConverter decimation

2007-06-05 Thread Sascha L. Teichmann
Hi! It's only that temp array, there are actually two. In case of decimation the first allocated is copied over to a second to archive tight fitting. Not to forget the Coordinate->Point2D->Coordinate transformations with the PointConverter, which also introduces a lot of temporal object allocation

Re: [JPP-Devel] [Geotools-devel] Common Feature model

2007-06-05 Thread Justin Deoliveira
Hi, A common java feature model would be great. This is essentially what the geoapi project strives to achieve. http://sourceforge.net/projects/geoapi/ Last year a couple of developers took a run at the interfaces for a feature model that definitely meets the requirements you list below. You can

Re: [JPP-Devel] [Geotools-devel] Common Feature model

2007-06-05 Thread Rob Atkinson
good one, Justin. Justin Deoliveira wrote: Hi, A common java feature model would be great. This is essentially what the geoapi project strives to achieve. http://sourceforge.net/projects/geoapi/ Last year a couple of developers took a run at the interfaces for a feature model that definit

Re: [JPP-Devel] [Geotools-devel] Common Feature model

2007-06-05 Thread Jody Garnett
Sunburned Surveyor wrote: > Paul wrote: "Here are the requirements I have. > Here are the requirements I had: - http://docs.codehaus.org/display/GEOTOOLS/Feature+Model+Design+Discussion Each "aspect" has a discussion and happy little icons This should answer some of your questions > Id

[JPP-Devel] R: Common Feature model

2007-06-05 Thread P . Rizzi Ag . Mobilità Ambiente
Maybe the situation has improved in the last year or so, but one of the reason why we decided to abandon uDig and GeoServer was indeed the GeoTools Feature model. They keep changing it, adding more and more new functionalities, without bothering for stability. One of the best thing about JUMP is

[JPP-Devel] R: Common Feature model

2007-06-05 Thread P . Rizzi Ag . Mobilità Ambiente
IDs can be multi fielded too. Bye Paolo Rizzi -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] conto di Paul Austin Inviato: martedì 5 giugno 2007 0.36 A: List for discussion of JPP development and use. Oggetto: [JPP-Devel] Common Feature model I agree if the open

[JPP-Devel] R: Support for non-spatial features...

2007-06-05 Thread P . Rizzi Ag . Mobilità Ambiente
There's a dirty path you may follow to support non spatial layers, you can make them spatial. If a layer is loaded without a Geometry field, one is added on the fly. The geometries will be empty, so the Core would have to be modified to cope with them, but it has anyway because right now you get

[JPP-Devel] deegree Feature Model for OJ [was: Re: R: Common Feature model]

2007-06-05 Thread Markus Müller
Folks, I try for another time... Paolo lists some of the same reasons why we (-> in deegree) decided to develop a separate Feature Model. Another reason was that we needed it sooner as GT, the cause for this seems to be that in Germany support of complex GML applications schemas was pretty soo

[JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Sascha L. Teichmann
Hi together! I was wondering why it takes so long to enable Colour Theming when working with layers with a higher number of features. If you open the "Changes Styles", choose tab "Colour Theming" and check "Enable colour theming". If I do this with a 36,000+ polygon shape file it takes about 24(

Re: [JPP-Devel] Streamlining Java2DConverter decimation

2007-06-05 Thread Larry Becker
Hi Sascha, I've done experiments with doing inline transformations (no AffineTransform), and found that it was no faster either. One theory to explain this is that the bottleneck is in the graphics system itself. However, that is contradicted by other experiments that I have done which show t

Re: [JPP-Devel] [Geotools-devel] Common Feature model

2007-06-05 Thread Paul Austin
Hi Jordy, When we spoke at Refractions 6 months ago you were in the middle of some major changes to the model, have these been completed and released now? If so I will look at these for use by my readers. The approach I have taken in the work that I have integrated into my JUMP plugi-ins is to ha

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Larry Becker
Hi Sascha, Great work! You have found the cause of another annoying slowdown. I first noticed this doing the burlulc benchark with Colour Theming. It really needs to be fixed. I noticed that it is fixed in Kosmo already, however their model is probably different. Fixing BasicStyle to use

Re: [JPP-Devel] named FeatureSchema

2007-06-05 Thread Paul Austin
Martin, If the FeatureSchema class could be extended to have a name property, with a getName (and maybe a setName) with a default constructor and a constructor that takes the name as an argument then that would be great. As we have default constructor existing code won't break as the name is optio

[JPP-Devel] Memory used by features in a Layer

2007-06-05 Thread Paul Austin
All, I'm interested in understanding the memory usage patterns of feature instances within a layer. Understanding a feature is simple as we have the following. FeatureSchema - Pointer to shared instance id - int value Object[] - The attributes, length is number of features Object[n] - The attrib

Re: [JPP-Devel] Streamlining Java2DConverter decimation

2007-06-05 Thread Larry Becker
I did try the -Dsun.java2d.opengl=true on Windows XP and it rendered just a little slower than the default method. Larry On 6/5/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Hi Sascha, > >I've done experiments with doing inline transformations (no > AffineTransform), and found that it was no

Re: [JPP-Devel] Streamlining Java2DConverter decimation

2007-06-05 Thread Sascha L. Teichmann
Have you also tried the Direct3D path (-Dsun.java2d.d3d=true)? I think the results depend on the graphics hardware and driver quality. Sascha Larry Becker schrieb: > I did try the -Dsun.java2d.opengl=true on Windows XP and it rendered > just a little slower than the default method. > > Larry >

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Sascha L. Teichmann
I'll try to remove the GUI dependencies for a preset fill pattern, but I also want to make BasicStyle more light weighted. I'll have a look at it later. - Sascha Larry Becker schrieb: > Hi Sascha, > >Great work! You have found the cause of another annoying slowdown. > I first noticed this

Re: [JPP-Devel] Streamlining Java2DConverter decimation

2007-06-05 Thread Larry Becker
Setting -Dsun.java2d.d3d=true is also slightly slower than the default. Larry On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > Have you also tried the Direct3D path (-Dsun.java2d.d3d=true)? > > I think the results depend on the graphics hardware and driver quality. > > Sascha > > > Lar

Re: [JPP-Devel] deegree Feature Model for OJ [was: Re: R: Common Feature model]

2007-06-05 Thread Martin Davis
Makes sense to me, Markus & Paolo. I have to admit, when I read Justin's and Jody's notes, I get a bad case of EGO (Eyes Glaze Over...). Maybe I'm just dumb, but the GT & GeoAPI work seems pretty complex. At the moment JUMP is providing a lot of value to people with a pretty simple model. I'

Re: [JPP-Devel] Common Feature model

2007-06-05 Thread Martin Davis
Some comments: 1. The IDs in JUMP were really intended to be for internal system use only, in order to give Features a unique identity. This capability is currently barely used (which is a good thing!), but I think it should be preserved as is (since this is the more memory, design and processi

Re: [JPP-Devel] Common Feature model

2007-06-05 Thread Paul Austin
Hi Martin, Just a note on point 4, a feature without a schema is a Map not a List, I guess what I mean a feature without a schema, is a feature where the schema can be dynamically defined using the semantics of a Map. Although recently I have come with the concept of a schema mapper, which us

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Sascha L. Teichmann
So, that should fix it Added an 'if (fillPattern == null)' to the GUI and removed the ultra expensive pattern creation from BasicStyle. The construction of 100,000 BasicStyle objects now take 0.267 secs. before it took 27.357 seconds. Find attached patches against BasicStyle and BasicStyleP

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Paul Austin
Sascha, In your comments you said you added an if statement but used the ?: operator, I think in this case a proper if {} else {} statement would be much more readable. I think that the ?: operator should be used minimally, for example if you were generating HTML and wanted to optionally include a

Re: [JPP-Devel] Common Feature model

2007-06-05 Thread Martin Davis
Yep, the schema mapper concept is what I had in mind for a "utility class". It might be useful to have this in the Feature model package, if it's general-purpose. Paul Austin wrote: > Hi Martin, > > Just a note on point 4, a feature without a schema is a Map not a > List, I guess what I mean a

Re: [JPP-Devel] Common Feature model

2007-06-05 Thread Paul Austin
Martin, For the feature mapper I think we would need an interface that would define the contract of mapping from one feature to another. This interface would be defined to work with a single schema. public interface FeatureMapper { Feature convert(Feature feature); } There would be a default

Re: [JPP-Devel] Javadoc for skyjump

2007-06-05 Thread Sunburned Surveyor
Roman, You can use an IDE like Eclipse to export the Javadoc from SkyJUMP's source code. I can give you some help with this if you would like. The Sunburned Surveyor On 6/3/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > the skyjump javadaoc is probably inside the source code which is stored >

Re: [JPP-Devel] Common Feature model

2007-06-05 Thread Martin Davis
Yep, makes sense. Er - don't you mean that the FeatureMapper would map a Feature with one schema into a Feature with a different schema? Not sure what you mean by "This interface would be defined to work with a single schema". Personally I have only rarely needed this level of generalization in

Re: [JPP-Devel] Common Feature model

2007-06-05 Thread Paul Austin
Martin, I meant only map from a single FeatureSchema to another FeatureSchema. For some cases you would also need a registry that would get the feature mapper instances from one feature schema to another feature schema. This framework is useful where you want to convert a data set with 50 featur

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Larry Becker
Sascha, I implemented your changes in SkyJUMP to BasicStyle and BasicStylePanel. It worked when I opened a task with colour theming already set up, but when I tried to add a new layer and chose Change Styles, I got: java.lang.NullPointerException at com.vividsolutions.jump.workbench.

Re: [JPP-Devel] Code Style Standards

2007-06-05 Thread Sunburned Surveyor
Paul, I have installed the Checkstyle plug-in for Eclipse and I will be giving it a spin with the XML file you provided. Thanks, The Sunburned Surveyor On 6/1/07, Paul Austin <[EMAIL PROTECTED]> wrote: > The Eclipses checkstyle plugin comes with the config for the Sun > conventions, which I hav

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Larry Becker
It seem to work when I modify getFillPattern in BasicStyle to include the check for null and then initialize the fillPattern as before. public Paint getFillPattern() { if (fillPattern == null) { fillPattern = WKTFillPattern.createDiagonalStripePattern(4,

Re: [JPP-Devel] Javadoc for skyjump

2007-06-05 Thread Larry Becker
Roman, The SkyJUMP javadoc is located at: http://skyjump.cvs.sourceforge.net/skyjump/skyjump/doc/ Unfortunately, SourceForge doesn't allow viewing it as html directly in their viewer so you will have to download it to browse it. regards, Larry Becker On 6/5/07, Sunburned Surveyor <[EMAIL P

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Sascha L. Teichmann
The NPE comes from BasicStylePanel#findEquivalentItem() Therefore it would vote for make this one more bullet proof. See my new patch. I would leave BasicStyle#getFillPattern() untouched. Larry Becker schrieb: > It seem to work when I modify getFillPattern in BasicStyle to include > the check fo

Re: [JPP-Devel] new files changelog, changes and todo on CVS

2007-06-05 Thread Sunburned Surveyor
Michael, You have identified an important issue. Please see my comments below: Michael wrote: "About the todo list, we may have to choose a central place. There are some todo lists on the wiki, there is the sourceforge feature request, the sourceforge bug report and now here... What others think

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Larry Becker
Works great and has no side effects that I have found. Larry On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > The NPE comes from BasicStylePanel#findEquivalentItem() > Therefore it would vote for make this one more bullet proof. > > See my new patch. I would leave BasicStyle#getFillPat

Re: [JPP-Devel] [ANN]: WFSPlugin 1.0.0 released

2007-06-05 Thread Sunburned Surveyor
Stephan, Good work! I don't use WFS personally, but I'm sure the other users appreciate your contributions. The Sunburned Surveyor On 6/4/07, Stephan Holl <[EMAIL PROTECTED]> wrote: > Hello OpenJUMP users, > > the development of a WFSPlugin has started in early april and a first > version was gi

Re: [JPP-Devel] writing help for Openjump

2007-06-05 Thread Sunburned Surveyor
Guiseppe, I will make time to edit the documentation you write. I will also try to make time to move it over to Scribus, but I can't make any promises here. Thank you very much for your contributions. This is really great. The Sunburned Surveyor On 6/5/07, Giuseppe Aruta <[EMAIL PROTECTED]> wro

Re: [JPP-Devel] R: Common Feature model

2007-06-05 Thread Sunburned Surveyor
Paolo, Thank you very much for your input. You make some very good points, and some of these same points were brought out in our earlier discussions on this topic. Paolo wrote: "Maybe the situation has improved in the last year or so, but one of the reason why we decided to abandon uDig and GeoSe

Re: [JPP-Devel] R: Support for non-spatial features...

2007-06-05 Thread Sunburned Surveyor
Paolo, I had considered this option, but thought the external plug-in might provide a cleaner road. But you are correct, I think this would work. The Sunburned Surveyor On 6/5/07, P.Rizzi Ag.Mobilità Ambiente <[EMAIL PROTECTED]> wrote: > There's a dirty path you may follow to support non spatial

Re: [JPP-Devel] writing help for Openjump - Menu>Edit function help

2007-06-05 Thread Sunburned Surveyor
Thanks Giuseppe. I'll take a look at this in the next few days and get back to you if I have any edits. The Sunburned Surveyor On 6/5/07, Giuseppe Aruta <[EMAIL PROTECTED]> wrote: > This is the Menu>Edit functions Help > > Giuseppe Aruta > > > ___ > L'email de

Re: [JPP-Devel] Memory used by features in a Layer

2007-06-05 Thread Sunburned Surveyor
Paul, I can't think of any other references that are created as part of a typical Feature object. However, anti-typical Feature objects might contain Objects as one or more of their attributes, and these "custom" attributes could have all types of other references. I don't think this happens a lo

Re: [JPP-Devel] deegree Feature Model for OJ [was: Re: R: Common Feature model]

2007-06-05 Thread Sunburned Surveyor
Martin, Are my efforts to slowly integrate GeoTools into OpenJUMP misguided? Markus mentioned using some of the code from the Deegree project. However, I don't know if the Deegree project contains the source code for things like data I/O and map projections. If the Deegree project does contain th

Re: [JPP-Devel] R: Common Feature model

2007-06-05 Thread Martin Davis
A comment on this... I'm not positioning this as a "competitor to GeoTools", but in the last release of JUMP we did split the JUMP jars into two, what we called the JUMP core and the the JUMP Workbench UI. Is that what you're thinking, SS? The core contains things like the Feature model, the v

Re: [JPP-Devel] new files changelog, changes and todo on CVS

2007-06-05 Thread Sascha L. Teichmann
> > P.S - Stefan: What is the difference between the Changes file and the > ChangeLog files? Even if I'm not Stefan: Changes.txt is summary of ChangeLog. Very useful for releases and show the progress to the users. They are not interested in the technical details. Look at [1] and [2] to see what

Re: [JPP-Devel] R: Support for non-spatial features...

2007-06-05 Thread Martin Davis
Yup, I've used this approach to "fake" non-spatial layers, and it works pretty well. Or you can always just put an empty GeometryCollection in the GEOMETRY attribute. You can even use a single GC object for all Feature instances, since they are never modified in JUMP. Really the issues aroun

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Sascha L. Teichmann
Okay, I 'grep'ed the sources carefully and could not find any other place were it may come to problems. I've tested the styling stuff quiet intensively now and I feel pretty sure about this patches. If no one disapproves I will commit them tomorrow. - Sascha Larry Becker schrieb: > Works great a

Re: [JPP-Devel] R: Support for non-spatial features...

2007-06-05 Thread Paul Austin
Hi Martin, I really like the combination of your catalogue idea and the Styling Layer idea. The catalogue contains a hierarchy of data sources (files, database connections) and below them contains one data table (layer in file for multi layer files or database table). Need to come up with a ni

Re: [JPP-Devel] R: Support for non-spatial features...

2007-06-05 Thread Martin Davis
Yep, that was the grand vision. I envisioned a tree view where you could organize and define all the data sources (files, databases, CRSes, WMS, WFS in the future...). Some of them might have multiple "data tables" (FeatureDatasets?) below them. You could drag'n'drop data tables to layer vie

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Michaël Michaud
my vote : +1 Michael Sascha L. Teichmann a écrit : >Okay, > >I 'grep'ed the sources carefully and could not find any other >place were it may come to problems. I've tested the styling stuff >quiet intensively now and I feel pretty sure about this patches. >If no one disapproves I will commit the

Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...

2007-06-05 Thread Stefan Steiniger
you now guy's i agree with the things you say, but my question was also rather technically. While you answerd my first (obvious) question that i can use branching I still have a problem. The problem is, that i can not create (in eclipse) a branch from the src folder which is within the openjump

Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...

2007-06-05 Thread Paul Austin
Stefan, I'm not sure why in eclipse you are just checking out the src directory and not the whole OpenJump and then just setting adding src as a source folder in eclipse. Paul - This SF.net email is sponsored by DB2 Express

Re: [JPP-Devel] Expensive construction of BasicStyle objects.

2007-06-05 Thread Stefan Steiniger
+1 too :) Michaël Michaud schrieb: > my vote : +1 > > Michael > > Sascha L. Teichmann a écrit : > >> Okay, >> >> I 'grep'ed the sources carefully and could not find any other >> place were it may come to problems. I've tested the styling stuff >> quiet intensively now and I feel pretty sure abo

Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...

2007-06-05 Thread Stefan Steiniger
Hei Paul, it is not about checking out. I simply don't have the cvs option in eclipse on the src folder, while i have it for the openjump module (in the cvs explorer view of eclipse). but maybe i don't see the relaion mhm.. that's curious. I just tried with the Tortoise client and it did somet

Re: [JPP-Devel] new files changelog, changes and todo on CVS

2007-06-05 Thread Stefan Steiniger
Salut Michael (i currently cant follow the list - to much is going on) Michaël Michaud schrieb: > Hi, > > Thanks Stefan, > Is there a way to use sourceforge cvs log to help completing the > changelog file you just added ? i hope sascha's answer was sufficient.. i have not used it yet and did l

Re: [JPP-Devel] new files changelog, changes and todo on CVS

2007-06-05 Thread Sunburned Surveyor
Sascha, Thank you for the explanation. I understand now that the Changes text is for users, while ChangeLog is for developers. SS On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > > > > P.S - Stefan: What is the difference between the Changes file and the > > ChangeLog files? > > Even

Re: [JPP-Devel] deegree Feature Model for OJ [was: Re: R: Common Feature model]

2007-06-05 Thread Markus Müller
Hi Landon, Sunburned Surveyor schrieb: > Martin, > > Are my efforts to slowly integrate GeoTools into OpenJUMP misguided? > > Markus mentioned using some of the code from the Deegree project. > However, I don't know if the Deegree project contains the source code > for things like data I/O and map

Re: [JPP-Devel] deegree Feature Model for OJ [was: Re: R: Common Feature model]

2007-06-05 Thread Paul Austin
I am also interested in migrating my work to use the geotools API and have had a quick look at both the deegree and geotools feature model. Looking at the deegree DefaultFeature implementation each feature contains 4 different arrays/collections for storing attribute values and the attribute n

Re: [JPP-Devel] deegree Feature Model for OJ [was: Re: R: Common Feature model]

2007-06-05 Thread Stephan Holl
Hello Markus, Markus Müller <[EMAIL PROTECTED]>, [20070606 - 07:36:37] > Hi Landon, > > Sunburned Surveyor schrieb: > > Martin, > > > > Are my efforts to slowly integrate GeoTools into OpenJUMP misguided? > > > > Markus mentioned using some of the code from the Deegree project. > > However, I do