Hey all,
It seems like coverages in geoserver have evolved from the idea of "one-big-raster-image" = "one-raster-datalayer".
This makes a lot of sense if your coverage is a 250Mb TIFF covering some watershed, but starts to break down when multiple files make up a single coverage. So far I think this has been solved by having the necessary parameters to create multi-image coverages be stored in a single file, and having that file be the single file referenced from the UI, but I'm curious about people's thoughts about the back-end configuration of this (and how it relates to the UI).
I realize that there's a big UI change brewing, so I'll contain my thoughts to the back-end of the coverage configuration, because I figure the back-end options drive what the UI looks like anyway.
For featureDataStores there is a map of parameters, and the UI lists the parameters with their names, so that each datastore can require different parameters. See DataStoreConfig.java
For coverageDataStores, there's just a fixed list of attributes. See CoverageStoreConfig.java.
Seems like coverageDataStores might want to have a map of paramaters as well. Simple map for files on disk, more complex for lists of files on disk, db connection params for rasters in databases, etc.
Thoughts?
--saul
This makes a lot of sense if your coverage is a 250Mb TIFF covering some
watershed, but starts to break down when multiple files make up a single
coverage. So far I think this has been solved by having the necessary
parameters to create multi-image coverages be stored in a single file,
and having that file be the single file referenced from the UI, but I'm
curious about people's thoughts about the back-end configuration of this
(and how it relates to the UI).
Saul, I believe the ImageMosaic plugin will help in the case with
multiple files described above (if I understand well what you are
asking).
I realize that there's a big UI change brewing, so I'll contain my
thoughts to the back-end of the coverage configuration, because I figure
the back-end options drive what the UI looks like anyway.
For featureDataStores there is a map of parameters, and the UI lists the
parameters with their names, so that each datastore can require
different parameters. See DataStoreConfig.java
For coverageDataStores, there's just a fixed list of attributes. See
CoverageStoreConfig.java.
Seems like coverageDataStores might want to have a map of paramaters as
well. Simple map for files on disk, more complex for lists of files on
disk, db connection params for rasters in databases, etc.
In the above-mentioned plugin, the files are listed in a .shp file,
acting as a "map" for the files on disk, sans the db connection
params.
Alex
Saul, I believe the ImageMosaic plugin will help in the case with
multiple files described above (if I understand well what you are
asking).
Right, you've got what I'm talking about. And I understand what's currently in-place pretty well. It's just unnecessarily limiting.
In the above-mentioned plugin, the files are listed in a .shp file,
acting as a "map" for the files on disk, sans the db connection
params.
Right now I'm handling the database connection case with a "db" url, but that's a bit of a stretch, semantically. sde://username:password@anonymised.com[:port]/dbname#tableName is ok, but what if the raster has an associated colormap and you need to flag the reader code to that somehow? Or what if the raster table is a raster catalog, and you need to specify some default behavior (which order to overlay overlapping tiles in, for example)?
I'm just saying there are lots of options to pass to a coverage in order to instantiate it correctly, and perhaps an easier way to describe the available options both from a UI and programming perspective is with a Map of options to be passed to Format.getReader(Object source);
Format.getReader() takes the required input (any input, actually!) It's just about getting Geoserver to store its coverage config that way.
--saul
Alex
Saul Farber wrote:
Hey all,
It seems like coverages in geoserver have evolved from the idea of "one-big-raster-image" = "one-raster-datalayer".
This makes a lot of sense if your coverage is a 250Mb TIFF covering some watershed, but starts to break down when multiple files make up a single coverage. So far I think this has been solved by having the necessary parameters to create multi-image coverages be stored in a single file, and having that file be the single file referenced from the UI, but I'm curious about people's thoughts about the back-end configuration of this (and how it relates to the UI).
I realize that there's a big UI change brewing, so I'll contain my thoughts to the back-end of the coverage configuration, because I figure the back-end options drive what the UI looks like anyway.
This is actually exactly the kind of feedback I want to see before we call this a 'release candidate'. It's been awhile since I checked out the UI for coverages, but it definitely felt 'built by programmers'. We definitely can't completely redo it within the confines of struts, esp. as we have a new UI somewhere in the works. But to call this 1.5.0 I think we do need to do a bit of UI love, even if it is painful to do in struts. So let's figure out the UI changes we'd like, and the ones we need to make it easier to use, and put in the ones we need. When that's done, and we have tutorials on showing one file, showing a bunch of files as one, and doing some pyramiding and displaying those, we'll call this RC1, and hopefully get to 1.5.0 pretty quick after that.
Chris
For featureDataStores there is a map of parameters, and the UI lists the parameters with their names, so that each datastore can require different parameters. See DataStoreConfig.java
For coverageDataStores, there's just a fixed list of attributes. See CoverageStoreConfig.java.
Seems like coverageDataStores might want to have a map of paramaters as well. Simple map for files on disk, more complex for lists of files on disk, db connection params for rasters in databases, etc.
Thoughts?
--saul
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1003,459554a2306567731818748!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org