Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-16 Thread Michaël Michaud
gt;>>>
>>>> @Michael. Thanks for the nice explanation. Very intuitive for the pictures.
>>>> Unfortunately it requires a hard job, more that the my (or our) target.
>>>>
>>>> Best regards
>>>>
>>>> Peppe
>>>>
>>>>
>>>>
>>>>
>>>> 2016-11-15 12:41 GMT+01:00 <edgar.sol...@web.de>:
>>>>
>>>>> Mike,
>>>>>
>>>>> i see your point. i'd vote to stick what we've got then and simply
>>>>> autocreate empty geometries as we do now. just curious, can CSV
>>>>> writer ignore geoms if i want to write a plain data table?
>>>>>
>>>>> ..ede
>>>>>
>>>>> On 15.11.2016 09:02, Michaël Michaud wrote:
>>>>>> Hi,
>>>>>>
>>>>>> If I had to refactor the layer hierarchy to include datasets
>>>>>> without
>>>>> geometry, I would probably try something like that
>>>>>> (note that it would be a big refactoring, and I am not able to
>>>>>> evaluate
>>>>> the workload to achieve it)
>>>>>> Current layer hierarchy
>>>>>>
>>>>>> Current layer hierarchy
>>>>>>
>>>>>> Proposition to include non-geometric data (and to factorize some
>>>>> attributes)
>>>>>> Proposed layer hierachy
>>>>>> Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :
>>>>>>> Hi,
>>>>>>>
>>>>>>> i used empty geomcollection so far, to have something there... I
>>>>>>> am not
>>>>> sure how much work it would be to introduce a new table/data layer
>>>>> without a geometry - as i am not sure if OJ is designed for that.
>>>>> Simplest may be to copy and make the field invisible for now.
>>>>>>> Perhaps Michaël has a better idea about the possibility to throw
>>>>>>> out
>>>>> the geom.
>>>>>>>
>>>>>>> cheers,
>>>>>>>
>>>>>>> stefan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- Originalnachricht --
>>>>>>> *Von: *
>>>>>>> *Datum: *14.11.2016 9:45
>>>>>>> *An: *OpenJump develop and use;
>>>>>>> *Betreff:*Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/
>>>>> vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
>>>>>>> i guess the cleanest solution would be a new layer class eg.
>>>>>>> DataLayer,
>>>>> that simply does not allow adding/editing geometries or does not
>>>>> even have a geometry attribute.
>>>>>>> in the 2nd case you would probably need a new featurecollection
>>>>>>> w/o a
>>>>> geometry column as well and the whole thing would throw some
>>>>> exceptions here and there, as OJ expects geometries in
>>>>> featurecollections, but apart from that it would be clean and the
>>>>> renderer would not need to monitor geom changes at all.
>>>>>>> ..ede
>>>>>>>
>>>>>>> On 14.11.2016 10:39, Giuseppe Aruta wrote:
>>>>>>>> Thanks Michael Ede
>>>>>>>> Indeed I came across (as a side relative problem ) working on
>>>>> Saxtante.
>>>>>>>> Sextante allows to work on Table files while Oj not. We can take
>>>>> advance of
>>>>>>>> the Sextante table algorithms  allowing Sextante to decode the
>>>>>>>> vector layers, with all features with empty geometries (see  for
>>>>>>>> instance
>>>>> loading
>>>>>>>> .csv on auto mode) as tables (I already added added into
>>>>>>>> Sextante
>>>>> binding a
>>>>>>>> Boolean method that allows to decode these files).
>>>>>>>> I wondered if users would also have benefit  to visualize that a
>>>>> table is
>>>>>>>> loaded into OJ workbench, with a table icon.
>>>>>>>> I will check other solutions. Thanks for the hint.
>>>>>>>> Peppe
>>>>>>>>
>>>>>>>> Il 13/Nov/2016 23:21, "Michaël Michaud

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-16 Thread edgar . soldin
15.11.2016 09:02, Michaël Michaud wrote:
>>>>> Hi,
>>>>>
>>>>> If I had to refactor the layer hierarchy to include datasets without
>>>> geometry, I would probably try something like that
>>>>> (note that it would be a big refactoring, and I am not able to
>>>>> evaluate
>>>> the workload to achieve it)
>>>>> Current layer hierarchy
>>>>>
>>>>> Current layer hierarchy
>>>>>
>>>>> Proposition to include non-geometric data (and to factorize some
>>>> attributes)
>>>>>
>>>>> Proposed layer hierachy
>>>>> Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :
>>>>>> Hi,
>>>>>>
>>>>>> i used empty geomcollection so far, to have something there... I am
>>>>>> not
>>>> sure how much work it would be to introduce a new table/data layer
>>>> without a geometry - as i am not sure if OJ is designed for that.
>>>> Simplest may be to copy and make the field invisible for now.
>>>>>> Perhaps Michaël has a better idea about the possibility to throw
>>>>>> out
>>>> the geom.
>>>>>>
>>>>>>
>>>>>> cheers,
>>>>>>
>>>>>> stefan
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- Originalnachricht --
>>>>>> *Von: *
>>>>>> *Datum: *14.11.2016 9:45
>>>>>> *An: *OpenJump develop and use;
>>>>>> *Betreff:*Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/
>>>> vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
>>>>>> i guess the cleanest solution would be a new layer class eg.
>>>>>> DataLayer,
>>>> that simply does not allow adding/editing geometries or does not even
>>>> have a geometry attribute.
>>>>>> in the 2nd case you would probably need a new featurecollection w/o
>>>>>> a
>>>> geometry column as well and the whole thing would throw some
>>>> exceptions here and there, as OJ expects geometries in
>>>> featurecollections, but apart from that it would be clean and the
>>>> renderer would not need to monitor geom changes at all.
>>>>>> ..ede
>>>>>>
>>>>>> On 14.11.2016 10:39, Giuseppe Aruta wrote:
>>>>>>> Thanks Michael Ede
>>>>>>> Indeed I came across (as a side relative problem ) working on
>>>> Saxtante.
>>>>>>> Sextante allows to work on Table files while Oj not. We can take
>>>> advance of
>>>>>>> the Sextante table algorithms  allowing Sextante to decode the
>>>>>>> vector layers, with all features with empty geometries (see  for
>>>>>>> instance
>>>> loading
>>>>>>> .csv on auto mode) as tables (I already added added into Sextante
>>>> binding a
>>>>>>> Boolean method that allows to decode these files).
>>>>>>> I wondered if users would also have benefit  to visualize that a
>>>> table is
>>>>>>> loaded into OJ workbench, with a table icon.
>>>>>>> I will check other solutions. Thanks for the hint.
>>>>>>> Peppe
>>>>>>>
>>>>>>> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
>>>>>>> scritto:
>>>>>>>
>>>>>>>> Hi Peppe,
>>>>>>>>
>>>>>>>> Seel also my answer on 2016-10-29.
>>>>>>>>
>>>>>>>> TreeLayerNamePanel has a listener, but to avoid a
>>>>>>>> featureCollection
>>>> scan
>>>>>>>> after each change
>>>>>>>> you probably need to keep a cache in the Layer as suggested by
>>>>>>>> Ede,
>>>> and
>>>>>>>> use the Layer's
>>>>>>>> listener to update the cache every time a feature is added,
>>>>>>>> removed
>>>> or
>>>>>>>> changed
>>>>>>>>
>>>>>>>> Michaël
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 13/11/2016 à 19:51, edgar.sol...@web.de a écrit :
>>>>>>>>> th

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread Michaël Michaud
Hi,

Renaming attributes to be compatible with shapefile specification is a 
common need.
I also had this need and decided to go through configuration files. With 
layers having
20 to 30 attributes each, if you have to rename attributes more than one 
or two times,
a graphical interface will not do it.

Currently, I just have a quick and dirty plugin, and I'm not completely 
satisfied with it
but I would be happy do discuss possible improvements. Current choices 
and limitations :
1 - not linked with drivers : layer names and attribute names are 
changed in the project
  -> not possible to remove geometry column
2 - renaming is not undoable
 (structure change is generally not undoable in OpenJUMP)
3 - I choose plain text file rather than xml to keep it as simple as 
possible

Notice : this is more a ETL capability. Wonder if it could be integrated 
to Sextante
modeler.

Michaël


Le 15/11/2016 à 21:49, Rahkonen Jukka (MML) a écrit :
> Good idea. How about having an option to rename the columns to be exported by 
> the same?  Would be handy for example when exporting columns with long names 
> into shapefiles when automatic truncation can create non-informative names.
>
> -Jukka Rahkonen-
>
> edgar soldin wrote:
>
>> maybe a panel to select the columns to be exported for the selected format 
>> would be A. reusable B. fitting for several formats (eg. csv, json).
> ..ede
>
>> On 15.11.2016 18:44, Giuseppe Aruta wrote:
>>> Hi everybody
>>> and thanks for the comments
>>>
>>> @Ede >can CSV writer ignore geoms if i want to write a plain data table?
>>> This is a good point. As CSV exporter also saves geometries in WKT.
>>> I did a couple of tests (exporting large shapefiles of Italian
>>> Regions/Provinces to csv), my LibreOffice speadsheet easly opened them
>>> (after a couple of quirks that the test is too long). Than I can
>>> delete the geometry columns and work with the other info
>> --
>>
>> Anyhow, going back to my modification. The problem cames out from the
>> following boolean
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *public static boolean isTable(Layer layer) { FeatureCollectionWrapper
>> featureCollection = layer
>> .getFeatureCollectionWrapper();List featureList =
>> featureCollection.getFeatures();Geometry nextGeo = null;for
>> (@SuppressWarnings("unchecked")Iterator i
>> = featureList.iterator(); i.hasNext();) {
>> Feature feature = (Feature) i.next();nextGeo =
>> feature.getGeometry();}if (!featureCollection.isEmpty() &&
>> nextGeo.isEmpty()) {return true;} else {
>> return false;}}*
>> It is rought and self explaining (I am not a good developer). The
>> feature collection is scanned. If all the geometries associated to all
>> features are empty, it gives back true().
>>
>> I wonder if I can limit all the trouble on this method, finding a
>> simpler and less invasive solution. Just a couple of idea:
>> It scan only over  the first 1000 of features or it does a random scan
>> over only 1000 features.
>>
>> There will be probably other simpler solutions. Any  idea is welcome.
>>
>>
>> @Michael. Thanks for the nice explanation. Very intuitive for the pictures.
>> Unfortunately it requires a hard job, more that the my (or our) target.
>>
>> Best regards
>>
>> Peppe
>>
>>
>>
>>
>> 2016-11-15 12:41 GMT+01:00 <edgar.sol...@web.de>:
>>
>>> Mike,
>>>
>>> i see your point. i'd vote to stick what we've got then and simply
>>> autocreate empty geometries as we do now. just curious, can CSV
>>> writer ignore geoms if i want to write a plain data table?
>>>
>>> ..ede
>>>
>>> On 15.11.2016 09:02, Michaël Michaud wrote:
>>>> Hi,
>>>>
>>>> If I had to refactor the layer hierarchy to include datasets without
>>> geometry, I would probably try something like that
>>>> (note that it would be a big refactoring, and I am not able to
>>>> evaluate
>>> the workload to achieve it)
>>>> Current layer hierarchy
>>>>
>>>> Current layer hierarchy
>>>>
>>>> Proposition to include non-geometric data (and to factorize some
>>> attributes)
>>>>
>>>> Proposed layer hierachy
>>>> Le 14/11/

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread Rahkonen Jukka (MML)
Good idea. How about having an option to rename the columns to be exported by 
the same?  Would be handy for example when exporting columns with long names 
into shapefiles when automatic truncation can create non-informative names.

-Jukka Rahkonen-

edgar soldin wrote:

> maybe a panel to select the columns to be exported for the selected format 
> would be A. reusable B. fitting for several formats (eg. csv, json).

..ede

> On 15.11.2016 18:44, Giuseppe Aruta wrote:
>> Hi everybody
>> and thanks for the comments
>> 
>> @Ede >can CSV writer ignore geoms if i want to write a plain data table?
>> This is a good point. As CSV exporter also saves geometries in WKT.
>> I did a couple of tests (exporting large shapefiles of Italian 
>> Regions/Provinces to csv), my LibreOffice speadsheet easly opened them 
>> (after a couple of quirks that the test is too long). Than I can 
>> delete the geometry columns and work with the other info
> 
> --
> 
> Anyhow, going back to my modification. The problem cames out from the 
> following boolean
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *public static boolean isTable(Layer layer) { FeatureCollectionWrapper 
> featureCollection = layer
> .getFeatureCollectionWrapper();List featureList =
> featureCollection.getFeatures();Geometry nextGeo = null;for
> (@SuppressWarnings("unchecked")Iterator i
> = featureList.iterator(); i.hasNext();) {
> Feature feature = (Feature) i.next();nextGeo =
> feature.getGeometry();}if (!featureCollection.isEmpty() &&
> nextGeo.isEmpty()) {return true;} else {
> return false;}}*
> It is rought and self explaining (I am not a good developer). The 
> feature collection is scanned. If all the geometries associated to all 
> features are empty, it gives back true().
> 
> I wonder if I can limit all the trouble on this method, finding a 
> simpler and less invasive solution. Just a couple of idea:
> It scan only over  the first 1000 of features or it does a random scan 
> over only 1000 features.
> 
> There will be probably other simpler solutions. Any  idea is welcome.
> 
> 
> @Michael. Thanks for the nice explanation. Very intuitive for the pictures.
> Unfortunately it requires a hard job, more that the my (or our) target.
> 
> Best regards
> 
> Peppe
> 
> 
> 
> 
> 2016-11-15 12:41 GMT+01:00 <edgar.sol...@web.de>:
> 
>> Mike,
>>
>> i see your point. i'd vote to stick what we've got then and simply 
>> autocreate empty geometries as we do now. just curious, can CSV 
>> writer ignore geoms if i want to write a plain data table?
>>
>> ..ede
>>
>> On 15.11.2016 09:02, Michaël Michaud wrote:
>>> Hi,
>>>
>>> If I had to refactor the layer hierarchy to include datasets without
>> geometry, I would probably try something like that
>>> (note that it would be a big refactoring, and I am not able to 
>>> evaluate
>> the workload to achieve it)
>>>
>>> Current layer hierarchy
>>>
>>> Current layer hierarchy
>>>
>>> Proposition to include non-geometric data (and to factorize some
>> attributes)
>>>
>>>
>>> Proposed layer hierachy
>>> Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :
>>>>
>>>> Hi,
>>>>
>>>> i used empty geomcollection so far, to have something there... I am 
>>>> not
>> sure how much work it would be to introduce a new table/data layer 
>> without a geometry - as i am not sure if OJ is designed for that. 
>> Simplest may be to copy and make the field invisible for now.
>>>>
>>>> Perhaps Michaël has a better idea about the possibility to throw 
>>>> out
>> the geom.
>>>>
>>>>
>>>>
>>>> cheers,
>>>>
>>>> stefan
>>>>
>>>>
>>>>
>>>> -- Originalnachricht --
>>>> *Von: *
>>>> *Datum: *14.11.2016 9:45
>>>> *An: *OpenJump develop and use;
>>>> *Betreff:*Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/
>> vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
>>>>
>>>> i guess the cleanest solution would be a new layer class eg. 
>>>> DataLayer,
>> that simply does not allow adding/editing geometries or does not even 
>> have a geometry attribute.
>>>>
>>

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread edgar . soldin
ok. A. equals B. there, i mean A. flexible B. reusable.. ede

On 15.11.2016 21:21, edgar.sol...@web.de wrote:
> maybe a panel to select the columns to be exported for the selected format 
> would be A. reusable B. fitting for several formats (eg. csv, json).
> 
> ..ede
> 
> On 15.11.2016 18:44, Giuseppe Aruta wrote:
>> Hi everybody
>> and thanks for the comments
>>
>> @Ede >can CSV writer ignore geoms if i want to write a plain data table?
>> This is a good point. As CSV exporter also saves geometries in WKT.
>> I did a couple of tests (exporting large shapefiles of Italian
>> Regions/Provinces to csv), my LibreOffice speadsheet easly opened them (after
>> a couple of quirks that the test is too long). Than I can delete the
>> geometry columns and work with the other info
>>
>> --
>>
>> Anyhow, going back to my modification. The problem cames out from the
>> following boolean
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *public static boolean isTable(Layer layer) {
>> FeatureCollectionWrapper featureCollection = layer
>> .getFeatureCollectionWrapper();List featureList =
>> featureCollection.getFeatures();Geometry nextGeo = null;for
>> (@SuppressWarnings("unchecked")Iterator i
>> = featureList.iterator(); i.hasNext();) {
>> Feature feature = (Feature) i.next();nextGeo =
>> feature.getGeometry();}if (!featureCollection.isEmpty() &&
>> nextGeo.isEmpty()) {return true;} else {
>> return false;}}*
>> It is rought and self explaining (I am not a good developer). The feature
>> collection is scanned. If all the geometries associated to all features are
>> empty, it gives back true().
>>
>> I wonder if I can limit all the trouble on this method, finding a simpler
>> and less invasive solution. Just a couple of idea:
>> It scan only over  the first 1000 of features
>> or
>> it does a random scan over only 1000 features.
>>
>> There will be probably other simpler solutions. Any  idea is welcome.
>>
>>
>> @Michael. Thanks for the nice explanation. Very intuitive for the pictures.
>> Unfortunately it requires a hard job, more that the my (or our) target.
>>
>> Best regards
>>
>> Peppe
>>
>>
>>
>>
>> 2016-11-15 12:41 GMT+01:00 <edgar.sol...@web.de>:
>>
>>> Mike,
>>>
>>> i see your point. i'd vote to stick what we've got then and simply
>>> autocreate empty geometries as we do now. just curious, can CSV writer
>>> ignore geoms if i want to write a plain data table?
>>>
>>> ..ede
>>>
>>> On 15.11.2016 09:02, Michaël Michaud wrote:
>>>> Hi,
>>>>
>>>> If I had to refactor the layer hierarchy to include datasets without
>>> geometry, I would probably try something like that
>>>> (note that it would be a big refactoring, and I am not able to evaluate
>>> the workload to achieve it)
>>>>
>>>> Current layer hierarchy
>>>>
>>>> Current layer hierarchy
>>>>
>>>> Proposition to include non-geometric data (and to factorize some
>>> attributes)
>>>>
>>>>
>>>> Proposed layer hierachy
>>>> Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :
>>>>>
>>>>> Hi,
>>>>>
>>>>> i used empty geomcollection so far, to have something there... I am not
>>> sure how much work it would be to introduce a new table/data layer without
>>> a geometry - as i am not sure if OJ is designed for that. Simplest may be
>>> to copy and make the field invisible for now.
>>>>>
>>>>> Perhaps Michaël has a better idea about the possibility to throw out
>>> the geom.
>>>>>
>>>>>
>>>>>
>>>>> cheers,
>>>>>
>>>>> stefan
>>>>>
>>>>>
>>>>>
>>>>> -- Originalnachricht --
>>>>> *Von: *
>>>>> *Datum: *14.11.2016 9:45
>>>>> *An: *OpenJump develop and use;
>>>>> *Betreff:*Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/
>>> vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
>>>>>
>>>>> i guess the cleanest solutio

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread Giuseppe Aruta
Hi everybody
and thanks for the comments

@Ede >can CSV writer ignore geoms if i want to write a plain data table?
This is a good point. As CSV exporter also saves geometries in WKT.
I did a couple of tests (exporting large shapefiles of Italian
Regions/Provinces to csv), my LibreOffice speadsheet easly opened them (after
a couple of quirks that the test is too long). Than I can delete the
geometry columns and work with the other info

--

Anyhow, going back to my modification. The problem cames out from the
following boolean



















*public static boolean isTable(Layer layer) {
FeatureCollectionWrapper featureCollection = layer
.getFeatureCollectionWrapper();List featureList =
featureCollection.getFeatures();Geometry nextGeo = null;for
(@SuppressWarnings("unchecked")Iterator i
= featureList.iterator(); i.hasNext();) {
Feature feature = (Feature) i.next();nextGeo =
feature.getGeometry();}if (!featureCollection.isEmpty() &&
nextGeo.isEmpty()) {return true;} else {
return false;}}*
It is rought and self explaining (I am not a good developer). The feature
collection is scanned. If all the geometries associated to all features are
empty, it gives back true().

I wonder if I can limit all the trouble on this method, finding a simpler
and less invasive solution. Just a couple of idea:
It scan only over  the first 1000 of features
or
it does a random scan over only 1000 features.

There will be probably other simpler solutions. Any  idea is welcome.


@Michael. Thanks for the nice explanation. Very intuitive for the pictures.
Unfortunately it requires a hard job, more that the my (or our) target.

Best regards

Peppe




2016-11-15 12:41 GMT+01:00 <edgar.sol...@web.de>:

> Mike,
>
> i see your point. i'd vote to stick what we've got then and simply
> autocreate empty geometries as we do now. just curious, can CSV writer
> ignore geoms if i want to write a plain data table?
>
> ..ede
>
> On 15.11.2016 09:02, Michaël Michaud wrote:
> > Hi,
> >
> > If I had to refactor the layer hierarchy to include datasets without
> geometry, I would probably try something like that
> > (note that it would be a big refactoring, and I am not able to evaluate
> the workload to achieve it)
> >
> > Current layer hierarchy
> >
> > Current layer hierarchy
> >
> > Proposition to include non-geometric data (and to factorize some
> attributes)
> >
> >
> > Proposed layer hierachy
> > Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :
> >>
> >> Hi,
> >>
> >> i used empty geomcollection so far, to have something there... I am not
> sure how much work it would be to introduce a new table/data layer without
> a geometry - as i am not sure if OJ is designed for that. Simplest may be
> to copy and make the field invisible for now.
> >>
> >> Perhaps Michaël has a better idea about the possibility to throw out
> the geom.
> >>
> >>
> >>
> >> cheers,
> >>
> >> stefan
> >>
> >>
> >>
> >> -- Originalnachricht --
> >> *Von: *
> >> *Datum: *14.11.2016 9:45
> >> *An: *OpenJump develop and use;
> >> *Betreff:*Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/
> vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
> >>
> >> i guess the cleanest solution would be a new layer class eg. DataLayer,
> that simply does not allow adding/editing geometries or does not even have
> a geometry attribute.
> >>
> >> in the 2nd case you would probably need a new featurecollection w/o a
> geometry column as well and the whole thing would throw some exceptions
> here and there, as OJ expects geometries in featurecollections, but apart
> from that it would be clean and the renderer would not need to monitor geom
> changes at all.
> >>
> >> ..ede
> >>
> >> On 14.11.2016 10:39, Giuseppe Aruta wrote:
> >> > Thanks Michael Ede
> >> > Indeed I came across (as a side relative problem ) working on
> Saxtante.
> >> > Sextante allows to work on Table files while Oj not. We can take
> advance of
> >> > the Sextante table algorithms  allowing Sextante to decode the vector
> >> > layers, with all features with empty geometries (see  for instance
> loading
> >> > .csv on auto mode) as tables (I already added added into Sextante
> binding a
> >> > Boolean method that allows to decode these files).
> >> > I wondered if users would also have benefit  to visualize that a
> table is

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread edgar . soldin
Jukka,

nothing to worry, my mind was w/ GeoJSON still and the only possibility to add 
an empty geom there is to use GeometryCollection because of the constraints i 
described.

my bad ..ede

On 15.11.2016 11:16, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> What do you mean? You did lot of work with empty geometries two years ago. In 
> December 1st, 2014 I answered you, probably after the final tests
> 
> "Hi Ede,
> 
> All this seems to work perfectly now:
> - Different empty geometries are visualized with corresponding icons
> - All kind of empty geometries can be saved into JUMP jml and FME GML and 
> returned as they were.
> - Empty geometries in shapefiles are handled in a reasonable way:
>  - "Extract layers by geometry type" extracts empty points to a point 
> layer, empty linestrings to a linestring layer etc.
> - Empty geometries which are read from a shapefile are marked to be empty 
> geometries of the same type as the not-empty geometries. A point shapefile 
> brings empty points, a line shapefile empty multilinestrings and a polygon 
> shape empty multipolygons. Because shapefiles do not make much difference 
> between simple and multivariants this is just right."
> 
> -Jukka-
> 
> -Alkuperäinen viesti-
> Lähettäjä: edgar.sol...@web.de [mailto:edgar.sol...@web.de] 
> Lähetetty: 15. marraskuuta 2016 12:11
> Vastaanottaja: Rahkonen Jukka (MML) <jukka.rahko...@maanmittauslaitos.fi>; 
> OpenJump develop and use <jump-pilot-devel@lists.sourceforge.net>
> Aihe: Re: [JPP-Devel] SVN: [5185] 
> core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
> 
> GeometryCollection is afaik the only possibility to have an empty geometry as 
> all other geom types require either coordinates or sub geoms per definition.
> 
> ..ede
> 
> On 15.11.2016 11:06, Rahkonen Jukka (MML) wrote:
>> Hi,
>>
>> DB Query plugin is attaching a fake GEOMETRYCOLLECTION EMPTY to all the 
>> lines without a real geometry. For my purposes it has been a good solution 
>> but I can’t say if it suits for other use cases.
>>
>> -Jukka Rahkonen-
>>
>> Stefan Steiniger wrote:
>>
>>
>> Hi,
>>
>> i used empty geomcollection so far, to have something there... I am not sure 
>> how much work it would be to introduce a new table/data layer without a 
>> geometry - as i am not sure if OJ is designed for that. Simplest may be to 
>> copy and make the field invisible for now.
>>
>> Perhaps Michaël has a better idea about the possibility to throw out the 
>> geom.
>>
>>
>>
>> cheers,
>>
>> stefan
>>
>>
>> -- Originalnachricht --
>> Von:
>> Datum: 14.11.2016 9:45
>> An: OpenJump develop and use;
>> Betreff:Re: [JPP-Devel] SVN: [5185] 
>> core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
>>
>> i guess the cleanest solution would be a new layer class eg. DataLayer, that 
>> simply does not allow adding/editing geometries or does not even have a 
>> geometry attribute.
>>
>>
>>
>> in the 2nd case you would probably need a new featurecollection w/o a 
>> geometry column as well and the whole thing would throw some exceptions here 
>> and there, as OJ expects geometries in featurecollections, but apart from 
>> that it would be clean and the renderer would not need to monitor geom 
>> changes at all.
>>
>>
>>
>> ..ede
>>
>>
>>
>> On 14.11.2016 10:39, Giuseppe Aruta wrote:
>>
>>> Thanks Michael Ede
>>
>>> Indeed I came across (as a side relative problem ) working on Saxtante.
>>
>>> Sextante allows to work on Table files while Oj not. We can take advance of
>>
>>> the Sextante table algorithms  allowing Sextante to decode the vector
>>
>>> layers, with all features with empty geometries (see  for instance loading
>>
>>> .csv on auto mode) as tables (I already added added into Sextante binding a
>>
>>> Boolean method that allows to decode these files).
>>
>>> I wondered if users would also have benefit  to visualize that a table is
>>
>>> loaded into OJ workbench, with a table icon.
>>
>>> I will check other solutions. Thanks for the hint.
>>
>>> Peppe
>>
>>>
>>
>>> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
>>
>>> scritto:
>>
>>>
>>
>>>> Hi Peppe,
>>
>>>>
>>
>>>> Seel also my answer on 2016-10-29.
>>
>>>>
>>
>>>>

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread Rahkonen Jukka (MML)
Hi,

What do you mean? You did lot of work with empty geometries two years ago. In 
December 1st, 2014 I answered you, probably after the final tests

"Hi Ede,

All this seems to work perfectly now:
- Different empty geometries are visualized with corresponding icons
- All kind of empty geometries can be saved into JUMP jml and FME GML and 
returned as they were.
- Empty geometries in shapefiles are handled in a reasonable way:
 - "Extract layers by geometry type" extracts empty points to a point 
layer, empty linestrings to a linestring layer etc.
- Empty geometries which are read from a shapefile are marked to be empty 
geometries of the same type as the not-empty geometries. A point shapefile 
brings empty points, a line shapefile empty multilinestrings and a polygon 
shape empty multipolygons. Because shapefiles do not make much difference 
between simple and multivariants this is just right."

-Jukka-

-Alkuperäinen viesti-
Lähettäjä: edgar.sol...@web.de [mailto:edgar.sol...@web.de] 
Lähetetty: 15. marraskuuta 2016 12:11
Vastaanottaja: Rahkonen Jukka (MML) <jukka.rahko...@maanmittauslaitos.fi>; 
OpenJump develop and use <jump-pilot-devel@lists.sourceforge.net>
Aihe: Re: [JPP-Devel] SVN: [5185] 
core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

GeometryCollection is afaik the only possibility to have an empty geometry as 
all other geom types require either coordinates or sub geoms per definition.

..ede

On 15.11.2016 11:06, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> DB Query plugin is attaching a fake GEOMETRYCOLLECTION EMPTY to all the lines 
> without a real geometry. For my purposes it has been a good solution but I 
> can’t say if it suits for other use cases.
> 
> -Jukka Rahkonen-
> 
> Stefan Steiniger wrote:
> 
> 
> Hi,
> 
> i used empty geomcollection so far, to have something there... I am not sure 
> how much work it would be to introduce a new table/data layer without a 
> geometry - as i am not sure if OJ is designed for that. Simplest may be to 
> copy and make the field invisible for now.
> 
> Perhaps Michaël has a better idea about the possibility to throw out the geom.
> 
> 
> 
> cheers,
> 
> stefan
> 
> 
> -- Originalnachricht --
> Von:
> Datum: 14.11.2016 9:45
> An: OpenJump develop and use;
> Betreff:Re: [JPP-Devel] SVN: [5185] 
> core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
> 
> i guess the cleanest solution would be a new layer class eg. DataLayer, that 
> simply does not allow adding/editing geometries or does not even have a 
> geometry attribute.
> 
> 
> 
> in the 2nd case you would probably need a new featurecollection w/o a 
> geometry column as well and the whole thing would throw some exceptions here 
> and there, as OJ expects geometries in featurecollections, but apart from 
> that it would be clean and the renderer would not need to monitor geom 
> changes at all.
> 
> 
> 
> ..ede
> 
> 
> 
> On 14.11.2016 10:39, Giuseppe Aruta wrote:
> 
>> Thanks Michael Ede
> 
>> Indeed I came across (as a side relative problem ) working on Saxtante.
> 
>> Sextante allows to work on Table files while Oj not. We can take advance of
> 
>> the Sextante table algorithms  allowing Sextante to decode the vector
> 
>> layers, with all features with empty geometries (see  for instance loading
> 
>> .csv on auto mode) as tables (I already added added into Sextante binding a
> 
>> Boolean method that allows to decode these files).
> 
>> I wondered if users would also have benefit  to visualize that a table is
> 
>> loaded into OJ workbench, with a table icon.
> 
>> I will check other solutions. Thanks for the hint.
> 
>> Peppe
> 
>>
> 
>> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
> 
>> scritto:
> 
>>
> 
>>> Hi Peppe,
> 
>>>
> 
>>> Seel also my answer on 2016-10-29.
> 
>>>
> 
>>> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan
> 
>>> after each change
> 
>>> you probably need to keep a cache in the Layer as suggested by Ede, and
> 
>>> use the Layer's
> 
>>> listener to update the cache every time a feature is added, removed or
> 
>>> changed
> 
>>>
> 
>>> Michaël
> 
>>>
> 
>>>
> 
>>> Le 13/11/2016 à 19:51, edgar.sol...@web.de<mailto:edgar.sol...@web.de> a 
>>> écrit :
> 
>>>> thanks.. how about implementing the caching/listener approach if you
> 
>>> like to have icon? ..ede
> 
>>>>
> 
>>>> On 13.11.2016 18:57, Gi

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread edgar . soldin
GeometryCollection is afaik the only possibility to have an empty geometry as 
all other geom types require either coordinates or sub geoms per definition.

..ede

On 15.11.2016 11:06, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> DB Query plugin is attaching a fake GEOMETRYCOLLECTION EMPTY to all the lines 
> without a real geometry. For my purposes it has been a good solution but I 
> can’t say if it suits for other use cases.
> 
> -Jukka Rahkonen-
> 
> Stefan Steiniger wrote:
> 
> 
> Hi,
> 
> i used empty geomcollection so far, to have something there... I am not sure 
> how much work it would be to introduce a new table/data layer without a 
> geometry - as i am not sure if OJ is designed for that. Simplest may be to 
> copy and make the field invisible for now.
> 
> Perhaps Michaël has a better idea about the possibility to throw out the geom.
> 
> 
> 
> cheers,
> 
> stefan
> 
> 
> -- Originalnachricht ------
> Von:
> Datum: 14.11.2016 9:45
> An: OpenJump develop and use;
> Betreff:Re: [JPP-Devel] SVN: [5185] 
> core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
> 
> i guess the cleanest solution would be a new layer class eg. DataLayer, that 
> simply does not allow adding/editing geometries or does not even have a 
> geometry attribute.
> 
> 
> 
> in the 2nd case you would probably need a new featurecollection w/o a 
> geometry column as well and the whole thing would throw some exceptions here 
> and there, as OJ expects geometries in featurecollections, but apart from 
> that it would be clean and the renderer would not need to monitor geom 
> changes at all.
> 
> 
> 
> ..ede
> 
> 
> 
> On 14.11.2016 10:39, Giuseppe Aruta wrote:
> 
>> Thanks Michael Ede
> 
>> Indeed I came across (as a side relative problem ) working on Saxtante.
> 
>> Sextante allows to work on Table files while Oj not. We can take advance of
> 
>> the Sextante table algorithms  allowing Sextante to decode the vector
> 
>> layers, with all features with empty geometries (see  for instance loading
> 
>> .csv on auto mode) as tables (I already added added into Sextante binding a
> 
>> Boolean method that allows to decode these files).
> 
>> I wondered if users would also have benefit  to visualize that a table is
> 
>> loaded into OJ workbench, with a table icon.
> 
>> I will check other solutions. Thanks for the hint.
> 
>> Peppe
> 
>>
> 
>> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
> 
>> scritto:
> 
>>
> 
>>> Hi Peppe,
> 
>>>
> 
>>> Seel also my answer on 2016-10-29.
> 
>>>
> 
>>> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan
> 
>>> after each change
> 
>>> you probably need to keep a cache in the Layer as suggested by Ede, and
> 
>>> use the Layer's
> 
>>> listener to update the cache every time a feature is added, removed or
> 
>>> changed
> 
>>>
> 
>>> Michaël
> 
>>>
> 
>>>
> 
>>> Le 13/11/2016 à 19:51, edgar.sol...@web.de<mailto:edgar.sol...@web.de> a 
>>> écrit :
> 
>>>> thanks.. how about implementing the caching/listener approach if you
> 
>>> like to have icon? ..ede
> 
>>>>
> 
>>>> On 13.11.2016 18:57, Giuseppe Aruta wrote:
> 
>>>>> Ok Ede, I didn't  know it. I will revert the change.
> 
>>>>> Thanks again
> 
>>>>> Peppe
> 
>>>>>
> 
>>>>> Il 13/Nov/2016 18:48,  ha scritto:
> 
>>>>>
> 
>>>>>> Peppe,
> 
>>>>>>
> 
>>>>>> NACK.. this is going to get very slow for huge datasets containing
> 
>>> empty
> 
>>>>>> geoms only, as it is run on every redraw of the layer tree. please
> 
>>> cache
> 
>>>>>> the state and use a layer change listener or else users will complain
> 
>>> about
> 
>>>>>> a frozen OJ some time in the future and we will have a hard time to
> 
>>>>>> pinpoint the reason, again ;)
> 
>>>>>>
> 
>>>>>> ..ede
> 
>>>>>>
> 
>>>>>> On 13.11.2016 18:41, 
>>>>>> jump-pilot-...@lists.sourceforge.net<mailto:jump-pilot-...@lists.sourceforge.net>
>>>>>>  wrote:
> 
>>>>>>> Revision: 5185
> 
>>>>>>>http://sourceforge.net/p/jump-pilot/code/5185
> 
>

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread Rahkonen Jukka (MML)
Hi,

DB Query plugin is attaching a fake GEOMETRYCOLLECTION EMPTY to all the lines 
without a real geometry. For my purposes it has been a good solution but I 
can’t say if it suits for other use cases.

-Jukka Rahkonen-

Stefan Steiniger wrote:


Hi,

i used empty geomcollection so far, to have something there... I am not sure 
how much work it would be to introduce a new table/data layer without a 
geometry - as i am not sure if OJ is designed for that. Simplest may be to copy 
and make the field invisible for now.

Perhaps Michaël has a better idea about the possibility to throw out the geom.



cheers,

stefan


-- Originalnachricht --
Von:
Datum: 14.11.2016 9:45
An: OpenJump develop and use;
Betreff:Re: [JPP-Devel] SVN: [5185] 
core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

i guess the cleanest solution would be a new layer class eg. DataLayer, that 
simply does not allow adding/editing geometries or does not even have a 
geometry attribute.



in the 2nd case you would probably need a new featurecollection w/o a geometry 
column as well and the whole thing would throw some exceptions here and there, 
as OJ expects geometries in featurecollections, but apart from that it would be 
clean and the renderer would not need to monitor geom changes at all.



..ede



On 14.11.2016 10:39, Giuseppe Aruta wrote:

> Thanks Michael Ede

> Indeed I came across (as a side relative problem ) working on Saxtante.

> Sextante allows to work on Table files while Oj not. We can take advance of

> the Sextante table algorithms  allowing Sextante to decode the vector

> layers, with all features with empty geometries (see  for instance loading

> .csv on auto mode) as tables (I already added added into Sextante binding a

> Boolean method that allows to decode these files).

> I wondered if users would also have benefit  to visualize that a table is

> loaded into OJ workbench, with a table icon.

> I will check other solutions. Thanks for the hint.

> Peppe

>

> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha

> scritto:

>

>> Hi Peppe,

>>

>> Seel also my answer on 2016-10-29.

>>

>> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan

>> after each change

>> you probably need to keep a cache in the Layer as suggested by Ede, and

>> use the Layer's

>> listener to update the cache every time a feature is added, removed or

>> changed

>>

>> Michaël

>>

>>

>> Le 13/11/2016 à 19:51, edgar.sol...@web.de<mailto:edgar.sol...@web.de> a 
>> écrit :

>>> thanks.. how about implementing the caching/listener approach if you

>> like to have icon? ..ede

>>>

>>> On 13.11.2016 18:57, Giuseppe Aruta wrote:

>>>> Ok Ede, I didn't  know it. I will revert the change.

>>>> Thanks again

>>>> Peppe

>>>>

>>>> Il 13/Nov/2016 18:48,  ha scritto:

>>>>

>>>>> Peppe,

>>>>>

>>>>> NACK.. this is going to get very slow for huge datasets containing

>> empty

>>>>> geoms only, as it is run on every redraw of the layer tree. please

>> cache

>>>>> the state and use a layer change listener or else users will complain

>> about

>>>>> a frozen OJ some time in the future and we will have a hard time to

>>>>> pinpoint the reason, again ;)

>>>>>

>>>>> ..ede

>>>>>

>>>>> On 13.11.2016 18:41, 
>>>>> jump-pilot-...@lists.sourceforge.net<mailto:jump-pilot-...@lists.sourceforge.net>
>>>>>  wrote:

>>>>>> Revision: 5185

>>>>>>http://sourceforge.net/p/jump-pilot/code/5185

>>>>>> Author:   ma15569

>>>>>> Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)

>>>>>> Log Message:

>>>>>> ---

>>>>>> The layer tree shows a table icon for layers that have features with

>>>>> empty geometries

>>>>>> Modified Paths:

>>>>>> --

>>>>>>  core/trunk/src/com/vividsolutions/jump/workbench/

>>>>> ui/LayerNameRenderer.java

>>>>>> Modified: core/trunk/src/com/vividsolutions/jump/workbench/

>>>>> ui/LayerNameRenderer.java

>>>>>> ===

>>>>>> --- core/trunk/src/com/vividsolutions/jump/workbench/

>> ui/LayerNameRenderer.java

>>>>>2016-11-13 17:21:20 UTC (rev 5184)

>>>>

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-15 Thread Michaël Michaud

Hi,

If I had to refactor the layer hierarchy to include datasets without 
geometry, I would probably try something like that
(note that it would be a big refactoring, and I am not able to evaluate 
the workload to achieve it)


Current layer hierarchy

Current layer hierarchy

Proposition to include non-geometric data (and to factorize some attributes)


Proposed layer hierachy
Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :


Hi,

i used empty geomcollection so far, to have something there... I am 
not sure how much work it would be to introduce a new table/data layer 
without a geometry - as i am not sure if OJ is designed for that. 
Simplest may be to copy and make the field invisible for now.


Perhaps Michaël has a better idea about the possibility to throw out 
the geom.


cheers,

stefan

-- Originalnachricht --
*Von: *
*Datum: *14.11.2016 9:45
*An: *OpenJump develop and use;
*Betreff:*Re: [JPP-Devel] SVN: [5185] 
core/trunk/src/com/vividsolutions/jump/workbench/ui/ 
LayerNameRenderer.java


i guess the cleanest solution would be a new layer class eg. DataLayer, that 
simply does not allow adding/editing geometries or does not even have a 
geometry attribute.

in the 2nd case you would probably need a new featurecollection w/o a geometry 
column as well and the whole thing would throw some exceptions here and there, 
as OJ expects geometries in featurecollections, but apart from that it would be 
clean and the renderer would not need to monitor geom changes at all.

..ede

On 14.11.2016 10:39, Giuseppe Aruta wrote:
> Thanks Michael Ede
> Indeed I came across (as a side relative problem ) working on Saxtante.
> Sextante allows to work on Table files while Oj not. We can take advance of
> the Sextante table algorithms  allowing Sextante to decode the vector
> layers, with all features with empty geometries (see  for instance loading
> .csv on auto mode) as tables (I already added added into Sextante binding a
> Boolean method that allows to decode these files).
> I wondered if users would also have benefit  to visualize that a table is
> loaded into OJ workbench, with a table icon.
> I will check other solutions. Thanks for the hint.
> Peppe
>
> Il 13/Nov/2016 23:21, "Michaël Michaud"ha > scritto: > >> Hi Peppe, >> >> Seel also my answer on 2016-10-29. 
>> >> TreeLayerNamePanel has a listener, but to avoid a 
featureCollection scan >> after each change >> you probably need to 
keep a cache in the Layer as suggested by Ede, and >> use the Layer's 
>> listener to update the cache every time a feature is added, removed 
or >> changed >> >> Michaël >> >> >> Le 13/11/2016 à 19:51, 
edgar.sol...@web.de a écrit : >>> thanks.. how about implementing the 
caching/listener approach if you >> like to have icon? ..ede >>> >>> 
On 13.11.2016 18:57, Giuseppe Aruta wrote: >>>> Ok Ede, I didn't  know 
it. I will revert the change. >>>> Thanks again >>>> Peppe >>>> >>>> 
Il 13/Nov/2016 18:48, ha scritto: >>>> >>>>> Peppe, >>>>> >>>>> NACK.. 
this is going to get very slow for huge datasets containing >> empty 
>>>>> geoms only, as it is run on every redraw of the layer tree. 
please >> cache >>>>> the state and use a layer change listener or 
else users will complain >> about >>>>> a frozen OJ some time in the 
future and we will have a hard time to >>>>> pinpoint the reason, 
again ;) >>>>> >>>>> ..ede >>>>> >>>>> On 13.11.2016 18:41, 
jump-pilot-...@lists.sourceforge.net wrote: >>>>>> Revision: 5185 
>>>>>>http://sourceforge.net/p/jump-pilot/code/5185 >>>>>> 
Author:   ma15569 >>>>>> Date: 2016-11-13 17:41:37 + (Sun, 13 
Nov 2016) >>>>>> Log Message: >>>>>> --- >>>>>> The layer tree 
shows a table icon for layers that have features with >>>>> empty 
geometries >>>>>> Modified Paths: >>>>>> -- >>>>>> 
 core/trunk/src/com/vividsolutions/jump/workbench/ >>>>> 
ui/LayerNameRenderer.java >>>>>> Modified: 
core/trunk/src/com/vividsolutions/jump/workbench/ >>>>> 
ui/LayerNameRenderer.java >>>>>> 
=== 
>>>>>> --- core/trunk/src/com/vividsolutions/jump/workbench/ >> 
ui/LayerNameRenderer.java >>>>>2016-11-13 17:21:20 UTC (rev 
5184) >>>>>> +++ core/trunk/s

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-14 Thread Stefan Steiniger


Hi,i used empty geomcollection so far, to have something there... I am not sure how much work it would be to introduce a new table/data layer without a geometry - as i am not sure if OJ is designed for that. Simplest may be to copy and make the field invisible for now. Perhaps Michaël has a better idea about the possibility to throw out the geom. cheers,stefan -- Originalnachricht --Von: Datum: 14.11.2016 9:45An: OpenJump develop and use;Betreff:Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.javai guess the cleanest solution would be a new layer class eg. DataLayer, that simply does not allow adding/editing geometries or does not even have a geometry attribute.

in the 2nd case you would probably need a new featurecollection w/o a geometry column as well and the whole thing would throw some exceptions here and there, as OJ expects geometries in featurecollections, but apart from that it would be clean and the renderer would not need to monitor geom changes at all.

..ede

On 14.11.2016 10:39, Giuseppe Aruta wrote:
> Thanks Michael Ede
> Indeed I came across (as a side relative problem ) working on Saxtante.
> Sextante allows to work on Table files while Oj not. We can take advance of
> the Sextante table algorithms  allowing Sextante to decode the vector
> layers, with all features with empty geometries (see  for instance loading
> .csv on auto mode) as tables (I already added added into Sextante binding a
> Boolean method that allows to decode these files).
> I wondered if users would also have benefit  to visualize that a table is
> loaded into OJ workbench, with a table icon.
> I will check other solutions. Thanks for the hint.
> Peppe
> 
> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
> scritto:
> 
>> Hi Peppe,
>>
>> Seel also my answer on 2016-10-29.
>>
>> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan
>> after each change
>> you probably need to keep a cache in the Layer as suggested by Ede, and
>> use the Layer's
>> listener to update the cache every time a feature is added, removed or
>> changed
>>
>> Michaël
>>
>>
>> Le 13/11/2016 à 19:51, edgar.sol...@web.de a écrit :
>>> thanks.. how about implementing the caching/listener approach if you
>> like to have icon? ..ede
>>>
>>> On 13.11.2016 18:57, Giuseppe Aruta wrote:
 Ok Ede, I didn't  know it. I will revert the change.
 Thanks again
 Peppe

 Il 13/Nov/2016 18:48,  ha scritto:

> Peppe,
>
> NACK.. this is going to get very slow for huge datasets containing
>> empty
> geoms only, as it is run on every redraw of the layer tree. please
>> cache
> the state and use a layer change listener or else users will complain
>> about
> a frozen OJ some time in the future and we will have a hard time to
> pinpoint the reason, again ;)
>
> ..ede
>
> On 13.11.2016 18:41, jump-pilot-...@lists.sourceforge.net wrote:
>> Revision: 5185
>>    http://sourceforge.net/p/jump-pilot/code/5185
>> Author:   ma15569
>> Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
>> Log Message:
>> ---
>> The layer tree shows a table icon for layers that have features with
> empty geometries
>> Modified Paths:
>> --
>>  core/trunk/src/com/vividsolutions/jump/workbench/
> ui/LayerNameRenderer.java
>> Modified: core/trunk/src/com/vividsolutions/jump/workbench/
> ui/LayerNameRenderer.java
>> ===
>> --- core/trunk/src/com/vividsolutions/jump/workbench/
>> ui/LayerNameRenderer.java
>    2016-11-13 17:21:20 UTC (rev 5184)
>> +++ core/trunk/src/com/vividsolutions/jump/workbench/
>> ui/LayerNameRenderer.java
>    2016-11-13 17:41:37 UTC (rev 5185)
>> @@ -36,6 +36,7 @@
>>   import java.awt.Rectangle;
>>   import java.io.File;
>>   import java.util.Iterator;
>> +import java.util.List;
>>
>>   import javax.swing.DefaultListCellRenderer;
>>   import javax.swing.Icon;
>> @@ -54,9 +55,11 @@
>>   import org.openjump.core.rasterimage.RasterImageLayer;
>>
>>   import com.vividsolutions.jts.geom.Envelope;
>> +import com.vividsolutions.jts.geom.Geometry;
>>   import com.vividsolutions.jump.I18N;
>>   import com.vividsolutions.jump.feature.Feature;
>>   import com.vividsolutions.jump.feature.FeatureCollection;
>> +import com.vividsolutions.jump.feature.FeatureCollectionWrapper;
>>   import com.vividsolutions.jump.io.datasource.DataSourceQuery;
>>   import com.vividsolutions.jump.util.StringUtil;
>>   import com.vividsolutions.jump.workbench.JUMPWorkbench;
>> @@ -118,6 +121,7 @@
>>   private ImageIcon rasterIcon 

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-14 Thread edgar . soldin
i guess the cleanest solution would be a new layer class eg. DataLayer, that 
simply does not allow adding/editing geometries or does not even have a 
geometry attribute.

in the 2nd case you would probably need a new featurecollection w/o a geometry 
column as well and the whole thing would throw some exceptions here and there, 
as OJ expects geometries in featurecollections, but apart from that it would be 
clean and the renderer would not need to monitor geom changes at all.

..ede

On 14.11.2016 10:39, Giuseppe Aruta wrote:
> Thanks Michael Ede
> Indeed I came across (as a side relative problem ) working on Saxtante.
> Sextante allows to work on Table files while Oj not. We can take advance of
> the Sextante table algorithms  allowing Sextante to decode the vector
> layers, with all features with empty geometries (see  for instance loading
> .csv on auto mode) as tables (I already added added into Sextante binding a
> Boolean method that allows to decode these files).
> I wondered if users would also have benefit  to visualize that a table is
> loaded into OJ workbench, with a table icon.
> I will check other solutions. Thanks for the hint.
> Peppe
> 
> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
> scritto:
> 
>> Hi Peppe,
>>
>> Seel also my answer on 2016-10-29.
>>
>> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan
>> after each change
>> you probably need to keep a cache in the Layer as suggested by Ede, and
>> use the Layer's
>> listener to update the cache every time a feature is added, removed or
>> changed
>>
>> Michaël
>>
>>
>> Le 13/11/2016 à 19:51, edgar.sol...@web.de a écrit :
>>> thanks.. how about implementing the caching/listener approach if you
>> like to have icon? ..ede
>>>
>>> On 13.11.2016 18:57, Giuseppe Aruta wrote:
 Ok Ede, I didn't  know it. I will revert the change.
 Thanks again
 Peppe

 Il 13/Nov/2016 18:48,  ha scritto:

> Peppe,
>
> NACK.. this is going to get very slow for huge datasets containing
>> empty
> geoms only, as it is run on every redraw of the layer tree. please
>> cache
> the state and use a layer change listener or else users will complain
>> about
> a frozen OJ some time in the future and we will have a hard time to
> pinpoint the reason, again ;)
>
> ..ede
>
> On 13.11.2016 18:41, jump-pilot-...@lists.sourceforge.net wrote:
>> Revision: 5185
>>http://sourceforge.net/p/jump-pilot/code/5185
>> Author:   ma15569
>> Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
>> Log Message:
>> ---
>> The layer tree shows a table icon for layers that have features with
> empty geometries
>> Modified Paths:
>> --
>>  core/trunk/src/com/vividsolutions/jump/workbench/
> ui/LayerNameRenderer.java
>> Modified: core/trunk/src/com/vividsolutions/jump/workbench/
> ui/LayerNameRenderer.java
>> ===
>> --- core/trunk/src/com/vividsolutions/jump/workbench/
>> ui/LayerNameRenderer.java
>2016-11-13 17:21:20 UTC (rev 5184)
>> +++ core/trunk/src/com/vividsolutions/jump/workbench/
>> ui/LayerNameRenderer.java
>2016-11-13 17:41:37 UTC (rev 5185)
>> @@ -36,6 +36,7 @@
>>   import java.awt.Rectangle;
>>   import java.io.File;
>>   import java.util.Iterator;
>> +import java.util.List;
>>
>>   import javax.swing.DefaultListCellRenderer;
>>   import javax.swing.Icon;
>> @@ -54,9 +55,11 @@
>>   import org.openjump.core.rasterimage.RasterImageLayer;
>>
>>   import com.vividsolutions.jts.geom.Envelope;
>> +import com.vividsolutions.jts.geom.Geometry;
>>   import com.vividsolutions.jump.I18N;
>>   import com.vividsolutions.jump.feature.Feature;
>>   import com.vividsolutions.jump.feature.FeatureCollection;
>> +import com.vividsolutions.jump.feature.FeatureCollectionWrapper;
>>   import com.vividsolutions.jump.io.datasource.DataSourceQuery;
>>   import com.vividsolutions.jump.util.StringUtil;
>>   import com.vividsolutions.jump.workbench.JUMPWorkbench;
>> @@ -118,6 +121,7 @@
>>   private ImageIcon rasterIcon = IconLoader.icon("map_13.png");
>>   private ImageIcon sextante_rasterIcon =
>> IconLoader.icon("mapSv2_13.
> png");
>>   private ImageIcon sextante_rasterIcon2 =
> IconLoader.icon("mapSv2_13bw.png");
>> +private ImageIcon table_Icon = IconLoader.icon("Table.gif");
>>   private final static String LAYER_NAME = I18N
>>   .get("org.openjump.core.ui.plugin.layer.
> LayerPropertiesPlugIn.Layer-Name");
>>   private final static String FILE_NAME =
> I18N.get("ui.MenuNames.FILE");
>> @@ -379,6 +383,12 @@
>>   .getFeatureCollectionWrapper().size() > 1 ?
> multiRasterIcon
>>  

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-14 Thread Giuseppe Aruta
Thanks Michael Ede
Indeed I came across (as a side relative problem ) working on Saxtante.
Sextante allows to work on Table files while Oj not. We can take advance of
the Sextante table algorithms  allowing Sextante to decode the vector
layers, with all features with empty geometries (see  for instance loading
.csv on auto mode) as tables (I already added added into Sextante binding a
Boolean method that allows to decode these files).
I wondered if users would also have benefit  to visualize that a table is
loaded into OJ workbench, with a table icon.
I will check other solutions. Thanks for the hint.
Peppe

Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
scritto:

> Hi Peppe,
>
> Seel also my answer on 2016-10-29.
>
> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan
> after each change
> you probably need to keep a cache in the Layer as suggested by Ede, and
> use the Layer's
> listener to update the cache every time a feature is added, removed or
> changed
>
> Michaël
>
>
> Le 13/11/2016 à 19:51, edgar.sol...@web.de a écrit :
> > thanks.. how about implementing the caching/listener approach if you
> like to have icon? ..ede
> >
> > On 13.11.2016 18:57, Giuseppe Aruta wrote:
> >> Ok Ede, I didn't  know it. I will revert the change.
> >> Thanks again
> >> Peppe
> >>
> >> Il 13/Nov/2016 18:48,  ha scritto:
> >>
> >>> Peppe,
> >>>
> >>> NACK.. this is going to get very slow for huge datasets containing
> empty
> >>> geoms only, as it is run on every redraw of the layer tree. please
> cache
> >>> the state and use a layer change listener or else users will complain
> about
> >>> a frozen OJ some time in the future and we will have a hard time to
> >>> pinpoint the reason, again ;)
> >>>
> >>> ..ede
> >>>
> >>> On 13.11.2016 18:41, jump-pilot-...@lists.sourceforge.net wrote:
>  Revision: 5185
> http://sourceforge.net/p/jump-pilot/code/5185
>  Author:   ma15569
>  Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
>  Log Message:
>  ---
>  The layer tree shows a table icon for layers that have features with
> >>> empty geometries
>  Modified Paths:
>  --
>   core/trunk/src/com/vividsolutions/jump/workbench/
> >>> ui/LayerNameRenderer.java
>  Modified: core/trunk/src/com/vividsolutions/jump/workbench/
> >>> ui/LayerNameRenderer.java
>  ===
>  --- core/trunk/src/com/vividsolutions/jump/workbench/
> ui/LayerNameRenderer.java
> >>>2016-11-13 17:21:20 UTC (rev 5184)
>  +++ core/trunk/src/com/vividsolutions/jump/workbench/
> ui/LayerNameRenderer.java
> >>>2016-11-13 17:41:37 UTC (rev 5185)
>  @@ -36,6 +36,7 @@
>    import java.awt.Rectangle;
>    import java.io.File;
>    import java.util.Iterator;
>  +import java.util.List;
> 
>    import javax.swing.DefaultListCellRenderer;
>    import javax.swing.Icon;
>  @@ -54,9 +55,11 @@
>    import org.openjump.core.rasterimage.RasterImageLayer;
> 
>    import com.vividsolutions.jts.geom.Envelope;
>  +import com.vividsolutions.jts.geom.Geometry;
>    import com.vividsolutions.jump.I18N;
>    import com.vividsolutions.jump.feature.Feature;
>    import com.vividsolutions.jump.feature.FeatureCollection;
>  +import com.vividsolutions.jump.feature.FeatureCollectionWrapper;
>    import com.vividsolutions.jump.io.datasource.DataSourceQuery;
>    import com.vividsolutions.jump.util.StringUtil;
>    import com.vividsolutions.jump.workbench.JUMPWorkbench;
>  @@ -118,6 +121,7 @@
>    private ImageIcon rasterIcon = IconLoader.icon("map_13.png");
>    private ImageIcon sextante_rasterIcon =
> IconLoader.icon("mapSv2_13.
> >>> png");
>    private ImageIcon sextante_rasterIcon2 =
> >>> IconLoader.icon("mapSv2_13bw.png");
>  +private ImageIcon table_Icon = IconLoader.icon("Table.gif");
>    private final static String LAYER_NAME = I18N
>    .get("org.openjump.core.ui.plugin.layer.
> >>> LayerPropertiesPlugIn.Layer-Name");
>    private final static String FILE_NAME =
> >>> I18N.get("ui.MenuNames.FILE");
>  @@ -379,6 +383,12 @@
>    .getFeatureCollectionWrapper().size() > 1 ?
> >>> multiRasterIcon
>    : rasterIcon);
>    imageLabel.setVisible(true);
>  +} else if (showColorPanel && layerable instanceof Layer
>  +&& isTable((Layer) layerable)) {
>  +  //Show a table icon if the Layer has features with empty
> >>> geometries
>  +imageLabel.setIcon(table_Icon);
>  +imageLabel.setVisible(true);
>  +
>    } else if (showColorPanel && layerable instanceof Layer) {
>    colorPanel.init((Layer) layerable, isSelected,
>    

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-13 Thread Michaël Michaud
Hi Peppe,

Seel also my answer on 2016-10-29.

TreeLayerNamePanel has a listener, but to avoid a featureCollection scan 
after each change
you probably need to keep a cache in the Layer as suggested by Ede, and 
use the Layer's
listener to update the cache every time a feature is added, removed or 
changed

Michaël


Le 13/11/2016 à 19:51, edgar.sol...@web.de a écrit :
> thanks.. how about implementing the caching/listener approach if you like to 
> have icon? ..ede
>
> On 13.11.2016 18:57, Giuseppe Aruta wrote:
>> Ok Ede, I didn't  know it. I will revert the change.
>> Thanks again
>> Peppe
>>
>> Il 13/Nov/2016 18:48,  ha scritto:
>>
>>> Peppe,
>>>
>>> NACK.. this is going to get very slow for huge datasets containing empty
>>> geoms only, as it is run on every redraw of the layer tree. please cache
>>> the state and use a layer change listener or else users will complain about
>>> a frozen OJ some time in the future and we will have a hard time to
>>> pinpoint the reason, again ;)
>>>
>>> ..ede
>>>
>>> On 13.11.2016 18:41, jump-pilot-...@lists.sourceforge.net wrote:
 Revision: 5185
http://sourceforge.net/p/jump-pilot/code/5185
 Author:   ma15569
 Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
 Log Message:
 ---
 The layer tree shows a table icon for layers that have features with
>>> empty geometries
 Modified Paths:
 --
  core/trunk/src/com/vividsolutions/jump/workbench/
>>> ui/LayerNameRenderer.java
 Modified: core/trunk/src/com/vividsolutions/jump/workbench/
>>> ui/LayerNameRenderer.java
 ===
 --- 
 core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
>>>2016-11-13 17:21:20 UTC (rev 5184)
 +++ 
 core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
>>>2016-11-13 17:41:37 UTC (rev 5185)
 @@ -36,6 +36,7 @@
   import java.awt.Rectangle;
   import java.io.File;
   import java.util.Iterator;
 +import java.util.List;

   import javax.swing.DefaultListCellRenderer;
   import javax.swing.Icon;
 @@ -54,9 +55,11 @@
   import org.openjump.core.rasterimage.RasterImageLayer;

   import com.vividsolutions.jts.geom.Envelope;
 +import com.vividsolutions.jts.geom.Geometry;
   import com.vividsolutions.jump.I18N;
   import com.vividsolutions.jump.feature.Feature;
   import com.vividsolutions.jump.feature.FeatureCollection;
 +import com.vividsolutions.jump.feature.FeatureCollectionWrapper;
   import com.vividsolutions.jump.io.datasource.DataSourceQuery;
   import com.vividsolutions.jump.util.StringUtil;
   import com.vividsolutions.jump.workbench.JUMPWorkbench;
 @@ -118,6 +121,7 @@
   private ImageIcon rasterIcon = IconLoader.icon("map_13.png");
   private ImageIcon sextante_rasterIcon = IconLoader.icon("mapSv2_13.
>>> png");
   private ImageIcon sextante_rasterIcon2 =
>>> IconLoader.icon("mapSv2_13bw.png");
 +private ImageIcon table_Icon = IconLoader.icon("Table.gif");
   private final static String LAYER_NAME = I18N
   .get("org.openjump.core.ui.plugin.layer.
>>> LayerPropertiesPlugIn.Layer-Name");
   private final static String FILE_NAME =
>>> I18N.get("ui.MenuNames.FILE");
 @@ -379,6 +383,12 @@
   .getFeatureCollectionWrapper().size() > 1 ?
>>> multiRasterIcon
   : rasterIcon);
   imageLabel.setVisible(true);
 +} else if (showColorPanel && layerable instanceof Layer
 +&& isTable((Layer) layerable)) {
 +  //Show a table icon if the Layer has features with empty
>>> geometries
 +imageLabel.setIcon(table_Icon);
 +imageLabel.setVisible(true);
 +
   } else if (showColorPanel && layerable instanceof Layer) {
   colorPanel.init((Layer) layerable, isSelected,
   list.getBackground(), list.getSelectionBackground())
>>> ;
 @@ -1022,4 +1032,27 @@
   && bgc.equals(p.getBackground()) && p.isOpaque();
   return !colorMatchOrOpaque && super.isOpaque();
   }
 +
 +/*
 + * [Giuseppe Aruta 11.2016] . True if all the layer geometries are
>>> empty
 + * (Geometrycollection empty). Workaround to decode table files
>>> (like .csv or .dbf)
 + *  so that they are loaded in Sextante as table
 +  */
 +public static boolean isTable(Layer layer) {
 +FeatureCollectionWrapper featureCollection = layer
 +.getFeatureCollectionWrapper();
 +List featureList = featureCollection.getFeatures();
 +Geometry nextGeo = null;
 +for (@SuppressWarnings("unchecked")
 +Iterator i = featureList.iterator();
>>> i

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-13 Thread edgar . soldin
thanks.. how about implementing the caching/listener approach if you like to 
have icon? ..ede

On 13.11.2016 18:57, Giuseppe Aruta wrote:
> Ok Ede, I didn't  know it. I will revert the change.
> Thanks again
> Peppe
> 
> Il 13/Nov/2016 18:48,  ha scritto:
> 
>> Peppe,
>>
>> NACK.. this is going to get very slow for huge datasets containing empty
>> geoms only, as it is run on every redraw of the layer tree. please cache
>> the state and use a layer change listener or else users will complain about
>> a frozen OJ some time in the future and we will have a hard time to
>> pinpoint the reason, again ;)
>>
>> ..ede
>>
>> On 13.11.2016 18:41, jump-pilot-...@lists.sourceforge.net wrote:
>>> Revision: 5185
>>>   http://sourceforge.net/p/jump-pilot/code/5185
>>> Author:   ma15569
>>> Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
>>> Log Message:
>>> ---
>>> The layer tree shows a table icon for layers that have features with
>> empty geometries
>>>
>>> Modified Paths:
>>> --
>>> core/trunk/src/com/vividsolutions/jump/workbench/
>> ui/LayerNameRenderer.java
>>>
>>> Modified: core/trunk/src/com/vividsolutions/jump/workbench/
>> ui/LayerNameRenderer.java
>>> ===
>>> --- 
>>> core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
>>   2016-11-13 17:21:20 UTC (rev 5184)
>>> +++ 
>>> core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
>>   2016-11-13 17:41:37 UTC (rev 5185)
>>> @@ -36,6 +36,7 @@
>>>  import java.awt.Rectangle;
>>>  import java.io.File;
>>>  import java.util.Iterator;
>>> +import java.util.List;
>>>
>>>  import javax.swing.DefaultListCellRenderer;
>>>  import javax.swing.Icon;
>>> @@ -54,9 +55,11 @@
>>>  import org.openjump.core.rasterimage.RasterImageLayer;
>>>
>>>  import com.vividsolutions.jts.geom.Envelope;
>>> +import com.vividsolutions.jts.geom.Geometry;
>>>  import com.vividsolutions.jump.I18N;
>>>  import com.vividsolutions.jump.feature.Feature;
>>>  import com.vividsolutions.jump.feature.FeatureCollection;
>>> +import com.vividsolutions.jump.feature.FeatureCollectionWrapper;
>>>  import com.vividsolutions.jump.io.datasource.DataSourceQuery;
>>>  import com.vividsolutions.jump.util.StringUtil;
>>>  import com.vividsolutions.jump.workbench.JUMPWorkbench;
>>> @@ -118,6 +121,7 @@
>>>  private ImageIcon rasterIcon = IconLoader.icon("map_13.png");
>>>  private ImageIcon sextante_rasterIcon = IconLoader.icon("mapSv2_13.
>> png");
>>>  private ImageIcon sextante_rasterIcon2 =
>> IconLoader.icon("mapSv2_13bw.png");
>>> +private ImageIcon table_Icon = IconLoader.icon("Table.gif");
>>>  private final static String LAYER_NAME = I18N
>>>  .get("org.openjump.core.ui.plugin.layer.
>> LayerPropertiesPlugIn.Layer-Name");
>>>  private final static String FILE_NAME =
>> I18N.get("ui.MenuNames.FILE");
>>> @@ -379,6 +383,12 @@
>>>  .getFeatureCollectionWrapper().size() > 1 ?
>> multiRasterIcon
>>>  : rasterIcon);
>>>  imageLabel.setVisible(true);
>>> +} else if (showColorPanel && layerable instanceof Layer
>>> +&& isTable((Layer) layerable)) {
>>> +  //Show a table icon if the Layer has features with empty
>> geometries
>>> +imageLabel.setIcon(table_Icon);
>>> +imageLabel.setVisible(true);
>>> +
>>>  } else if (showColorPanel && layerable instanceof Layer) {
>>>  colorPanel.init((Layer) layerable, isSelected,
>>>  list.getBackground(), list.getSelectionBackground())
>> ;
>>> @@ -1022,4 +1032,27 @@
>>>  && bgc.equals(p.getBackground()) && p.isOpaque();
>>>  return !colorMatchOrOpaque && super.isOpaque();
>>>  }
>>> +
>>> +/*
>>> + * [Giuseppe Aruta 11.2016] . True if all the layer geometries are
>> empty
>>> + * (Geometrycollection empty). Workaround to decode table files
>> (like .csv or .dbf)
>>> + *  so that they are loaded in Sextante as table
>>> +  */
>>> +public static boolean isTable(Layer layer) {
>>> +FeatureCollectionWrapper featureCollection = layer
>>> +.getFeatureCollectionWrapper();
>>> +List featureList = featureCollection.getFeatures();
>>> +Geometry nextGeo = null;
>>> +for (@SuppressWarnings("unchecked")
>>> +Iterator i = featureList.iterator();
>> i
>>> +.hasNext();) {
>>> +Feature feature = (Feature) i.next();
>>> +nextGeo = feature.getGeometry();
>>> +}
>>> +if (!featureCollection.isEmpty() && nextGeo.isEmpty()) {
>>> +return true;
>>> +} else {
>>> +return false;
>>> +}
>>> +}
>>>  }
>>> \ No newline at end of file
>>>
>>>
>>> 
>> --
>>> Developer Access Program for Intel 

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-13 Thread Giuseppe Aruta
Ok Ede, I didn't  know it. I will revert the change.
Thanks again
Peppe

Il 13/Nov/2016 18:48,  ha scritto:

> Peppe,
>
> NACK.. this is going to get very slow for huge datasets containing empty
> geoms only, as it is run on every redraw of the layer tree. please cache
> the state and use a layer change listener or else users will complain about
> a frozen OJ some time in the future and we will have a hard time to
> pinpoint the reason, again ;)
>
> ..ede
>
> On 13.11.2016 18:41, jump-pilot-...@lists.sourceforge.net wrote:
> > Revision: 5185
> >   http://sourceforge.net/p/jump-pilot/code/5185
> > Author:   ma15569
> > Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
> > Log Message:
> > ---
> > The layer tree shows a table icon for layers that have features with
> empty geometries
> >
> > Modified Paths:
> > --
> > core/trunk/src/com/vividsolutions/jump/workbench/
> ui/LayerNameRenderer.java
> >
> > Modified: core/trunk/src/com/vividsolutions/jump/workbench/
> ui/LayerNameRenderer.java
> > ===
> > --- 
> > core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
>   2016-11-13 17:21:20 UTC (rev 5184)
> > +++ 
> > core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
>   2016-11-13 17:41:37 UTC (rev 5185)
> > @@ -36,6 +36,7 @@
> >  import java.awt.Rectangle;
> >  import java.io.File;
> >  import java.util.Iterator;
> > +import java.util.List;
> >
> >  import javax.swing.DefaultListCellRenderer;
> >  import javax.swing.Icon;
> > @@ -54,9 +55,11 @@
> >  import org.openjump.core.rasterimage.RasterImageLayer;
> >
> >  import com.vividsolutions.jts.geom.Envelope;
> > +import com.vividsolutions.jts.geom.Geometry;
> >  import com.vividsolutions.jump.I18N;
> >  import com.vividsolutions.jump.feature.Feature;
> >  import com.vividsolutions.jump.feature.FeatureCollection;
> > +import com.vividsolutions.jump.feature.FeatureCollectionWrapper;
> >  import com.vividsolutions.jump.io.datasource.DataSourceQuery;
> >  import com.vividsolutions.jump.util.StringUtil;
> >  import com.vividsolutions.jump.workbench.JUMPWorkbench;
> > @@ -118,6 +121,7 @@
> >  private ImageIcon rasterIcon = IconLoader.icon("map_13.png");
> >  private ImageIcon sextante_rasterIcon = IconLoader.icon("mapSv2_13.
> png");
> >  private ImageIcon sextante_rasterIcon2 =
> IconLoader.icon("mapSv2_13bw.png");
> > +private ImageIcon table_Icon = IconLoader.icon("Table.gif");
> >  private final static String LAYER_NAME = I18N
> >  .get("org.openjump.core.ui.plugin.layer.
> LayerPropertiesPlugIn.Layer-Name");
> >  private final static String FILE_NAME =
> I18N.get("ui.MenuNames.FILE");
> > @@ -379,6 +383,12 @@
> >  .getFeatureCollectionWrapper().size() > 1 ?
> multiRasterIcon
> >  : rasterIcon);
> >  imageLabel.setVisible(true);
> > +} else if (showColorPanel && layerable instanceof Layer
> > +&& isTable((Layer) layerable)) {
> > +  //Show a table icon if the Layer has features with empty
> geometries
> > +imageLabel.setIcon(table_Icon);
> > +imageLabel.setVisible(true);
> > +
> >  } else if (showColorPanel && layerable instanceof Layer) {
> >  colorPanel.init((Layer) layerable, isSelected,
> >  list.getBackground(), list.getSelectionBackground())
> ;
> > @@ -1022,4 +1032,27 @@
> >  && bgc.equals(p.getBackground()) && p.isOpaque();
> >  return !colorMatchOrOpaque && super.isOpaque();
> >  }
> > +
> > +/*
> > + * [Giuseppe Aruta 11.2016] . True if all the layer geometries are
> empty
> > + * (Geometrycollection empty). Workaround to decode table files
> (like .csv or .dbf)
> > + *  so that they are loaded in Sextante as table
> > +  */
> > +public static boolean isTable(Layer layer) {
> > +FeatureCollectionWrapper featureCollection = layer
> > +.getFeatureCollectionWrapper();
> > +List featureList = featureCollection.getFeatures();
> > +Geometry nextGeo = null;
> > +for (@SuppressWarnings("unchecked")
> > +Iterator i = featureList.iterator();
> i
> > +.hasNext();) {
> > +Feature feature = (Feature) i.next();
> > +nextGeo = feature.getGeometry();
> > +}
> > +if (!featureCollection.isEmpty() && nextGeo.isEmpty()) {
> > +return true;
> > +} else {
> > +return false;
> > +}
> > +}
> >  }
> > \ No newline at end of file
> >
> >
> > 
> --
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > 

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-13 Thread edgar . soldin
Peppe,

