> > That was my first thought some time ago. So I tried for a while the > > coverage api for getiff reading and I couldn't get a matrix of values > > just for working with them. I couldn't understand exactly the meaning of > > the coverages, but to be honest I also couldn't spend lot's of time on > > it. > > It's basically just rasters, but I think can additionally can have > multiple dimensions. It's not my area of expertise.
Multiple dimensions in the sense of voxels? > Yeah, our coverage API is just coming to maturity. And I think it still > does not do much raster analysis at all. We're working on data loading > and rendering first, and sticking it all behind standards based > interfaces. So this actually sounds like an area where our communities > can learn a lot from one another. Yes, that is very important to share. For example with very large datasets (which are more and more common today) we are going to have problems because of to high amount of memory requests. Most geomorphologic modules are iterative and recursive and since you never know what the dem looks like, it is difficult to keep only small pieces of the raster in memory. I don't know if I was able to explain myself. An example: to create a map of the total contribution area (the area that drains water in every pixel) you have to follow the flowdirections of the elevation model. In every pixel the algorythm look for the next pixel, which means that this could go diagonal throught the data matrix, i.e. I can't just read row by row and evaluate. We are moving towards tiled and indexed reading. The idea from which we will start is the following, http://www.llnl.gov/graphics/ROAM/roam.pdf, but we are not sure that there will be resources enough. In the next half year the feasibility study will be there and we will see. > Great! We're still working on the coverage api, you can see progress > and lots of information at: > http://docs.codehaus.org/display/GEOTOOLS/Multidimensional+Georegistered+Gr >id I will keep uptodate with this. > Gotcha. Yeah, this is an area where I think you could gain a lot, since > GeoTools is platform independant. This is probably a bit of a longer > term goal, but basically it seems like you've focused on raster > manipulation with rasters, while we've been doing the loading and > rendering. Yes, exactly, and we have yet some problems in rendering and loading :) > And it sounds like if we're to get the grass stuff behind > coverages, we then could offer our users GDAL access with your JNI code, > which would be a great win as well. Perhaps I didn't explain myself properly. We stopped the JNI part because of it's non portability. We ported some parts and for some others we just created the java GUIs and execute them through Runtime execs. > Excellent, good to hear you're leveraging GeoTools for vectors, as > that's where we're strongest. Our raster stuff is younger, but coming > on quite strong right now, so you're catching up with a good time. It > would actually be great to have you try out the interfaces while they're > still young, in case we're missing any obvious requirements. Alright, I hope Simboss will give me some starting help and I will try my best. > Basically what GRASS does super well. An operation being something that > changes the data in some way. So all the things you do with GRASS we > would call 'operations'. What we need is an API that allows you > flexibly define how you are going to take some piece of geographical > information in and do something with it. If done right, we could use > GeoTools models, vector and raster, and operate on them with the > 'operations api', which could hide GRASS internals. So if GRASS was > available through JNI, our API could allow one to use the API on any > piece of GeoTools. > > This may expose my low knowledge of GRASS and how it works, but > basically we have no real good way of taking a piece of information in, > and doing something to change it, which is what GRASS does really well. > Which is why our communities could learn a lot from one another - > though we need to get talking the same language first ;) Absolutely! > Excellent. When our developers start getting to raster processing I'll > start pointing them at JGRASS as well, and perhaps we'll even be able to > really unite the toolkits at some point. I will now follow the devel list, so I should be able to contribute when the time comes. Best regards, Andrea > > best regards, > > Chris > > > My warmest regards, > > Andrea > > > >>best regards, > >> > >>Chris > >> > >>Andrea Antonello wrote: > >>>Hi folks, > >>>I could finally force myself to extract the GRASS binary reader from the > >>>JGrass code and make a small standalone versione, cleaning up all the > >>>JGrass dependent code. > >>> > >>>I would really love to see that added to the geotools package at some > >>>point, since the GRASS raster binary format is a highly important format > >>>because of the importance of GRASS. > >>> > >>>In the attched zip you can find the base classes reduced to the bone and > >>>a TestGrassRasterReader class to see how it works. > >>>The class reads a raster map and writes it to ascii. The steps should be > >>>clear. I also tried to document as well as possible the various steps. I > >>>hope you will enjoy it. > >>> > >>>My best regards and my contribution to this important osgeo community, > >>>Many thanks > >>>Andrea -- ____________________________________________________________________________ HydroloGIS - Environmental Safety Modelling www.hydrologis.com Andrea Antonello Environmental Engineer mobile: +393288497722 "Let it be as much a great honour to take as to give learning, if you want to be called wise." Skuggsja' - The King's mirror - 1240 Reykjavik ____________________________________________________________________________ ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
