Alberto, I'm copying this message to Stefan, who heads up the administration and development of OpenJUMP.
However, I think I can express the OpenJUMP's interest in collaborating with the AdB-ToolBox development team. It sounds like you have been doing great work with OpenJUMP, and a couple of our Italian users speak very highly of the program. Having said that, I know our developer resources are very limited, and done on a volunteer basis. We've got Stefan, Larry Becker, Michael Michaud and a few others that contribute code. So, I think there is potential to work together on some changes to OJ needed to address some of the issues raised in your e-mail, as long as we are realistic in what we can accomplish. I am certainly interested in learning more about some of the functionality in the AdB-ToolBox that could be packaged as JUMP/OpenJUMP plug-ins. If you had a couple of specific tasks in mind to move collaboration forward, I encourage you to mention them here. I tihnk that would be a good way to get the discussion started. I've loaded the AdB-ToolBox source code in my SurveyOS SourceForge SVN, but I haven't had much time to look at it. If we can work together and share some programming burden, we should. The Sunburned Surveyor On Fri, Feb 5, 2010 at 3:21 AM, Alberto De Luca <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
