On Wed, Feb 15, 2012 at 10:54 PM, Mike Benowitz
<michael.benow...@gdit.com>wrote:
> Hello,
>
> I am working on some modifications to allow GeoServer to support dimensions
> other than TIME and ELEVATION for coverage layers, and I was wondering if
> this group could comment on whether this approach is reasonable, and also
> what it would take to get my changes included in the mainline GeoServer
> branch.
>
> As I understand it, GeoServer currently supports TIME and ELEVATION
> dimensions for coverage layers through the use of custom plugins that
> define
> their own coverage readers (by subclassing
> org.geotools.coverage.grid.io.AbstractGridCoverage2DReader). The actual
> handling of dimensions is determined by the custom coverage reader's
> implementation of the getMetadataValue(String) and
> read(GeneralParameterValue[]) methods, while the set of supported
> dimensions
> is advertised via its getMetadataNames() method. This mechanism is
> currently
> limited strictly by the fact that the core GeoServer logic expressly
> ignores
> any metadata entry that is not a "TIME" or "ELEVATION" entry. I would like
> to remove this limitation, so that custom plugins can truly support custom
> dimensions.
>
The thing is, the metadata values can be anything, not just dimensions.
TIME and ELEVATION are conventionally understood, if you come up with
another dimension there must be a way to know it is a dimension and not
other random metadata.
It could be that a api change is required to declare the available
dimensions,
or it could be that we choose a naming convention, any metadata key
named like DIMENSION_<something> is to be considered a dimension.
Another thing that might problematic, but I'm not sure if it will be
problematic
or not, is that we know the data type of time and elevation, but what about
the other dimensions? We treat them as strings and that's it?
>
> The changes to core GeoServer would be minimal, and would occur in the
> following classes:
>
> org.geoserver.wms.capabilities.DimensionHelper (writes dimension entries to
> WMS GetCapabilities response) - modify handleRasterLayerDimensions and
> declareWMS11Dimensions methods to process any metadata entry whose name is
> valid according to the coverage reader (in addition to the current
> processing for "time" and "elevation" entries)
>
> org.geoserver.catalog.util.ReaderDimensionsAccessor - add getDomain(String)
> and hasDomain(String) methods so that coverage reader queries are not
> limited to just time and elevation
>
>
Seems reasonable
> DefaultWebCoverageService100 - modify getCoverage method so that in
> addition
> to "ELEVATION" axis subsets being handled, any axis subset whose name is
> valid according to the coverage reader will be similarly handled (and
> corrsponding entries will be included in the array passed to the coverage
> reader's read(GeneralParameterValue[]) method).
>
>
Might work, but I believe (not sure) that the custom dimension would be
numeric
to be handled that way?
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