NACK.. this is going to get very slow for huge datasets containing empty geoms 
only, as it is run on every redraw of the layer tree. please cache the state 
and use a layer change listener or else users will complain about a frozen OJ 
some time in the future and we will have a hard time to pinpoint the reason, 
again ;)

..ede

On 13.11.2016 18:41, jump-pilot-...@lists.sourceforge.net wrote:
> Revision: 5185
>   http://sourceforge.net/p/jump-pilot/code/5185
> Author:   ma15569
> Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
> Log Message:
> ---
> The layer tree shows a table icon for layers that have features with empty 
> geometries 
> 
> Modified Paths:
> --
> core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
> 
> Modified: 
> core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
> ===
> --- 
> core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
> 2016-11-13 17:21:20 UTC (rev 5184)
> +++ 
> core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
> 2016-11-13 17:41:37 UTC (rev 5185)
> @@ -36,6 +36,7 @@
>  import java.awt.Rectangle;
>  import java.io.File;
>  import java.util.Iterator;
> +import java.util.List;
>  
>  import javax.swing.DefaultListCellRenderer;
>  import javax.swing.Icon;
> @@ -54,9 +55,11 @@
>  import org.openjump.core.rasterimage.RasterImageLayer;
>  
>  import com.vividsolutions.jts.geom.Envelope;
> +import com.vividsolutions.jts.geom.Geometry;
>  import com.vividsolutions.jump.I18N;
>  import com.vividsolutions.jump.feature.Feature;
>  import com.vividsolutions.jump.feature.FeatureCollection;
> +import com.vividsolutions.jump.feature.FeatureCollectionWrapper;
>  import com.vividsolutions.jump.io.datasource.DataSourceQuery;
>  import com.vividsolutions.jump.util.StringUtil;
>  import com.vividsolutions.jump.workbench.JUMPWorkbench;
> @@ -118,6 +121,7 @@
>  private ImageIcon rasterIcon = IconLoader.icon("map_13.png");
>  private ImageIcon sextante_rasterIcon = IconLoader.icon("mapSv2_13.png");
>  private ImageIcon sextante_rasterIcon2 = 
> IconLoader.icon("mapSv2_13bw.png");
> +private ImageIcon table_Icon = IconLoader.icon("Table.gif");
>  private final static String LAYER_NAME = I18N
>  
> .get("org.openjump.core.ui.plugin.layer.LayerPropertiesPlugIn.Layer-Name");
>  private final static String FILE_NAME = I18N.get("ui.MenuNames.FILE");
> @@ -379,6 +383,12 @@
>  .getFeatureCollectionWrapper().size() > 1 ? 
> multiRasterIcon
>  : rasterIcon);
>  imageLabel.setVisible(true);
> +} else if (showColorPanel && layerable instanceof Layer
> +&& isTable((Layer) layerable)) {
> +  //Show a table icon if the Layer has features with empty geometries
> +imageLabel.setIcon(table_Icon);
> +imageLabel.setVisible(true);
> +
>  } else if (showColorPanel && layerable instanceof Layer) {
>  colorPanel.init((Layer) layerable, isSelected,
>  list.getBackground(), list.getSelectionBackground());
> @@ -1022,4 +1032,27 @@
>  && bgc.equals(p.getBackground()) && p.isOpaque();
>  return !colorMatchOrOpaque && super.isOpaque();
>  }
> +
> +/* 
> + * [Giuseppe Aruta 11.2016] . True if all the layer geometries are empty
> + * (Geometrycollection empty). Workaround to decode table files (like 
> .csv or .dbf)
> + *  so that they are loaded in Sextante as table
> +  */
> +public static boolean isTable(Layer layer) {
> +FeatureCollectionWrapper featureCollection = layer
> +.getFeatureCollectionWrapper();
> +List featureList = featureCollection.getFeatures();
> +Geometry nextGeo = null;
> +for (@SuppressWarnings("unchecked")
> +Iterator i = featureList.iterator(); i
> +.hasNext();) {
> +Feature feature = (Feature) i.next();
> +nextGeo = feature.getGeometry();
> +}
> +if (!featureCollection.isEmpty() && nextGeo.isEmpty()) {
> +return true;
> +} else {
> +return false;
> +}
> +}
>  }
> \ No newline at end of file
> 
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 

--
Developer Access 

[JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

2016-11-13 Thread jump-pilot-svn
Revision: 5185
  http://sourceforge.net/p/jump-pilot/code/5185
Author:   ma15569
Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
Log Message:
---
The layer tree shows a table icon for layers that have features with empty 
geometries 

Modified Paths:
--
core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java

Modified: 
core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java
===
--- core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java  
2016-11-13 17:21:20 UTC (rev 5184)
+++ core/trunk/src/com/vividsolutions/jump/workbench/ui/LayerNameRenderer.java  
2016-11-13 17:41:37 UTC (rev 5185)
@@ -36,6 +36,7 @@
 import java.awt.Rectangle;
 import java.io.File;
 import java.util.Iterator;
+import java.util.List;
 
 import javax.swing.DefaultListCellRenderer;
 import javax.swing.Icon;
@@ -54,9 +55,11 @@
 import org.openjump.core.rasterimage.RasterImageLayer;
 
 import com.vividsolutions.jts.geom.Envelope;
+import com.vividsolutions.jts.geom.Geometry;
 import com.vividsolutions.jump.I18N;
 import com.vividsolutions.jump.feature.Feature;
 import com.vividsolutions.jump.feature.FeatureCollection;
+import com.vividsolutions.jump.feature.FeatureCollectionWrapper;
 import com.vividsolutions.jump.io.datasource.DataSourceQuery;
 import com.vividsolutions.jump.util.StringUtil;
 import com.vividsolutions.jump.workbench.JUMPWorkbench;
@@ -118,6 +121,7 @@
 private ImageIcon rasterIcon = IconLoader.icon("map_13.png");
 private ImageIcon sextante_rasterIcon = IconLoader.icon("mapSv2_13.png");
 private ImageIcon sextante_rasterIcon2 = 
IconLoader.icon("mapSv2_13bw.png");
+private ImageIcon table_Icon = IconLoader.icon("Table.gif");
 private final static String LAYER_NAME = I18N
 
.get("org.openjump.core.ui.plugin.layer.LayerPropertiesPlugIn.Layer-Name");
 private final static String FILE_NAME = I18N.get("ui.MenuNames.FILE");
@@ -379,6 +383,12 @@
 .getFeatureCollectionWrapper().size() > 1 ? multiRasterIcon
 : rasterIcon);
 imageLabel.setVisible(true);
+} else if (showColorPanel && layerable instanceof Layer
+&& isTable((Layer) layerable)) {
+  //Show a table icon if the Layer has features with empty geometries
+imageLabel.setIcon(table_Icon);
+imageLabel.setVisible(true);
+
 } else if (showColorPanel && layerable instanceof Layer) {
 colorPanel.init((Layer) layerable, isSelected,
 list.getBackground(), list.getSelectionBackground());
@@ -1022,4 +1032,27 @@
 && bgc.equals(p.getBackground()) && p.isOpaque();
 return !colorMatchOrOpaque && super.isOpaque();
 }
+
+/* 
+ * [Giuseppe Aruta 11.2016] . True if all the layer geometries are empty
+ * (Geometrycollection empty). Workaround to decode table files (like .csv 
or .dbf)
+ *  so that they are loaded in Sextante as table
+  */
+public static boolean isTable(Layer layer) {
+FeatureCollectionWrapper featureCollection = layer
+.getFeatureCollectionWrapper();
+List featureList = featureCollection.getFeatures();
+Geometry nextGeo = null;
+for (@SuppressWarnings("unchecked")
+Iterator i = featureList.iterator(); i
+.hasNext();) {
+Feature feature = (Feature) i.next();
+nextGeo = feature.getGeometry();
+}
+if (!featureCollection.isEmpty() && nextGeo.isEmpty()) {
+return true;
+} else {
+return false;
+}
+}
 }
\ No newline at end of file


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel