Many response to my last request and mainly sent directly to my email.
I will answer via mailing list so that I'm sure not to forget anybody.
Simone Giannecchini gave me some pointers where you're plans were discussed. The plans to support multidimensional Coverages with these dimensions covering the spectral domain and the time domain is something we like to see, too. The time domain is more important to us but a general solution might not make any difference between the nature of the dimensions. So implementing a generic model sounds good to me.
Other points we like to see is the storages of coverages in a database and a more elegant way to tell geoserver about them. I dream of simply inserting a new coverage in the database and the next time I query geoserver it will know about my updates without the need of a restart or the call of some URLs. (Ok, ok, I'm aware of the impact on performance with that. But maybe we can find a reasonable compromise).
I agree with Bryce Nordgren, that the fundament of these changes should be laid in geotools but we need the funcionality in geoserver. All changes in geotools aren't worth the effort if they are not used to their full extend in geoserver. So I started the discussion here.
What I learned from your answers is that our goals are widely identical to ours and that it makes sense to discuss details. I also learned that most (nearly all) things we like to see are already in the discussion.
What we would like to add is some kind of dictionary to the new Gridcoverage so that geotools (by the means of the proper plugin) can find out about
available coverages.
Gerhard Dünnebeil
Tel: 050550 - 3173
Gerhard.Duennebeil@anonymised.com
www.arcs.ac.at
I agree with Bryce Nordgren, that the fundament of these changes should be laid in geotools but we need the funcionality in geoserver. All changes in geotools aren't worth the effort if they are not used to their full extend in geoserver. So I started the discussion here.
Hi Gerhard - uDIG is also working on raster support with you guys. We are looking into OSSIM right now, so the more work we share at the Geotools level the more developers you get to work and test.
What I learned from your answers is that our goals are widely identical to ours and that it makes sense to discuss details. I also learned that most (nearly all) things we like to see are already in the discussion.
What we would like to add is some kind of dictionary to the new Gridcoverage so that geotools (by the means of the proper plugin) can find out about available coverages.
That should be covered by the GridCoverageExchange API right now, although I confess nobody is very fond of it. It had discovery support by way of a Catalog interface for a while (to list the files in a directory), you may also be thinking about the available GridCoverages in a single file - in which case a GridCoverageReader gets the job done.
Hi Gerhard,
my suggestions can be summarised in the following items:
1>Sign up for the GeoTools wiki and add your needs to the pages where
I pointed you yesterday. You should also add a page where you describe
what you would like to do with coverages in DB (that sounds very
interesting to me....).
2>Attend next GridCoverage IRC which we should hold shortly since, as
Bryce said, the last one was held like 3 weeks ago. That will provide
the occasion to coordinate our efforts in order to be more efficient.
Simone.
On 8/19/05, Dünnebeil Gerhard <Gerhard.Duennebeil@anonymised.com> wrote:
Hello everyone.
Many response to my last request and mainly sent directly to my email.
I will answer via mailing list so that I'm sure not to forget anybody.
Simone Giannecchini gave me some pointers where you're plans were >discussed. The plans to support multidimensional Coverages with these dimensions covering the spectral domain and the time domain is something we like to see, too. The time domain is more important to us but a general solution might not make any difference between the nature of the dimensions. So implementing a generic model sounds good to me.
Other points we like to see is the storages of coverages in a database and a more elegant way to tell geoserver about them. I dream of simply inserting a new coverage in the database and the next time I query geoserver it will know about my updates without the need of a restart or the call of some URLs. (Ok, ok, I'm aware of the impact on performance with that. But maybe we can find a reasonable compromise).
I agree with Bryce Nordgren, that the fundament of these changes should be laid in geotools but we need the funcionality in geoserver. All changes in geotools aren't worth the effort if they are not used to their full extend in geoserver. So I started the discussion here.
What I learned from your answers is that our goals are widely identical to ours and that it makes sense to discuss details. I also learned that most (nearly all) things we like to see are already in the discussion.
What we would like to add is some kind of dictionary to the new Gridcoverage so that geotools (by the means of the proper plugin) can find out about
available coverages.
Gerhard Dünnebeil
Tel: 050550 - 3173
Gerhard.Duennebeil@anonymised.com
www.arcs.ac.at
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel