Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Giuseppe Aruta]

Hi Landon,
I added two classes under org.openjump.core.ui.util (LayerableUtil.class
and GeometryUtil.class) where I collect some methods for future development.
Best regards
Peppe

2016-02-04 17:02 GMT+01:00 Giuseppe Aruta :

> Thanks Landon for your help. I will add a class (probably on a test
> Package) just to collect all (layerable/layer) usable methods
>
> 2016-02-03 23:40 GMT+01:00 Michaël Michaud :
>
>> Hi,
>>
>> To give more food for thought about layerable hierarchy, I have an old
>> project in mind to create VirtualLayers. A VirtualLayer would be the
>> dataset of another Layer. It may be read-only. Its main purpose is to
>> have more than one style associated to a single datasource and to be
>> able to interleave styles associated with one datasource with styles
>> associated to another datasource.
>>
>> Michaël
>>
>> Le 03/02/2016 17:58, edgar.sol...@web.de a écrit :
>> > sure, go ahead.
>> >
>> > it's just important to me that we talk about it first and find an
>> ordered approach that takes into account the existing API. i am a big fan
>> of small steps, but into the right direction. meaning a big overhaul
>> refactoring is possibly bringing more problems than the whole cleanup is
>> worth.
>> > streamlining the existing API by eg. moving a small functionality out
>> of Layer into AbstractLayerable at a time and test it will probably the
>> least dangerous approach.
>> >
>> > visualizing the current design beforehand might probably help all
>> parties to get an initial overview as well.
>> >
>> > ..ede
>> >
>> > On 03.02.2016 17:49, Landon Blake wrote:
>> >> How do you guys feel about having Peppe and I review our existing
>> layerable
>> >> class/interface architecture and come up with a proposal for clean-up
>> and
>> >> revisions. I think some of Peppe's suggested methods are useful, but
>> agree
>> >> with Ede that we need to plug them into the correct interface.
>> >>
>> >> I think this is exactly the type of TLC the OpenJUMP core needs. I
>> would
>> >> love to work with Peppe to test some code and then propose a more
>> >> comprehensive clean-up of the layerable code here.
>> >>
>> >> Peppe: Let me know if you want my help.
>> >>
>> >> Others: Let me know if you'd be willing to consider a proposal and some
>> >> test code from Peppe and I.
>> >>
>> >> Landon
>> >>
>> >> On Wed, Jan 27, 2016 at 7:02 AM, Giuseppe Aruta <
>> giuseppe.ar...@gmail.com>
>> >> wrote:
>> >>
>> >>> OK,
>> >>> I had the response of everybody.
>> >>>
>> >>> - I am going to remove all the Layer.class parts and restore as it is
>> >>> before
>> >>> - I am going to leave only the RasterImageLayer.class method
>> >>> isTemporaryLayer()
>> >>> - I will create an external class, called maybe LayerbleUtils - no
>> >>> implementation to Layerable or other classes, just a useful Util
>> class to
>> >>> group all these potential boolen/String methods.
>> >>>
>>  you mean as default saving format when leaving OJ? why?
>> >>> No. Not talking about SaveDatasetsPlugIn. It has a useful behaviour:
>> if I
>> >>> try to add a  a polygon to a point layer (belonging to a Shapefile,
>> already
>> >>> saved). And than I will save it, the plugin will save the original
>> geometry
>> >>> collection to the original file, and create another SHP file with the
>> >>> polygon. This is probably better than a warning message.
>> >>> My idea is to add this capability to Michael's project
>> >>> SaveLayersWithoutDatasource.class ( it saves a list of layers without
>> >>> datasource, the user can choose JML or SHP as export format) which is
>> also
>> >>> invoked on Saving a project.
>> >>> An alternative simpler idea is to give the plugin the capability to
>> >>> distinguish mixed geometry types layers among all, and to save them
>> as JML,
>> >>> even if the user choose SHP.
>> >>> In any  I will not change none of the actual classes. As I frequently
>> >>> work with Sextante rasters(RasterImageLayer.class), I will start from
>> >>> Michael's plugin to create another one  that has these two extra
>> >>> capabilities:
>> >>> a) it saves also a list of Temporary Raster layers as TIF
>> >>> b) it  allows users to commit changes on "modified layers" ( I will
>> >>> consider "modified layers" as Layer.class, vector based, with a
>> datasource.
>> >>> I will exclude  from this collection ("modified layers")
>> >>> DataStoreQueryDataSources and ReferencedImageLayer (legacy images) as
>> >>> their saving is still complex and ambiguous (see a previous discussion
>> >>> about saving a ReferencedImageLayer when its envelope has been moved
>> or
>> >>> resized)
>> >>> Peppe
>> >>>
>> >>> 2016-01-27 13:53 GMT+01:00 Michaël Michaud <
>> m.michael.mich...@orange.fr>:
>> >>>
>>  Hi,
>> 
>>  I think that Peppe's request show some flaws in layerable hierarchy.
>>  Some may be addressed by adding helper methods to existing class.
>>  Others maybe addressed by introducing new 

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Giuseppe Aruta]

Thanks Landon for your help. I will add a class (probably on a test
Package) just to collect all (layerable/layer) usable methods

2016-02-03 23:40 GMT+01:00 Michaël Michaud :

> Hi,
>
> To give more food for thought about layerable hierarchy, I have an old
> project in mind to create VirtualLayers. A VirtualLayer would be the
> dataset of another Layer. It may be read-only. Its main purpose is to
> have more than one style associated to a single datasource and to be
> able to interleave styles associated with one datasource with styles
> associated to another datasource.
>
> Michaël
>
> Le 03/02/2016 17:58, edgar.sol...@web.de a écrit :
> > sure, go ahead.
> >
> > it's just important to me that we talk about it first and find an
> ordered approach that takes into account the existing API. i am a big fan
> of small steps, but into the right direction. meaning a big overhaul
> refactoring is possibly bringing more problems than the whole cleanup is
> worth.
> > streamlining the existing API by eg. moving a small functionality out of
> Layer into AbstractLayerable at a time and test it will probably the least
> dangerous approach.
> >
> > visualizing the current design beforehand might probably help all
> parties to get an initial overview as well.
> >
> > ..ede
> >
> > On 03.02.2016 17:49, Landon Blake wrote:
> >> How do you guys feel about having Peppe and I review our existing
> layerable
> >> class/interface architecture and come up with a proposal for clean-up
> and
> >> revisions. I think some of Peppe's suggested methods are useful, but
> agree
> >> with Ede that we need to plug them into the correct interface.
> >>
> >> I think this is exactly the type of TLC the OpenJUMP core needs. I would
> >> love to work with Peppe to test some code and then propose a more
> >> comprehensive clean-up of the layerable code here.
> >>
> >> Peppe: Let me know if you want my help.
> >>
> >> Others: Let me know if you'd be willing to consider a proposal and some
> >> test code from Peppe and I.
> >>
> >> Landon
> >>
> >> On Wed, Jan 27, 2016 at 7:02 AM, Giuseppe Aruta <
> giuseppe.ar...@gmail.com>
> >> wrote:
> >>
> >>> OK,
> >>> I had the response of everybody.
> >>>
> >>> - I am going to remove all the Layer.class parts and restore as it is
> >>> before
> >>> - I am going to leave only the RasterImageLayer.class method
> >>> isTemporaryLayer()
> >>> - I will create an external class, called maybe LayerbleUtils - no
> >>> implementation to Layerable or other classes, just a useful Util class
> to
> >>> group all these potential boolen/String methods.
> >>>
>  you mean as default saving format when leaving OJ? why?
> >>> No. Not talking about SaveDatasetsPlugIn. It has a useful behaviour:
> if I
> >>> try to add a  a polygon to a point layer (belonging to a Shapefile,
> already
> >>> saved). And than I will save it, the plugin will save the original
> geometry
> >>> collection to the original file, and create another SHP file with the
> >>> polygon. This is probably better than a warning message.
> >>> My idea is to add this capability to Michael's project
> >>> SaveLayersWithoutDatasource.class ( it saves a list of layers without
> >>> datasource, the user can choose JML or SHP as export format) which is
> also
> >>> invoked on Saving a project.
> >>> An alternative simpler idea is to give the plugin the capability to
> >>> distinguish mixed geometry types layers among all, and to save them as
> JML,
> >>> even if the user choose SHP.
> >>> In any  I will not change none of the actual classes. As I frequently
> >>> work with Sextante rasters(RasterImageLayer.class), I will start from
> >>> Michael's plugin to create another one  that has these two extra
> >>> capabilities:
> >>> a) it saves also a list of Temporary Raster layers as TIF
> >>> b) it  allows users to commit changes on "modified layers" ( I will
> >>> consider "modified layers" as Layer.class, vector based, with a
> datasource.
> >>> I will exclude  from this collection ("modified layers")
> >>> DataStoreQueryDataSources and ReferencedImageLayer (legacy images) as
> >>> their saving is still complex and ambiguous (see a previous discussion
> >>> about saving a ReferencedImageLayer when its envelope has been moved or
> >>> resized)
> >>> Peppe
> >>>
> >>> 2016-01-27 13:53 GMT+01:00 Michaël Michaud <
> m.michael.mich...@orange.fr>:
> >>>
>  Hi,
> 
>  I think that Peppe's request show some flaws in layerable hierarchy.
>  Some may be addressed by adding helper methods to existing class.
>  Others maybe addressed by introducing new interfaces.
>  Some are not so difficult to find in current implementation.
> 
>  My main complain about the design is that raster has two very
> different
>  representations (a layer subclass for legacy images and a different
>  class for
>  sextante)
>  It could be a good idea to arrive to the following hierarchy :
>  AbstractLayer
>  

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Michaël Michaud]

