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
