Hi all,
I was hoping to get an update to where the coverage branch is at.
Perhaps someone can show up at todays IRC meeting with an update?
Back before we branches 1.6.x we said that while we got trunk stable
onto geotools trunk the coverage branch would experiment, and then join
us on trunk. Is that still a workable plan?
-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Hi all,
very quickly summarizing, what we have done on GeoServer 1.6.x-nD branch until now is:
Adding real ND capabilities by using our new ImageIO ND plugins. At this time we have ported the old Grib1 plugin to the new ND Framework, soon we will port also the others.
If GeoServer recognizes a CoverageStore which is based on the new GeoTools ND Plugin, it will create many Coverages as contained in the store, and also it is now able to handle also the temporal and vertical extent, both on WCS and WMS.
Adding a real RasterSymbolizer support, which is able to apply different kind of Color-Maps and operations to the rasters.
The new RasterSymbolizer, mainly reviewed and modified by Simone Giannecchini, can now apply to the Covreage to be rendered different kind of real ColorMaps, like ramps and intervals, i.e. it is able to apply colors to the Coverage values and create a nice portrayal as specified by the user. Moreover it can also perform several operations like histogram, shaded-relief, gamma, contrast and more.
Testing new raster format plugins, like ECW, MrSID, HDF-APS.
Actually we are working on adding watermarking capabilities to GeoServer WMS, and next to create nice overlay legends on WMS layers.
On Dec 11, 2007 3:13 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
I was hoping to get an update to where the coverage branch is at.
Perhaps someone can show up at todays IRC meeting with an update?Back before we branches 1.6.x we said that while we got trunk stable
onto geotools trunk the coverage branch would experiment, and then join
us on trunk. Is that still a workable plan?-Justin
–
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It’s the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
Thanks for the update Alessio! It sounds like you guys are making great
progress.
So about you guys moving to trunk? Any word on that?
-Justin
Alessio Fabiani wrote:
Hi all,
very quickly summarizing, what we have done on GeoServer 1.6.x-nD branch
until now is:1. Adding real ND capabilities by using our new ImageIO ND plugins. At
this time we have ported the old Grib1 plugin to the new ND Framework,
soon we will port also the others.
If GeoServer recognizes a CoverageStore which is based on the new
GeoTools ND Plugin, it will create many Coverages as contained in the
store, and also it is now able to handle also the temporal and vertical
extent, both on WCS and WMS.2. Adding a real RasterSymbolizer support, which is able to apply
different kind of Color-Maps and operations to the rasters.
The new RasterSymbolizer, mainly reviewed and modified by Simone
Giannecchini, can now apply to the Covreage to be rendered different
kind of real ColorMaps, like ramps and intervals, i.e. it is able to
apply colors to the Coverage values and create a nice portrayal as
specified by the user. Moreover it can also perform several operations
like histogram, shaded-relief, gamma, contrast and more.3. Testing new raster format plugins, like ECW, MrSID, HDF-APS.
Actually we are working on adding watermarking capabilities to GeoServer
WMS, and next to create nice overlay legends on WMS layers.On Dec 11, 2007 3:13 PM, Justin Deoliveira <jdeolive@anonymised.com
<mailto:jdeolive@anonymised.com>> wrote:Hi all,
I was hoping to get an update to where the coverage branch is at.
Perhaps someone can show up at todays IRC meeting with an update?Back before we branches 1.6.x we said that while we got trunk stable
onto geotools trunk the coverage branch would experiment, and then join
us on trunk. Is that still a workable plan?-Justin
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
<mailto:Geoserver-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
<https://lists.sourceforge.net/lists/listinfo/geoserver-devel>--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italyphone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000-------------------------------------------------------
!DSPAM:4007,475fa807272611336712104!------------------------------------------------------------------------
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php!DSPAM:4007,475fa807272611336712104!
------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,475fa807272611336712104!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
After the creation of the nD experimental branch a while ago, we commited a
little bit of work, then the branch took a direction that was incompatible with
our work, so we hold-on any work on that branch.
For now we are doing our work on geotools and seagis project only (which has
"real" nD coverage support as well since 2003 but it was not a web service until
recently), developping a mini-WMS/WCS there. The reason is that we tried very
hard to make it work with geoserver for many months, but realized that acheiving
our goals would require consequent changes to AbstractGridCoverage2DReader
design and Geoserver configuration interface. Now, time constraint (we are bound
by contract to finish before the end of 2007) is so hard that we have to act in
emergency and the path of less resistence has been to write a mini-WMS/WCS (only
for rasters served by the postgrid database, nothing else) from scratch. With
this approach, if any of the strange behaviors that we observed with Geoserver
(images that mysteriously disapear for some WIDTH and HEIGHT parameter value,
unability to performs some reprojections, etc.) are still there, at least I will
be sure that the bug is our and we known where to debug. This approach work well
in this case because the WMS layer is very tin - geotools and seagis already do
most of the work we need. Less than 2 weeks have been enough for getting a
working mini-WMS. See that as a useful debugging tools allowing us to focus our
debugging on postgrid code.
On a historical note, the seagis project has been the home of referencing and
coverage module before the code moved to geotools in 2002. The same could happen
here for this nD stuff, depending on community wish. But a review of Geotools
Coverage I/O code is necessary before we get there (I still have missed time so
far for doing that). I want to focus on code quality (or what seems "quality"
from my point of view - I may be wrong). To me, a nD-Coverage is "real" only
when associated with a CoordinateReferenceSystem having that amount of
dimensions and when capable to interpolate over all those dimensions. I'm doing
that since 2003 in postgrid (and more that you have not yet seen), but not as a
web service.
Alessio Fabiani a écrit :
If GeoServer recognizes a CoverageStore which is based on the new
GeoTools ND Plugin, it will create many Coverages as contained in the
store, and also it is now able to handle also the temporal and vertical
extent, both on WCS and WMS.
Is this CoverageStore defined on the 2.4 branch? I don't see it on GeoTools trunk.
Martin
Martin Desruisseaux wrote:
After the creation of the nD experimental branch a while ago, we commited a
little bit of work, then the branch took a direction that was incompatible with
our work, so we hold-on any work on that branch.our goals would require consequent changes to AbstractGridCoverage2DReader
design and Geoserver configuration interface.
I tried to engage the community on a CoverageStore api last year at this time had did not get any review (other than shock
when it was removed from trunk due to lack of feedback).
The GeoTools configuration stack is holding up a lot of work it is true; but I did not know it was causing efforts to fragment.
Now, time constraint (we are bound by contract to finish before the end of 2007)
is so hard that we have to act in emergency and the path of less resistence
has been to write a mini-WMS/WCS
So we are out of time and it is too late to do anything?
If GeoServer recognizes a CoverageStore which is based on the new
GeoTools ND Plugin, it will create many Coverages as contained in the
store, and also it is now able to handle also the temporal and vertical
extent, both on WCS and WMS.
Is this CoverageStore defined on the 2.4 branch? I don't see it on GeoTools trunk.
I removed the code from trunk as it had no implementation to speak of and had not received any feedback.
Martin if you know what you want / need can you make a list so we can at least revise the proposal for
when you (or anyone) gets a chance to work on it for GeoTools.
Jody
Martin Desruisseaux ha scritto:
After the creation of the nD experimental branch a while ago, we commited a
little bit of work, then the branch took a direction that was incompatible with
our work, so we hold-on any work on that branch.For now we are doing our work on geotools and seagis project only (which has
"real" nD coverage support as well since 2003 but it was not a web service until
recently), developping a mini-WMS/WCS there. The reason is that we tried very
hard to make it work with geoserver for many months, but realized that acheiving
our goals would require consequent changes to AbstractGridCoverage2DReader
design and Geoserver configuration interface.
Ah, this is really bad from our own perspective, since I was looking forward to have nd coverage support in GeoServer.
Well, since it's clear we won't have it soon, allow me to try and salvage what still can be rescued.
For AbstractGridCoverage2DReader, it would be nice to know exactly what's not working for you and eventually fix it on trunk.
For the GeoServer configuration interface, again, it would be interesting to know what you were looking for so that the next config
and UI effort will take it into consideration.
Now, time constraint (we are bound
by contract to finish before the end of 2007) is so hard that we have to act in
emergency and the path of less resistence has been to write a mini-WMS/WCS (only
for rasters served by the postgrid database, nothing else) from scratch. With
this approach, if any of the strange behaviors that we observed with Geoserver
(images that mysteriously disapear for some WIDTH and HEIGHT parameter value,
unability to performs some reprojections, etc.)
Anything reproducable that could be reported, analyzed and fixed?
are still there, at least I will
be sure that the bug is our and we known where to debug. This approach work well
in this case because the WMS layer is very tin - geotools and seagis already do
most of the work we need. Less than 2 weeks have been enough for getting a
working mini-WMS. See that as a useful debugging tools allowing us to focus our
debugging on postgrid code.On a historical note, the seagis project has been the home of referencing and
coverage module before the code moved to geotools in 2002. The same could happen
here for this nD stuff, depending on community wish. But a review of Geotools
Coverage I/O code is necessary before we get there (I still have missed time so
far for doing that). I want to focus on code quality (or what seems "quality"
from my point of view - I may be wrong). To me, a nD-Coverage is "real" only
when associated with a CoordinateReferenceSystem having that amount of
dimensions and when capable to interpolate over all those dimensions. I'm doing
that since 2003 in postgrid (and more that you have not yet seen), but not as a
web service.
We need to struck a middle ground here too. My personal opinion on this matter is that we miss the equivalent of DataStore for the coverage land. We already see various cases of entities that could be see as black box holder of coverages:
* a plain directory filled with coverage data in various formats
* a single complex file such as the netcdf or the hdf ones
* postgrid
* a remote WCS server (that is, if we're ever going to have a client
to talk with them)
* ArcSDE grids
* Oracle grids
A CoverageStore could be modelled against the WCS service interfaces the
same way we modelled DataStore against the WFS datastore interfaces.
Any interest in doing a common work in this direction, anyone?
Cheers
Andrea
Andrea Aime wrote:
We need to struck a middle ground here too. My personal opinion on this matter is that we miss the equivalent of DataStore for the coverage land. We already see various cases of entities that could be see as black box holder of coverages:
* a plain directory filled with coverage data in various formats
* a single complex file such as the netcdf or the hdf ones
* postgrid
* a remote WCS server (that is, if we're ever going to have a client
to talk with them)
* ArcSDE grids
* Oracle gridsA CoverageStore could be modelled against the WCS service interfaces the
same way we modelled DataStore against the WFS datastore interfaces.
Any interest in doing a common work in this direction, anyone?
I like that by way of direction for two reasons:
a) we know it will work for the geoserver case
b) we have documentation and definitions to fall back on so we don't waste a lot of time arguing back and forth
Indeed I find it favorable to the approach taken last year of extracting the useful bits of DataStore into a DataAccess; and then subclassing for CoverageStore.
I can bang out an initial interface; if someone wants to make a sample implementation.
Cheers,
Jody
Hi Martin,
since we have basically the same needs, we also need to write a new AbstractGridCoverageReader and modify GeoServer interface, maybe I can help you to port your work on GeoServer/GeoTools and see how our codes, which are many similar on my feeling, can converge on a common shape.
I need at least some directives, documentation and access to the code of course.
On Dec 16, 2007 9:42 PM, Martin Desruisseaux <martin.desruisseaux@anonymised.com > wrote:
After the creation of the nD experimental branch a while ago, we commited a
little bit of work, then the branch took a direction that was incompatible with
our work, so we hold-on any work on that branch.For now we are doing our work on geotools and seagis project only (which has
“real” nD coverage support as well since 2003 but it was not a web service until
recently), developping a mini-WMS/WCS there. The reason is that we tried very
hard to make it work with geoserver for many months, but realized that acheiving
our goals would require consequent changes to AbstractGridCoverage2DReader
design and Geoserver configuration interface. Now, time constraint (we are bound
by contract to finish before the end of 2007) is so hard that we have to act in
emergency and the path of less resistence has been to write a mini-WMS/WCS (only
for rasters served by the postgrid database, nothing else) from scratch. With
this approach, if any of the strange behaviors that we observed with Geoserver
(images that mysteriously disapear for some WIDTH and HEIGHT parameter value,
unability to performs some reprojections, etc.) are still there, at least I will
be sure that the bug is our and we known where to debug. This approach work well
in this case because the WMS layer is very tin - geotools and seagis already do
most of the work we need. Less than 2 weeks have been enough for getting a
working mini-WMS. See that as a useful debugging tools allowing us to focus our
debugging on postgrid code.On a historical note, the seagis project has been the home of referencing and
coverage module before the code moved to geotools in 2002. The same could happen
here for this nD stuff, depending on community wish. But a review of Geotools
Coverage I/O code is necessary before we get there (I still have missed time so
far for doing that). I want to focus on code quality (or what seems “quality”
from my point of view - I may be wrong). To me, a nD-Coverage is “real” only
when associated with a CoordinateReferenceSystem having that amount of
dimensions and when capable to interpolate over all those dimensions. I’m doing
that since 2003 in postgrid (and more that you have not yet seen), but not as a
web service.Alessio Fabiani a écrit :
If GeoServer recognizes a CoverageStore which is based on the new
GeoTools ND Plugin, it will create many Coverages as contained in the
store, and also it is now able to handle also the temporal and vertical
extent, both on WCS and WMS.Is this CoverageStore defined on the 2.4 branch? I don’t see it on GeoTools trunk.
Martin
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
Andrea Aime a écrit :
For AbstractGridCoverage2DReader, it would be nice to know exactly
what's not working for you and eventually fix it on trunk.
My issues are:
Configuration interface expects a File input source
-------------------------------------------------------------
I'm not sure where the restriction come from, but we had to provide a dummy file
for every layer in order to get it working. GeoServer checks for file existence,
which make it impossible to use it if we don't give him a dummy file even if it
will be totally ignored by our code. It make configuration more tedious since
the client must browse through large data directory for nothing. Note:
AbstractGridCoverage2DReader has an ImageInputStream attribute, which is not
applicable to a database connection. It should be splitted in a really abstract
superclass, and have specialized subclasses working on ImageInputStream only
when wanted.
Needs an GridFormatFactorySpi instance for each layer
-------------------------------------------------------------
We were trapped in a "one GridFormatFactorySpi == one 'LAYER' parameter value"
relationship, partially because of the inability to pass a non-File input in the
configuration interface. This relationship is not applicable to a database where
a single GridFormat serves an arbitrary amount of layers. For every row added in
our "Layer" table in the database, we had to create a GridFormatFactorySpi
instance. In practice, it means that the client can not add any layer without
writting a new class and recompiling the code. I guess that we could have
avoided this constraint with some configuration interface work, but we though
that GeoServer configuration was scheduled for refactoring, so we prefer to wait
for this work to be done.
Attributes that should be part of decoding process
-------------------------------------------------------------
AbstractGridCoverage2DReader contains a lot of attributes that should be part of
the decoding process, not properties of a CoverageReader (e.g. crs, envelope,
coverage name, num overviews, raster2model, originalGridRange and more...). I
understand that they may be convenience during the decoding process, in which
case they should not be in the public API. Because those attributes are public
(protected actually), they looks like as if they had to be provided at
construction time. Actually experience suggest that AbstractGridFormat do not
work well in Geoserver if we don't provide at less the CRS and the Envelope near
the construction time. Of course we don't have this information at construction
time in practice.
Lack of encapsulation
-------------------------------------------------------------
AbstractGridCoverage2DReader and its friends (AbstractGridFormat, etc.) expose
totally and without any control all their internal working. The above-cited
attributes should be private so that the implementation can make sure that:
- They are cleared when the input source change.
- They are consistent (in current state, absolutly nothing garantee that
those attributes have the expected dimensions, chains consistently ("grid
range" --> "raster2model" --> "envelope" --> "crs"), etc.).
Current AbstractGridCoverage2DReader implementation do not applies encapsulation
principles, which increase the risk of bugs and reduce our ability to change the
code in the future without compatibility break. As a side note, we have heard of
users who abandonned GeoTools because the API is changing too much. The lack of
encapsulation in classes like AbstractGridCoverage2DReader increase our
exposition to this kind of situations.
Lack of javadoc
-------------------------------------------------------------
The Coverage I/O stuff has some mysteries and few javadoc explaining them. For
example why the "Crop" operation expects 2 envelopes? I would expect a Crop to
work with a single Envelope parameter value.
While reading some code, I feel like a geologist digging in the Earth's crust
and reading the Earth's history from the geologic layers. I had the feeling to
read a little bit of Class's history by seeing what looks like patchs applied
over patchs. For example CoverageUtilities.prepareSourceForOperation(...) had
many redundancies in its "if ... else" statements, testing again stuff that was
already tested differently before, maybe because some conditions were added at a
later stage without revisiting the big picture. I cleaned this little method on
trunk last week. My feeling (but I may be completly wrong) is that current
AbstractGridCoverage2DReader is in a similar situation.
For the GeoServer configuration interface, again, it would be
interesting to know what you were looking for so that the next config
and UI effort will take it into consideration.
The only thing we need is the parameter connection to a database and remove
everything else. No file to specify, no CRS and no Envelope to provide, no
format to select, not even any layer to declare - all this stuff is in the database.
The way to declare a layer is a little bit "CoverageFormat" specific. For
example in the case of postgrid, the user just need to push a "update this
layer" button. Postgrid will scan some known directories on the server, find any
new files he didn't know about before and update its database accordingly
(possibly asking some file-dependant question to the user).
So we need the ability to start from a blank sheet and put configuration options
that are totally different from what we would have for a classical 2D raster.
Anything reproducable that could be reported, analyzed and fixed?
As soon as the "WIDTH" and "HEIGHT" parameter values are smaller than the size
that the cropped image would have if it wasn't scaled, our image disaspear. I'm
not totally sure that the bug isn't ours, which is why we try our code through a
mini-WMS before to bother the mailing list.
My intuition is that some code somewhere performs a division using integer
arithmetic or some other arithmetic that round the result to zero when we should
have a fraction between 0 and 1.
As far as projection is concerned, a quick look in some code suggests that many
projection are performed back and forth, maybe more than necessary (but I need
more investigation to be sure). The result is that we get ProjectionException
for bounding box where some result should be possible. For example we are unable
to draw a Raster in Mercator projection over a world map in WGS84. I understand
that we can't project a WGS84 coordinates to Mercator if we are close to a pole,
but the converse should be possible - currently it is not. Again I need more
investigation on this issue, maybe fix some code in referencing and coverage module.
We need to struck a middle ground here too. My personal opinion on this
matter is that we miss the equivalent of DataStore for the coverage
land. We already see various cases of entities that could be see as
black box holder of coverages:
* a plain directory filled with coverage data in various formats
* a single complex file such as the netcdf or the hdf ones
* postgrid
* a remote WCS server (that is, if we're ever going to have a client
to talk with them)
* ArcSDE grids
* Oracle gridsA CoverageStore could be modelled against the WCS service interfaces the
same way we modelled DataStore against the WFS datastore interfaces.
Any interest in doing a common work in this direction, anyone?
I want to do that, it is on my schedule, but for now we are on a emergency mode.
For now it is scheduled for March to May 2008. But I known that a promized a
coverage I/O review for a very long time and delayed it for years...
Regards,
Martin
Martin Desruisseaux ha scritto:
Andrea Aime a écrit :
For AbstractGridCoverage2DReader, it would be nice to know exactly
what's not working for you and eventually fix it on trunk.My issues are:
Configuration interface expects a File input source
-------------------------------------------------------------
I'm not sure where the restriction come from, but we had to provide a dummy file
for every layer in order to get it working. GeoServer checks for file existence,
which make it impossible to use it if we don't give him a dummy file even if it
will be totally ignored by our code.
We added it because all of our coverage sources are file based and people kept on making mistakes on the location, so now we check that the file it's really there. Yet afaik we did remove this limitation for vector based data to allow WFS to be configured, if you spoke up we
could've done the same for coverage based data too (actually, don't know
if the check code is still there for coverages either, since ArcSDE uses
an URL that's not a file either)?
> It make configuration more tedious since
the client must browse through large data directory for nothing. Note:
AbstractGridCoverage2DReader has an ImageInputStream attribute, which is not
applicable to a database connection. It should be splitted in a really abstract
superclass, and have specialized subclasses working on ImageInputStream only
when wanted.
Yeah, fully agree.
Needs an GridFormatFactorySpi instance for each layer
-------------------------------------------------------------
We were trapped in a "one GridFormatFactorySpi == one 'LAYER' parameter value"
relationship, partially because of the inability to pass a non-File input in the
configuration interface. This relationship is not applicable to a database where
a single GridFormat serves an arbitrary amount of layers. For every row added in
our "Layer" table in the database, we had to create a GridFormatFactorySpi
instance. In practice, it means that the client can not add any layer without
writting a new class and recompiling the code. I guess that we could have
avoided this constraint with some configuration interface work, but we though
that GeoServer configuration was scheduled for refactoring, so we prefer to wait
for this work to be done.
That is something that could be addressed with a CoverageStore proposal, the same way we handle DataStore/FeatureType distinction.
Attributes that should be part of decoding process
-------------------------------------------------------------
AbstractGridCoverage2DReader contains a lot of attributes that should be part of
the decoding process, not properties of a CoverageReader (e.g. crs, envelope,
coverage name, num overviews, raster2model, originalGridRange and more...). I
understand that they may be convenience during the decoding process, in which
case they should not be in the public API. Because those attributes are public
(protected actually), they looks like as if they had to be provided at
construction time. Actually experience suggest that AbstractGridFormat do not
work well in Geoserver if we don't provide at less the CRS and the Envelope near
the construction time. Of course we don't have this information at construction
time in practice.
I wasn't aware of this. Not sure what needs to be done to fix it either...
Lack of encapsulation
-------------------------------------------------------------
AbstractGridCoverage2DReader and its friends (AbstractGridFormat, etc.) expose
totally and without any control all their internal working. The above-cited
attributes should be private so that the implementation can make sure that:- They are cleared when the input source change.
- They are consistent (in current state, absolutly nothing garantee that
those attributes have the expected dimensions, chains consistently ("grid
range" --> "raster2model" --> "envelope" --> "crs"), etc.).Current AbstractGridCoverage2DReader implementation do not applies encapsulation
principles, which increase the risk of bugs and reduce our ability to change the
code in the future without compatibility break. As a side note, we have heard of
users who abandonned GeoTools because the API is changing too much. The lack of
encapsulation in classes like AbstractGridCoverage2DReader increase our
exposition to this kind of situations.
Agreed.
Lack of javadoc
-------------------------------------------------------------
The Coverage I/O stuff has some mysteries and few javadoc explaining them. For
example why the "Crop" operation expects 2 envelopes? I would expect a Crop to
work with a single Envelope parameter value.While reading some code, I feel like a geologist digging in the Earth's crust
and reading the Earth's history from the geologic layers. I had the feeling to
read a little bit of Class's history by seeing what looks like patchs applied
over patchs. For example CoverageUtilities.prepareSourceForOperation(...) had
many redundancies in its "if ... else" statements, testing again stuff that was
already tested differently before, maybe because some conditions were added at a
later stage without revisiting the big picture. I cleaned this little method on
trunk last week. My feeling (but I may be completly wrong) is that current
AbstractGridCoverage2DReader is in a similar situation.
It may well be... I never had time to look into the sources of those
classes other than in a debugger walk.
For the GeoServer configuration interface, again, it would be
interesting to know what you were looking for so that the next config
and UI effort will take it into consideration.The only thing we need is the parameter connection to a database and remove
everything else. No file to specify, no CRS and no Envelope to provide, no
format to select, not even any layer to declare - all this stuff is in the database.The way to declare a layer is a little bit "CoverageFormat" specific. For
example in the case of postgrid, the user just need to push a "update this
layer" button. Postgrid will scan some known directories on the server, find any
new files he didn't know about before and update its database accordingly
(possibly asking some file-dependant question to the user).So we need the ability to start from a blank sheet and put configuration options
that are totally different from what we would have for a classical 2D raster.
Yes, DataStore/CoverageStore specific UI would be good. I full agree,
it's just that coding a UI for anything in GeoServer is way too hard now... sigh...
...
A CoverageStore could be modelled against the WCS service interfaces the
same way we modelled DataStore against the WFS datastore interfaces.
Any interest in doing a common work in this direction, anyone?I want to do that, it is on my schedule, but for now we are on a emergency mode.
For now it is scheduled for March to May 2008. But I known that a promized a
coverage I/O review for a very long time and delayed it for years...
I understand deadlines very well 
Maybe we can start talking about this in January? There are many people having a stake into this new interface
Cheers
Andrea
Hi Martin,
sorry to join the discussion so late but I was abroad working on
another project.
I don't think alessio used the word "real" to criticise work done by
cedric, but anyway we all know all the good work you guys have done in
the past and you are doing now, hence there is no need to expose
references to demonstrate your capabilities, unless you really feel
like everydoby should do so before talking. I would like to remind
you that we based our work on the work that you had started hence you
are targeting the wrong people here since we are basically the ones
who have always promoted the use of the GridCoverage module you
originally came up with. This also applies to this work alessio is
doing right now.
About the AbstractGridCoverage2DReader work, I already told more than
once that that work was done in a real hurry (something like 2 nights
back in 2006) to use overviews inside the geoserver and it does not
aim to be a proposal for a standard API or something like it. It just
tried to cope with things that were not working and to show that we
*could* use the GridCoverage package inside the GeoServer to server
high res imagery in a performant way. As you know (but also Jody,
Aaime, etc..) I have always been keen to replace this work with
something more stable and agreed by everybody but it is not something
that can be done overnight and since I don't like the fact that
GeoTools changes interfaces too quickly I wont make any changes before
we have something we are all happy with. Therefore, if you don't like
something try to make a proposal and ask people what they think. I can
ensure I will take time to provide feedback, I am sure Jody will do
the same and probably Aaime and Justin as well. I have done some work
in that direction myself and I will probably try to wrap it up and
send it over next week, if time permits.
About the problems you have found in GeoServer, since you always
dispensate good advices to us, I'll give you one. Open Source is about
collaboration, you find something that it does not work, report the
problem and/or try to fix it. The sentence "we found out that the
component X does not work in some conditions" is not really helpful,
it is rather useless, indeed. If you keep your findings for you and
just create a branch, that's not going to be helpful because despite
to what your initial desire was that code will hardly ever come back
to the community. The result is duplication of efforts.
Simone.
On Dec 16, 2007 9:42 PM, Martin Desruisseaux
<martin.desruisseaux@anonymised.com> wrote:
After the creation of the nD experimental branch a while ago, we commited a
little bit of work, then the branch took a direction that was incompatible with
our work, so we hold-on any work on that branch.
Mmmhh, I don't remember anyone telling us anything about this. The
whole goal of having Alessio working on the GeoServer branch instead
of in isolation on our svn was to have you guys cehcking things out
and giving feedback. We should have probably have been better at
giving you inputs, but I think we did try quite hard to cooperate on
our side.
For now we are doing our work on geotools and seagis project only (which has
"real" nD coverage support as well since 2003 but it was not a web service until
recently), developping a mini-WMS/WCS there. The reason is that we tried very
hard to make it work with geoserver for many months, but realized that acheiving
our goals would require consequent changes to AbstractGridCoverage2DReader
design and Geoserver configuration interface. Now, time constraint (we are bound
by contract to finish before the end of 2007) is so hard that we have to act in
emergency and the path of less resistence has been to write a mini-WMS/WCS (only
for rasters served by the postgrid database, nothing else) from scratch.
With this approach, if any of the strange behaviors that we observed with Geoserver
(images that mysteriously disapear for some WIDTH and HEIGHT parameter value,
unability to performs some reprojections, etc.) are still there, at least I will
be sure that the bug is our and we known where to debug. This approach work well
in this case because the WMS layer is very tin - geotools and seagis already do
most of the work we need. Less than 2 weeks have been enough for getting a
working mini-WMS. See that as a useful debugging tools allowing us to focus our
debugging on postgrid code.On a historical note, the seagis project has been the home of referencing and
coverage module before the code moved to geotools in 2002. The same could happen
here for this nD stuff, depending on community wish. But a review of Geotools
Coverage I/O code is necessary before we get there (I still have missed time so
far for doing that). I want to focus on code quality (or what seems "quality"
from my point of view - I may be wrong). To me, a nD-Coverage is "real" only
when associated with a CoordinateReferenceSystem having that amount of
dimensions and when capable to interpolate over all those dimensions. I'm doing
that since 2003 in postgrid (and more that you have not yet seen), but not as a
web service.Alessio Fabiani a écrit :
> If GeoServer recognizes a CoverageStore which is based on the new
> GeoTools ND Plugin, it will create many Coverages as contained in the
> store, and also it is now able to handle also the temporal and vertical
> extent, both on WCS and WMS.Is this CoverageStore defined on the 2.4 branch? I don't see it on GeoTools trunk.
Martin
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
-------------------------------------------------------
Ciao Jody,
I think that would be a great idea. If you come up with an interface I
can ask Daniele to make a simple implementation (but only right after
the 2nd of january) for, let's say, ascii grid format.
Simone.
On Dec 17, 2007 9:43 AM, Jody Garnett <jgarnett@anonymised.com> wrote:
Andrea Aime wrote:
> We need to struck a middle ground here too. My personal opinion on this
> matter is that we miss the equivalent of DataStore for the coverage
> land. We already see various cases of entities that could be see as
> black box holder of coverages:
> * a plain directory filled with coverage data in various formats
> * a single complex file such as the netcdf or the hdf ones
> * postgrid
> * a remote WCS server (that is, if we're ever going to have a client
> to talk with them)
> * ArcSDE grids
> * Oracle grids
>
> A CoverageStore could be modelled against the WCS service interfaces the
> same way we modelled DataStore against the WFS datastore interfaces.
> Any interest in doing a common work in this direction, anyone?
>
I like that by way of direction for two reasons:
a) we know it will work for the geoserver case
b) we have documentation and definitions to fall back on so we don't
waste a lot of time arguing back and forthIndeed I find it favorable to the approach taken last year of extracting
the useful bits of DataStore into a DataAccess; and then subclassing for
CoverageStore.I can bang out an initial interface; if someone wants to make a sample
implementation.Cheers,
Jody-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
-------------------------------------------------------
On Thu, December 20, 2007 2:51 pm, Simone Giannecchini wrote:
Ciao Jody,
I think that would be a great idea. If you come up with an interface I
can ask Daniele to make a simple implementation (but only right after the
2nd of january) for, let's say, ascii grid format.
Since we're talking about a coverage store that can host multiple
coverages, what about a directory based one instead (one that reports all
the coverages found in a single directory).
Cheers
Andrea
Ciao Andrea,
what exactly do you have in mind?
Simone.
On Dec 20, 2007 3:04 PM, <aaime@anonymised.com> wrote:
On Thu, December 20, 2007 2:51 pm, Simone Giannecchini wrote:
> Ciao Jody,
> I think that would be a great idea. If you come up with an interface I
> can ask Daniele to make a simple implementation (but only right after the
> 2nd of january) for, let's say, ascii grid format.Since we're talking about a coverage store that can host multiple
coverages, what about a directory based one instead (one that reports all
the coverages found in a single directory).Cheers
Andrea
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
-------------------------------------------------------