date:20070605

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 name and value are wrapped in a FeatureProperty instance. 
If you look at this in context of one of my data sets which loads 
140,000 features into memory this would dramatically increase the amount 
of memory used compared with the existing JUMP feature model.


If we look at the DefaultFeature in GeoTools the attributes are stored 
as a single Object array and has a String id, reference to the schema, 
envelope and link to the feature collection. This is very similar to the 
JUMP features except it has some additional fields.


If we look at my DataObject implementation it uses a Map and (an List of 
Attribute instances which I plan to remove) and a reference to a 
ClassDefinition (schema). I hope to retire this for one of the above.


At a basic level with the models for feature instances you need at a 
minimum.


get/setAttribute by index or name (or Property depending on name preference)
getAttributeCount
get/set DefaultGeometry
get/set Id

Maybe there could be a way for all groups to agree on a standard 
interface for the above items and then each group can have their own 
concrete implementations for features that meet their needs.


Paul

Sunburned Surveyor wrote:

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 this code, perhaps Markus can let me know.

My original desire to tap into GeoTools came from my desire to avoid
writing new Shapefile drivers for JUMP. It looked like the GeoTools
developers had done some good work in this area.

However, it seems like there is a lot of opposition to this effort on
my part. Perhaps I should tinker with GeoTools in my own work and quit
discussing it on the mailing list?

Is there any other OpenJUMP developer that is interested in tapping
into GeoTools? If there isn't I'll back off on the whole idea.

The Sunburned Surveyor


On 6/4/07, Martin Davis <[EMAIL PROTECTED]> wrote:
  

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'm not keen to dive in and
make a wholesale change to something which is much more complex and much
more volatile.  I'd much rather see slow and steady incremental improvement.

Maybe there will come a day when the GT/GeoAPI model has been stable for
a couple of years and it is blindingly obvious that it is the One True
Geospatial API - at that time JUMP can maybe migrate to it.

If people really need a more complex Feature model etc - there's always
uDig!

Martin


Markus Müller wrote:


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 soon pretty important. The
deegree2 Feature Model was put to use in a number of projects and it is
stable. So I propose (again): if OJ goes into the direction of support
for complex features, please consider using the deegree Feature Model.

Additionally I want to propose that if such a decision (regarding a
complex feature model) is made, this should IMHO be done in a new,
experimental branch of the OJ CVS, as (as Paolo says) a simple Feature
Model has a number of advantages such as simplicity and stability. I
would be good if this new development would go through some development
stages, before a final decision is made.


best regards,

Markus


P.Rizzi Ag.Mobilità Ambiente schrieb:

  

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 that it has a simple Feature model
and that it works!!!
If you want to move to a more complex model you should be aware that
you may end up losing simplicity and stability.
About using GeoTools DataStores (aka drivers) to access data,
that was one other reason why we abandoned it.
DataStores for PostGIS and Oracle had many bugs, but no one cared
to fix them. And the changing Feature model prevented us to fix them
on our own, without wasting a lot of time keeping in sync with the changes.
If you want t

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 projections. If the Deegree project
> does contain this code, perhaps Markus can let me know.
>   
Well, .. It does... ;-)
Just have a look at deegree (http://www.deegree.org/). It has a public SVN.

My point simply is: we (lat/lon, being the major developer of deegree) 
work for a while with and contribute to OJ (see Ugo's work, and the WFS 
plugin announced by Stephan). We will contribute more to OJ in the 
future (a number of plugins are planned). If we find the funding (and 
the chances are not so bad) we will start implementing a complex Feature 
Model for OJ (well, if the community wants this). So: I think there are 
some good reasons for looking at deegree and its feature model - besides 
the fact that it is stable and well-tested.


cheers,

Markus


> My original desire to tap into GeoTools came from my desire to avoid
> writing new Shapefile drivers for JUMP. It looked like the GeoTools
> developers had done some good work in this area.
>
> However, it seems like there is a lot of opposition to this effort on
> my part. Perhaps I should tinker with GeoTools in my own work and quit
> discussing it on the mailing list?
>
> Is there any other OpenJUMP developer that is interested in tapping
> into GeoTools? If there isn't I'll back off on the whole idea.
>
> The Sunburned Surveyor
>
>
> On 6/4/07, Martin Davis <[EMAIL PROTECTED]> wrote:
>   
>> 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'm not keen to dive in and
>> make a wholesale change to something which is much more complex and much
>> more volatile.  I'd much rather see slow and steady incremental improvement.
>>
>> Maybe there will come a day when the GT/GeoAPI model has been stable for
>> a couple of years and it is blindingly obvious that it is the One True
>> Geospatial API - at that time JUMP can maybe migrate to it.
>>
>> If people really need a more complex Feature model etc - there's always
>> uDig!
>>
>> Martin
>>
>>
>> Markus Müller wrote:
>> 
>>> 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 soon pretty important. The
>>> deegree2 Feature Model was put to use in a number of projects and it is
>>> stable. So I propose (again): if OJ goes into the direction of support
>>> for complex features, please consider using the deegree Feature Model.
>>>
>>> Additionally I want to propose that if such a decision (regarding a
>>> complex feature model) is made, this should IMHO be done in a new,
>>> experimental branch of the OJ CVS, as (as Paolo says) a simple Feature
>>> Model has a number of advantages such as simplicity and stability. I
>>> would be good if this new development would go through some development
>>> stages, before a final decision is made.
>>>
>>>
>>> best regards,
>>>
>>> Markus
>>>
>>>
>>> P.Rizzi Ag.Mobilità Ambiente schrieb:
>>>
>>>   
 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 that it has a simple Feature model
 and that it works!!!
 If you want to move to a more complex model you should be aware that
 you may end up losing simplicity and stability.
 About using GeoTools DataStores (aka drivers) to access data,
 that was one other reason why we abandoned it.
 DataStores for PostGIS and Oracle had many bugs, but no one cared
 to fix them. And the changing Feature model prevented us to fix them
 on our own, without wasting a lot of time keeping in sync with the changes.
 If you want to use GT DataStores, you could write a simple adapter
 that converts between their Feture model and JUMP on the fly.

 Bye
 Paolo Rizzi




 
> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] conto di
> Sunburned Surveyor
> Inviato: martedì 5 giugno 2007 1.29
> A: List for discussion of JPP development and use.
> Cc: Geotools-Devel list
> Oggetto: Re: [JPP-Devel] Common Feature model
>

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

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 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 I mean.
>
> - Sascha
>
> [1]
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/Changes.txt
>
> [2]
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/Changes.txt?revision=1.4
>
>
>
> -
> 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] new files changelog, changes and todo on CVS

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 
look only on the wfs and printplugin files for an example

> 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 ?

i think the todo list in src folder is our personal (devel) thing and we 
shoudl also add here the improtant bugs that we receive at sourceforge.
I also aggree with Sascha that it is somehow important not to rely on 
the wiki or webpages - thats rather for the publicity. Priority from now 
on should be on the comments in the new files (because i also have a 
personal todo list on my laptop related to ojump - which i can now move 
:o)

bon nuit

stefan

> 
> Michaël
> 
> Sunburned Surveyor a écrit :
> 
>> Thanks for taking care of this Stefan. Hopefully Sascha approves!
>>
>> SS
>>
>> On 6/2/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
>>  
>>
>>> btw. to check the files out in eclipse I used:
>>>
>>> - cvs repository explorer view
>>> - selected the src folder
>>> - chosed "checkout as..." from the mouse menu
>>> - disabled the "subfolder" checkbox
>>> - selected "check out into existing project"
>>>
>>> - i chosed my openjump project (but i could not remove the folder name
>>> "src", thus the change log files will be in that project sub-folder -
>>> but a renaming to "changelog" should be possible)
>>>
>>> stefan
>>>
>>>
>>> Stefan Steiniger schrieb:
>>>
>>>
 Hei Guys,

 i added to the cvs module openjump\src\ three log files.
 Please check them out to enable a better logging of changes.

 I hope it is what Sascha expected?

 stefan

 PS: i dont know why my eclipse now wants to update the complete
 openjump\src tree. I hope it is only a problem with my machine and not
 yours as well.

 -
 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
>>>
>>>
>>>
>> -
>> 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
> 
> 

-
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] Unstable branch of the OpenJUMP CVS...

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 
something with the "src" folder

i tried to created a branch called: oj_stable_1_2_beta... or so
but it does not seem like eclipse recognizes the branch??? Maybe it 
tagged it only locally and i need to commit it?

puh.. i should read probably something on it

stefan

Paul Austin schrieb:
> 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
> 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] Expensive construction of BasicStyle objects.

+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 about this patches.
>> If no one disapproves I will commit them tomorrow.
>>
>> - Sascha
>>
>> Larry Becker schrieb:
>>  
>>
>>> 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#getFillPattern()
 untouched.


 Larry Becker schrieb:
  

> 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,
>  2, false, true);
>  }
>return fillPattern;
>}
>
> The only side effect is that initially in the Change Styles Rendering
> Tab, the Fill pattern is 0 grey.  However when you check the Fill
> pattern check box, it turns solid black and works correctly so I don't
> see this as an issue.
>
> regards,
> Larry
>
> On 6/5/07, Larry Becker <[EMAIL PROTECTED]> wrote:
>
>
>> 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.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
>>at 
>> com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
>>at 
>> com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.(RenderingStylePanel.java:189)
>>at 
>> com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)
>>
>> regards,
>> Larry
>>
>> On 6/5/07, Paul Austin <[EMAIL PROTECTED]> wrote:
>>  
>>
>>> 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 an attribute on a tag.
>>>
>>> +fill = fill == null
>>> +? fillPatternComboBox.getItemAt(0)
>>> +: findEquivalentItem(fill, fillPatternComboBox);
>>>
>>> BTW does this improvement only improve speed if you have a themed layer
>>> or will it speed up all layers?
>>>
>>> Paul
>>>
>>> -
>>> 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
>>>
>>>
>>>
>> --
>> http://amusingprogrammer.blogspot.com/
>>
>>  
>>
 Index: src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java
 ===
 RCS file: 
 /cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java,v
 retrieving revision 1.4
 diff -u -r1.4 BasicStylePanel.java
 --- src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 13 
 May 2007 13:24:55 -  1.4
 +++ src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 5 
 Jun 2007 17:57:16 -
 @@ -457,8 +457,12 @@
 //Because fillPatternComboBox is not editable, we must use 
 findEquivalentItem,
 //otherwise the combobox gets confused and a stack overflow occurs
 //if the two items are equal but not == . [Jon Aquino]
 -fillPatternComboBox.setSelectedItem(findEquivalentItem(
 -basicStyle.getFillPattern(), fillPatternComboBox));
 +
 +   Object fill = 
 findE

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

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
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] Unstable branch of the OpenJUMP CVS...

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 module, but only from the openjump 
module itself. this is rather stupid (engl.?) since we would need copy 
the complete stuff inside .. otherwise we need to restructure the cvs? 
(which breaks also the nightly built setup by Jon)

or am i wrong?

stefan

Stephan Holl schrieb:
> Hello Craig, SS,
> 
> "A. Craig West" <[EMAIL PROTECTED]>, [20070604 - 22:22:16]
> 
>> Normally, the head is the unstable code, and any changes which have
>> been tested get merged to the stable branch...
> 
> Yes, that was my intention to tell as well. I strongly suggest to
> follow this schema in OJ-development as well.
> 
>> On 6/4/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
>>> Stephan,
>>>
>>> You wrote: "I am more than happy to watch the process of getting a
>>> development trunk in OpenJUMP development."
>>>
>>> That is awesome. I don't think that anyone is going to argue with
>>> your volunterring. :]
>>>
>>> You wrote: "The so called trunk is the (current) CVS HEAD which gets
>>> branched into release-branches which can be kept separately."
>>>
>>> I think I am trying to describe the same thing, but not as well.I
>>> may have incorrectly referred to a "stable branch" and an "unstable
>>> branch" when what we really want is a stable code in the trunk or
>>> CVS HEAD and a branch for the unstable code.
>>>
>>> The Sunburned Surveyor
>>>
>>> P.S. - Are you a registered developer on SourceForge? You will need
>>> to be registered before we will be able to give you admin rights to
>>> the CVS repository at the JPP.
> 
> Yes, I do have an account, I have access to CVS, at least to the
> modules WFSPlugin and PrintLayoutPlugin which I manage.
> 
> [snip]
> 
> Best
>   Stephan
> 
> 
> 

-
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] 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 them tomorrow.
>
>- Sascha
>
>Larry Becker schrieb:
>  
>
>>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#getFillPattern()
>>>untouched.
>>>
>>>
>>>Larry Becker schrieb:
>>>  
>>>
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,
  2, false, true);
  }
return fillPattern;
}

The only side effect is that initially in the Change Styles Rendering
Tab, the Fill pattern is 0 grey.  However when you check the Fill
pattern check box, it turns solid black and works correctly so I don't
see this as an issue.

regards,
Larry

On 6/5/07, Larry Becker <[EMAIL PROTECTED]> wrote:


