[Geoserver-devel] What features should a data source have?

John_Armstrong1 · March 7, 2012, 2:05pm

I've recently been developing a new GeoServer data source for use on a project I've been working on. I'm interested in fleshing it out to something more generally useful, and I'd like to know what features I should make sure it supports.

Of course at heart is the ability to respond to WMS requests, and (after the helpful discussion here) I've set it up to handle TIME parameters on the requests. I also have a panel for creating new stores by hand in the GeoServer webapp, and new stores and layers can be registered through HTTP calls from other programs.

Is there anything else that I should make sure to design in before this plugin would be "ready for prime time"?

Thanks.

Andrea_Aime4 · March 7, 2012, 2:28pm

On Wed, Mar 7, 2012 at 3:05 PM, John Armstrong <jrja@anonymised.com> wrote:

I've recently been developing a new GeoServer data source for use on a
project I've been working on. I'm interested in fleshing it out to
something more generally useful, and I'd like to know what features I
should make sure it supports.

Of course at heart is the ability to respond to WMS requests, and (after
the helpful discussion here) I've set it up to handle TIME parameters on
the requests. I also have a panel for creating new stores by hand in
the GeoServer webapp, and new stores and layers can be registered
through HTTP calls from other programs.

Is there anything else that I should make sure to design in before this
plugin would be "ready for prime time"?

You are talking about a raster data source I presume?

It would help if you could describe what the raster data source does,
maybe show some screenshots of the GUI

Generally speaking, good raster data sources try to respect the grid
geometry passed in by GeoServer
if possible, that is, if they have overviews they use them to load as few data
as possible in order to satisfy the resoution requested by GeoServer (implied
in the suggested grid resolution).
And they have proper resource handling, eventual file descriptors kept open
for performance reasons are guaranteed to be closed when the reader is closed.

Ah, and then there is the project choice and then licensing.
The reader could be part of GeoTools, the GUI needs forcefully to be part
of GeoServer.
The two project have different copyright assignemnt that you have to sign
before donating code, and different licenses, GeoTools is LGPL and GeoServer
is GPLd

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

-------------------------------------------------------

John_Armstrong1 · March 7, 2012, 2:37pm

On 03/07/2012 09:28 AM, Andrea Aime wrote:

You are talking about a raster data source I presume?

Yes, it's designed to store pre-computed tiles in an Accumulo datastore (Accumulo is like Hbase or BigTable) and retrieve them quickly.

It would help if you could describe what the raster data source does,
maybe show some screenshots of the GUI

Not sure what GUI you'd want to show; the store creation panel?

Generally speaking, good raster data sources try to respect the grid
geometry passed in by GeoServer
if possible, that is, if they have overviews they use them to load as few data
as possible in order to satisfy the resoution requested by GeoServer (implied
in the suggested grid resolution).
And they have proper resource handling, eventual file descriptors kept open
for performance reasons are guaranteed to be closed when the reader is closed.

Currently it either returns a tile if one is present in the datastore at the given location and resolution, or it returns a blank. Is it required to cobble together imagery at higher/lower resolutions from the available ones?

Ah, and then there is the project choice and then licensing.
The reader could be part of GeoTools, the GUI needs forcefully to be part
of GeoServer.
The two project have different copyright assignemnt that you have to sign
before donating code, and different licenses, GeoTools is LGPL and GeoServer
is GPLd

Yes, licensing is the last step, which I'd have to clear with people higher up the chain than me. Right now I'm just trying to figure out what features are expected -- what calls/requests should it support in its interface.

Andrea_Aime4 · March 7, 2012, 3:03pm

On Wed, Mar 7, 2012 at 3:37 PM, John Armstrong <jrja@anonymised.com> wrote:

On 03/07/2012 09:28 AM, Andrea Aime wrote:

You are talking about a raster data source I presume?

Yes, it's designed to store pre-computed tiles in an Accumulo datastore
(Accumulo is like Hbase or BigTable) and retrieve them quickly.

It would help if you could describe what the raster data source does,
maybe show some screenshots of the GUI

Not sure what GUI you'd want to show; the store creation panel?

Yep, that one. Not a specific requirement per se... I mean, we don't know
what your data source is about, the first step when presenting a new
module is normally to tell people what it can do

Currently it either returns a tile if one is present in the datastore at
the given location and resolution, or it returns a blank. Is it
required to cobble together imagery at higher/lower resolutions from the
available ones?

Nope, that GeoServer can already do. What I said applies only if you
have precomputed overviews (like geotiff ones), if you have to compute that
on the fly GeoServer can do that as well.
One common way to quickly return a reduced resolution version that
GeoServer cannot do is subsampling though, that is, read one pixel
every N. Most of our data sources do that in case no overview is available.
That said, it's a nice to have, not a requirement.

Ah, and then there is the project choice and then licensing.
The reader could be part of GeoTools, the GUI needs forcefully to be part
of GeoServer.
The two project have different copyright assignemnt that you have to sign
before donating code, and different licenses, GeoTools is LGPL and GeoServer
is GPLd

Yes, licensing is the last step, which I'd have to clear with people
higher up the chain than me. Right now I'm just trying to figure out
what features are expected -- what calls/requests should it support in
its interface.

If it's working for WMS I believe you pretty much satisfied all the basic
requirements already, as far I can imagine at least.

If/when you share the source code we'll probably be able to provide some more
suggestions.
Hopefully others will chime in with different perspectives, I just dumped what
came to mind here and now