Hi,

To give more food for thought about layerable hierarchy, I have an old 
project in mind to create VirtualLayers. A VirtualLayer would be the 
dataset of another Layer. It may be read-only. Its main purpose is to 
have more than one style associated to a single datasource and to be 
able to interleave styles associated with one datasource with styles 
associated to another datasource.

Michaël

Le 03/02/2016 17:58, edgar.sol...@web.de a écrit :
> sure, go ahead.
>
> it's just important to me that we talk about it first and find an ordered 
> approach that takes into account the existing API. i am a big fan of small 
> steps, but into the right direction. meaning a big overhaul refactoring is 
> possibly bringing more problems than the whole cleanup is worth.
> streamlining the existing API by eg. moving a small functionality out of 
> Layer into AbstractLayerable at a time and test it will probably the least 
> dangerous approach.
>
> visualizing the current design beforehand might probably help all parties to 
> get an initial overview as well.
>
> ..ede
>
> On 03.02.2016 17:49, Landon Blake wrote:
>> How do you guys feel about having Peppe and I review our existing layerable
>> class/interface architecture and come up with a proposal for clean-up and
>> revisions. I think some of Peppe's suggested methods are useful, but agree
>> with Ede that we need to plug them into the correct interface.
>>
>> I think this is exactly the type of TLC the OpenJUMP core needs. I would
>> love to work with Peppe to test some code and then propose a more
>> comprehensive clean-up of the layerable code here.
>>
>> Peppe: Let me know if you want my help.
>>
>> Others: Let me know if you'd be willing to consider a proposal and some
>> test code from Peppe and I.
>>
>> Landon
>>
>> On Wed, Jan 27, 2016 at 7:02 AM, Giuseppe Aruta 
>> wrote:
>>
>>> OK,
>>> I had the response of everybody.
>>>
>>> - I am going to remove all the Layer.class parts and restore as it is
>>> before
>>> - I am going to leave only the RasterImageLayer.class method
>>> isTemporaryLayer()
>>> - I will create an external class, called maybe LayerbleUtils - no
>>> implementation to Layerable or other classes, just a useful Util class to
>>> group all these potential boolen/String methods.
>>>
 you mean as default saving format when leaving OJ? why?
>>> No. Not talking about SaveDatasetsPlugIn. It has a useful behaviour: if I
>>> try to add a  a polygon to a point layer (belonging to a Shapefile, already
>>> saved). And than I will save it, the plugin will save the original geometry
>>> collection to the original file, and create another SHP file with the
>>> polygon. This is probably better than a warning message.
>>> My idea is to add this capability to Michael's project
>>> SaveLayersWithoutDatasource.class ( it saves a list of layers without
>>> datasource, the user can choose JML or SHP as export format) which is also
>>> invoked on Saving a project.
>>> An alternative simpler idea is to give the plugin the capability to
>>> distinguish mixed geometry types layers among all, and to save them as JML,
>>> even if the user choose SHP.
>>> In any  I will not change none of the actual classes. As I frequently
>>> work with Sextante rasters(RasterImageLayer.class), I will start from
>>> Michael's plugin to create another one  that has these two extra
>>> capabilities:
>>> a) it saves also a list of Temporary Raster layers as TIF
>>> b) it  allows users to commit changes on "modified layers" ( I will
>>> consider "modified layers" as Layer.class, vector based, with a datasource.
>>> I will exclude  from this collection ("modified layers")
>>> DataStoreQueryDataSources and ReferencedImageLayer (legacy images) as
>>> their saving is still complex and ambiguous (see a previous discussion
>>> about saving a ReferencedImageLayer when its envelope has been moved or
>>> resized)
>>> Peppe
>>>
>>> 2016-01-27 13:53 GMT+01:00 Michaël Michaud :
>>>
 Hi,

 I think that Peppe's request show some flaws in layerable hierarchy.
 Some may be addressed by adding helper methods to existing class.
 Others maybe addressed by introducing new interfaces.
 Some are not so difficult to find in current implementation.

 My main complain about the design is that raster has two very different
 representations (a layer subclass for legacy images and a different
 class for
 sextante)
 It could be a good idea to arrive to the following hierarchy :
 AbstractLayer
 - rasterLayer (RasterImageLayer + Sextante + WMS : is it possible ?)
 - vectorLayer (Shape, database, WFS...)

 In such a scenario, I don't know if current Layer should be equal to
 VectorLayer
 or above Vector and Raster.

 Another feature I'd like which meets peppe's requirement is some
 information
 about the source (null/file[tmp,compressed]/url[database,service]) 

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Landon Blake]

How do you guys feel about having Peppe and I review our existing layerable
class/interface architecture and come up with a proposal for clean-up and
revisions. I think some of Peppe's suggested methods are useful, but agree
with Ede that we need to plug them into the correct interface.

I think this is exactly the type of TLC the OpenJUMP core needs. I would
love to work with Peppe to test some code and then propose a more
comprehensive clean-up of the layerable code here.

Peppe: Let me know if you want my help.

Others: Let me know if you'd be willing to consider a proposal and some
test code from Peppe and I.

Landon

On Wed, Jan 27, 2016 at 7:02 AM, Giuseppe Aruta 
wrote:

> OK,
> I had the response of everybody.
>
> - I am going to remove all the Layer.class parts and restore as it is
> before
> - I am going to leave only the RasterImageLayer.class method
> isTemporaryLayer()
> - I will create an external class, called maybe LayerbleUtils - no
> implementation to Layerable or other classes, just a useful Util class to
> group all these potential boolen/String methods.
>
> >you mean as default saving format when leaving OJ? why?
> No. Not talking about SaveDatasetsPlugIn. It has a useful behaviour: if I
> try to add a  a polygon to a point layer (belonging to a Shapefile, already
> saved). And than I will save it, the plugin will save the original geometry
> collection to the original file, and create another SHP file with the
> polygon. This is probably better than a warning message.
> My idea is to add this capability to Michael's project
> SaveLayersWithoutDatasource.class ( it saves a list of layers without
> datasource, the user can choose JML or SHP as export format) which is also
> invoked on Saving a project.
> An alternative simpler idea is to give the plugin the capability to
> distinguish mixed geometry types layers among all, and to save them as JML,
> even if the user choose SHP.
> In any  I will not change none of the actual classes. As I frequently
> work with Sextante rasters(RasterImageLayer.class), I will start from
> Michael's plugin to create another one  that has these two extra
> capabilities:
> a) it saves also a list of Temporary Raster layers as TIF
> b) it  allows users to commit changes on "modified layers" ( I will
> consider "modified layers" as Layer.class, vector based, with a datasource.
> I will exclude  from this collection ("modified layers")
> DataStoreQueryDataSources and ReferencedImageLayer (legacy images) as
> their saving is still complex and ambiguous (see a previous discussion
> about saving a ReferencedImageLayer when its envelope has been moved or
> resized)
> Peppe
>
> 2016-01-27 13:53 GMT+01:00 Michaël Michaud :
>
>> Hi,
>>
>> I think that Peppe's request show some flaws in layerable hierarchy.
>> Some may be addressed by adding helper methods to existing class.
>> Others maybe addressed by introducing new interfaces.
>> Some are not so difficult to find in current implementation.
>>
>> My main complain about the design is that raster has two very different
>> representations (a layer subclass for legacy images and a different
>> class for
>> sextante)
>> It could be a good idea to arrive to the following hierarchy :
>> AbstractLayer
>>- rasterLayer (RasterImageLayer + Sextante + WMS : is it possible ?)
>>- vectorLayer (Shape, database, WFS...)
>>
>> In such a scenario, I don't know if current Layer should be equal to
>> VectorLayer
>> or above Vector and Raster.
>>
>> Another feature I'd like which meets peppe's requirement is some
>> information
>> about the source (null/file[tmp,compressed]/url[database,service]) at the
>> AbstractLayer level, or at least above Raster/Vector, because this is a
>> common thing
>> which is quite difficult to get in a uniform way in the current
>> hierarchy (and which is
>> a bit hidden).
>>
>> Maybe also methods like
>> - getEnvelope (currently available in raster layer and wms but not in
>> layer !) should be
>> implemented at the AbstractLayer level, as well as
>> - getFeatureCollection which could return image(s) enveloppes in case of
>> raster layers.
>>
>> My 2 cents
>>
>> Michaël
>>
>> Le 27/01/2016 12:22, edgar.sol...@web.de a écrit :
>> > thx! and exactly my point :) ..ede
>> >
>> > On 27.01.2016 12:17, Alberto De Luca wrote:
>> >> Ede,
>> >>
>> >> yes I am aware of the majority of the additions relate to Layer.java,
>> but I
>> >> wouldn't venture into commenting on those since my knowledge with
>> regards
>> >> to the Layer class is limited. What I could say though is that for what
>> >> I've seen the design of Layer is very neat and though-through in
>> comparison
>> >> to RasterImageLayer, therefore I would think more than twice before
>> >> touching it.
>> >>
>> >> Alberto
>> >>
>> >> On 27 January 2016 at 11:13,  wrote:
>> >>
>> >>> Alberto,
>> >>>
>> >>> you are aware most additions Peppe did were to Layer.java where they

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[edgar . soldin]

