Hi,
this mail tries to summarize the feedback I got during the FOSS4G
conference week about GeoServer. I encourage other participants
to the conference to provide their impression as well, this is
but a summary of just one person, so it's obviously skewed both
by the limited number of people I spoke to, and my personal filtering
of what I deem to be more or less important.
Perceived strong points:
* Easy to use (easy to introduce to new people), this
actually is one of the reasons many people pick up GeoServer out of
other options that do provide the same OGC services.
Hopefully the new UI will strengthen this point.
* Stable, works, performance within expectations
* Growing, lively community
* Strong OGC service support. Many people stumbling into GeoServer are
not looking for a generic web GIS, but specifically for OGC
services. This is a strong point we have to make even stronger if
possible.
Improvement areas:
* Quickly configuring lots of layers. This is probably the most asked
question of all FOSS4G, a user has lots of shapefiles, lots of PostGIS
tables, and wants to configure them all in one shot (of course,
without caring much about styles to start with, just have the
datastore figure out the SRS and the bounds to start with).
In 2.0.x we want to develop such a mass configure action, whilst
in the short term, for 1.7.x, we could try to resurrect the directory
data store as an incremental helpful step.
* missing self configuring (drop data into a directory and have it self
configure), both feature type and coverage wise.
This is quite similar to the idea of an Ingestion Engine, minus the
preprocessing that Simone and Alessio added.
An IE could really be just an extra module that you drop into
GeoServer and that has its own way to configure stuff on the fly.
The use case, at least for the moment, does not require massive
scalability concerns to be dealt with, since the catalog itself
will not scale that much (we know it works fine on the thousands
layers range, not sure it can be any good at hundred of thousands
thought). So an IE that can deal with 10-100 new layers a day
is most probably more than enough. Also, we would like it to be
able to spot new tables in an already connected db, and not only
to deal with a file system "drop area" where new data can be put
waiting for it to be collected and configured.
* have a way to configure on the fly session level layers that are only
visible to the current user, and that do expire (and be deleted) once
the session expires (or after a fixed amount of time).
This is quite a common requirement for UI that share a server side
component performing some kind of processing or complex
filtering and that do require the result to be visible through
WMS/WFS but only for the current user and only for a limited
amount of time. An example for all, a shortest path as computed by
PgRouting, that needs to be displayed and interacted with using
an OL client, but that of course is of any interest only to the user
that asked for its computation.
* multiple services per server, similar to MapServer mapfiles. This is
a question we had (too) many times on the users list as well.
* Got a couple of negative feedbacks on the layer grouping
functionality, people do expect the grouping to produce a tree that
can be then used by smart clients to show a correspondent UI tree
(I guess MapFish does this?).
I know we do allow for tree bulding using the wmspath property,
yet this way is cumbersome at best, we should be providing a better
way to structure this in GeoServer 2.0, ideally providing a layer
group as a catalog level item that can be drilled down.
Oh, this would also ask for a LayerGroup to be a Layer and thus
allowing deeper nesting and actual tree building (we need an actual
tree based UI to allow people reorganizing the tree as they see fit).
* Provide information about the raster on the coverage layers (pixel
size, tile structure and so on), that is, basically the gdal_info,
so that people may know more about the layer they are/have been
configuring.
* Auto mosaic building as part of the configuration, just point the
mosaic to a directory of files and let it go. It's an easy, no
nonsense way to configure a mosaic that everybody can handle.
We just have to beware of HTTP request timeouts during such
configuration. Any idea of how much time it takes to build a big
mosaic? (say, 1000 or more tiles?). This is actually something
that some commercial image server is doing already (actually the
configuration tools allow for effortless pyramid building as well).
* The same could go for a pyramid, provide a folder that contains a set
of images (the initial mosaic) and have it build the pyramid as part ù
of the configuration...
* Per layer reprojection SRS list, as opposed to server wide one.
* Allowing the usage of a completely custom catalog, some people already
have their own catalog subsystems and they do want to plug in
directly into them without having to copy the configs to GeoServer.
This is actually very doable right now, since the new catalog is an
interface, yet we need to deal at least with a couple of issues:
- turn the catalog in a real extension point, so that you can have
GeoServer use a custom one by just dropping the appropriate jar
in
- deal with service configuration in the same way. Consider for
example a catalog driven by .map files. We would like to have
a different service configuration for each of the .map files,
so ideally what configures the in memory catalog would also
have to configure the services.
Well, this is what I gathered. Comments appreciated.
Cheers
Andrea
