On Mon, 2008-09-15 at 10:01 +0200, Simone Giannecchini wrote:
> Just a quick clarification about the CoverageCrop.
> There is nothing mysterious about such operation (at least for a poor
> enthusiastic developer like me).
> Such operations tries to crop a Coverage given a 2d envelope. It uses
> either the JAI crop or the JAI mosaic in case the latter is mroe
> convenient. This may happen in case the Grid-to-World transform is not
> a simple scale and translate in which case cropping an envelope does
> not means cropping rectangle in the raster world, therefore it might
> be convenient using a ROI approach like Mosaic allows.
> This operation for the moment allows us to work only in a 2d space, in
> the near future I would probably either extend it to be more generic
> or make it fallback on the resample operation.
So was I right to guess that the operation is going down to the JAI
level to do its work rather than trying to do the crop itself? That
seemed to me the thrust of Michael Bedward's question.
>
> About the processor it uses, this is just an implementation detail,
> which is inherited from the other GridCoverage operations that allows
> you to either use the default JAI instance or a specific one as
> provided. Therefore if this is misterious I would assume that also the
> other operations are misterious (or probably that depends on who
> implemented them?).
I didn't understand the example which is why it was mysterious. As
Michael Bedward just let slip in the question he asked, there is a whole
parallel system based on 'DefaultProcessor' which Martin had nicely
hidden from me since it is more complex than the 'Operations.DEFAULT'
system and too hard for my naive brain. Now, I have learned that this
parallel system exists.
In our docs, this is the first introduction of this whole parallel
system so we will need to explain it.
--adrian
>
> Personal Note.
> I believe that a "real" scientist (which I am not, I am a poor
> engineer) should be always rigorous,
"Real" or "good" or "the ones who get the jobs" are very different
beasts, all with their own advantages and constraints. Natural
philosophers are a different beast, people who are infinitely interested
in learning, no matter from whom, no matter where, and no matter the
subject. Anyone can be such a scientist but few actually are. So far the
best indicator I have for the latter kind of scientist is that they are
the ones able to say 'I don't know'.
As for rigour, perhaps you are confusing the 'rigour' required of the
scientific statement with the advice given in any given craft. You are
right that scientific statements should be accurate above all else. Wiki
advice however is generally shared on a 'best effort' basis.
> therefore he should not dispensate advice on things he does nto
> understand entirely, unless he just wants to spread confusion around.
Yes, indeed, I do wait for the experts to write the docs. Then
eventually I realize that the experts are busy being experts and never
write the docs. Perhaps that's a good thing, since the best thing the
experts can do is keep being experts and the docs should be written by
writers. This is why I'm writing the docs on a subject I know *nothing*
about---I've never so much as written a line of code that uses JAI!
Martin has explained the whole chain to me 4 times and this time I tried
to share the best of my understanding on the wiki.
Anyhow, the users are repeatedly asking for explanations on how this
whole coverage thing is supposed to work. So I finally updated the first
chapters. The questions which remain are:
* (1) did I understand the thing correctly and
* (2) did I write something comprehensible to outsiders?
So I'm hoping the experts tell me where I have made bad statements or
given bad advice and the new users tell me what they don't understand.
Does that work for you?
>
> Ciao,
> Simone.
>
> On Mon, Sep 15, 2008 at 9:43 AM, Adrian Custer <[EMAIL PROTECTED]>
> wrote:
> On Mon, 2008-09-15 at 13:14 +1000, Michael Bedward wrote:
> > This is great - thanks Adrian !
> >
> > I just had a very quick look and I've already learned
> something (that
> > I don't have to go down to JAI level to do a crop).
>
>
> Hmm, I'm not sure about that. That crop operation was floating
> around
> from earlier docs---it uses some mysterious 'processor' class
> which
> comes from somewhere I did not look for. If you find it, look
> at the
> code inside and see what it does. Either it goes down to the
> JAI level
> to do its work or it should, I suspect. JAI can undoubtedly
> crop more
> efficiently than we ever could.
>
>
> >
> > I'll read it properly later today and see if there's
> anything useful
> > that I can contribute to it. I've been working on some
> raster
> > algorithms recently (raster to vector, edge cell tracing,
> region
> > buffering...) some of which may be useful demos - though
> probably
> > after a lot of refactoring of my code :)
> >
> > cheers
> > Michael
> >
> > 2008/9/15 Adrian Custer <[EMAIL PROTECTED]>:
> > > Hey all,
> > >
> > > We had hoped to generate this documentation earlier in the
> summer but
> > > better late than ...
> > >
> > > The page http://docs.codehaus.org/display/GEOTDOC/08+Grid
> +Coverage
> > > and the first few subsections hold our first draft of an
> explanation of
> > > how the coverage module works at a programmatic level.
> Probably there is
> > > a lot still to explain---we just realized that we should
> have a "Why is
> > > this so complicated?" section---and we hope to have more
> examples,
> > > possibly demo code of some sort.
> > >
> > > Anyhow, if anyone is playing around with some interesting
> GridCoverage
> > > format and feels like trying to decipher our explanations,
> feedback,
> > > comments, or edits are welcome.
> > >
> > > cheers,
> > > --adrian
> > >
> > >
> > >
>
> -------------------------------------------------------------------------
> > > This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> > > Build the coolest Linux based applications with Moblin SDK
> & win great prizes
> > > Grand prize is a trip for two to an Open Source event
> anywhere in the world
> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > _______________________________________________
> > > Geotools-devel mailing list
> > > Geotools-devel@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> > >
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK &
> win great prizes
> Grand prize is a trip for two to an Open Source event anywhere
> in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
>
>
> --
> -------------------------------------------------------
> Eng. Simone Giannecchini
> GeoSolutions S.A.S.
> Owner - Software Engineer
> Via Carignoni 51
> 55041 Camaiore (LU)
> Italy
>
> phone: +39 0584983027
> fax: +39 0584983027
> mob: +39 333 8128928
>
>
> http://www.geo-solutions.it
> http://www.geo-solutions.it/simone.giannecchini
>
> -------------------------------------------------------
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