sure, go ahead.

it's just important to me that we talk about it first and find an ordered 
approach that takes into account the existing API. i am a big fan of small 
steps, but into the right direction. meaning a big overhaul refactoring is 
possibly bringing more problems than the whole cleanup is worth.
streamlining the existing API by eg. moving a small functionality out of Layer 
into AbstractLayerable at a time and test it will probably the least dangerous 
approach.

visualizing the current design beforehand might probably help all parties to 
get an initial overview as well.

..ede

On 03.02.2016 17:49, Landon Blake wrote:
> How do you guys feel about having Peppe and I review our existing layerable
> class/interface architecture and come up with a proposal for clean-up and
> revisions. I think some of Peppe's suggested methods are useful, but agree
> with Ede that we need to plug them into the correct interface.
> 
> I think this is exactly the type of TLC the OpenJUMP core needs. I would
> love to work with Peppe to test some code and then propose a more
> comprehensive clean-up of the layerable code here.
> 
> Peppe: Let me know if you want my help.
> 
> Others: Let me know if you'd be willing to consider a proposal and some
> test code from Peppe and I.
> 
> Landon
> 
> On Wed, Jan 27, 2016 at 7:02 AM, Giuseppe Aruta 
> wrote:
> 
>> OK,
>> I had the response of everybody.
>>
>> - I am going to remove all the Layer.class parts and restore as it is
>> before
>> - I am going to leave only the RasterImageLayer.class method
>> isTemporaryLayer()
>> - I will create an external class, called maybe LayerbleUtils - no
>> implementation to Layerable or other classes, just a useful Util class to
>> group all these potential boolen/String methods.
>>
>>> you mean as default saving format when leaving OJ? why?
>> No. Not talking about SaveDatasetsPlugIn. It has a useful behaviour: if I
>> try to add a  a polygon to a point layer (belonging to a Shapefile, already
>> saved). And than I will save it, the plugin will save the original geometry
>> collection to the original file, and create another SHP file with the
>> polygon. This is probably better than a warning message.
>> My idea is to add this capability to Michael's project
>> SaveLayersWithoutDatasource.class ( it saves a list of layers without
>> datasource, the user can choose JML or SHP as export format) which is also
>> invoked on Saving a project.
>> An alternative simpler idea is to give the plugin the capability to
>> distinguish mixed geometry types layers among all, and to save them as JML,
>> even if the user choose SHP.
>> In any  I will not change none of the actual classes. As I frequently
>> work with Sextante rasters(RasterImageLayer.class), I will start from
>> Michael's plugin to create another one  that has these two extra
>> capabilities:
>> a) it saves also a list of Temporary Raster layers as TIF
>> b) it  allows users to commit changes on "modified layers" ( I will
>> consider "modified layers" as Layer.class, vector based, with a datasource.
>> I will exclude  from this collection ("modified layers")
>> DataStoreQueryDataSources and ReferencedImageLayer (legacy images) as
>> their saving is still complex and ambiguous (see a previous discussion
>> about saving a ReferencedImageLayer when its envelope has been moved or
>> resized)
>> Peppe
>>
>> 2016-01-27 13:53 GMT+01:00 Michaël Michaud :
>>
>>> Hi,
>>>
>>> I think that Peppe's request show some flaws in layerable hierarchy.
>>> Some may be addressed by adding helper methods to existing class.
>>> Others maybe addressed by introducing new interfaces.
>>> Some are not so difficult to find in current implementation.
>>>
>>> My main complain about the design is that raster has two very different
>>> representations (a layer subclass for legacy images and a different
>>> class for
>>> sextante)
>>> It could be a good idea to arrive to the following hierarchy :
>>> AbstractLayer
>>>- rasterLayer (RasterImageLayer + Sextante + WMS : is it possible ?)
>>>- vectorLayer (Shape, database, WFS...)
>>>
>>> In such a scenario, I don't know if current Layer should be equal to
>>> VectorLayer
>>> or above Vector and Raster.
>>>
>>> Another feature I'd like which meets peppe's requirement is some
>>> information
>>> about the source (null/file[tmp,compressed]/url[database,service]) at the
>>> AbstractLayer level, or at least above Raster/Vector, because this is a
>>> common thing
>>> which is quite difficult to get in a uniform way in the current
>>> hierarchy (and which is
>>> a bit hidden).
>>>
>>> Maybe also methods like
>>> - getEnvelope (currently available in raster layer and wms but not in
>>> layer !) should be
>>> implemented at the AbstractLayer level, as well as
>>> - getFeatureCollection which could return image(s) enveloppes in case of
>>> raster layers.
>>>
>>> My 2 cents
>>>
>>> Michaël
>>>
>>> Le 27/01/2016 12:22, 

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Alberto De Luca]

Ede,

yes I am aware of the majority of the additions relate to Layer.java, but I
wouldn't venture into commenting on those since my knowledge with regards
to the Layer class is limited. What I could say though is that for what
I've seen the design of Layer is very neat and though-through in comparison
to RasterImageLayer, therefore I would think more than twice before
touching it.

Alberto

On 27 January 2016 at 11:13,  wrote:

> Alberto,
>
> you are aware most additions Peppe did were to Layer.java where they
> definitely don't belong?
>
> if it's needed in RasterImageLayer, i don't oppose at all.
>
> ..ede
>
> On 27.01.2016 10:53, Alberto De Luca wrote:
> > Hey guys,
> >
> > at the moment RasterImageLayer is quite a messy class (a mess to whom
> I've
> > been contributing, by the way), because there's a bit of everything in
> in,
> > from methods that manipulate the raster values to methods that take care
> of
> > the rendering on screen...
> >
> > So while we wait for the lucky ticket-owner to come along, I think that
> the
> > utility methods added by Peppe (that to me are definitely useful) should
> > stay: they just made the class a bit messier :P
> >
> > Alberto
> >
> >
> > On 27 January 2016 at 03:00, Stefan Steiniger  wrote:
> >
> >> see below
> >>
> >> Am 26.01.16 um 13:31 schrieb Giuseppe Aruta:
> >>> Just few extra details:
> >>>
> >>> 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
> >>> layers (isTemporaryLayer())
> >>> - Sextante is a different software and it handles raster and vector in
> a
> >>> separate way from OpenJUMP
> >>> - while TEMP files should be stored in Windows forever (except if user
> >>> does a deep OS cleaning) Linux and MacOSX delete these files from the
> >>> /TEMP folder on shuts down
> >>> Linux and Mac users should be aware that, if they shut down the OS and
> >>> if they don't save these temp data in another folder, they will lost
> >>> them. But I am sure that few know about this.
> >>>
> >>> Pratical usage:
> >>> Other temporary layers  also layers with no datasource.
> >>> SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about
> >>> the presence of these layers.
> >>> I am planning to expand this plugin  to this other group of temporary
> >>> layers (the one stored into /TEMP folder) both Layers and
> >> RasterImageLayers.
> >>> I could work on the plugin without adding new boolean on System classes
> >>> (you are right, Ede, those functionality are already there)
> >>> But a flag like RasterImagerLayer.isTemporary() would avoid some extra
> >>> code and, more important,  it could be used also in the future
> >>
> >> I agree with Peppe here...
> >> But perhaps we need to see how this fits also with Michaels DB
> >> experiences (and approaches). At least most Raster-Related helper
> >> classes make sense to me. Perhaps Alberto has a comment on that too.
> >> And if Ede points out to the original JUMP design/development... well
> >> the design focus was on vector... everything else raster wise was more
> >> experimental (my opinion). And this is now also some wooohhhoo 12-13
> >> years ago... ;)
> >>
> >> Ideally of course one would need to do what QGIS did, a complete
> >> redesign of the core, but... (perhaps someone wins in the lottery and
> >> funds 5 devs from that :)
> >>
> >> cheers,
> >> Stefan
> >>
> >>
> >>
> --
> >> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> >> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> >> Monitor end-to-end web transactions and take corrective actions now
> >> Troubleshoot faster and improve end-user experience. Signup Now!
> >> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> >> ___
> >> Jump-pilot-devel mailing list
> >> Jump-pilot-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>
> >
> >
> >
> >
> --
> > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > Monitor end-to-end web transactions and take corrective actions now
> > Troubleshoot faster and improve end-user experience. Signup Now!
> > http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> >
> >
> >
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> 

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[edgar . soldin]

