HI guys, please, see my thoughts, inlined below....
On 2/13/06, Bryce L Nordgren <bnordgren@anonymised.com> wrote:
Martin wrote:
> Following Jody email
>
> But I currently get a change for every files, because of some changes
> like the addition of $URL$ keyword. Can we do one of the following (when
> Simone or Bryce would have a little bit of time of course)?My current understanding was in a previous email to Jody: currently, I
think that branch contains Simone's and Alessio's changes which were
required to make a Geoserver/WCS. Some fixes to various GCE plugins, etc.
It should shortly contain a 19123 implementation as well.> 1) Just explain (in plain text) where are the main changes applied
> on coverages in coverage_branchFor details, Simone's the one to talk to.
The branch we made contains:
1>Improved version of the old plugin with special attention to image,
geotiff (reader and writer) and gtopo. A plugn for grib files edition
1 is also present. I worked a lot on a better integration with JAI and
its caching mechanism.
A lot of time has been spent in order to remove the assumption that
WGS84 is lon,lat, which might seem stupid, but causes to us a lot of
problems.
2> Possibility to set the description of a sample dimension of a coverage
3>first improvements of the grid coverage renderer
4>an experimental plugin to read (and soon write) ascii grids using
ImageIO directly. This plugin is based on the ImageIO transcoding
framework allowing us to use it directly from JAI. Perfomances are
unbelievably better than before (try it, it is under spike). right now
we are working on returning an extensive set of metadata taken from
ISO19115 using IIOMetadataFormat from JAI but we still need one or two
weeks to work.
What we aim to do in less than a month:
2>Coverage caching and overview.
3>Coverage disposition and interaction with JAI tile cache.
4>Finish the experiment with the ImageIO plugin so anybody can take a
look and we can start talking about such an approach.
As Bryce pointed out, this work is made in conjunction with a new
release of the WCS branch in geoserver.
Aside from this, another guy is working with me in order to implement
ISO 19123. He spent a couple of months trying to understand all the
various specifications for coverages. Right noe he is working on a
document which will propose a unified well-accepted version of the
ISO19123 interfaces (as Martin already pointed out).
> 2) Synchronize the coverage_branch with the trunk (using "svn merge"
> from trunk to the branch) so the above-cited "svn diff" command
> can get less verbose.
Actually I have been doing that for a while but after the last bug
change that Martin made to trunk I have not been able to perform the
merge anymore. I have to confess that svn has been a pain since the
day we started the branch. Tomorrow I will try again to merge again,
in case I do not succedd a bit of help would be greatly appreciated.
I'd like to think we've been doing that. At least we started out doing
that. Certainly we should synchronize before starting the 19123
implementation, so we have a nice clean baseline. Actually, we should
probably make a "tag" for the last pre-implementation config, so we can
always get back something that compiles.
Agree
> Also, I would like a road map for merging coverages_branch to trunk.
>
> What do you think?I think I'll produce a road map before we merge to trunk.
However, I
think I'll be breaking the task at hand down into Implementation Work Units
(IWUs) this week. As IWUs are produced, they will be formed into Jira
tasks with the proper dependencies on existing, broad tasks ("Implement
Coverage Objects") At this point, they may be taken by anyone, but will
probably be taken by someone out of NURC or Firelab, as we are the most
motivated. When these are all done, with test cases, and they work, and
NURC's ready to make a Geoserver/WCS release against it, we'll _start_
thinking about how to merge to trunk.
I think we need another week before being able to lay down a decent
plan since I am tired of making promises I cannot respect due to
contingency therefore. Baseline is merge with trunk and have someone
from pmc (martin, jody) taking a look a the branch (with me giving
more details if requested).
Does that sound good?
Simone.
In short, for the _main implementation effort_, you're going to have #1
(above) before we generate any code at all.Bryce
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel