Andrea Antonello wrote:
Thank you! :)
Indeed!
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.
Is JGrass available as a library that I could place into uDig? We are
limping with geotools coverage support
right now (all the cool kids are on a branch fixing it, for an update
see the last IRC logs on the geotools
website). We are also working with OSSIM, in a manner similar to you -
JNI bindings.
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.
You may do better to look at what simboss is doing right now based on
ISO specs. There are a couple pdfs you can
read as well.
For my purposes we can use your APIs directly in uDig (at least based on
documentation :-) ), however some of it comes down
to ability to communicate the current projection to you - using WKT, or
through the standard GeoAPI interface of the same.
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.
Sweet.
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 :)).
Indeed, I am looking forward to being through this. However next time
please give us feedback - we are only so many
minds and any holes you find would be great to point out. If you are
interested the improvements are available for reivew,
although I have not yet added operation support.
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"?
Think chaining processing together as is done with Feature Manipulation
Engine, or Java Advanced Imaging or OSSIM (or Web Processing Service).
He was not talking about an opperation used to define a coverage if that
was what you were worried about.
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... :)
GPL? We would need to mark any plugin that used JGrass as GPL then, and
have a separate click through.
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.
Looking forward to it.
Jody
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
-------------------------------------------------------
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