>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.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
>at 
> com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
>at 
> com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.(RenderingStylePanel.java:189)
>at 
> com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)
>
>regards,
>Larry
>
>On 6/5/07, Paul Austin <[EMAIL PROTECTED]> wrote:
>  
>
>>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 an attribute on a tag.
>>
>>+fill = fill == null
>>+? fillPatternComboBox.getItemAt(0)
>>+: findEquivalentItem(fill, fillPatternComboBox);
>>
>>BTW does this improvement only improve speed if you have a themed layer
>>or will it speed up all layers?
>>
>>Paul
>>
>>-
>>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
>>
>>
>>
>--
>http://amusingprogrammer.blogspot.com/
>
>  
>
>>>Index: src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java
>>>===
>>>RCS file: 
>>>/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java,v
>>>retrieving revision 1.4
>>>diff -u -r1.4 BasicStylePanel.java
>>>--- src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 13 
>>>May 2007 13:24:55 -  1.4
>>>+++ src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 5 
>>>Jun 2007 17:57:16 -
>>>@@ -457,8 +457,12 @@
>>> //Because fillPatternComboBox is not editable, we must use 
>>> findEquivalentItem,
>>> //otherwise the combobox gets confused and a stack overflow occurs
>>> //if the two items are equal but not == . [Jon Aquino]
>>>-fillPatternComboBox.setSelectedItem(findEquivalentItem(
>>>-basicStyle.getFillPattern(), fillPatternComboBox));
>>>+
>>>+   Object fill = 
>>>findEquivalentItem(basicStyle.getFillPattern(), fillPatternComboBox);
>>>+
>>>+   if (fill != null)
>>>+   
>>>fillPatternComboBox.setSelectedItem(fill);
>>>+
>>> updateControls();

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

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 views, and then style them.

I even envisioned the ability to support multiple Catalogs, which would 
manage the data sources for a set of related Tasks.  (This is really 
where the Project idea came from - it was intended to support multiple 
Tasks).

In fact, maybe Project is really the same as Catalog.  This would just 
be giving an explicit UI to the Project concept, and making it more 
concrete and better supported in JUMP.  Not sure... maybe they are a bit 
different.  Catalog might be more global in scope and have a longer 
lifetime that a given Project, and be focussed purely on data sources 
(whereas Project would contain all the other user settings as well).  
But I'm worried about creating too many of these "managing container" 
concepts - it all takes effort to design and maintain.

Paul Austin wrote:
> 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 
> nicer name than data table for the things that read features from a 
> data source.
>
> We then have the current category and layer view for the visual layers 
> where you can organize the visual layers which are attached to a data 
> table (or raster source for WMS or local raster files).
>
> Paul
>
> Martin Davis wrote:
>> 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 around handling non-spatial layers lie more with 
>> creating a nice UI for them, which will present a nice intuitive model 
>> to the user.  Part of this involves making the current tools sensitive 
>> to whether a layer is non-spatial, so they are visually disabled when a 
>> non-spatial layer in in focus.  This however does require some 
>> indication that a layer is non-spatial.  One way to do this would be to 
>> extend Feature and FeatureSchema with a method "hasGeometry".
>>
>> It might also be nice to support Features with more than one Geometry.  
>> In this case, the schema needs to indicate which Geometry attribute is 
>> the "primary" one, which will be returned by the getGeometry method.
>>
>> This reminds me of another feature we added to RoadMatcher, which might 
>> be nice to have in JUMP.  We supported the idea of "Styling Layers".  
>> These are virtual layers backed by a real Layer, which allowed different 
>> kinds of styling to be applied to a single layer.  These might be useful 
>> for the multi-Geometry concept, because a StylingLayer could also depict 
>> a different Geometry attribute (i.e. not just the default) from a 
>> Layer's FeatureSchema.
>>
>> Sunburned Surveyor wrote:
>>   
>>> 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 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
 NullPointer exceptions if you load a Layer from a DataStore query
 that results in one or more records with empty geometries.

 After that the layer is treated like any other one, although it's not 
 rendered.

 You can even think of some kind of "calculator" class you can attach
 to the Layer (maybe through BeanShell) that can "calculate" the
 geometry field on the fly, making a non spatial layer spatial.

 Bye
 Paolo Rizzi

> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] conto di
> Sunburned Surveyor
> Inviato: martedì 5 giugno 2007 0.33
> A: List for discussion of JPP development and use.
> Oggetto: [JPP-Devel] Support for non-spatial features...
>
>
> I thought I would start a new thread so we could split this apart from
> the discussion that Paul and Martin were having about the FeatureInfo
> tool.
>
> When I suggested that support for non-spatial features could be
> included in a p

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





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
nicer name than data table for the things that read features from a
data source.

We then have the current category and layer view for the visual layers
where you can organize the visual layers which are attached to a data
table (or raster source for WMS or local raster files).

Paul

Martin Davis wrote:

  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 around handling non-spatial layers lie more with 
creating a nice UI for them, which will present a nice intuitive model 
to the user.  Part of this involves making the current tools sensitive 
to whether a layer is non-spatial, so they are visually disabled when a 
non-spatial layer in in focus.  This however does require some 
indication that a layer is non-spatial.  One way to do this would be to 
extend Feature and FeatureSchema with a method "hasGeometry".

It might also be nice to support Features with more than one Geometry.  
In this case, the schema needs to indicate which Geometry attribute is 
the "primary" one, which will be returned by the getGeometry method.

This reminds me of another feature we added to RoadMatcher, which might 
be nice to have in JUMP.  We supported the idea of "Styling Layers".  
These are virtual layers backed by a real Layer, which allowed different 
kinds of styling to be applied to a single layer.  These might be useful 
for the multi-Geometry concept, because a StylingLayer could also depict 
a different Geometry attribute (i.e. not just the default) from a 
Layer's FeatureSchema.

Sunburned Surveyor wrote:
  
  
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 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
NullPointer exceptions if you load a Layer from a DataStore query
that results in one or more records with empty geometries.

After that the layer is treated like any other one, although it's not rendered.

You can even think of some kind of "calculator" class you can attach
to the Layer (maybe through BeanShell) that can "calculate" the
geometry field on the fly, making a non spatial layer spatial.


Bye
Paolo Rizzi




  
  
-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Per conto di
Sunburned Surveyor
Inviato: martedì 5 giugno 2007 0.33
A: List for discussion of JPP development and use.
Oggetto: [JPP-Devel] Support for non-spatial features...


I thought I would start a new thread so we could split this apart from
the discussion that Paul and Martin were having about the FeatureInfo
tool.

When I suggested that support for non-spatial features could be
included in a plug-in Martin wrote: "I had similar thoughts a while
back.  In fact, the Feature concept
easily supports non-spatial features.  About all that is
required is to
get the UI to recognize non-spatial Feature Schemas and do sensible
things with them  (such as display a little table icon rather than the
symbology icon in the Layer List panel, and not display the button for
View/Edit Geometry).

There's quite a few of these kinds of changes required to support this
cleanly, but I don't think any of them are very difficult.  This
is more than just a single plugin, tho - it's a more of a
generalization
of the existing Feature framework."

I still think you could encapsulate this functionality in a plug-in or
set of plug-ins. This might not be the best way to go long term, but
it could let us test out how things would work without messing with
the core.

For example, I wouldn't even mess with the Layer List. I'd create a
separate UI component that could be used to manage non-spatial feature
collections or tables. We could make it look similar to the Layer List
for purposes of consistency. I think it would be a little confusing to
include symbols for non-spatial feature collections in the Layer List.
They wouldn't affect the display order for one thing, and we currently
use the visual arrangement of layers in the Layer List to do this.

I imagined a plug-in that created a "Non-Spatial Feature" menu entry
somewhere. This

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

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 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#getFillPattern()
>> untouched.
>>
>>
>> Larry Becker schrieb:
>>> 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,
>>>   2, false, true);
>>>   }
>>> return fillPattern;
>>> }
>>>
>>> The only side effect is that initially in the Change Styles Rendering
>>> Tab, the Fill pattern is 0 grey.  However when you check the Fill
>>> pattern check box, it turns solid black and works correctly so I don't
>>> see this as an issue.
>>>
>>> regards,
>>> Larry
>>>
>>> On 6/5/07, Larry Becker <[EMAIL PROTECTED]> wrote:
 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.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
 at 
 com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
 at 
 com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.(RenderingStylePanel.java:189)
 at 
 com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)

 regards,
 Larry

 On 6/5/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> 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 an attribute on a tag.
>
> +fill = fill == null
> +? fillPatternComboBox.getItemAt(0)
> +: findEquivalentItem(fill, fillPatternComboBox);
>
> BTW does this improvement only improve speed if you have a themed layer
> or will it speed up all layers?
>
> Paul
>
> -
> 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
>
 --
 http://amusingprogrammer.blogspot.com/

>>>
>> Index: src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java
>> ===
>> RCS file: 
>> /cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java,v
>> retrieving revision 1.4
>> diff -u -r1.4 BasicStylePanel.java
>> --- src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 13 
>> May 2007 13:24:55 -  1.4
>> +++ src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 5 
>> Jun 2007 17:57:16 -
>> @@ -457,8 +457,12 @@
>>  //Because fillPatternComboBox is not editable, we must use 
>> findEquivalentItem,
>>  //otherwise the combobox gets confused and a stack overflow occurs
>>  //if the two items are equal but not == . [Jon Aquino]
>> -fillPatternComboBox.setSelectedItem(findEquivalentItem(
>> -basicStyle.getFillPattern(), fillPatternComboBox));
>> +
>> +   Object fill = 
>> findEquivalentItem(basicStyle.getFillPattern(), fillPatternComboBox);
>> +
>> +   if (fill != null)
>> +   
>> fillPatternComboBox.setSelectedItem(fill);
>> +
>>  updateControls();
>>  }
>>
>> @@ -477,6 +481,16 @@
>>  }
>>
>>  private Object findEquivalentItem(Object item, JComboBox comboBox) {
>> +
>> +   if (comboBox == null)
>> +

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

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 around handling non-spatial layers lie more with 
creating a nice UI for them, which will present a nice intuitive model 
to the user.  Part of this involves making the current tools sensitive 
to whether a layer is non-spatial, so they are visually disabled when a 
non-spatial layer in in focus.  This however does require some 
indication that a layer is non-spatial.  One way to do this would be to 
extend Feature and FeatureSchema with a method "hasGeometry".

It might also be nice to support Features with more than one Geometry.  
In this case, the schema needs to indicate which Geometry attribute is 
the "primary" one, which will be returned by the getGeometry method.

This reminds me of another feature we added to RoadMatcher, which might 
be nice to have in JUMP.  We supported the idea of "Styling Layers".  
These are virtual layers backed by a real Layer, which allowed different 
kinds of styling to be applied to a single layer.  These might be useful 
for the multi-Geometry concept, because a StylingLayer could also depict 
a different Geometry attribute (i.e. not just the default) from a 
Layer's FeatureSchema.

Sunburned Surveyor wrote:
> 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 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
>> NullPointer exceptions if you load a Layer from a DataStore query
>> that results in one or more records with empty geometries.
>>
>> After that the layer is treated like any other one, although it's not 
>> rendered.
>>
>> You can even think of some kind of "calculator" class you can attach
>> to the Layer (maybe through BeanShell) that can "calculate" the
>> geometry field on the fly, making a non spatial layer spatial.
>>
>>
>> Bye
>> Paolo Rizzi
>>
>>
>>
>> 
>>> -Messaggio originale-
>>> Da: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] conto di
>>> Sunburned Surveyor
>>> Inviato: martedì 5 giugno 2007 0.33
>>> A: List for discussion of JPP development and use.
>>> Oggetto: [JPP-Devel] Support for non-spatial features...
>>>
>>>
>>> I thought I would start a new thread so we could split this apart from
>>> the discussion that Paul and Martin were having about the FeatureInfo
>>> tool.
>>>
>>> When I suggested that support for non-spatial features could be
>>> included in a plug-in Martin wrote: "I had similar thoughts a while
>>> back.  In fact, the Feature concept
>>> easily supports non-spatial features.  About all that is
>>> required is to
>>> get the UI to recognize non-spatial Feature Schemas and do sensible
>>> things with them  (such as display a little table icon rather than the
>>> symbology icon in the Layer List panel, and not display the button for
>>> View/Edit Geometry).
>>>
>>> There's quite a few of these kinds of changes required to support this
>>> cleanly, but I don't think any of them are very difficult.  This
>>> is more than just a single plugin, tho - it's a more of a
>>> generalization
>>> of the existing Feature framework."
>>>
>>> I still think you could encapsulate this functionality in a plug-in or
>>> set of plug-ins. This might not be the best way to go long term, but
>>> it could let us test out how things would work without messing with
>>> the core.
>>>
>>> For example, I wouldn't even mess with the Layer List. I'd create a
>>> separate UI component that could be used to manage non-spatial feature
>>> collections or tables. We could make it look similar to the Layer List
>>> for purposes of consistency. I think it would be a little confusing to
>>> include symbols for non-spatial feature collections in the Layer List.
>>> They wouldn't affect the display order for one thing, and we currently
>>> use the visual arrangement of layers in the Layer List to do this.
>>>
>>> I imagined a plug-in that created a "Non-Spatial Feature" menu entry
>>> somewhere. This menu entry would pull up a UI that would allow the
>>> user to create, delete, modify, and import/export non-spatial feature
>>> collections.
>>>
>>> Another related plug-in could be used to create associations between
>>> non-spatial feature collections and spatial feature collections. I
>>> think most of this functionality could be managed internally by the
>>> plug-in.
>>>
>>> These are just some ideas. :]

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

> 
> 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 I mean.

- Sascha

[1]
http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/Changes.txt

[2]
http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/Changes.txt?revision=1.4



-
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] R: Common Feature model

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 various I/O 
drivers, various utilities, warping, the Coordinate System support (such 
as it is), Jon's Java2XML API, the WMS core classes, etc.

I've used the core API in some projects I've done which weren't doing 
GUI stuff - it's nice to have it split out into a small, focussed JAR.

Sunburned Surveyor wrote:
> I
> think we will need to give some serious thought to splitting out some
> of JUMP's code into a reusable library that can compete with GeoTools.
>   

-
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] deegree Feature Model for OJ [was: Re: R: Common Feature model]

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 this code, perhaps Markus can let me know.

My original desire to tap into GeoTools came from my desire to avoid
writing new Shapefile drivers for JUMP. It looked like the GeoTools
developers had done some good work in this area.

However, it seems like there is a lot of opposition to this effort on
my part. Perhaps I should tinker with GeoTools in my own work and quit
discussing it on the mailing list?

Is there any other OpenJUMP developer that is interested in tapping
into GeoTools? If there isn't I'll back off on the whole idea.

The Sunburned Surveyor


On 6/4/07, Martin Davis <[EMAIL PROTECTED]> wrote:
> 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'm not keen to dive in and
> make a wholesale change to something which is much more complex and much
> more volatile.  I'd much rather see slow and steady incremental improvement.
>
> Maybe there will come a day when the GT/GeoAPI model has been stable for
> a couple of years and it is blindingly obvious that it is the One True
> Geospatial API - at that time JUMP can maybe migrate to it.
>
> If people really need a more complex Feature model etc - there's always
> uDig!
>
> Martin
>
>
> Markus Müller wrote:
> > 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 soon pretty important. The
> > deegree2 Feature Model was put to use in a number of projects and it is
> > stable. So I propose (again): if OJ goes into the direction of support
> > for complex features, please consider using the deegree Feature Model.
> >
> > Additionally I want to propose that if such a decision (regarding a
> > complex feature model) is made, this should IMHO be done in a new,
> > experimental branch of the OJ CVS, as (as Paolo says) a simple Feature
> > Model has a number of advantages such as simplicity and stability. I
> > would be good if this new development would go through some development
> > stages, before a final decision is made.
> >
> >
> > best regards,
> >
> > Markus
> >
> >
> > P.Rizzi Ag.Mobilità Ambiente schrieb:
> >
> >> 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 that it has a simple Feature model
> >> and that it works!!!
> >> If you want to move to a more complex model you should be aware that
> >> you may end up losing simplicity and stability.
> >> About using GeoTools DataStores (aka drivers) to access data,
> >> that was one other reason why we abandoned it.
> >> DataStores for PostGIS and Oracle had many bugs, but no one cared
> >> to fix them. And the changing Feature model prevented us to fix them
> >> on our own, without wasting a lot of time keeping in sync with the changes.
> >> If you want to use GT DataStores, you could write a simple adapter
> >> that converts between their Feture model and JUMP on the fly.
> >>
> >> Bye
> >> Paolo Rizzi
> >>
> >>
> >>
> >>
> >>> -Messaggio originale-
> >>> Da: [EMAIL PROTECTED]
> >>> [mailto:[EMAIL PROTECTED] conto di
> >>> Sunburned Surveyor
> >>> Inviato: martedì 5 giugno 2007 1.29
> >>> A: List for discussion of JPP development and use.
> >>> Cc: Geotools-Devel list
> >>> Oggetto: Re: [JPP-Devel] Common Feature model
> >>>
> >>>
> >>> There is almost too much good stuff going on around here to
> >>> keep up with. :]
> >>>
> >>> Paul wrote: "I agree if the open source GIS community can agree on a
> >>> single in memory Java representation for geographic features that
> >>> would make all the tools more interoperable."
> >>>
> >>> You should definitely get more involved with the GeoTools folks. We
> >>> had some pretty extensive discussion about this very issue not to long
> >>> ago on this mailing list. Some of the GeoTools folks participated, as
> >>> did Frank Wammerdam. (Frank is no longer subscribed.)
> >>>
> >>> I think we identified some of the reasons why adopting the GeoTools
> >>> feature model into OpenJUMP at "one time" isn't practical. However, we
> >>> had some general agreement that it would be good to mov

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

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 lot, but I
have heard of it. (For example, I know that some developers store an
additional JTS geometry in an "Object attribute".

The Sunburned Surveyor

On 6/5/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> 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 attribute value, can be any object type
>
> Are there any other objects which are created for each individual
> feature instance?
>
> Cheers,
> Paul
>
> -
> 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] writing help for Openjump - Menu>Edit function help

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 della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
> http://it.docs.yahoo.com/nowyoucan.html
> -
> 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] R: Support for non-spatial features...

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 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
> NullPointer exceptions if you load a Layer from a DataStore query
> that results in one or more records with empty geometries.
>
> After that the layer is treated like any other one, although it's not 
> rendered.
>
> You can even think of some kind of "calculator" class you can attach
> to the Layer (maybe through BeanShell) that can "calculate" the
> geometry field on the fly, making a non spatial layer spatial.
>
>
> Bye
> Paolo Rizzi
>
>
>
> > -Messaggio originale-
> > Da: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] conto di
> > Sunburned Surveyor
> > Inviato: martedì 5 giugno 2007 0.33
> > A: List for discussion of JPP development and use.
> > Oggetto: [JPP-Devel] Support for non-spatial features...
> >
> >
> > I thought I would start a new thread so we could split this apart from
> > the discussion that Paul and Martin were having about the FeatureInfo
> > tool.
> >
> > When I suggested that support for non-spatial features could be
> > included in a plug-in Martin wrote: "I had similar thoughts a while
> > back.  In fact, the Feature concept
> > easily supports non-spatial features.  About all that is
> > required is to
> > get the UI to recognize non-spatial Feature Schemas and do sensible
> > things with them  (such as display a little table icon rather than the
> > symbology icon in the Layer List panel, and not display the button for
> > View/Edit Geometry).
> >
> > There's quite a few of these kinds of changes required to support this
> > cleanly, but I don't think any of them are very difficult.  This
> > is more than just a single plugin, tho - it's a more of a
> > generalization
> > of the existing Feature framework."
> >
> > I still think you could encapsulate this functionality in a plug-in or
> > set of plug-ins. This might not be the best way to go long term, but
> > it could let us test out how things would work without messing with
> > the core.
> >
> > For example, I wouldn't even mess with the Layer List. I'd create a
> > separate UI component that could be used to manage non-spatial feature
> > collections or tables. We could make it look similar to the Layer List
> > for purposes of consistency. I think it would be a little confusing to
> > include symbols for non-spatial feature collections in the Layer List.
> > They wouldn't affect the display order for one thing, and we currently
> > use the visual arrangement of layers in the Layer List to do this.
> >
> > I imagined a plug-in that created a "Non-Spatial Feature" menu entry
> > somewhere. This menu entry would pull up a UI that would allow the
> > user to create, delete, modify, and import/export non-spatial feature
> > collections.
> >
> > Another related plug-in could be used to create associations between
> > non-spatial feature collections and spatial feature collections. I
> > think most of this functionality could be managed internally by the
> > plug-in.
> >
> > These are just some ideas. :]
> >
> > I think one danger of walking down the "non-spatial" feature path is
> > that we will begin to implement more and more traditional RDBMS
> > features. (For example: "Let's ass support for transactions to our
> > non-spatial feature collections."..."Let's add support for custom
> > datatypes to our non-spatial feature collections."..."Let's add
> > support for datatype constraints to our non-spatial feature
> > collections.") Perhaps the smart thing to do is to design a system for
> > non-spatial features that uses an embedded Java database that already
> > contains all of this functionality. I wouldn't have a problem with
> > this if we could access the database components directly without
> > having to mess with a JDBC layer. (Note: I'm not talking about storing
> > the attribute information for spatial features in an embedded
> > database. I think the Sigle team is already working on something like
> > this. I'm talking about storing the attributes of non-spatial
> > features.)
> >
> > Then again, maybe it wouldn't be a big deal to implement some RDBMS
> > features if we have support for non-spatial features in OpenJUMP. It
> > just seems like a waste of effort with all the work that must be going
> > on in open source Java databases.
> >
> > Michael wrote: "And what about having a way to join a spatial
> > layer in OJ to a
> > non-spatial db table or view, and to see the whole result as one flat
> > layer in OJ..."
> >
> > Good idea...
> >
> > Martin wrote: "Yes, definit

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

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 GeoServer
was indeed the GeoTools Feature model. They keep changing it, adding
more and more new functionalities, without bothering for
stability...About using GeoTools DataStores (aka drivers) to access
data, that was one other reason why we abandoned it. DataStores for
PostGIS and Oracle had many bugs, but no one cared
to fix them. And the changing Feature model prevented us to fix them
on our own, without wasting a lot of time keeping in sync with the changes."

I think we can all agree that there are some issues with how the
GeoTools Feature Model is managed. I have decided, at least for the
time being, to try and work with the developers at GeoTools to correct
these issues. I'm going to start incorporating the GeoTools feature
model in my own work when I can, and I'm going to scream bloody murder
whenever they change the public API. I think part of the problem with
GeoTools is that they don't have enough "end users" of their API that
are willing to pitch a fit when the continue to change things. I plan
on being that end user. :] My goal is to help GeoTools change the way
they manage their feature model for the better. I realize this will
not be easy, but I think it is worth the effort.

Paolo wrote: "If you want to move to a more complex model you should
be aware that you may end up losing simplicity and stability."

I really agree with you strongly on this. I worry about changing what
is a really simple feature model. It's easy to use and understand.
Look at what happened when they moved from GML 2 to GML 3. I think we
could run into the same type of problems if we aren't careful.

Paolo wrote: "If you want to use GT DataStores, you could write a simple adapter
that converts between their Feture model and JUMP on the fly."

I'm already planning on this. Jody Garnett has pointed me to some
documentation that explains part of what I need to know about the
GeoTools feature model. I also was told about some code by Edgar
Solding that could convert between GeoTools Features and JUMP
Features. I'm going to look at this closely in the next few weeks. (If
I can ever stop reading and responding to all of these e-mails.) :]

Jody Garnett has been very supportive of my efforts to start using
GeoTools in OpenJUMP. I really want to see if we can get a good
working relationship with the GeoTools community because I think we
have the opportunity to share a lot of code if we play our cards
right.

If for some reason this effort at collaboration doesn't work out I
think we will need to give some serious thought to splitting out some
of JUMP's code into a reusable library that can compete with GeoTools.
I believe it is pretty difficult for newcomers to use parts of JUMP's
code base without confusion. This is one advantage of GeoTools that we
will need to address if we don't want to hop into bed with them and
plan on being a valid alternative to what they offer. (This should be
a last resort for us. I believe the colloboration with GeoTools is
going to work well in the long run.)

The Sunburned Surveyor

On 6/5/07, P.Rizzi Ag.Mobilità Ambiente <[EMAIL PROTECTED]> wrote:
>
> 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 source GIS community can agree on a single in memory
> Java representation for geographic features that would make all the tools
> more interoperable. Right now I'm using my own schema and feature model but
> would prefer not to maintain that in the future. Here are the requirements I
> have.
>
>
> Ids can be any type not just an int
> Properties can contain complex objects including other features or POJO
> Properties can contain a collection (List or Set) value
> Features don't have to have a schema (useful when transforming a feature
> from one schema to another)
>
> Paul
>
>
>
> -
> 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
contr

