>
> once the raster
> is loaded, and "translated" into an RGB image to be shown in AdB, it
> loses the actual pixel data information (it's just an RGB image). We
> think that a step forward would be to load the raster values into an
> array to be kept in memory, whose values could be used by any plug in or
> tool that needs them.
>
I think it would be possible to create an adapter class that uses the
existing layer dataset drivers to return an accessible data structure of
that layer's pixels, probably in a buffered image.
regards,
Larry
On Fri, Feb 5, 2010 at 5:21 AM, Alberto De Luca
<i...@geomaticaeambiente.it>wrote:
> Hello everyone.
>
> As a member of the team who has been working on AdB-ToolBox in the last
> months, I'd like to address a couple of issues regarding its future
> developments: internationalization, raster management and platform
> independence. By the way, AdB-ToolBox is a piece of software, part of
> the JUMP family, whose development was originally funded by the Italian
> ministry for the environment. Their goal was to expand OpenJUMP
> features, by adding raster handling capabilities and tools specialized
> for hydrological and geomorphological analysis.
>
> First of all: internationalization. We are aware that the Italian-only
> interface of AdB-ToolBox has been annoying for some of you.
> Unfortunately, due to limited resources, we couldn't afford to add
> international support in the first instance. Nevertheless, we plan to
> translate interfaces to English in the near future.
>
> Second: raster management. AdB-ToolBox can open and visualize several
> raster formats (ASCII grid, ESRI grid, ESRI floating point grid), but
> the various plug ins only accept the ESRI floating point grid as their
> input (and output) format. This was quite convenient from a developer's
> perspective, but not as good from a user's perspective. Ideally, every
> plug in needing a raster layer among its inputs, should be able to use
> every raster format that OJ can open and visualize. In other terms, the
> reading capability should be part of OJ only and, once opened, a raster
> should be passed to the plug ins as an object (just like now we can pass
> an instance of the Layer class). Presently, every plug in that needs a
> raster as an input, has to reload it from scratch, regardless the raster
> being already loaded in AdB. This is a limit of the current
> implementation of the class managing the raster layers: once the raster
> is loaded, and "translated" into an RGB image to be shown in AdB, it
> loses the actual pixel data information (it's just an RGB image). We
> think that a step forward would be to load the raster values into an
> array to be kept in memory, whose values could be used by any plug in or
> tool that needs them.
> In any case, raster support cannot be an independent plug in, but must
> be made part of OJ, so that raster layers can be managed inside projects
> and queried with the standard "info tool".
>
> Third: platform independence. Many of the AdB-ToolBox plug ins still
> need DLLs. But their number is decreasing over time, as we gradually
> port parts of software from Fortran to Java. Presently (AdB-ToolBox
> version 1.6), there are already 2 (out of 5) AdB-ToolBox extensions that
> are DLL-free, one dedicated to topographic analyses (contour lines and
> sections extraction...) and the other including some raster tools (a
> raster calculator, zonal statistics, and many others). We plan to keep
> porting code to Java, but some plug ins (the ones that are too specific
> or too complex) will be left out, due to resources limitations.
>
> Now, I think the raster management issue is probably the one needing
> more attention, planning, discussion, and collaboration!
>
> Thanks for your your interest in AdB-ToolBox
> Alberto
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the
> business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Larry Becker
Integrated Systems Analysts, Inc.
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