thx! and exactly my point :) ..ede

On 27.01.2016 12:17, Alberto De Luca wrote:
> Ede,
> 
> yes I am aware of the majority of the additions relate to Layer.java, but I
> wouldn't venture into commenting on those since my knowledge with regards
> to the Layer class is limited. What I could say though is that for what
> I've seen the design of Layer is very neat and though-through in comparison
> to RasterImageLayer, therefore I would think more than twice before
> touching it.
> 
> Alberto
> 
> On 27 January 2016 at 11:13,  wrote:
> 
>> Alberto,
>>
>> you are aware most additions Peppe did were to Layer.java where they
>> definitely don't belong?
>>
>> if it's needed in RasterImageLayer, i don't oppose at all.
>>
>> ..ede
>>
>> On 27.01.2016 10:53, Alberto De Luca wrote:
>>> Hey guys,
>>>
>>> at the moment RasterImageLayer is quite a messy class (a mess to whom
>> I've
>>> been contributing, by the way), because there's a bit of everything in
>> in,
>>> from methods that manipulate the raster values to methods that take care
>> of
>>> the rendering on screen...
>>>
>>> So while we wait for the lucky ticket-owner to come along, I think that
>> the
>>> utility methods added by Peppe (that to me are definitely useful) should
>>> stay: they just made the class a bit messier :P
>>>
>>> Alberto
>>>
>>>
>>> On 27 January 2016 at 03:00, Stefan Steiniger  wrote:
>>>
 see below

 Am 26.01.16 um 13:31 schrieb Giuseppe Aruta:
> Just few extra details:
>
> 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
> layers (isTemporaryLayer())
> - Sextante is a different software and it handles raster and vector in
>> a
> separate way from OpenJUMP
> - while TEMP files should be stored in Windows forever (except if user
> does a deep OS cleaning) Linux and MacOSX delete these files from the
> /TEMP folder on shuts down
> Linux and Mac users should be aware that, if they shut down the OS and
> if they don't save these temp data in another folder, they will lost
> them. But I am sure that few know about this.
>
> Pratical usage:
> Other temporary layers  also layers with no datasource.
> SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about
> the presence of these layers.
> I am planning to expand this plugin  to this other group of temporary
> layers (the one stored into /TEMP folder) both Layers and
 RasterImageLayers.
> I could work on the plugin without adding new boolean on System classes
> (you are right, Ede, those functionality are already there)
> But a flag like RasterImagerLayer.isTemporary() would avoid some extra
> code and, more important,  it could be used also in the future

 I agree with Peppe here...
 But perhaps we need to see how this fits also with Michaels DB
 experiences (and approaches). At least most Raster-Related helper
 classes make sense to me. Perhaps Alberto has a comment on that too.
 And if Ede points out to the original JUMP design/development... well
 the design focus was on vector... everything else raster wise was more
 experimental (my opinion). And this is now also some wooohhhoo 12-13
 years ago... ;)

 Ideally of course one would need to do what QGIS did, a complete
 redesign of the core, but... (perhaps someone wins in the lottery and
 funds 5 devs from that :)

 cheers,
 Stefan



>> --
 Site24x7 APM Insight: Get Deep Visibility into Application Performance
 APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
 Monitor end-to-end web transactions and take corrective actions now
 Troubleshoot faster and improve end-user experience. Signup Now!
 http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
 ___
 Jump-pilot-devel mailing list
 Jump-pilot-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

>>>
>>>
>>>
>>>
>> --
>>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>>> Monitor end-to-end web transactions and take corrective actions now
>>> Troubleshoot faster and improve end-user experience. Signup Now!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
>>>
>>>
>>>
>>> ___
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + 

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[edgar . soldin]

On 26.01.2016 17:31, Giuseppe Aruta wrote:
> Just few extra details:
> 
> 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
> layers (isTemporaryLayer())
> - Sextante is a different software and it handles raster and vector in a
> separate way from OpenJUMP
> - while TEMP files should be stored in Windows forever (except if user does
> a deep OS cleaning) Linux and MacOSX delete these files from the /TEMP
> folder on shuts down
> Linux and Mac users should be aware that, if they shut down the OS and if
> they don't save these temp data in another folder, they will lost them. But
> I am sure that few know about this.
> 
> Pratical usage:
> Other temporary layers  also layers with no datasource.
> SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about the
> presence of these layers.
> I am planning to expand this plugin  to this other group of temporary
> layers (the one stored into /TEMP folder) both Layers and RasterImageLayers.
> I could work on the plugin without adding new boolean on System classes
> (you are right, Ede, those functionality are already there)
> But a flag like RasterImagerLayer.isTemporary() would avoid some extra code
> and, more important,  it could be used also in the future

if you need it there, go ahead. but please remove the stuff from Layer.java 
that does not belong there. 
the code is already messy enough and we should strive to clean it instead of 
messing it up even more (sorry Alberto).
 
> 2) check if layer has a mixed geometry
> Thanks Michael, I can see that polygons and multipolygons are considered as
> "mixed geometry". I will change the code: my idea is to check if the layer
> has point/linestring/polygon collection, to define different procedure on
> exporting (->to JML if it is a geometry collection, to SHP if is point or
> point/multipoint collection). I also was aware to use FeatureCollection
> (Kosmo implemented some flag here, too for geometries), I will move to that
> class)

you mean as default saving format when leaving OJ? why?
 
> 3) System layers.
> SaveLayrsWithoutDatasourcePlugIn  check to save Fence layer too on a
> project. I feel that this fence and measure layers should be sometimes
> treated in different way that other layers
 
isn't a system layer currently a layer of any kind residing in the category 
system? even wfs layers are placed there by default currently.

i guess you talk about runtime generated (helper-)layers? if so, i don't see 
the difference between them and layers without datasource from a coding 
perspective.
or is there?

some afterthought:

afaics only (Vector)Layer has currently support for DataSourceQueries. probably 
because most, if not all other layer types are read only currently.

if we cleanly want to implement the current OJ API we should consider extending 
AbstractLayer accordingly and peu a peu add support for it to the layer types 
that need it eg. RasterImageLayer in your case.

..ede

..ede

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Alberto De Luca]

Hey guys,

at the moment RasterImageLayer is quite a messy class (a mess to whom I've
been contributing, by the way), because there's a bit of everything in in,
from methods that manipulate the raster values to methods that take care of
the rendering on screen...

So while we wait for the lucky ticket-owner to come along, I think that the
utility methods added by Peppe (that to me are definitely useful) should
stay: they just made the class a bit messier :P

Alberto


On 27 January 2016 at 03:00, Stefan Steiniger  wrote:

> see below
>
> Am 26.01.16 um 13:31 schrieb Giuseppe Aruta:
> > Just few extra details:
> >
> > 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
> > layers (isTemporaryLayer())
> > - Sextante is a different software and it handles raster and vector in a
> > separate way from OpenJUMP
> > - while TEMP files should be stored in Windows forever (except if user
> > does a deep OS cleaning) Linux and MacOSX delete these files from the
> > /TEMP folder on shuts down
> > Linux and Mac users should be aware that, if they shut down the OS and
> > if they don't save these temp data in another folder, they will lost
> > them. But I am sure that few know about this.
> >
> > Pratical usage:
> > Other temporary layers  also layers with no datasource.
> > SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about
> > the presence of these layers.
> > I am planning to expand this plugin  to this other group of temporary
> > layers (the one stored into /TEMP folder) both Layers and
> RasterImageLayers.
> > I could work on the plugin without adding new boolean on System classes
> > (you are right, Ede, those functionality are already there)
> > But a flag like RasterImagerLayer.isTemporary() would avoid some extra
> > code and, more important,  it could be used also in the future
>
> I agree with Peppe here...
> But perhaps we need to see how this fits also with Michaels DB
> experiences (and approaches). At least most Raster-Related helper
> classes make sense to me. Perhaps Alberto has a comment on that too.
> And if Ede points out to the original JUMP design/development... well
> the design focus was on vector... everything else raster wise was more
> experimental (my opinion). And this is now also some wooohhhoo 12-13
> years ago... ;)
>
> Ideally of course one would need to do what QGIS did, a complete
> redesign of the core, but... (perhaps someone wins in the lottery and
> funds 5 devs from that :)
>
> cheers,
> Stefan
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[edgar . soldin]

Alberto,

you are aware most additions Peppe did were to Layer.java where they definitely 
don't belong?

