Metacat

Just for reference, here are the general steps to configure a layer to be displayed in our web map. Each step varies in ease of automation/webification:

1. Upload the data to the server. This can be handled through metacat.

2. Configure the data store (paths, geographic projection, format, etc). This is best handled by Geoserver as they have already worked out an excellent interface for this step. This tells the WMS server how to access your data

3. Create that styles and classification filters. These are created using OGC standard SLD documents. Geoserver lacks a sophisticated editor for these docs.

4. Associate your data store with the styles and filters. Essentially this tells the WMS server how to style your data creating a "featuretype". Again geoserver handles this quite well already.

5. Once the feature type has been configured, it has to be added to your Web Map context (WMC) document which tells the web client how to request your data. There are now good interfaces (other than a text editor) for adding entries to a WMC.

Since geoserver already does so much of this so well, I would vote for keeping 2-4 in the geoserver web admin interface (perhaps contributing to the enhancement of #3). All layers that are configured properly in geoserver can then appear in a metcat web mapping admin interface to handle step #5.

There are some parts of the geoserver admin page that can be improved upon. Namely alot of the information it prompts for can be determined through the metadata document (the epsg, title, keywords, abstract, geographic bounds, etc)

It's true that Geoserver does all of this except including the new layer in a rendered map in Metacat.We could include a configuration step that allows and admin user to select which layers should appear for any given skin's map.

Original Bugzilla ID was 2180