Andrea Antonello wrote:
Hi Chris,
find inline my comments.
(moving this to the devel list)
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.
It's basically just rasters, but I think can additionally can have
multiple dimensions. It's not my area of expertise.
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.
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.
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.
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+Grid
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.
Cool.
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.
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. 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.
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 :)).
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.
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"?
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 ;)
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... :)
No worries. We leverage them in the thought that a lot of smart people
have thought about how to model things, and we just have to figure out
how to translate them in to Java. To some extent you've done the same
with GRASS. If you want an in-depth education on the issues around
geotools, geoapi and coverage specs, see:
http://docs.codehaus.org/download/attachments/31212/ISO19123+Primer.pdf?version=5
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.
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.
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
--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