if it's needed in RasterImageLayer, i don't oppose at all.

..ede

On 27.01.2016 10:53, Alberto De Luca wrote:
> Hey guys,
> 
> at the moment RasterImageLayer is quite a messy class (a mess to whom I've
> been contributing, by the way), because there's a bit of everything in in,
> from methods that manipulate the raster values to methods that take care of
> the rendering on screen...
> 
> So while we wait for the lucky ticket-owner to come along, I think that the
> utility methods added by Peppe (that to me are definitely useful) should
> stay: they just made the class a bit messier :P
> 
> Alberto
> 
> 
> On 27 January 2016 at 03:00, Stefan Steiniger  wrote:
> 
>> see below
>>
>> Am 26.01.16 um 13:31 schrieb Giuseppe Aruta:
>>> Just few extra details:
>>>
>>> 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
>>> layers (isTemporaryLayer())
>>> - Sextante is a different software and it handles raster and vector in a
>>> separate way from OpenJUMP
>>> - while TEMP files should be stored in Windows forever (except if user
>>> does a deep OS cleaning) Linux and MacOSX delete these files from the
>>> /TEMP folder on shuts down
>>> Linux and Mac users should be aware that, if they shut down the OS and
>>> if they don't save these temp data in another folder, they will lost
>>> them. But I am sure that few know about this.
>>>
>>> Pratical usage:
>>> Other temporary layers  also layers with no datasource.
>>> SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about
>>> the presence of these layers.
>>> I am planning to expand this plugin  to this other group of temporary
>>> layers (the one stored into /TEMP folder) both Layers and
>> RasterImageLayers.
>>> I could work on the plugin without adding new boolean on System classes
>>> (you are right, Ede, those functionality are already there)
>>> But a flag like RasterImagerLayer.isTemporary() would avoid some extra
>>> code and, more important,  it could be used also in the future
>>
>> I agree with Peppe here...
>> But perhaps we need to see how this fits also with Michaels DB
>> experiences (and approaches). At least most Raster-Related helper
>> classes make sense to me. Perhaps Alberto has a comment on that too.
>> And if Ede points out to the original JUMP design/development... well
>> the design focus was on vector... everything else raster wise was more
>> experimental (my opinion). And this is now also some wooohhhoo 12-13
>> years ago... ;)
>>
>> Ideally of course one would need to do what QGIS did, a complete
>> redesign of the core, but... (perhaps someone wins in the lottery and
>> funds 5 devs from that :)
>>
>> cheers,
>> Stefan
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
> 
> 
> 
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> 
> 
> 
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Michaël Michaud]

Hi,

I think that Peppe's request show some flaws in layerable hierarchy.
Some may be addressed by adding helper methods to existing class.
Others maybe addressed by introducing new interfaces.
Some are not so difficult to find in current implementation.

My main complain about the design is that raster has two very different
representations (a layer subclass for legacy images and a different 
class for
sextante)
It could be a good idea to arrive to the following hierarchy :
AbstractLayer
   - rasterLayer (RasterImageLayer + Sextante + WMS : is it possible ?)
   - vectorLayer (Shape, database, WFS...)

In such a scenario, I don't know if current Layer should be equal to 
VectorLayer
or above Vector and Raster.

Another feature I'd like which meets peppe's requirement is some information
about the source (null/file[tmp,compressed]/url[database,service]) at the
AbstractLayer level, or at least above Raster/Vector, because this is a 
common thing
which is quite difficult to get in a uniform way in the current 
hierarchy (and which is
a bit hidden).

Maybe also methods like
- getEnvelope (currently available in raster layer and wms but not in 
layer !) should be
implemented at the AbstractLayer level, as well as
- getFeatureCollection which could return image(s) enveloppes in case of 
raster layers.

My 2 cents

Michaël

Le 27/01/2016 12:22, edgar.sol...@web.de a écrit :
> thx! and exactly my point :) ..ede
>
> On 27.01.2016 12:17, Alberto De Luca wrote:
>> Ede,
>>
>> yes I am aware of the majority of the additions relate to Layer.java, but I
>> wouldn't venture into commenting on those since my knowledge with regards
>> to the Layer class is limited. What I could say though is that for what
>> I've seen the design of Layer is very neat and though-through in comparison
>> to RasterImageLayer, therefore I would think more than twice before
>> touching it.
>>
>> Alberto
>>
>> On 27 January 2016 at 11:13,  wrote:
>>
>>> Alberto,
>>>
>>> you are aware most additions Peppe did were to Layer.java where they
>>> definitely don't belong?
>>>
>>> if it's needed in RasterImageLayer, i don't oppose at all.
>>>
>>> ..ede
>>>
>>> On 27.01.2016 10:53, Alberto De Luca wrote:
 Hey guys,

 at the moment RasterImageLayer is quite a messy class (a mess to whom
>>> I've
 been contributing, by the way), because there's a bit of everything in
>>> in,
 from methods that manipulate the raster values to methods that take care
>>> of
 the rendering on screen...

 So while we wait for the lucky ticket-owner to come along, I think that
>>> the
 utility methods added by Peppe (that to me are definitely useful) should
 stay: they just made the class a bit messier :P

 Alberto


 On 27 January 2016 at 03:00, Stefan Steiniger  wrote:

> see below
>
> Am 26.01.16 um 13:31 schrieb Giuseppe Aruta:
>> Just few extra details:
>>
>> 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
>> layers (isTemporaryLayer())
>> - Sextante is a different software and it handles raster and vector in
>>> a
>> separate way from OpenJUMP
>> - while TEMP files should be stored in Windows forever (except if user
>> does a deep OS cleaning) Linux and MacOSX delete these files from the
>> /TEMP folder on shuts down
>> Linux and Mac users should be aware that, if they shut down the OS and
>> if they don't save these temp data in another folder, they will lost
>> them. But I am sure that few know about this.
>>
>> Pratical usage:
>> Other temporary layers  also layers with no datasource.
>> SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about
>> the presence of these layers.
>> I am planning to expand this plugin  to this other group of temporary
>> layers (the one stored into /TEMP folder) both Layers and
> RasterImageLayers.
>> I could work on the plugin without adding new boolean on System classes
>> (you are right, Ede, those functionality are already there)
>> But a flag like RasterImagerLayer.isTemporary() would avoid some extra
>> code and, more important,  it could be used also in the future
> I agree with Peppe here...
> But perhaps we need to see how this fits also with Michaels DB
> experiences (and approaches). At least most Raster-Related helper
> classes make sense to me. Perhaps Alberto has a comment on that too.
> And if Ede points out to the original JUMP design/development... well
> the design focus was on vector... everything else raster wise was more
> experimental (my opinion). And this is now also some wooohhhoo 12-13
> years ago... ;)
>
> Ideally of course one would need to do what QGIS did, a complete
> redesign of the core, but... (perhaps someone wins in the lottery and
> funds 5 devs from that :)
>
> cheers,
> Stefan
>
>
>
>>> 

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Giuseppe Aruta]

OK,
I had the response of everybody.

- I am going to remove all the Layer.class parts and restore as it is before
- I am going to leave only the RasterImageLayer.class method
isTemporaryLayer()
- I will create an external class, called maybe LayerbleUtils - no
implementation to Layerable or other classes, just a useful Util class to
group all these potential boolen/String methods.

>you mean as default saving format when leaving OJ? why?
No. Not talking about SaveDatasetsPlugIn. It has a useful behaviour: if I
try to add a  a polygon to a point layer (belonging to a Shapefile, already
saved). And than I will save it, the plugin will save the original geometry
collection to the original file, and create another SHP file with the
polygon. This is probably better than a warning message.
My idea is to add this capability to Michael's project
SaveLayersWithoutDatasource.class ( it saves a list of layers without
datasource, the user can choose JML or SHP as export format) which is also
invoked on Saving a project.
An alternative simpler idea is to give the plugin the capability to
distinguish mixed geometry types layers among all, and to save them as JML,
even if the user choose SHP.
In any  I will not change none of the actual classes. As I frequently work
with Sextante rasters(RasterImageLayer.class), I will start from Michael's
plugin to create another one  that has these two extra capabilities:
a) it saves also a list of Temporary Raster layers as TIF
b) it  allows users to commit changes on "modified layers" ( I will
consider "modified layers" as Layer.class, vector based, with a datasource.
I will exclude  from this collection ("modified layers")
DataStoreQueryDataSources and ReferencedImageLayer (legacy images) as their
saving is still complex and ambiguous (see a previous discussion about
saving a ReferencedImageLayer when its envelope has been moved or resized)
Peppe

2016-01-27 13:53 GMT+01:00 Michaël Michaud :

> Hi,
>
> I think that Peppe's request show some flaws in layerable hierarchy.
> Some may be addressed by adding helper methods to existing class.
> Others maybe addressed by introducing new interfaces.
> Some are not so difficult to find in current implementation.
>
> My main complain about the design is that raster has two very different
> representations (a layer subclass for legacy images and a different
> class for
> sextante)
> It could be a good idea to arrive to the following hierarchy :
> AbstractLayer
>- rasterLayer (RasterImageLayer + Sextante + WMS : is it possible ?)
>- vectorLayer (Shape, database, WFS...)
>
> In such a scenario, I don't know if current Layer should be equal to
> VectorLayer
> or above Vector and Raster.
>
> Another feature I'd like which meets peppe's requirement is some
> information
> about the source (null/file[tmp,compressed]/url[database,service]) at the
> AbstractLayer level, or at least above Raster/Vector, because this is a
> common thing
> which is quite difficult to get in a uniform way in the current
> hierarchy (and which is
> a bit hidden).
>
> Maybe also methods like
> - getEnvelope (currently available in raster layer and wms but not in
> layer !) should be
> implemented at the AbstractLayer level, as well as
> - getFeatureCollection which could return image(s) enveloppes in case of
> raster layers.
>
> My 2 cents
>
> Michaël
>
> Le 27/01/2016 12:22, edgar.sol...@web.de a écrit :
> > thx! and exactly my point :) ..ede
> >
> > On 27.01.2016 12:17, Alberto De Luca wrote:
> >> Ede,
> >>
> >> yes I am aware of the majority of the additions relate to Layer.java,
> but I
> >> wouldn't venture into commenting on those since my knowledge with
> regards
> >> to the Layer class is limited. What I could say though is that for what
> >> I've seen the design of Layer is very neat and though-through in
> comparison
> >> to RasterImageLayer, therefore I would think more than twice before
> >> touching it.
> >>
> >> Alberto
> >>
> >> On 27 January 2016 at 11:13,  wrote:
> >>
> >>> Alberto,
> >>>
> >>> you are aware most additions Peppe did were to Layer.java where they
> >>> definitely don't belong?
> >>>
> >>> if it's needed in RasterImageLayer, i don't oppose at all.
> >>>
> >>> ..ede
> >>>
> >>> On 27.01.2016 10:53, Alberto De Luca wrote:
>  Hey guys,
> 
>  at the moment RasterImageLayer is quite a messy class (a mess to whom
> >>> I've
>  been contributing, by the way), because there's a bit of everything in
> >>> in,
>  from methods that manipulate the raster values to methods that take
> care
> >>> of
>  the rendering on screen...
> 
>  So while we wait for the lucky ticket-owner to come along, I think
> that
> >>> the
>  utility methods added by Peppe (that to me are definitely useful)
> should
>  stay: they just made the class a bit messier :P
> 
>  Alberto
> 
> 
>  On 27 January 2016 at 03:00, Stefan Steiniger 
> 

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[edgar . soldin]

Stefan,

the original authors probably created the API with some afterthought and 
accidentally i agree w/ them. OJ layers are merely responsible to render their 
data into the layerview. if you want more you ask the layer to give you the 
featcol or the datasource to work w/.

this is clean and efficient and i see no argument invalidating that so far.

..ede

On 26.01.2016 13:15, Stefan Steiniger wrote:
> Hey,
> 
> i think some of the stuff is quite usefull and even having it in Layer 
> class... 
> for an OJ programmer who knows clases etc., probabky not the right place, but 
> for someone who writes scripts (python, bash, etc) this is the obvious place 
> to 
> get to know layer properties.
> 
> Of course i don't know how many do scripting with OJ, but...
> 
> cheers,
> 
> stefan
> 
> -- Originalnachricht --
> *Von: *
> *Datum: *26.01.2016 8:22
> *An: *OpenJump develop and use;
> *Betreff:*Re: [JPP-Devel] Add some useful methods on Layer.class and 
> RasterImageLayer.class
> 
> Peppe,
> 
> 
> first of all while i commend your drive i really think that API 
> changes/additions this deep in CORE should be discussed first and committed 
> only after.
> this is unless you
> - are absolutely sure what you are doing ;)
> and
> - know how to revert the commit cleanly (keeping revisions)
> 
> further comments in the text below
> 
> On 26.01.2016 07:26, Giuseppe Aruta wrote:
>> Hi Ede, Michael, Jukka, Stefan and others
>> I added some simple boolean ans String methods on
>> com.vividsolutions.jump.workbench.model.Layer class and
>> org.openjump.core.rasterimage.RasterImageLayer class
>> I ask you to give a look and your opinion, these methods should cover many
>> aspects and can be used for future development.
>> I would like to know if
>> a) those methods are in the right place
> 
> no.
> 
> 1. Layer is the oldest layer representation in OJ (when it only suppported 
> vectors), but not the most basic, that is Layerable or the implementor 
> AbstractLayerable (which can be used to implement nearly anything as an OJ 
> layerable)
> 
> 2. it mixes up functionality. you ask the layer about things that are and 
> should only be known to it's feature collection or datasource.
> 
> 3. you are (mostly) implementing functionality that is already there. if you 
> want to know what type a layer is you check out what it is instanceof or ask 
> it's datasource.
> check out eg. how
>   ReferencedImagesLayer extends Layer extends AbstractLayerable implements 
> Layerable
> so if you want to know if you deal with an ReferencedImagesLayer use 
> *instanceof*.
> 
> OJ layers keep the way the handle their data private, so there is no way to 
> generalize handling of say images (totally different implementation between 
> RasterImageLayer & ReferencedImageLayer) today.
> if you want functionality like that consider
> a) inserting a generalized interface class with the functions you need eg. 
> ImageLayer extends AbstractLayerable and have both extend from that
> b) implement an interface eg. ImageLayer in both that defines functions you 
> need for generalized image handling
> 
>> b) if they are really efficient ( i might loose some aspects)
> 
> what do you mean by this?
> 
>> on Layer class:
>>
>> 1) isTemporaryLayer()  Defines all Layer which datasource is null or Layer
>> which are saved into a TEMP folder (those layers are created by Sextante if
>> the Sextante option "save as temporary file" is activated)
> 
> why is this actually needed? if the the data is needed between runs, after an 
> OJ restart, it should not be saved in temp in the first place.
>   
>> 2) isModifiedLayer() == is FeatureCollectionModified
> 
> well, this depends on the type of layer, but should probably be set like 
> visible, editable etc. in AbstractLayerable, for implementers to override at 
> will
>   
>> 3) isVectorLayer() Defines all layer  excluding images (and datastores
>>
>> 4) isImageLayer() Defines all image loaded by Layer.class (hope so)
>>
>> 5) isMultipleImagesLayer() Defines a Layer with multiple image
>>
>> 6) isDataStoreLayer() should be defines all Datastore layers. I am not sure
>> about this part of the code
> 
> see ,my point 3. above
> 
>> 7) isSystemLayer() Defines layer like Fence and Measure, which should be
>> considered as "System" layers
> 
> what do we need that for?
>   
>> 8) isCadLayer() Something I test to work with DXF files, Only layers with
>> COLOR and TEXT attributes
> 
> probably point 3. again
>   
>> 9) isMixedGeometryTypes() Should check if the Layer

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Stefan Steiniger]

Hey, i think some of the stuff is quite usefull and even having it in Layer class... for an OJ programmer who knows clases etc., probabky not the right place, but for someone who writes scripts (python, bash, etc) this is the obvious place to get to know layer properties. Of course i don't know how many do scripting with OJ, but... cheers,stefan -- Originalnachricht --Von: Datum: 26.01.2016 8:22An: OpenJump develop and use;Betreff:Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.classPeppe,


first of all while i commend your drive i really think that API changes/additions this deep in CORE should be discussed first and committed only after.
this is unless you
- are absolutely sure what you are doing ;)
and
- know how to revert the commit cleanly (keeping revisions)

further comments in the text below

On 26.01.2016 07:26, Giuseppe Aruta wrote:
> Hi Ede, Michael, Jukka, Stefan and others
> I added some simple boolean ans String methods on
> com.vividsolutions.jump.workbench.model.Layer class and
> org.openjump.core.rasterimage.RasterImageLayer class
> I ask you to give a look and your opinion, these methods should cover many
> aspects and can be used for future development.
> I would like to know if
> a) those methods are in the right place

no.

1. Layer is the oldest layer representation in OJ (when it only suppported vectors), but not the most basic, that is Layerable or the implementor AbstractLayerable (which can be used to implement nearly anything as an OJ layerable)

2. it mixes up functionality. you ask the layer about things that are and should only be known to it's feature collection or datasource.

3. you are (mostly) implementing functionality that is already there. if you want to know what type a layer is you check out what it is instanceof or ask it's datasource.
check out eg. how 
 ReferencedImagesLayer extends Layer extends AbstractLayerable implements Layerable
so if you want to know if you deal with an ReferencedImagesLayer use *instanceof*.

OJ layers keep the way the handle their data private, so there is no way to generalize handling of say images (totally different implementation between RasterImageLayer & ReferencedImageLayer) today. 
if you want functionality like that consider 
a) inserting a generalized interface class with the functions you need eg. ImageLayer extends AbstractLayerable and have both extend from that
b) implement an interface eg. ImageLayer in both that defines functions you need for generalized image handling

> b) if they are really efficient ( i might loose some aspects)

what do you mean by this?

> on Layer class:
> 
> 1) isTemporaryLayer()  Defines all Layer which datasource is null or Layer
> which are saved into a TEMP folder (those layers are created by Sextante if
> the Sextante option "save as temporary file" is activated)

why is this actually needed? if the the data is needed between runs, after an OJ restart, it should not be saved in temp in the first place.
 
> 2) isModifiedLayer() == is FeatureCollectionModified

well, this depends on the type of layer, but should probably be set like visible, editable etc. in AbstractLayerable, for implementers to override at will
 
> 3) isVectorLayer() Defines all layer  excluding images (and datastores
> 
> 4) isImageLayer() Defines all image loaded by Layer.class (hope so)
> 
> 5) isMultipleImagesLayer() Defines a Layer with multiple image
> 
> 6) isDataStoreLayer() should be defines all Datastore layers. I am not sure
> about this part of the code

see ,my point 3. above

> 7) isSystemLayer() Defines layer like Fence and Measure, which should be
> considered as "System" layers

what do we need that for?
 
> 8) isCadLayer() Something I test to work with DXF files, Only layers with
> COLOR and TEXT attributes

probably point 3. again
 
> 9) isMixedGeometryTypes() Should check if the Layer has mixed geometry types
> 
> 10) isEmpy() Should defines if the Layer has an empty feature collection
> 
> 11) String getGeometryType(). returns the geometry types of the layer

can be retrieved already by getting the featurecollection
 
> 12) String getFilePath() return the path of a Layer, eg.
> C:/folder/file.shp. If the file is stored into a TEMP folder it returns a
> warning message (see point 1)

ask the layer's datasource
 
> for RasterImageLayers:
> 
> 1) isTemporaryLayer() defines if RasterImageLayer file is stored into a
> TEMP folder
> 
> 12) String getFilePath() return the path of a Layer, eg.
> C:/folder/file.tif. If the file is stored into a TEMP folder it returns a
> warning message (see point 1)
> 
> waiting for your opinion
> 

afaiac this smells like a complete revert. sorry :)) ..ede

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile 

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Giuseppe Aruta]

Just few extra details:

1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
layers (isTemporaryLayer())
- Sextante is a different software and it handles raster and vector in a
separate way from OpenJUMP
- while TEMP files should be stored in Windows forever (except if user does
a deep OS cleaning) Linux and MacOSX delete these files from the /TEMP
folder on shuts down
Linux and Mac users should be aware that, if they shut down the OS and if
they don't save these temp data in another folder, they will lost them. But
I am sure that few know about this.

Pratical usage:
Other temporary layers  also layers with no datasource.
SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about the
presence of these layers.
I am planning to expand this plugin  to this other group of temporary
layers (the one stored into /TEMP folder) both Layers and RasterImageLayers.
I could work on the plugin without adding new boolean on System classes
(you are right, Ede, those functionality are already there)
But a flag like RasterImagerLayer.isTemporary() would avoid some extra code
and, more important,  it could be used also in the future

2) check if layer has a mixed geometry
Thanks Michael, I can see that polygons and multipolygons are considered as
"mixed geometry". I will change the code: my idea is to check if the layer
has point/linestring/polygon collection, to define different procedure on
exporting (->to JML if it is a geometry collection, to SHP if is point or
point/multipoint collection). I also was aware to use FeatureCollection
(Kosmo implemented some flag here, too for geometries), I will move to that
class)

3) System layers.
SaveLayrsWithoutDatasourcePlugIn  check to save Fence layer too on a
project. I feel that this fence and measure layers should be sometimes
treated in different way that other layers


I wait for other comments. and reassure that all these modification can be
easily  reverted





2016-01-26 13:20 GMT+01:00 <edgar.sol...@web.de>:

> Stefan,
>
> the original authors probably created the API with some afterthought and
> accidentally i agree w/ them. OJ layers are merely responsible to render
> their data into the layerview. if you want more you ask the layer to give
> you the featcol or the datasource to work w/.
>
> this is clean and efficient and i see no argument invalidating that so far.
>
> ..ede
>
> On 26.01.2016 13:15, Stefan Steiniger wrote:
> > Hey,
> >
> > i think some of the stuff is quite usefull and even having it in Layer
> class...
> > for an OJ programmer who knows clases etc., probabky not the right
> place, but
> > for someone who writes scripts (python, bash, etc) this is the obvious
> place to
> > get to know layer properties.
> >
> > Of course i don't know how many do scripting with OJ, but...
> >
> > cheers,
> >
> > stefan
> >
> > -- Originalnachricht --
> > *Von: *
> > *Datum: *26.01.2016 8:22
> > *An: *OpenJump develop and use;
> > *Betreff:*Re: [JPP-Devel] Add some useful methods on Layer.class and
> > RasterImageLayer.class
> >
> > Peppe,
> >
> >
> > first of all while i commend your drive i really think that API
> changes/additions this deep in CORE should be discussed first and committed
> only after.
> > this is unless you
> > - are absolutely sure what you are doing ;)
> > and
> > - know how to revert the commit cleanly (keeping revisions)
> >
> > further comments in the text below
> >
> > On 26.01.2016 07:26, Giuseppe Aruta wrote:
> >> Hi Ede, Michael, Jukka, Stefan and others
> >> I added some simple boolean ans String methods on
> >> com.vividsolutions.jump.workbench.model.Layer class and
> >> org.openjump.core.rasterimage.RasterImageLayer class
> >> I ask you to give a look and your opinion, these methods should cover
> many
> >> aspects and can be used for future development.
> >> I would like to know if
> >> a) those methods are in the right place
> >
> > no.
> >
> > 1. Layer is the oldest layer representation in OJ (when it only
> suppported vectors), but not the most basic, that is Layerable or the
> implementor AbstractLayerable (which can be used to implement nearly
> anything as an OJ layerable)
> >
> > 2. it mixes up functionality. you ask the layer about things that are
> and should only be known to it's feature collection or datasource.
> >
> > 3. you are (mostly) implementing functionality that is already there. if
> you want to know what type a layer is you check out what it is instanceof
> or ask it's datasource.
> > check out eg. how
> >   ReferencedImagesLayer extends Layer extends AbstractLayerabl

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Stefan Steiniger]

see below

Am 26.01.16 um 13:31 schrieb Giuseppe Aruta:
> Just few extra details:
>
> 1) Temporary vector (Layer.class) and raster (RasterImageLayer.class)
> layers (isTemporaryLayer())
> - Sextante is a different software and it handles raster and vector in a
> separate way from OpenJUMP
> - while TEMP files should be stored in Windows forever (except if user
> does a deep OS cleaning) Linux and MacOSX delete these files from the
> /TEMP folder on shuts down
> Linux and Mac users should be aware that, if they shut down the OS and
> if they don't save these temp data in another folder, they will lost
> them. But I am sure that few know about this.
>
> Pratical usage:
> Other temporary layers  also layers with no datasource.
> SaveLayrsWithoutDatasourcePlugIn of Michael already advises users about
> the presence of these layers.
> I am planning to expand this plugin  to this other group of temporary
> layers (the one stored into /TEMP folder) both Layers and RasterImageLayers.
> I could work on the plugin without adding new boolean on System classes
> (you are right, Ede, those functionality are already there)
> But a flag like RasterImagerLayer.isTemporary() would avoid some extra
> code and, more important,  it could be used also in the future

I agree with Peppe here...
But perhaps we need to see how this fits also with Michaels DB 
experiences (and approaches). At least most Raster-Related helper 
classes make sense to me. Perhaps Alberto has a comment on that too.
And if Ede points out to the original JUMP design/development... well 
the design focus was on vector... everything else raster wise was more 
experimental (my opinion). And this is now also some wooohhhoo 12-13 
years ago... ;)

Ideally of course one would need to do what QGIS did, a complete 
redesign of the core, but... (perhaps someone wins in the lottery and 
funds 5 devs from that :)

cheers,
Stefan

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[edgar . soldin]

Peppe,


first of all while i commend your drive i really think that API 
changes/additions this deep in CORE should be discussed first and committed 
only after.
this is unless you
- are absolutely sure what you are doing ;)
and
- know how to revert the commit cleanly (keeping revisions)

further comments in the text below

On 26.01.2016 07:26, Giuseppe Aruta wrote:
> Hi Ede, Michael, Jukka, Stefan and others
> I added some simple boolean ans String methods on
> com.vividsolutions.jump.workbench.model.Layer class and
> org.openjump.core.rasterimage.RasterImageLayer class
> I ask you to give a look and your opinion, these methods should cover many
> aspects and can be used for future development.
> I would like to know if
> a) those methods are in the right place