Re: [JPP-Devel] writing help for Openjump

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]> wrote:
> Hi Sunburned Surveyor and Michael
>
> I know the good User manual  of OpenJUMP 1.0 from UWE
> and also the official Jump Manual. Project SIGLE also
> have a good documentation.
>
> What I am thinking about "help" is a sort of list that
> just  explains  all the functions (menu, tools and
> right-click mouse) of  Openjump.
> This list could be written in few  weeks, and  could
> be apart (in this moment) from the  manual, which
> requires more attention and details.
>
> When the help is ready (even in BETA version) we could
> put in in the Openjump Web Page as a PDF. This will
> help people to understand better the functions of
> OpenJUMP (and it helps, of coarse, to speed up the
> corrections of bugs!).
>
> Michael, my idea is not opposing the Online Help. We
> can put all the informations also online: some people
> can use online, other people who don't want (I am
> thinking about people who do not have a difficult
> access to internet, or thay pay a lot for a
> connection, or they simply want to have all the
> documentation printed) can download and share the PDF
> Help
>
> By the time that the manual is ready the Help document
> could be integrated in it, with all the hyperlinks and
> a better explanation.
>
> Since my idea is to have a "Help documentation" in a
> very short time, I decided to use OpenWriter to write
> it. All the images are in JPG file format and belong
> from screeshots of Openjump (I use Windows XP with
> "classical win2000" theme). Everything is  saved in
> PDF.
>
> I took the model of "Help" from the online help of
> FGIS, a GIS editor for forestry
> http://www.forestpal.com/Help/fGIS_help.html
>
> Sunburned Surveyor, we can work together. I will be
> glad if you help me for the english. There are also
> some functions on OpenJUMP which are still "occult"
> for me, and you probabily know better.
> I am sending the original document in OpenWriter
> (.odt) which you can use for editing the raw text and
> to correct.
>
> I think to write different documents for each Menu
> functions (es. File Menu, Edit Menu, View Menu) which
> can be easly corrected.
> I use Inkscape. I know Sribus but I never used it.
> By the time we have all the documentation in odt or
> rtf (after BETA version of Help) we can tranfer
> everything in Sribus.
>
>
> Giuseppe
>
>
>
>
>
>
> ___
> L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail:
> http://it.docs.yahoo.com/nowyoucan.html
> -
> 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] [ANN]: WFSPlugin 1.0.0 released

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 given to the community recently.
>
> Now with this release we have have fullfilled the roadmap within
> this project and release the WFSPlugin as 1.0.0.
>
> There are lots of bugfixes and some new features included.
>
> The plugin is known to work with OJ 1.0.1 and OJ 1.2b as well as with
> the nightly builds.
>
> Download binary here:
> http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=150819
>
>
> Installing:
> 1. Copy the wfsplugin.jar
>   into the lib/ext directory of
>   your OpenJump installation.
>
> 2. Install additional libraries needed to run the plugin.
>   Download the following jar files and put them into  installed OpenJUMP>/lib/ext:
>
>   
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/commons-codec-1.3.jar
>   
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/commons-logging.jar
>   
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/jaxen-1.1-beta-8.jar
>   
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/deegree2.jar
>   
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/commons-httpclient-2.0.2-deegreeversion.jar
>   
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/vecmath.jar
>
>   *IMPORTANT*:
>   If you tried version < 0.2.0 of WFSPlugin, you need to update at
>   least the deegree2.jar following the link below:
>   
> http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/deegree2.jar
>
> 3. Start your OpenJUMP and you should use the WFSPlugin-icon
>
> Possible features for upcoming versions:
> -
>  - make (poorly configured) UMN MapServer-WFS also available
>  - integrate WFS-T against geoserver/deegree
>  - more general SRS-integration (in deegree2)
>  - create user-documentation
>
>
> Have fun and all the best
>
>Stephan Holl
>
>
> --
> Stephan Holl <[EMAIL PROTECTED]>, http://intevation.de/~stephan
> Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998
> Geschäftsführer:  Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> -
> 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] Expensive construction of BasicStyle objects.

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#getFillPattern()
> untouched.
>
>
> Larry Becker schrieb:
> > 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,
> >   2, false, true);
> >   }
> > return fillPattern;
> > }
> >
> > The only side effect is that initially in the Change Styles Rendering
> > Tab, the Fill pattern is 0 grey.  However when you check the Fill
> > pattern check box, it turns solid black and works correctly so I don't
> > see this as an issue.
> >
> > regards,
> > Larry
> >
> > On 6/5/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> >> 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.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
> >> at 
> >> com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
> >> at 
> >> com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.(RenderingStylePanel.java:189)
> >> at 
> >> com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)
> >>
> >> regards,
> >> Larry
> >>
> >> On 6/5/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> >>> 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 an attribute on a tag.
> >>>
> >>> +fill = fill == null
> >>> +? fillPatternComboBox.getItemAt(0)
> >>> +: findEquivalentItem(fill, fillPatternComboBox);
> >>>
> >>> BTW does this improvement only improve speed if you have a themed layer
> >>> or will it speed up all layers?
> >>>
> >>> Paul
> >>>
> >>> -
> >>> 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
> >>>
> >>
> >> --
> >> http://amusingprogrammer.blogspot.com/
> >>
> >
> >
>
> Index: src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java
> ===
> RCS file: 
> /cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java,v
> retrieving revision 1.4
> diff -u -r1.4 BasicStylePanel.java
> --- src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 13 
> May 2007 13:24:55 -  1.4
> +++ src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 5 Jun 
> 2007 17:57:16 -
> @@ -457,8 +457,12 @@
>  //Because fillPatternComboBox is not editable, we must use 
> findEquivalentItem,
>  //otherwise the combobox gets confused and a stack overflow occurs
>  //if the two items are equal but not == . [Jon Aquino]
> -fillPatternComboBox.setSelectedItem(findEquivalentItem(
> -basicStyle.getFillPattern(), fillPatternComboBox));
> +
> +   Object fill = 
> findEquivalentItem(basicStyle.getFillPattern(), fillPatternComboBox);
> +
> +   if (fill != null)
> +   
> fillPatternComboBox.setSelectedItem(fill);
> +
>  updateControls();
>  }
>
> @@ -477,6 +481,16 @@
>  }
>
>  private Object findEquivalentItem(Object item, JComboBox comboBox) {
> +
> +   if (comboBox == null)
> +   return null;
> +
> +   if (item == null) {
> +   return comboBox.getItemCount() > 0
> +   ? comboBox.getItemAt(0)
> +   : null;
> +

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

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 ?"

I think it is important to make distinction between a bug report, a
feature request, and a programmer's todo. Here is how I imagine things
working with our current system and the files that Stefan has set up:

[1] We will use the Feature Request log at SourceForge to track user's
requests for new or additional features to JUMP. I don't think we
should track developer's requests for changes to the code or API in
this list. I think this should be for user requests. I'm talking about
the "I want to push a button and have this happen" stuff.

[2] We will use the Bug Tracker at SourceForge to track bugs. These
are problems that generally result from mistakes in the source code.
This is not a place to log comments like "I really wished function X
would do Y instead of what it does now." That type of comment should
be encapsulated in a Feature Request.

[3] The todo list that Stefan has set up in the CVS should be used to
track improvements or changes that programmers would like to make for
the source code. For example, I might be designing a new class or
working with an existing class and identify something that would be a
great improvement to JUMP's architecture, a way to clarify the source
code, or an opoortunity for optimization. But I might not have the
time to implement the improvement at that moment. I could add an entry
to the todo list for the improvement that I identified. (This would be
a great place to start new developers that want to help with OpenJUMP,
if we ever get any.) :]

Does this make sense to everyone? I'm open to sufggestions for a
better system. :]

Sascha wrote: "But ones again: Writing a ChangeLog this way is only for
the lazy. ChangeLog changes should be checked in each time
you do a check in."

Agreed. Reading a message generated automatically by the CVS
repository or some other tool doesn't tell me a lot about the reasons
why you are commiting the changes, or what those changes are.

Sascha wrote: "Wikis are not reliable in the long
term. It's not working off-line, depends on a internal data base
structure not accessible to to user (migration issues)."

Agreed. Wikis are great for collaborative documentation efforts, but I
think that the text files Stefan has set up in the CVS will work
better for logs."

The Sunburned Surveyor

P.S - Stefan: What is the difference between the Changes file and the
ChangeLog files?

-
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] Expensive construction of BasicStyle objects.

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 for null and then initialize the fillPattern as before.
> 
> public Paint getFillPattern() {
>   if (fillPattern == null) {
>   fillPattern = WKTFillPattern.createDiagonalStripePattern(4,
>   2, false, true);
>   }
> return fillPattern;
> }
> 
> The only side effect is that initially in the Change Styles Rendering
> Tab, the Fill pattern is 0 grey.  However when you check the Fill
> pattern check box, it turns solid black and works correctly so I don't
> see this as an issue.
> 
> regards,
> Larry
> 
> On 6/5/07, Larry Becker <[EMAIL PROTECTED]> wrote:
>> 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.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
>> at 
>> com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
>> at 
>> com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.(RenderingStylePanel.java:189)
>> at 
>> com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)
>>
>> regards,
>> Larry
>>
>> On 6/5/07, Paul Austin <[EMAIL PROTECTED]> wrote:
>>> 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 an attribute on a tag.
>>>
>>> +fill = fill == null
>>> +? fillPatternComboBox.getItemAt(0)
>>> +: findEquivalentItem(fill, fillPatternComboBox);
>>>
>>> BTW does this improvement only improve speed if you have a themed layer
>>> or will it speed up all layers?
>>>
>>> Paul
>>>
>>> -
>>> 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
>>>
>>
>> --
>> http://amusingprogrammer.blogspot.com/
>>
> 
> 
Index: src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java
===
RCS file: 
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java,v
retrieving revision 1.4
diff -u -r1.4 BasicStylePanel.java
--- src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 13 May 
2007 13:24:55 -  1.4
+++ src/com/vividsolutions/jump/workbench/ui/style/BasicStylePanel.java 5 Jun 
2007 17:57:16 -
@@ -457,8 +457,12 @@
 //Because fillPatternComboBox is not editable, we must use 
findEquivalentItem,
 //otherwise the combobox gets confused and a stack overflow occurs
 //if the two items are equal but not == . [Jon Aquino]
-fillPatternComboBox.setSelectedItem(findEquivalentItem(
-basicStyle.getFillPattern(), fillPatternComboBox));
+
+   Object fill = 
findEquivalentItem(basicStyle.getFillPattern(), fillPatternComboBox);
+
+   if (fill != null)
+   
fillPatternComboBox.setSelectedItem(fill);
+
 updateControls();
 }
 
@@ -477,6 +481,16 @@
 }
 
 private Object findEquivalentItem(Object item, JComboBox comboBox) {
+
+   if (comboBox == null)
+   return null;
+
+   if (item == null) {
+   return comboBox.getItemCount() > 0
+   ? comboBox.getItemAt(0)
+   : null;
+   }
+
 for (int i = 0; i < comboBox.getItemCount(); i++) {
 if (item.equals(comboBox.getItemAt(i))) {
 return comboBox.getItemAt(i);
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2

Re: [JPP-Devel] Javadoc for skyjump

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 PROTECTED]> wrote:
> 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
> > on sourceforge
> >
> > stefan
> >
> > Roman Isitua schrieb:
> > > Hello,
> > >
> > > I have checked the skyjump website and haven't found a
> > > link to download the javadoc for skyjump. I am sure i
> > > am missing something here. I am particularly
> > > interested in the database connection plugins.
> > >
> > > Roman
> > >
> > >
> > >
> > >
> > > 
> > > Get the free Yahoo! toolbar and rest assured with the added security of 
> > > spyware protection.
> > > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
> > >
> > > -
> > > 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
> >
>
> -
> 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
>


-- 
http://amusingprogrammer.blogspot.com/

-
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] Expensive construction of BasicStyle objects.

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,
2, false, true);
}
return fillPattern;
}

The only side effect is that initially in the Change Styles Rendering
Tab, the Fill pattern is 0 grey.  However when you check the Fill
pattern check box, it turns solid black and works correctly so I don't
see this as an issue.

regards,
Larry

On 6/5/07, Larry Becker <[EMAIL PROTECTED]> wrote:
> 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.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
> at 
> com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
> at 
> com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.(RenderingStylePanel.java:189)
> at 
> com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)
>
> regards,
> Larry
>
> On 6/5/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> > 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 an attribute on a tag.
> >
> > +fill = fill == null
> > +? fillPatternComboBox.getItemAt(0)
> > +: findEquivalentItem(fill, fillPatternComboBox);
> >
> > BTW does this improvement only improve speed if you have a themed layer
> > or will it speed up all layers?
> >
> > Paul
> >
> > -
> > 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
> >
>
>
> --
> http://amusingprogrammer.blogspot.com/
>


-- 
http://amusingprogrammer.blogspot.com/

-
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] Code Style Standards

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 have attached to this email.
>
> I recommend that you get the Eclipse plugin
> http://eclipse-cs.sourceforge.net/ and then set enable this
> for a project to check that you want to use all those rules (some of them
> you may not like) and then create a copy of it using the configuration page
> and disable those rules you don't want and save that file as the one for
> OpenJump.
>
> Paul
>
>
> Sunburned Surveyor wrote:
> Paul,

Please see my comments below.

Paul wrote: "I think a good set of
> standards to follow are the Sun Java Code
Conventions. It's a fairly short
> (ish) standard and avoids all the
variable prefix and class prefix
> stuff.

http://java.sun.com/docs/codeconv/CodeConventions.pdf";

I
> agree with you. This would be a simple standard to use.

Paul wrote: "So
> here is my argument for following code conventions
> and
import/code
formatting guidelines.

If two developers are making a set
> of changes to some files and they
both auto format the code but using
> different conventions when they go
to merge their changes with the other
> developer the diff tool will
highlight a whole bunch of changes for them to
> review that are just due
to the difference in formatting. So by following
> the same formatting
rules merging changes should be easier."

I think this
> is the best argument I have heard for following a code
style standard so
> far.

Paul wrote: "I would encourage (not enforce) developers to use
> Checkstyle
http://checkstyle.sourceforge.net/ to flag as
> warnings where the code
differs from coding practices that we as a group
> decide upon. We can
create a config file for checkstyle containing that can
> be used by the
checkstyle plugin for Eclipse, JBuilder, Netbeans, IntelliJ
> IDEA, Emacs
JDE, Vim etc."

This is an excellent idea and I plan to follow
> up with your
recommendation if Stefan has no strong objections. Would you
> be
willing to help me set up the Checkstyle configuration file for the
Sun
> Jave Code Conventions? I will then place a copy of it on the
SurveyOS
> SourceForge site for the other developers. I have never used
Checkstyle, but
> I will get it installed in Eclipse and will put some
simple instructions on
> the wiki for others.

The Sunburned Surveyor



On 5/30/07, Paul Austin
> <[EMAIL PROTECTED]> wrote:

> I think a good set of standards to follow are the Sun Java Code
Conventions.
> It's a fairly short (ish) standard and avoids all the
variable prefix and
> class prefix
> stuff.

http://java.sun.com/docs/codeconv/CodeConventions.pdf

In
> terms of package imports I don't ever manually type imports any more,
I
> either use Ctrl-Space to auto add the import when typing a class name
and
> use the organize imports functionality in eclipse.

Same for code
> formatting, I take the Eclipse Sun Code Conventions rule
and have it auto
> format as I type or reformat after cut and paste.

So here is my argument
> for following code conventions and import/code
formatting guidelines.

If
> two developers are making a set of changes to some files and they
both auto
> format the code but using different conventions when they go
to merge their
> changes with the other developer the diff tool will
highlight a whole bunch
> of changes for them to review that are just due
to the difference in
> formatting. So by following the same formatting
rules merging changes should
> be easier.

I would encourage (not enforce) developers to use
> Checkstyle
http://checkstyle.sourceforge.net/ to flag as
> warnings where the code
differs from coding practices that we as a group
> decide upon. We can
create a config file for checkstyle containing that can
> be used by the
checkstyle plugin for Eclipse, JBuilder, Netbeans, IntelliJ
> IDEA, Emacs
JDE, Vim etc.

Those are my thoughts,
Paul

Sunburned Surveyor
> wrote:

> 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 also a suggestion.

I'm really excited that others would be
> interested in this type of
consistency and quality for our source code of
> OpenJUMP. I don't want
us to loose that momentum!
However, I'm concerned
> about implementing such a code style standard
for a couple of reasons:

[1]
> I don't think we want to get into a situation where we are
dictating what
> IDE, if any, our contributing developers use. I would
want to make sure that
> any tools and/or plug-ins that we use for
automatic code formatting were
> free from dependencies on a particular
IDE.

[2] Do we really need to hav

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

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.ui.style.BasicStylePanel.findEquivalentItem(BasicStylePanel.java:483)
at 
com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.setBasicStyle(BasicStylePanel.java:459)
at 
com.vividsolutions.jump.workbench.ui.style.RenderingStylePanel.(RenderingStylePanel.java:189)
at 
com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn.execute(ChangeStylesPlugIn.java:87)

regards,
Larry

On 6/5/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> 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 an attribute on a tag.
>
> +fill = fill == null
> +? fillPatternComboBox.getItemAt(0)
> +: findEquivalentItem(fill, fillPatternComboBox);
>
> BTW does this improvement only improve speed if you have a themed layer
> or will it speed up all layers?
>
> Paul
>
> -
> 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
>


-- 
http://amusingprogrammer.blogspot.com/

-
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] Common Feature model

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
feature types from say a postgres database where you can have long names
to shape files where you can only have short names.

Paul

-
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] Common Feature model

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 the 
code I've written.  For the kinds of geoprocessing plugins I've written 
for JUMP, the amount of code needed to do a mapping is far, far 
outweighed by the code for actually implementing the function. 

Paul Austin wrote:
> 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 implementation that can be configured by
> specifying the source and target FeatureSchema and a map from source to
> target attribute names. This can be used by plug-ins or even better
> configuration files to create simple mappings.
>
> There is also need for a more complex mapper that can create attribute
> values using some kind of processing (e.g. a Point from attribute
> converter), this could also be done in a configurable approach.
>
> Paul
>
> -
> 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
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

-
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] Javadoc for skyjump

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
> on sourceforge
>
> stefan
>
> Roman Isitua schrieb:
> > Hello,
> >
> > I have checked the skyjump website and haven't found a
> > link to download the javadoc for skyjump. I am sure i
> > am missing something here. I am particularly
> > interested in the database connection plugins.
> >
> > Roman
> >
> >
> >
> >
> > 
> > Get the free Yahoo! toolbar and rest assured with the added security of 
> > spyware protection.
> > http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
> >
> > -
> > 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
>

-
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] Common Feature model

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 implementation that can be configured by
specifying the source and target FeatureSchema and a map from source to
target attribute names. This can be used by plug-ins or even better
configuration files to create simple mappings.

There is also need for a more complex mapper that can create attribute
values using some kind of processing (e.g. a Point from attribute
converter), this could also be done in a configurable approach.

Paul

-
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] Common Feature model

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 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 using rules (such as renaming attribute names or more complex 
> processing) that would convert a feature from one schema to another in 
> a "single" step as far as features. In this case the JUMP feature 
> model will work as it's only the start and end features which need to 
> have a static schema.
>
> Paul
>
>
> Martin Davis wrote:
>> 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 processing 
>> efficient way of assigning IDs).
>>
>> If you need a different kind of ID, just add another attribute to your 
>> FeatureSchema. 
>>
>> 2&3. This is already really supported (at least for POJOs).  What isn't 
>> supported is describing the resulting object model in the FeatureSchema 
>> model.  Some extension here might be good (at the risk of making things 
>> more complex).  I think the deegree Feature model might do this.
>>
>> 4. I am *really* not in favour of this concept.  Once you throw away the 
>> schema, you don't have much left in a Feature.  Java already has a 
>> "typeless variable-length container" - it's called a List. 
>>
>> If you are finding it painful to migrate data between FeatureSchemas, 
>> you can always write some helper methods.  Or dump your data into a List 
>> and move it that way. 
>>
>> Paul Austin wrote:
>>   
>>> I agree if the open source GIS community can agree on a single in 
>>> memory Java representation for geographic features that would make all 
>>> the tools more interoperable. Right now I'm using my own schema and 
>>> feature model but would prefer not to maintain that in the future. 
>>> Here are the requirements I have.
>>>
>>>1. Ids can be any type not just an int
>>>2. Properties can contain complex objects including other features
>>>   or POJO
>>>3. Properties can contain a collection (List or Set) value
>>>4. Features don't have to have a schema (useful when transforming a
>>>   feature from one schema to another)
>>>
>>>
>>>
>>> Paul
>>>
>>>
>>> 
>>>
>>> -
>>> 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
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


-
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] Expensive construction of BasicStyle objects.

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 an attribute on a tag.

+fill = fill == null
+? fillPatternComboBox.getItemAt(0)
+: findEquivalentItem(fill, fillPatternComboBox);

BTW does this improvement only improve speed if you have a themed layer
or will it speed up all layers?

Paul

-
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] Expensive construction of BasicStyle objects.

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 BasicStylePanel.

If you like them I would commit them to the core.

regards, Sascha

Sascha L. Teichmann schrieb:
> 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 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 a more lightweight fill pattern
>> construction method would be a good idea.  I'm not sure why we can't
>> just have every new instance point to the same default copy stashed
>> somewhere.
>>
>> regards,
>> Larry
>>
>> On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>>> 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(!) seconds before I can go on.
>>> (AMD 1.2 GHz/Athlon-T-Bird, GNU/Linux, Java6)
>>>
>>> I profiled it a bit and found out that almost
>>> the whole time is spend with constructing simple
>>> BasicStyle [1] objects. In this concrete case the problem
>>> can be solved if you reuse already created BasicStyle objects.
>>> After this fix the 24 secs go down to 0.001 secs!!!
>>> I can send a patch which does this.
>>>
>>> The main problem is the expensive construction of
>>> the BasicStyle objects. When they are created
>>> a WKTFillPattern is created too. Always! Even if it
>>> is not used! The construction of such a fill pattern
>>> involves a lot of string parsing with a WKTReader,
>>> math, etc. A little bit heavy weighted in my opinion.
>>> Jon has a comment in BasicStyle that says it is done
>>> to make the GUI happy. This has to be done better!
>>> Because BasicStyle objects are constructed very often
>>> in *JUMP I cannot estimate the overall performance
>>> lost coming with this issue.
>>>
>>> Comments?
>>>
>>> - Sascha
>>>
>>> [1] com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle
>>>
>>> -
>>> 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
Index: src/com/vividsolutions/jump/workbench/ui/renderer/style/BasicStyle.java
===
RCS file: 
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/renderer/style/BasicStyle.java,v
retrieving revision 1.1
diff -u -r1.1 BasicStyle.java
--- src/com/vividsolutions/jump/workbench/ui/renderer/style/BasicStyle.java 
16 Jun 2005 22:53:48 -  1.1
+++ src/com/vividsolutions/jump/workbench/ui/renderer/style/BasicStyle.java 
5 Jun 2007 16:27:42 -
@@ -56,18 +56,23 @@
 private boolean renderingLinePattern = false;
 private boolean renderingFillPattern = false;
 
+   public static final Color   DEFAULT_FILL_COLOR  = new 
Color(0, 0, 0, 255);
+   public static final Color   DEFAULT_LINE_COLOR  = 
DEFAULT_FILL_COLOR;
+   public static final BasicStroke DEFAULT_FILL_STROKE = new 
BasicStroke(1);
+
 //The important thing here is the initial alpha. [Jon Aquino]
-private Color fillColor = new Color(0, 0, 0, 255);
-private Color lineColor = new Color(0, 0, 0, 255);
+private Color fillColor = DEFAULT_FILL_COLOR;
+private Color lineColor = DEFAULT_LINE_COLOR;
+
 private BasicStroke lineStroke;
-private Stroke fillStroke = new BasicStroke(1);
+private Stroke fillS

Re: [JPP-Devel] Common Feature model





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 using rules (such as renaming attribute names or more complex
processing) that would convert a feature from one schema to another in
a "single" step as far as features. In this case the JUMP feature model
will work as it's only the start and end features which need to have a
static schema.

Paul


Martin Davis wrote:

  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 processing 
efficient way of assigning IDs).

If you need a different kind of ID, just add another attribute to your 
FeatureSchema. 

2&3. This is already really supported (at least for POJOs).  What isn't 
supported is describing the resulting object model in the FeatureSchema 
model.  Some extension here might be good (at the risk of making things 
more complex).  I think the deegree Feature model might do this.

4. I am *really* not in favour of this concept.  Once you throw away the 
schema, you don't have much left in a Feature.  Java already has a 
"typeless variable-length container" - it's called a List. 

If you are finding it painful to migrate data between FeatureSchemas, 
you can always write some helper methods.  Or dump your data into a List 
and move it that way. 

Paul Austin wrote:
  
  
I agree if the open source GIS community can agree on a single in 
memory Java representation for geographic features that would make all 
the tools more interoperable. Right now I'm using my own schema and 
feature model but would prefer not to maintain that in the future. 
Here are the requirements I have.

   1. Ids can be any type not just an int
   2. Properties can contain complex objects including other features
  or POJO
   3. Properties can contain a collection (List or Set) value
   4. Features don't have to have a schema (useful when transforming a
  feature from one schema to another)



Paul




-
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] Common Feature model

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 processing 
efficient way of assigning IDs).

If you need a different kind of ID, just add another attribute to your 
FeatureSchema. 

2&3. This is already really supported (at least for POJOs).  What isn't 
supported is describing the resulting object model in the FeatureSchema 
model.  Some extension here might be good (at the risk of making things 
more complex).  I think the deegree Feature model might do this.

4. I am *really* not in favour of this concept.  Once you throw away the 
schema, you don't have much left in a Feature.  Java already has a 
"typeless variable-length container" - it's called a List. 

If you are finding it painful to migrate data between FeatureSchemas, 
you can always write some helper methods.  Or dump your data into a List 
and move it that way. 

Paul Austin wrote:
> I agree if the open source GIS community can agree on a single in 
> memory Java representation for geographic features that would make all 
> the tools more interoperable. Right now I'm using my own schema and 
> feature model but would prefer not to maintain that in the future. 
> Here are the requirements I have.
>
>1. Ids can be any type not just an int
>2. Properties can contain complex objects including other features
>   or POJO
>3. Properties can contain a collection (List or Set) value
>4. Features don't have to have a schema (useful when transforming a
>   feature from one schema to another)
>
>
>
> Paul
>
>
> 
>
> -
> 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
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022

-
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] deegree Feature Model for OJ [was: Re: R: Common Feature model]

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'm not keen to dive in and 
make a wholesale change to something which is much more complex and much 
more volatile.  I'd much rather see slow and steady incremental improvement.

Maybe there will come a day when the GT/GeoAPI model has been stable for 
a couple of years and it is blindingly obvious that it is the One True 
Geospatial API - at that time JUMP can maybe migrate to it.

If people really need a more complex Feature model etc - there's always 
uDig!

Martin
 

Markus Müller wrote:
> 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 soon pretty important. The 
> deegree2 Feature Model was put to use in a number of projects and it is 
> stable. So I propose (again): if OJ goes into the direction of support 
> for complex features, please consider using the deegree Feature Model.
>
> Additionally I want to propose that if such a decision (regarding a 
> complex feature model) is made, this should IMHO be done in a new, 
> experimental branch of the OJ CVS, as (as Paolo says) a simple Feature 
> Model has a number of advantages such as simplicity and stability. I 
> would be good if this new development would go through some development 
> stages, before a final decision is made.
>
>
> best regards,
>
> Markus
>
>
> P.Rizzi Ag.Mobilità Ambiente schrieb:
>   
>> 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 that it has a simple Feature model
>> and that it works!!!
>> If you want to move to a more complex model you should be aware that
>> you may end up losing simplicity and stability.
>> About using GeoTools DataStores (aka drivers) to access data,
>> that was one other reason why we abandoned it.
>> DataStores for PostGIS and Oracle had many bugs, but no one cared
>> to fix them. And the changing Feature model prevented us to fix them
>> on our own, without wasting a lot of time keeping in sync with the changes.
>> If you want to use GT DataStores, you could write a simple adapter
>> that converts between their Feture model and JUMP on the fly.
>>
>> Bye
>> Paolo Rizzi
>>
>>
>>   
>> 
>>> -Messaggio originale-
>>> Da: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] conto di
>>> Sunburned Surveyor
>>> Inviato: martedì 5 giugno 2007 1.29
>>> A: List for discussion of JPP development and use.
>>> Cc: Geotools-Devel list
>>> Oggetto: Re: [JPP-Devel] Common Feature model
>>>
>>>
>>> There is almost too much good stuff going on around here to 
>>> keep up with. :]
>>>
>>> Paul wrote: "I agree if the open source GIS community can agree on a
>>> single in memory Java representation for geographic features that
>>> would make all the tools more interoperable."
>>>
>>> You should definitely get more involved with the GeoTools folks. We
>>> had some pretty extensive discussion about this very issue not to long
>>> ago on this mailing list. Some of the GeoTools folks participated, as
>>> did Frank Wammerdam. (Frank is no longer subscribed.)
>>>
>>> I think we identified some of the reasons why adopting the GeoTools
>>> feature model into OpenJUMP at "one time" isn't practical. However, we
>>> had some general agreement that it would be good to move OpenJUMP
>>> towards using the GeoTools feature model as we move forward.
>>>
>>> I will be using the GeoTools feature model in my FeatureCache
>>> implementation, which will allow me to store features from and data
>>> source for which there exists a GeoTools driver. One of my goals in
>>> the use of the GeoTools feature model in this project was to see how
>>> well it will play with OpenJUMP. It will give me a chance to get to
>>> know the GeoTools code that is involved, and will help me identify
>>> challenges that exist in our eventual migration of OpenJUMP to the
>>> GeoTools feature model.
>>>
>>> A key first step in making this migration is creating an class that
>>> can convert between GeoTools Feature objects and JUMP Feature objects.
>>> Edgar Soldin has already done some work in this area and I hope to
>>> continue it.
>>>
>>> In summary, we are a long ways towards sharing a common feature model
>>> with UDig, but I think we are starting to explore that possibility
>>> with some concrete steps. I think there is wisdom in this, because

Re: [JPP-Devel] Streamlining Java2DConverter decimation

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
>
>
> 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
> >
> > 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 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 that if you have all of the shape objects
> >> already, the time to plot them is not significant on modern
> >> accelerated graphics cards (less than a second).  It might be
> >> different on X11 under Linux though.
> >>
> >> What we need is a better understanding of where the time is being
> >> spent, but this is difficult to achieve.  So far I have not been
> >> successful at getting the profile information needed.
> >>
> >> I do know that the redraw process is responsible for most of the
> >> cyclic (new generation) memory consumption in JUMP.  This doesn't seem
> >> to slow down the program much until the percent of free memory drops
> >> to below 5 %.
> >>
> >> regards,
> >> Larry
> >>
> >> On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> >>> 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. The
> >>> new created GeneralPaths stores another internal copy
> >>> of the data too if the moveTo()/lineTo() calls are done
> >>> to fill it.
> >>>
> >>> I experimented with caching the result of the
> >>> on-the-fly DirectPolygon in case of filled polygons
> >>> where the geometry is rendered twice (border + fill).
> >>> In this case the inline decimation is run twice per
> >>> polygon. You can log the transformation result from
> >>> the first rendering and associate it with last transform.
> >>> If the second path iterator call is coming you can
> >>> compare the last transform and new one and in case
> >>> of equality you can run a simple and fast replay PathIterator
> >>> for the last result. But this does _not_ lead to
> >>> speed improvements. The extra book keeping seems to be more
> >>> expensive than the simply run the decimation twice.
> >>> I've code for this, but I think we do better without this.
> >>>
> >>> The streamlining is a good idea! I will do the same
> >>> optimization to LineStrings too, if you approve.
> >>>
> >>> BTW: If I turn on the OpenGL backend (-Dsun.java2d.opengl=true)
> >>> the burlulc layer renders a second faster when compared to
> >>> the plain X11 backend. As soon as I've access to a 3D accelerated
> >>> MS Windows I will have a look if this holds for Direct3D too.
> >>>
> >>> regards, Sascha
> >>>
> >>>
> >>>
> >>> Larry Becker schrieb:
>  I don't have time to look at it closely right now, but it sounds like
>  a logical simplification.  I hate that temp array too.
> 
>  regards,
>  Larry
> 
>  On 6/4/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> > Hi Sascha;
> >
> > Sounds interesting.
> > Please, let me some more time to have a closer look and see how your
> > code compare to the one in CVS.
> > Note : I made a recent change in CVS to have the resolution as a
> > property and modify it as needed (default=1/2 pixel) for special 
> > renderers.
> >
> > Michael
> >
> > Sascha L. Teichmann a écrit :
> >
> >> Hi Larry, hi Michaël,
> >>
> >> I had a look at the decimation code in Java2DConverter.
> >> This is awesome! Congratulations! :-)
> >>
> >> But way not go step further and streamline the model to view
> >> coordination transform. Why to create all this temporary
> >> Coordinate[] stuff? In the end all what matters is a PathIterator
> >> that can handle an AffineTransform coming from Java2D.
> >> Instead of transform the data to a temporary Coordinate array
> >> and used this to construct GeneralPaths we can write a PathIterator
> >> that transforms and decimates the data on-the-fly.
> >> All we have to do is to concatenate the model to view transform to the
> >> incoming matrix.
> >>
> >> To archive this we must add a
> >>
> >> AffineTransform getModelToViewTransform();
> >>
> >> method to the Java2DConverter.PointConverter interface. This
> >> does not hurt because Viewport alrea

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

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 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 a more lightweight fill pattern
> construction method would be a good idea.  I'm not sure why we can't
> just have every new instance point to the same default copy stashed
> somewhere.
> 
> regards,
> Larry
> 
> On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>> 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(!) seconds before I can go on.
>> (AMD 1.2 GHz/Athlon-T-Bird, GNU/Linux, Java6)
>>
>> I profiled it a bit and found out that almost
>> the whole time is spend with constructing simple
>> BasicStyle [1] objects. In this concrete case the problem
>> can be solved if you reuse already created BasicStyle objects.
>> After this fix the 24 secs go down to 0.001 secs!!!
>> I can send a patch which does this.
>>
>> The main problem is the expensive construction of
>> the BasicStyle objects. When they are created
>> a WKTFillPattern is created too. Always! Even if it
>> is not used! The construction of such a fill pattern
>> involves a lot of string parsing with a WKTReader,
>> math, etc. A little bit heavy weighted in my opinion.
>> Jon has a comment in BasicStyle that says it is done
>> to make the GUI happy. This has to be done better!
>> Because BasicStyle objects are constructed very often
>> in *JUMP I cannot estimate the overall performance
>> lost coming with this issue.
>>
>> Comments?
>>
>> - Sascha
>>
>> [1] com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle
>>
>> -
>> 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] Streamlining Java2DConverter decimation

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
> 
> 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 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 that if you have all of the shape objects
>> already, the time to plot them is not significant on modern
>> accelerated graphics cards (less than a second).  It might be
>> different on X11 under Linux though.
>>
>> What we need is a better understanding of where the time is being
>> spent, but this is difficult to achieve.  So far I have not been
>> successful at getting the profile information needed.
>>
>> I do know that the redraw process is responsible for most of the
>> cyclic (new generation) memory consumption in JUMP.  This doesn't seem
>> to slow down the program much until the percent of free memory drops
>> to below 5 %.
>>
>> regards,
>> Larry
>>
>> On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>>> 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. The
>>> new created GeneralPaths stores another internal copy
>>> of the data too if the moveTo()/lineTo() calls are done
>>> to fill it.
>>>
>>> I experimented with caching the result of the
>>> on-the-fly DirectPolygon in case of filled polygons
>>> where the geometry is rendered twice (border + fill).
>>> In this case the inline decimation is run twice per
>>> polygon. You can log the transformation result from
>>> the first rendering and associate it with last transform.
>>> If the second path iterator call is coming you can
>>> compare the last transform and new one and in case
>>> of equality you can run a simple and fast replay PathIterator
>>> for the last result. But this does _not_ lead to
>>> speed improvements. The extra book keeping seems to be more
>>> expensive than the simply run the decimation twice.
>>> I've code for this, but I think we do better without this.
>>>
>>> The streamlining is a good idea! I will do the same
>>> optimization to LineStrings too, if you approve.
>>>
>>> BTW: If I turn on the OpenGL backend (-Dsun.java2d.opengl=true)
>>> the burlulc layer renders a second faster when compared to
>>> the plain X11 backend. As soon as I've access to a 3D accelerated
>>> MS Windows I will have a look if this holds for Direct3D too.
>>>
>>> regards, Sascha
>>>
>>>
>>>
>>> Larry Becker schrieb:
 I don't have time to look at it closely right now, but it sounds like
 a logical simplification.  I hate that temp array too.

 regards,
 Larry

 On 6/4/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> Hi Sascha;
>
> Sounds interesting.
> Please, let me some more time to have a closer look and see how your
> code compare to the one in CVS.
> Note : I made a recent change in CVS to have the resolution as a
> property and modify it as needed (default=1/2 pixel) for special 
> renderers.
>
> Michael
>
> Sascha L. Teichmann a écrit :
>
>> Hi Larry, hi Michaël,
>>
>> I had a look at the decimation code in Java2DConverter.
>> This is awesome! Congratulations! :-)
>>
>> But way not go step further and streamline the model to view
>> coordination transform. Why to create all this temporary
>> Coordinate[] stuff? In the end all what matters is a PathIterator
>> that can handle an AffineTransform coming from Java2D.
>> Instead of transform the data to a temporary Coordinate array
>> and used this to construct GeneralPaths we can write a PathIterator
>> that transforms and decimates the data on-the-fly.
>> All we have to do is to concatenate the model to view transform to the
>> incoming matrix.
>>
>> To archive this we must add a
>>
>> AffineTransform getModelToViewTransform();
>>
>> method to the Java2DConverter.PointConverter interface. This
>> does not hurt because Viewport already implements it.
>>
>> To see what I mean, look at the DirectPolygonShape that I've
>> attached. It handles the Polygon case of Java2DConverter.
>> Add this class to the sources and change the toShape(Polygon)
>> method to look as follow:
>>
>>  private Shape toShape(Polygon polygon) throws
>>  NoninvertibleTransformException
>>

Re: [JPP-Devel] Streamlining Java2DConverter decimation

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 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 that if you have all of the shape objects
> already, the time to plot them is not significant on modern
> accelerated graphics cards (less than a second).  It might be
> different on X11 under Linux though.
>
> What we need is a better understanding of where the time is being
> spent, but this is difficult to achieve.  So far I have not been
> successful at getting the profile information needed.
>
> I do know that the redraw process is responsible for most of the
> cyclic (new generation) memory consumption in JUMP.  This doesn't seem
> to slow down the program much until the percent of free memory drops
> to below 5 %.
>
> regards,
> Larry
>
> On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> > 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. The
> > new created GeneralPaths stores another internal copy
> > of the data too if the moveTo()/lineTo() calls are done
> > to fill it.
> >
> > I experimented with caching the result of the
> > on-the-fly DirectPolygon in case of filled polygons
> > where the geometry is rendered twice (border + fill).
> > In this case the inline decimation is run twice per
> > polygon. You can log the transformation result from
> > the first rendering and associate it with last transform.
> > If the second path iterator call is coming you can
> > compare the last transform and new one and in case
> > of equality you can run a simple and fast replay PathIterator
> > for the last result. But this does _not_ lead to
> > speed improvements. The extra book keeping seems to be more
> > expensive than the simply run the decimation twice.
> > I've code for this, but I think we do better without this.
> >
> > The streamlining is a good idea! I will do the same
> > optimization to LineStrings too, if you approve.
> >
> > BTW: If I turn on the OpenGL backend (-Dsun.java2d.opengl=true)
> > the burlulc layer renders a second faster when compared to
> > the plain X11 backend. As soon as I've access to a 3D accelerated
> > MS Windows I will have a look if this holds for Direct3D too.
> >
> > regards, Sascha
> >
> >
> >
> > Larry Becker schrieb:
> > > I don't have time to look at it closely right now, but it sounds like
> > > a logical simplification.  I hate that temp array too.
> > >
> > > regards,
> > > Larry
> > >
> > > On 6/4/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> > >> Hi Sascha;
> > >>
> > >> Sounds interesting.
> > >> Please, let me some more time to have a closer look and see how your
> > >> code compare to the one in CVS.
> > >> Note : I made a recent change in CVS to have the resolution as a
> > >> property and modify it as needed (default=1/2 pixel) for special 
> > >> renderers.
> > >>
> > >> Michael
> > >>
> > >> Sascha L. Teichmann a écrit :
> > >>
> > >>> Hi Larry, hi Michaël,
> > >>>
> > >>> I had a look at the decimation code in Java2DConverter.
> > >>> This is awesome! Congratulations! :-)
> > >>>
> > >>> But way not go step further and streamline the model to view
> > >>> coordination transform. Why to create all this temporary
> > >>> Coordinate[] stuff? In the end all what matters is a PathIterator
> > >>> that can handle an AffineTransform coming from Java2D.
> > >>> Instead of transform the data to a temporary Coordinate array
> > >>> and used this to construct GeneralPaths we can write a PathIterator
> > >>> that transforms and decimates the data on-the-fly.
> > >>> All we have to do is to concatenate the model to view transform to the
> > >>> incoming matrix.
> > >>>
> > >>> To archive this we must add a
> > >>>
> > >>> AffineTransform getModelToViewTransform();
> > >>>
> > >>> method to the Java2DConverter.PointConverter interface. This
> > >>> does not hurt because Viewport already implements it.
> > >>>
> > >>> To see what I mean, look at the DirectPolygonShape that I've
> > >>> attached. It handles the Polygon case of Java2DConverter.
> > >>> Add this class to the sources and change the toShape(Polygon)
> > >>> method to look as follow:
> > >>>
> > >>>  private Shape toShape(Polygon polygon) throws
> > >>>  NoninvertibleTransformException
> > >>>  {
> > >>>return new DirectPolygonShape(
> > >>>  polygon,
> > >>>  pointConverter.getModelToViewTransform(),
> > >>>  1d / (2d*pointConve

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

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 attribute value, can be any object type

Are there any other objects which are created for each individual
feature instance?

Cheers,
Paul

-
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] named FeatureSchema

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
optional.

The advantage of having the name is that if you were doing some
processing of features and don't have reference to the layer you can
find out what type of feature it is and do different processing accordingly.

Paul

Martin Davis wrote:
> BTW, the idea of having hum-readable names for FeatureSchemas is a nice 
> one.  I'd definitely support adding that functionality, even if it isn't 
> exposed right now.
>   

-
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] Expensive construction of BasicStyle objects.

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 a more lightweight fill pattern
construction method would be a good idea.  I'm not sure why we can't
just have every new instance point to the same default copy stashed
somewhere.

regards,
Larry

On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> 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(!) seconds before I can go on.
> (AMD 1.2 GHz/Athlon-T-Bird, GNU/Linux, Java6)
>
> I profiled it a bit and found out that almost
> the whole time is spend with constructing simple
> BasicStyle [1] objects. In this concrete case the problem
> can be solved if you reuse already created BasicStyle objects.
> After this fix the 24 secs go down to 0.001 secs!!!
> I can send a patch which does this.
>
> The main problem is the expensive construction of
> the BasicStyle objects. When they are created
> a WKTFillPattern is created too. Always! Even if it
> is not used! The construction of such a fill pattern
> involves a lot of string parsing with a WKTReader,
> math, etc. A little bit heavy weighted in my opinion.
> Jon has a comment in BasicStyle that says it is done
> to make the GUI happy. This has to be done better!
> Because BasicStyle objects are constructed very often
> in *JUMP I cannot estimate the overall performance
> lost coming with this issue.
>
> Comments?
>
> - Sascha
>
> [1] com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle
>
> -
> 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
>

-- 
http://amusingprogrammer.blogspot.com/

-
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] [Geotools-devel] Common Feature model

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 have my concrete feature implementations implement
both the JUMP Feature and my DataObject interface. My reader
implementations then use a DataObjectFactory to create instances when
they are read for a file or database. When in JUMP I use a factory that
returns the JUMP compatible features and in my external tools use a more
complex/flexible model. That way my reader implementation can be reused
across multiple environments.

Paul

-
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] Streamlining Java2DConverter decimation

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 that if you have all of the shape objects
already, the time to plot them is not significant on modern
accelerated graphics cards (less than a second).  It might be
different on X11 under Linux though.

What we need is a better understanding of where the time is being
spent, but this is difficult to achieve.  So far I have not been
successful at getting the profile information needed.

I do know that the redraw process is responsible for most of the
cyclic (new generation) memory consumption in JUMP.  This doesn't seem
to slow down the program much until the percent of free memory drops
to below 5 %.

regards,
Larry

On 6/5/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
> 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. The
> new created GeneralPaths stores another internal copy
> of the data too if the moveTo()/lineTo() calls are done
> to fill it.
>
> I experimented with caching the result of the
> on-the-fly DirectPolygon in case of filled polygons
> where the geometry is rendered twice (border + fill).
> In this case the inline decimation is run twice per
> polygon. You can log the transformation result from
> the first rendering and associate it with last transform.
> If the second path iterator call is coming you can
> compare the last transform and new one and in case
> of equality you can run a simple and fast replay PathIterator
> for the last result. But this does _not_ lead to
> speed improvements. The extra book keeping seems to be more
> expensive than the simply run the decimation twice.
> I've code for this, but I think we do better without this.
>
> The streamlining is a good idea! I will do the same
> optimization to LineStrings too, if you approve.
>
> BTW: If I turn on the OpenGL backend (-Dsun.java2d.opengl=true)
> the burlulc layer renders a second faster when compared to
> the plain X11 backend. As soon as I've access to a 3D accelerated
> MS Windows I will have a look if this holds for Direct3D too.
>
> regards, Sascha
>
>
>
> Larry Becker schrieb:
> > I don't have time to look at it closely right now, but it sounds like
> > a logical simplification.  I hate that temp array too.
> >
> > regards,
> > Larry
> >
> > On 6/4/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> >> Hi Sascha;
> >>
> >> Sounds interesting.
> >> Please, let me some more time to have a closer look and see how your
> >> code compare to the one in CVS.
> >> Note : I made a recent change in CVS to have the resolution as a
> >> property and modify it as needed (default=1/2 pixel) for special renderers.
> >>
> >> Michael
> >>
> >> Sascha L. Teichmann a écrit :
> >>
> >>> Hi Larry, hi Michaël,
> >>>
> >>> I had a look at the decimation code in Java2DConverter.
> >>> This is awesome! Congratulations! :-)
> >>>
> >>> But way not go step further and streamline the model to view
> >>> coordination transform. Why to create all this temporary
> >>> Coordinate[] stuff? In the end all what matters is a PathIterator
> >>> that can handle an AffineTransform coming from Java2D.
> >>> Instead of transform the data to a temporary Coordinate array
> >>> and used this to construct GeneralPaths we can write a PathIterator
> >>> that transforms and decimates the data on-the-fly.
> >>> All we have to do is to concatenate the model to view transform to the
> >>> incoming matrix.
> >>>
> >>> To archive this we must add a
> >>>
> >>> AffineTransform getModelToViewTransform();
> >>>
> >>> method to the Java2DConverter.PointConverter interface. This
> >>> does not hurt because Viewport already implements it.
> >>>
> >>> To see what I mean, look at the DirectPolygonShape that I've
> >>> attached. It handles the Polygon case of Java2DConverter.
> >>> Add this class to the sources and change the toShape(Polygon)
> >>> method to look as follow:
> >>>
> >>>  private Shape toShape(Polygon polygon) throws
> >>>  NoninvertibleTransformException
> >>>  {
> >>>return new DirectPolygonShape(
> >>>  polygon,
> >>>  pointConverter.getModelToViewTransform(),
> >>>  1d / (2d*pointConverter.getScale()));
> >>>  }
> >>>
> >>> Speaking of performance. On my computer
> >>> (very old 1.2 GHz AMD/Athlon-T-Bird running GNU/Linux, Java 6)
> >>> the burluc layer is rendered in full extend without the streamling
> >>> in about 9.x seconds, with the streamling in about 8.x secs, with
> >>> x varying a bit. It's just a second, but it's a second! ;-)
> >>>
> >>> What do you think?
> >>>
> >>> Regard

[JPP-Devel] Expensive construction of BasicStyle objects.

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(!) seconds before I can go on.
(AMD 1.2 GHz/Athlon-T-Bird, GNU/Linux, Java6)

I profiled it a bit and found out that almost
the whole time is spend with constructing simple
BasicStyle [1] objects. In this concrete case the problem
can be solved if you reuse already created BasicStyle objects.
After this fix the 24 secs go down to 0.001 secs!!!
I can send a patch which does this.

The main problem is the expensive construction of
the BasicStyle objects. When they are created
a WKTFillPattern is created too. Always! Even if it
is not used! The construction of such a fill pattern
involves a lot of string parsing with a WKTReader,
math, etc. A little bit heavy weighted in my opinion.
Jon has a comment in BasicStyle that says it is done
to make the GUI happy. This has to be done better!
Because BasicStyle objects are constructed very often
in *JUMP I cannot estimate the overall performance
lost coming with this issue.

Comments?

- Sascha

[1] com.vividsolutions.jump.workbench.ui.renderer.style.BasicStyle

-
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

[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 soon pretty important. The 
deegree2 Feature Model was put to use in a number of projects and it is 
stable. So I propose (again): if OJ goes into the direction of support 
for complex features, please consider using the deegree Feature Model.

Additionally I want to propose that if such a decision (regarding a 
complex feature model) is made, this should IMHO be done in a new, 
experimental branch of the OJ CVS, as (as Paolo says) a simple Feature 
Model has a number of advantages such as simplicity and stability. I 
would be good if this new development would go through some development 
stages, before a final decision is made.


best regards,

Markus


P.Rizzi Ag.Mobilità Ambiente schrieb:
> 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 that it has a simple Feature model
> and that it works!!!
> If you want to move to a more complex model you should be aware that
> you may end up losing simplicity and stability.
> About using GeoTools DataStores (aka drivers) to access data,
> that was one other reason why we abandoned it.
> DataStores for PostGIS and Oracle had many bugs, but no one cared
> to fix them. And the changing Feature model prevented us to fix them
> on our own, without wasting a lot of time keeping in sync with the changes.
> If you want to use GT DataStores, you could write a simple adapter
> that converts between their Feture model and JUMP on the fly.
>
> Bye
> Paolo Rizzi
>
>
>   
>> -Messaggio originale-
>> Da: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] conto di
>> Sunburned Surveyor
>> Inviato: martedì 5 giugno 2007 1.29
>> A: List for discussion of JPP development and use.
>> Cc: Geotools-Devel list
>> Oggetto: Re: [JPP-Devel] Common Feature model
>>
>>
>> There is almost too much good stuff going on around here to 
>> keep up with. :]
>>
>> Paul wrote: "I agree if the open source GIS community can agree on a
>> single in memory Java representation for geographic features that
>> would make all the tools more interoperable."
>>
>> You should definitely get more involved with the GeoTools folks. We
>> had some pretty extensive discussion about this very issue not to long
>> ago on this mailing list. Some of the GeoTools folks participated, as
>> did Frank Wammerdam. (Frank is no longer subscribed.)
>>
>> I think we identified some of the reasons why adopting the GeoTools
>> feature model into OpenJUMP at "one time" isn't practical. However, we
>> had some general agreement that it would be good to move OpenJUMP
>> towards using the GeoTools feature model as we move forward.
>>
>> I will be using the GeoTools feature model in my FeatureCache
>> implementation, which will allow me to store features from and data
>> source for which there exists a GeoTools driver. One of my goals in
>> the use of the GeoTools feature model in this project was to see how
>> well it will play with OpenJUMP. It will give me a chance to get to
>> know the GeoTools code that is involved, and will help me identify
>> challenges that exist in our eventual migration of OpenJUMP to the
>> GeoTools feature model.
>>
>> A key first step in making this migration is creating an class that
>> can convert between GeoTools Feature objects and JUMP Feature objects.
>> Edgar Soldin has already done some work in this area and I hope to
>> continue it.
>>
>> In summary, we are a long ways towards sharing a common feature model
>> with UDig, but I think we are starting to explore that possibility
>> with some concrete steps. I think there is wisdom in this, because "if
>> the open source GIS community can agree on a single in memory Java
>> representation for geographic features" it will be the one in
>> GeoTools.
>>
>> Paul wrote: "Here are the requirements I have.
>>
>> Ids can be any type not just an int
>> Properties can contain complex objects including other 
>> features or POJO
>> Properties can contain a collection (List or Set) value
>> Features don't have to have a schema (useful when transforming a
>> feature from one schema to another) "
>>
>> I'm almost positive that the GeoTools folks have already considered
>> many of these issues. In the end developers have to find the balance
>> between the ultimate flexibility and a system that can be used. By its
>> very nature a system must have some structure to be usable, and
>> structure means constraints. For example, the most flexible way to
>> represent geographic features in Java would be to just have them

[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 
NullPointer exceptions if you load a Layer from a DataStore query
that results in one or more records with empty geometries.

After that the layer is treated like any other one, although it's not rendered.

You can even think of some kind of "calculator" class you can attach
to the Layer (maybe through BeanShell) that can "calculate" the
geometry field on the fly, making a non spatial layer spatial.


Bye
Paolo Rizzi



> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] conto di
> Sunburned Surveyor
> Inviato: martedì 5 giugno 2007 0.33
> A: List for discussion of JPP development and use.
> Oggetto: [JPP-Devel] Support for non-spatial features...
> 
> 
> I thought I would start a new thread so we could split this apart from
> the discussion that Paul and Martin were having about the FeatureInfo
> tool.
> 
> When I suggested that support for non-spatial features could be
> included in a plug-in Martin wrote: "I had similar thoughts a while
> back.  In fact, the Feature concept
> easily supports non-spatial features.  About all that is 
> required is to
> get the UI to recognize non-spatial Feature Schemas and do sensible
> things with them  (such as display a little table icon rather than the
> symbology icon in the Layer List panel, and not display the button for
> View/Edit Geometry).
> 
> There's quite a few of these kinds of changes required to support this
> cleanly, but I don't think any of them are very difficult.  This
> is more than just a single plugin, tho - it's a more of a 
> generalization
> of the existing Feature framework."
> 
> I still think you could encapsulate this functionality in a plug-in or
> set of plug-ins. This might not be the best way to go long term, but
> it could let us test out how things would work without messing with
> the core.
> 
> For example, I wouldn't even mess with the Layer List. I'd create a
> separate UI component that could be used to manage non-spatial feature
> collections or tables. We could make it look similar to the Layer List
> for purposes of consistency. I think it would be a little confusing to
> include symbols for non-spatial feature collections in the Layer List.
> They wouldn't affect the display order for one thing, and we currently
> use the visual arrangement of layers in the Layer List to do this.
> 
> I imagined a plug-in that created a "Non-Spatial Feature" menu entry
> somewhere. This menu entry would pull up a UI that would allow the
> user to create, delete, modify, and import/export non-spatial feature
> collections.
> 
> Another related plug-in could be used to create associations between
> non-spatial feature collections and spatial feature collections. I
> think most of this functionality could be managed internally by the
> plug-in.
> 
> These are just some ideas. :]
> 
> I think one danger of walking down the "non-spatial" feature path is
> that we will begin to implement more and more traditional RDBMS
> features. (For example: "Let's ass support for transactions to our
> non-spatial feature collections."..."Let's add support for custom
> datatypes to our non-spatial feature collections."..."Let's add
> support for datatype constraints to our non-spatial feature
> collections.") Perhaps the smart thing to do is to design a system for
> non-spatial features that uses an embedded Java database that already
> contains all of this functionality. I wouldn't have a problem with
> this if we could access the database components directly without
> having to mess with a JDBC layer. (Note: I'm not talking about storing
> the attribute information for spatial features in an embedded
> database. I think the Sigle team is already working on something like
> this. I'm talking about storing the attributes of non-spatial
> features.)
> 
> Then again, maybe it wouldn't be a big deal to implement some RDBMS
> features if we have support for non-spatial features in OpenJUMP. It
> just seems like a waste of effort with all the work that must be going
> on in open source Java databases.
> 
> Michael wrote: "And what about having a way to join a spatial 
> layer in OJ to a
> non-spatial db table or view, and to see the whole result as one flat
> layer in OJ..."
> 
> Good idea...
> 
> Martin wrote: "Yes, definitely that would be cool.  This would be
> equivalent to a
> defining a view in an RDBMS."
> 
> See! That is what I was talking about. :]
> 
> SS
> 
> --
> ---
> 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://sourcef

[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 source GIS community can agree on a single in memory Java 
representation for geographic features that would make all the tools more 
interoperable. Right now I'm using my own schema and feature model but would 
prefer not to maintain that in the future. Here are the requirements I have.



1.  Ids can be any type not just an int 

2.  Properties can contain complex objects including other features or POJO 

3.  Properties can contain a collection (List or Set) value 

4.  Features don't have to have a schema (useful when transforming a 
feature from one schema to another) 



Paul




-
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

[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 that it has a simple Feature model
and that it works!!!
If you want to move to a more complex model you should be aware that
you may end up losing simplicity and stability.
About using GeoTools DataStores (aka drivers) to access data,
that was one other reason why we abandoned it.
DataStores for PostGIS and Oracle had many bugs, but no one cared
to fix them. And the changing Feature model prevented us to fix them
on our own, without wasting a lot of time keeping in sync with the changes.
If you want to use GT DataStores, you could write a simple adapter
that converts between their Feture model and JUMP on the fly.

Bye
Paolo Rizzi


> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] conto di
> Sunburned Surveyor
> Inviato: martedì 5 giugno 2007 1.29
> A: List for discussion of JPP development and use.
> Cc: Geotools-Devel list
> Oggetto: Re: [JPP-Devel] Common Feature model
> 
> 
> There is almost too much good stuff going on around here to 
> keep up with. :]
> 
> Paul wrote: "I agree if the open source GIS community can agree on a
> single in memory Java representation for geographic features that
> would make all the tools more interoperable."
> 
> You should definitely get more involved with the GeoTools folks. We
> had some pretty extensive discussion about this very issue not to long
> ago on this mailing list. Some of the GeoTools folks participated, as
> did Frank Wammerdam. (Frank is no longer subscribed.)
> 
> I think we identified some of the reasons why adopting the GeoTools
> feature model into OpenJUMP at "one time" isn't practical. However, we
> had some general agreement that it would be good to move OpenJUMP
> towards using the GeoTools feature model as we move forward.
> 
> I will be using the GeoTools feature model in my FeatureCache
> implementation, which will allow me to store features from and data
> source for which there exists a GeoTools driver. One of my goals in
> the use of the GeoTools feature model in this project was to see how
> well it will play with OpenJUMP. It will give me a chance to get to
> know the GeoTools code that is involved, and will help me identify
> challenges that exist in our eventual migration of OpenJUMP to the
> GeoTools feature model.
> 
> A key first step in making this migration is creating an class that
> can convert between GeoTools Feature objects and JUMP Feature objects.
> Edgar Soldin has already done some work in this area and I hope to
> continue it.
> 
> In summary, we are a long ways towards sharing a common feature model
> with UDig, but I think we are starting to explore that possibility
> with some concrete steps. I think there is wisdom in this, because "if
> the open source GIS community can agree on a single in memory Java
> representation for geographic features" it will be the one in
> GeoTools.
> 
> Paul wrote: "Here are the requirements I have.
> 
> Ids can be any type not just an int
> Properties can contain complex objects including other 
> features or POJO
> Properties can contain a collection (List or Set) value
> Features don't have to have a schema (useful when transforming a
> feature from one schema to another) "
> 
> I'm almost positive that the GeoTools folks have already considered
> many of these issues. In the end developers have to find the balance
> between the ultimate flexibility and a system that can be used. By its
> very nature a system must have some structure to be usable, and
> structure means constraints. For example, the most flexible way to
> represent geographic features in Java would be to just have them
> extend of the Object class. But that doesn't do anyone a lot of good,
> does it?
> 
> You need to be able to assume some things about the Feature you are
> working with, and that means it has to obey some rules. I think it
> would be foolish to debate again what has already been debated by some
> of the smart folks at GeoTools. I think they must have good reasons
> for settling on the feature model they chose.
> 
> I really don't think the best solution is significantly changing
> OpenJUMP's feature model, but adopting and then working to improve the
> GeoTools feature model.
> 
> The Sunburned Surveyor
> 
> 
> 
> On 6/4/07, Paul Austin <[EMAIL PROTECTED]> wrote:
> > The reason I was thinking of Object type for Ids is that 
> then you could use
> > a Long, Integer or String for the feature ID depending on 
> the type of data.
> > I normally use Long but some models may use String based 
> globally unique
> > ids, I wouldn't want to use String for numeric fields all the time.
> >
> > On the schema issue, I still like to have a schema 
> associated with a feature
> > but not m

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 definitely meets the requirements you list below. You
can look at the interfaces here:

http://geoapi.svn.sourceforge.net/viewvc/geoapi/trunk/geoapi/src/main/java/org/opengis/feature/

The simple package is where you probably want to focus most of your
attention. The model is somewhat verbose and a bit intimidating. But the
point of the simple package was to develop interfaces that people coming
from the current geotools model, or the JUMP feature model would
understand and could work with.

We also were able to get a geotools implementation to turn over. That
implementation is currently being used as a base for the "complex
features project" in GeoServer.

http://docs.codehaus.org/display/GEOS/Complex+Datastore
http://docs.codehaus.org/display/GEOTOOLS/Community+Schema+Road+Map

(Rob,Gabriel: is there a link to any more recent docs?)

I've just re-established editing rights, and want to update where we are
at, but essentially we have a vastly improved, from the ground up
approach supported by a real schema parser. This means that we have a
way to create the in-memory model from an external configuration, which
would be necessary to share in-memory features between different
application layers.

The reality is that neither the persistence schema (database metadata)
or the XML schema (community schema) hold all the information - often a
schema will have abstract types that instances should realise with a
specialised equivalent. I.e. the community schema is an interface, the
configured featureType is an implementation.

Keeping these concerns neatly separated is the key.

IMHO there is scope for an extra configuration layer here - a "profile"
that contains hints about how to interpret the schema, and this would
allow in-memory features to be realised in a consistent way.

Another bit of info you may find interesting is summed up here, it is
essentially an annuncement that we got some funding to support getting
the geoapi feautre model fully implemented on geotools trunk.

http://www.mail-archive.com/[EMAIL PROTECTED]/msg07996.html

We need to have a transition plan from the project just winding up into
this one - what can we do to help?

Rob Atkinson

begin:vcard
fn:Rob Atkinson
n:Atkinson;Rob
org:Social Change Online
email;internet:[EMAIL PROTECTED]
title:Principal Consultant
tel;work:+61 2 42265490
tel;cell:0419 202 973
x-mozilla-html:TRUE
url:http://online.socialchange.net.au
version:2.1
end:vcard

-
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] [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
> Ids can be any type not just an int
>   
Yes - can be backed onto anything (or several somethigns) but is made 
available as an opaque feature id
> Properties can contain complex objects including other features or POJO
>   
Yes, (we had the need for all three subclasses of property: attributes, 
associations and operations)
> Properties can contain a collection (List or Set) value
>   
Nope - we ended up doing this as repeating properties with the same 
name. When you use query on the Feature you get a List or Set.
The factory here is when repeating groups of attributes have order that 
is significant to the application.
> Features don't have to have a schema (useful when transforming a
> feature from one schema to another) "
>   
Bingo - and also importantly Features do not have to be valid against 
there Schema (also important).
> I'm almost positive that the GeoTools folks have already considered
> many of these issues. In the end developers have to find the balance
> between the ultimate flexibility and a system that can be used. By its
> very nature a system must have some structure to be usable, and
> structure means constraints. For example, the most flexible way to
> represent geographic features in Java would be to just have them
> extend of the Object class. But that doesn't do anyone a lot of good,
> does it?
>
> You need to be able to assume some things about the Feature you are
> working with, and that means it has to obey some rules. I think it
> would be foolish to debate again what has already been debated by some
> of the smart folks at GeoTools. I think they must have good reasons
> for settling on the feature model they chose.
>   
Well settled on; and doing the work are too different things :-) We 
welcome collaboration !

I will point out that we are making use of GeoAPI for the feature model; 
as it already has the policies in place for inter project communication 
(and a formal review process). GeoTools is about implementation (and 
getting the job done) - we also like to leave the interfaces up to the 
experts.
> I really don't think the best solution is significantly changing
> OpenJUMP's feature model, but adopting and then working to improve the
> GeoTools feature model.
>   
Cheers,
Jody
> The Sunburned Surveyor
>
> On 6/4/07, Paul Austin <[EMAIL PROTECTED]> wrote:
>   
>> The reason I was thinking of Object type for Ids is that then you could use
>> a Long, Integer or String for the feature ID depending on the type of data.
>> I normally use Long but some models may use String based globally unique
>> ids, I wouldn't want to use String for numeric fields all the time.
>>
>> On the schema issue, I still like to have a schema associated with a feature
>> but not making it mandatory, having the schema there allows you to do
>> validation on the feature to make sure it conforms to the schema (e.g. type
>> and allowed values for enumerations).
>>
>> When I'm looking at a feature model I'm looking at it for passing around in
>> a processing pipeline for transformation, spatial processing and validation
>> rather than just for the display in JUMP.
>>
>> Paul
>>
>>
>> Michaël Michaud wrote:
>> Hi Paul,
>> 
>
> 1. Do you really need Object type for ids (I think ids are Strings
>   
>> in
>> 
> GeoTools - don't know if there is performance penality compared to int
>   
> ids, or some cases where a genaral Object type is needed)
> 2/3. If I can
>   
>> remember, GeoTools complex feature model fulfill 2 and 3
>> 
> requirements, and
>   
>> define a subclass (SimpleFeature ?) looking like
>> 
> jump's feature model (more
>   
>> or less)
>> 
> 4. I already thought that a feature should't have a schema.
>   
> Fundamentally, I think a feature is like a map with attribute/value
> pairs,
>   
>> and that feature schema belong to the feature collection level.
>> 
> It would be
>   
>> interesting to know why jump's designers have choosen to
>> 
> include a
>   
>> featureschema reference in each feature.
>> 
>
> Michaël
>
> Paul Austin a écrit :
>
>
>   
>> I agree if the open source GIS community can agree on a single in
>> 
> memory
>   
>> Java representation for geographic features that would make all
>> 
> the tools
>   
>> more interoperable. Right now I'm using my own schema and
>> 
> feature model but
>   
>> would prefer not to maintain that in the future.
>> 
> Here are the requirements
>   
>> I have.
>> 
>
>  1. Ids can be any type not just an int
>  2. Properties can contain
>   
>> complex objects including other features
>> 
>  or POJO
>  3. Properties can contain
>   
>> a collection (List or Set) value
>> 
>  4. Features don'

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 look at the interfaces here:

http://geoapi.svn.sourceforge.net/viewvc/geoapi/trunk/geoapi/src/main/java/org/opengis/feature/

The simple package is where you probably want to focus most of your
attention. The model is somewhat verbose and a bit intimidating. But the
point of the simple package was to develop interfaces that people coming
from the current geotools model, or the JUMP feature model would
understand and could work with.

We also were able to get a geotools implementation to turn over. That
implementation is currently being used as a base for the "complex
features project" in GeoServer.

http://docs.codehaus.org/display/GEOS/Complex+Datastore
http://docs.codehaus.org/display/GEOTOOLS/Community+Schema+Road+Map

(Rob,Gabriel: is there a link to any more recent docs?)

Another bit of info you may find interesting is summed up here, it is
essentially an annuncement that we got some funding to support getting
the geoapi feautre model fully implemented on geotools trunk.

http://www.mail-archive.com/[EMAIL PROTECTED]/msg07996.html

-Justin

Sunburned Surveyor wrote:
> There is almost too much good stuff going on around here to keep up with. :]
> 
> Paul wrote: "I agree if the open source GIS community can agree on a
> single in memory Java representation for geographic features that
> would make all the tools more interoperable."
> 
> You should definitely get more involved with the GeoTools folks. We
> had some pretty extensive discussion about this very issue not to long
> ago on this mailing list. Some of the GeoTools folks participated, as
> did Frank Wammerdam. (Frank is no longer subscribed.)
> 
> I think we identified some of the reasons why adopting the GeoTools
> feature model into OpenJUMP at "one time" isn't practical. However, we
> had some general agreement that it would be good to move OpenJUMP
> towards using the GeoTools feature model as we move forward.
> 
> I will be using the GeoTools feature model in my FeatureCache
> implementation, which will allow me to store features from and data
> source for which there exists a GeoTools driver. One of my goals in
> the use of the GeoTools feature model in this project was to see how
> well it will play with OpenJUMP. It will give me a chance to get to
> know the GeoTools code that is involved, and will help me identify
> challenges that exist in our eventual migration of OpenJUMP to the
> GeoTools feature model.
> 
> A key first step in making this migration is creating an class that
> can convert between GeoTools Feature objects and JUMP Feature objects.
> Edgar Soldin has already done some work in this area and I hope to
> continue it.
> 
> In summary, we are a long ways towards sharing a common feature model
> with UDig, but I think we are starting to explore that possibility
> with some concrete steps. I think there is wisdom in this, because "if
> the open source GIS community can agree on a single in memory Java
> representation for geographic features" it will be the one in
> GeoTools.
> 
> Paul wrote: "Here are the requirements I have.
> 
> Ids can be any type not just an int
> Properties can contain complex objects including other features or POJO
> Properties can contain a collection (List or Set) value
> Features don't have to have a schema (useful when transforming a
> feature from one schema to another) "
> 
> I'm almost positive that the GeoTools folks have already considered
> many of these issues. In the end developers have to find the balance
> between the ultimate flexibility and a system that can be used. By its
> very nature a system must have some structure to be usable, and
> structure means constraints. For example, the most flexible way to
> represent geographic features in Java would be to just have them
> extend of the Object class. But that doesn't do anyone a lot of good,
> does it?
> 
> You need to be able to assume some things about the Feature you are
> working with, and that means it has to obey some rules. I think it
> would be foolish to debate again what has already been debated by some
> of the smart folks at GeoTools. I think they must have good reasons
> for settling on the feature model they chose.
> 
> I really don't think the best solution is significantly changing
> OpenJUMP's feature model, but adopting and then working to improve the
> GeoTools feature model.
> 
> The Sunburned Surveyor
> 
> 
> 
> On 6/4/07, Paul Austin <[EMAIL PROTECTED]> wrote:
>> The reason I was thinking of Object type for Ids is that then you could use
>> a Long, Integer or String for the feature ID depending on the type of data.
>> I normally use Long but some models may use String based globally unique
>> ids, I wouldn't want to

Re: [JPP-Devel] Streamlining Java2DConverter decimation