Hi Chris, find inline my comments. > This is great!
Thank you! :) > The ideal thing to do would to make it a full geotools coverager reader, > so that it fits in to our APIs - it would be the same for the programmer > to work with geotiff, grib, or grass binary, and would then be available > for display through uDig and GeoServer. 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. We are starting the third year of JGrass now and we have always dealth with raster analysis. Raster analysis needs straight data manipulation, which I couldn't find in the coverage api. As I said, I had not enough time to spend on it, but I would be glad to be corrected now. > If you're interested in learning geotools more that would be great, or > what we could do is start a grass module, and await a future volunteer > to put it in to the api, while also allowing anyone to make use of the > reader. We have our reader interfaces, but we are going towards lots of architecture changes for the jgrass3 version, so probably (not soon, but at some point) we will study the geotools api for coverage. If an adaption is found, I will be glad to maintain the package. > I'm interested in learning more about JGrass, as it seems like there > could be some more overlap, less replication of work. That would be absolutely great. > It looks like JGrass is pure java, is that right? So it's sort of a > complete re-write of Grass? To have similar functionality, but written > for Java? Yes and no, we try to exploit everything that already is there in GRASS, therefore we started with JNI binding. Very soon that got a killing thing for the portability and we started to port the most important (in our eyes) parts, which included the raster I/O and some modules. The choice was in direction hydro-geomorphology, because the jobs done in that field supported the development. > What data formats do you read? This to me seems like the most sensible > area of overlap. GeoTools defines a very good feature model for > vectors, and we read in shapefile, postgis, oracle, db2, WFS, GML, > MySQL, and coming VPF and MapInfo. We just use the GRASS format natively. That's it (not including some ascii formats and raw data interpolation), we then use the GRASS gdal library, which offers a huge amount of formats towards GRASS. > We're still working on good raster > interfaces, based on some ISO spec (sorry, not my area of expertise), > and experimenting with some very nice speed improvements. So we could > perhaps work on the same set of data readers, or at least share > interfaces with GeoAPI (http://geoapi.sourceforge.net) and then be able > to use one another's readers. That is a thing that I would really like to get... standard interfaces that are tested and do not explode in my hands after some time. Which is basically what is happening from the moment we decided to use geotools for the vector management and at that point lots of adaption was made (that explains also future changes :)). > We're also hoping to eventually have an operations API, which I feel > like is where GRASS excels. It could be a big win if we collaborate on > that, as they could then be used in uDig, or in GeoServer as a WPS. What do you mean exactly by "operations API"? > It looks like you guys are GPL, so it would make sense to collaborate on > the interfaces, keep them in GeoTools/GeoAPI, and then keep your > algorithms and implementations in JGrass. Yes, absolutely, that would be great. I hope to soon be able to get some knowledge in the geoapi and standards field, which I now do not have... To discuss with developers at my actual knowledge in standards would be depressive. And yes, I feel kinda ashamed... :) > Just a few thoughts, but thanks a lot for taking the time to start > collaborations, it would be great if we can get more cross overs. Yes, I hope that will be possible. We are including more and more geotools tools and that makes us know and understand the various interfaces and programming logic, I think at some point we will be able to think following your flowdirection. 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-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