no.

1. Layer is the oldest layer representation in OJ (when it only suppported 
vectors), but not the most basic, that is Layerable or the implementor 
AbstractLayerable (which can be used to implement nearly anything as an OJ 
layerable)

2. it mixes up functionality. you ask the layer about things that are and 
should only be known to it's feature collection or datasource.

3. you are (mostly) implementing functionality that is already there. if you 
want to know what type a layer is you check out what it is instanceof or ask 
it's datasource.
check out eg. how 
 ReferencedImagesLayer extends Layer extends AbstractLayerable implements 
Layerable
so if you want to know if you deal with an ReferencedImagesLayer use 
*instanceof*.

OJ layers keep the way the handle their data private, so there is no way to 
generalize handling of say images (totally different implementation between 
RasterImageLayer & ReferencedImageLayer) today. 
if you want functionality like that consider 
a) inserting a generalized interface class with the functions you need eg. 
ImageLayer extends AbstractLayerable and have both extend from that
b) implement an interface eg. ImageLayer in both that defines functions you 
need for generalized image handling

> b) if they are really efficient ( i might loose some aspects)

what do you mean by this?

> on Layer class:
> 
> 1) isTemporaryLayer()  Defines all Layer which datasource is null or Layer
> which are saved into a TEMP folder (those layers are created by Sextante if
> the Sextante option "save as temporary file" is activated)

why is this actually needed? if the the data is needed between runs, after an 
OJ restart, it should not be saved in temp in the first place.
 
> 2) isModifiedLayer() == is FeatureCollectionModified

well, this depends on the type of layer, but should probably be set like 
visible, editable etc. in AbstractLayerable, for implementers to override at 
will
 
> 3) isVectorLayer() Defines all layer  excluding images (and datastores
> 
> 4) isImageLayer() Defines all image loaded by Layer.class (hope so)
> 
> 5) isMultipleImagesLayer() Defines a Layer with multiple image
> 
> 6) isDataStoreLayer() should be defines all Datastore layers. I am not sure
> about this part of the code

see ,my point 3. above

> 7) isSystemLayer() Defines layer like Fence and Measure, which should be
> considered as "System" layers

what do we need that for?
 
> 8) isCadLayer() Something I test to work with DXF files, Only layers with
> COLOR and TEXT attributes

probably point 3. again
 
> 9) isMixedGeometryTypes() Should check if the Layer has mixed geometry types
> 
> 10) isEmpy() Should defines if the Layer has an empty feature collection
> 
> 11) String getGeometryType(). returns the geometry types of the layer

can be retrieved already by getting the featurecollection
 
> 12) String getFilePath() return the path of a Layer, eg.
> C:/folder/file.shp. If the file is stored into a TEMP folder it returns a
> warning message (see point 1)

ask the layer's datasource
 
> for RasterImageLayers:
> 
> 1) isTemporaryLayer() defines if RasterImageLayer file is stored into a
> TEMP folder
> 
> 12) String getFilePath() return the path of a Layer, eg.
> C:/folder/file.tif. If the file is stored into a TEMP folder it returns a
> warning message (see point 1)
> 
> waiting for your opinion
> 

afaiac this smells like a complete revert. sorry :)) ..ede

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Michaël Michaud]

Hi Peppe,

Interesting changes. Here are some comments, some of which have to be 
discussed furter with Ede and others,


Le 26/01/2016 07:26, Giuseppe Aruta a écrit :

Hi Ede, Michael, Jukka, Stefan and others
I added some simple boolean ans String methods on
com.vividsolutions.jump.workbench.model.Layer class and
org.openjump.core.rasterimage.RasterImageLayer class
I ask you to give a look and your opinion, these methods should cover 
many aspects and can be used for future development.

I would like to know if
a) those methods are in the right place
I first thought that the place of such methods should be in layerable or 
AbstractLayerable, but most of them need Layer specific methods.
Something we must pay attention, is that a developper should be able to 
add new Layer classes (in plugins) without having to modify Layer class 
(but I think most of your propositions are OK with that)

b) if they are really efficient ( i might loose some aspects)

on Layer class:

1) isTemporaryLayer()  Defines all Layer which datasource is null or 
Layer which are saved into a TEMP folder (those layers are created by 
Sextante if the Sextante option "save as temporary file" is activated)
I dont't know much about this problem. If this is an information you 
need to know, I don't mind.


2) isModifiedLayer() == is FeatureCollectionModified
This is a shortcut. In my opinion, it does not improve usability much as 
it just replace a method name by another. I would not retain it (to make 
it shorter, you should have writen "return isFeatureCollectionModified()").


3) isVectorLayer() Defines all layer  excluding images (and datastores
Maybe useful. Just wonder why database should not be considered as 
vectorLayer (or possibly as ImageLayer in future versions).

I think data type and datasource have to be clearly distinguished :
datasource maybe : null (in-memory) temp (for images), file based, 
datastore, internet
datatype maybe : vector (in-memory, file, database, wfs), images (layer, 
rasterLayer, WMS)
Wonder if if could consider datatype as an attribute of layerable and 
keep datasource at he datasource level...




4) isImageLayer() Defines all image loaded by Layer.class (hope so)

See above


5) isMultipleImagesLayer() Defines a Layer with multiple image

See above


6) isDataStoreLayer() should be defines all Datastore layers. I am not 
sure about this part of the code

See above


7) isSystemLayer() Defines layer like Fence and Measure, which should 
be considered as "System" layers
I'm not strictly opposite, but I am not sure what a system layer is 
exactly. For example, measure layer makes no more sense if you remove 
the layer it is related to. Is it still a "system" layer. There is a 
drawback to add such information in


8) isCadLayer() Something I test to work with DXF files, Only layers 
with COLOR and TEXT attributes

Little helper method. Why not ?


9) isMixedGeometryTypes() Should check if the Layer has mixed geometry 
types
I think that this method should stay at the FeatureCollection level. It 
does not make much sense for Image layers.
Also I don't know what it is for exactly, but you must know that 
shapefile can have mixed Polygon/MultiPolygon type.


10) isEmpy() Should defines if the Layer has an empty feature collection

Does not add much, but I don't mind if it makes life easier.
Can be written as a one liner :
return getFeatureCollecctionWrapper().iEmpty()


11) String getGeometryType(). returns the geometry types of the layer

Same remark as 9.


12) String getFilePath() return the path of a Layer, eg. 
C:/folder/file.shp. If the file is stored into a TEMP folder it 
returns a warning message (see point 1)
I don't think that DataStoreDataSource.CONNECTION_DESCRIPTOR_KEY should 
be returned.




for RasterImageLayers:

1) isTemporaryLayer() defines if RasterImageLayer file is stored into 
a TEMP folder
Wonder if your test with contains is platform independant (it has to be 
tested).


Michaël


12) String getFilePath() return the path of a Layer, eg. 
C:/folder/file.tif. If the file is stored into a TEMP folder it 
returns a warning message (see point 1)


waiting for your opinion

best regards

Peppe


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140


___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just 

[JPP-Devel] Add some useful methods on Layer.class and RasterImageLayer.class

[Giuseppe Aruta]

Hi Ede, Michael, Jukka, Stefan and others
I added some simple boolean ans String methods on
com.vividsolutions.jump.workbench.model.Layer class and
org.openjump.core.rasterimage.RasterImageLayer class
I ask you to give a look and your opinion, these methods should cover many
aspects and can be used for future development.
I would like to know if
a) those methods are in the right place
b) if they are really efficient ( i might loose some aspects)

on Layer class:

1) isTemporaryLayer()  Defines all Layer which datasource is null or Layer
which are saved into a TEMP folder (those layers are created by Sextante if
the Sextante option "save as temporary file" is activated)

2) isModifiedLayer() == is FeatureCollectionModified

3) isVectorLayer() Defines all layer  excluding images (and datastores

4) isImageLayer() Defines all image loaded by Layer.class (hope so)

5) isMultipleImagesLayer() Defines a Layer with multiple image

6) isDataStoreLayer() should be defines all Datastore layers. I am not sure
about this part of the code

7) isSystemLayer() Defines layer like Fence and Measure, which should be
considered as "System" layers

8) isCadLayer() Something I test to work with DXF files, Only layers with
COLOR and TEXT attributes

9) isMixedGeometryTypes() Should check if the Layer has mixed geometry types

10) isEmpy() Should defines if the Layer has an empty feature collection

11) String getGeometryType(). returns the geometry types of the layer

12) String getFilePath() return the path of a Layer, eg.
C:/folder/file.shp. If the file is stored into a TEMP folder it returns a
warning message (see point 1)

for RasterImageLayers:

1) isTemporaryLayer() defines if RasterImageLayer file is stored into a
TEMP folder

12) String getFilePath() return the path of a Layer, eg.
C:/folder/file.tif. If the file is stored into a TEMP folder it returns a
warning message (see point 1)

waiting for your opinion

best regards

Peppe
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel