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 <sst...@geo.uzh.ch> 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&iu=/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&iu=/4140
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
