Hei all, I actually asked a couple of months ago if other people would accept if I commit the basic Raster classes used in Sextante. There was not much exitement/repsonse ;) However, I still think it would be a good idea, so we could with low efforts use/adapt Sextante raster functions. So far Sextante uses the Pirol Image plugin which is based on a buffered image. As my current interest is on raster analysis I am open for that.
So Alberto: Would the Sextante interface/classes work for you too? If you want I could make a new OpenJUMP branch so you can check what I have copied over [by now all is local]. Unfortunately I am not a good programmer nor exprienced designer, but I found the raster implementation used in Sextante quite interesting as it allows easy access and manipulation of rasters. However, some display stuff on OJ's side need improvement (i.e. a grey code look-up-table) And yes, I also wished I could see what pixel has what value - so I programmed a plugin which generates a vector grid out of the raster. However, Erwan programmed once a cursor tool which can display pixel values (I think the sources are in the OrbisGIS repository for the ASCII grid reader). so let me know if you think that we should build on the Sextante design as well (also with respect to all their algorithms). stefan Larry Becker schrieb: > 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 ------------------------------------------------------------------------------ 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
