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