GeoServer

New workflow for adding data

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Configuration
  • Labels:
    None
  • Number of attachments :
    0

Description

Talking on email David Blasby pointed out how closely linked our web config tool is linked to the xml config files and geotools ideas. I got to thinking, and it's really quite bad. When we were just a WFS the FeatureType thing was ok, but DataStore was still pretty klunky. Now that we in WFS and soon WCS, it's just silly. So it got me thinking about how you actually want to add data.

There should just be one menu - data (name up for debate, as the parent config is also called data). No featureType and DataStore.

You click on data, and are shown the FeatureType Configuration screen (config/data/typeSelect.do), which lists all the configured FeatureTypes, and has a button for new. You can edit a FeatureType, just like before. Or you can hit 'new'.

New takes you to the Create New FeatureType (config/data/typeNew.do), where you can create a new FeatureType from an available datastore. Here we add two new buttons called 'new data source' and 'edit data source'. Edit data source takes you to the old DataStore Config page (config/data/store.do), and New data source takes you to the old DataStore New page (config/data/storeNew.do).

After you configure a new data store, geoserver will figure out if there is more than one available FeatureType. If there is only one (as is always the case in shapefiles) then we don't bother with a page to select which one. We go straight to the FeatureType editor. If there is more than one, then you are given a page where you can select just from the datastore that you just created.

Overall this is a pretty new workflow, but I don't think it should be all that hard to implement, as it requires no more than 2-3 new pages, which will be mostly based on old pages. I feel this is infinitely more intuitive though. Especially for shapefiles. To add a new shapefile it's just: click on data, click on new, enter the url of the shapefile, edit the featureType. Instead of: click on stores, click on new, enter data store params, click on featureType, click on new, find the newly created datastore, edit the featureType.

It doesn't need to be precisely that way, but I think getting rid of the feature type and store junk, especially when you have a datastore with only one featureType in it, will make things a lot more intuitive.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
dblasby added a comment -

moved forward.

Show
dblasby added a comment - moved forward.
Hide
Permalink
Gabriel Roldan added a comment -

may be it would be even more intuitive if we use DirectoryDatastore to list all the FileDataStore's that are in a given directory?

that way you select a directory and get a list of all supported file formats (shp, arcgrid, mif, gml, world+file, geotiff, etc), regardless of it is vector or raster based.

Show
Gabriel Roldan added a comment - may be it would be even more intuitive if we use DirectoryDatastore to list all the FileDataStore's that are in a given directory? that way you select a directory and get a list of all supported file formats (shp, arcgrid, mif, gml, world+file, geotiff, etc), regardless of it is vector or raster based.
Hide
Permalink
Chris Holmes added a comment -

I'm definitely not opposed to DirectoryDatastore, but I don't know that it was ever a success - I think it might have withered out of commission. But yeah, I think in this workflow it would just be another option - you could select a directoryDataStore, and then you'd input a directory, and you'd be taken to the dialog to select which featureType for that. Or you could do an individual file, and it would bypass the featureType new selection screen.

Show
Chris Holmes added a comment - I'm definitely not opposed to DirectoryDatastore, but I don't know that it was ever a success - I think it might have withered out of commission. But yeah, I think in this workflow it would just be another option - you could select a directoryDataStore, and then you'd input a directory, and you'd be taken to the dialog to select which featureType for that. Or you could do an individual file, and it would bypass the featureType new selection screen.
Hide
Permalink
Rob Atkinson added a comment -

There is more than one major problem with the current workflow, but we dont necessarily need to lose the benefits of the current GUI.

The major problem is highlighted when we look at coverages: the data store itself does not drive the feature type, which is a generic feature type (coverage is a feature, and currently we support a common, anonymous 2D orthorectified grid - AFAIK. ) So, the workflow is mapping the data store onto the coverage type, conceptually.

The FM concept will be similar. We will want to start with the target type and then map the data store to it.

Now, if the current process is looked at differently:
Datastore = connection
Create Feature type has the option of browsing data available at a connection and creating a Feature Type
FeatureType mapping then occurs between the target feature type and a data store.

In the case of a "auto-generated" feature type, the mapping process can be automated. Other approaches will use different strategies - these configuration mapping tools can be UI plugins, and/or XML file driven. For now, it would be perfectly acceptable to say that the UI tools only exist for the current functionality, and more complex mapping strategies need configuration files.

It seems the important thing is to create the extension points in the right place. Creating a true plugin approach will have to wait, but perhaps with the current struts approach we could allow the underlying modules to start doing things in the right order at least, allowing extension in the future.

Show
Rob Atkinson added a comment - There is more than one major problem with the current workflow, but we dont necessarily need to lose the benefits of the current GUI. The major problem is highlighted when we look at coverages: the data store itself does not drive the feature type, which is a generic feature type (coverage is a feature, and currently we support a common, anonymous 2D orthorectified grid - AFAIK. ) So, the workflow is mapping the data store onto the coverage type, conceptually. The FM concept will be similar. We will want to start with the target type and then map the data store to it. Now, if the current process is looked at differently: Datastore = connection Create Feature type has the option of browsing data available at a connection and creating a Feature Type FeatureType mapping then occurs between the target feature type and a data store. In the case of a "auto-generated" feature type, the mapping process can be automated. Other approaches will use different strategies - these configuration mapping tools can be UI plugins, and/or XML file driven. For now, it would be perfectly acceptable to say that the UI tools only exist for the current functionality, and more complex mapping strategies need configuration files. It seems the important thing is to create the extension points in the right place. Creating a true plugin approach will have to wait, but perhaps with the current struts approach we could allow the underlying modules to start doing things in the right order at least, allowing extension in the future.
Hide
Permalink
Gabriel Roldan added a comment -

Chris, this is no longer relevant as per the new Wicket UI, right?

Show
Gabriel Roldan added a comment - Chris, this is no longer relevant as per the new Wicket UI, right?
Hide
Permalink
Chris Holmes added a comment -

Yup, new UI should do an even better job than this proposed workflow (I hope)

Show
Chris Holmes added a comment - Yup, new UI should do an even better job than this proposed workflow (I hope)

People

  • Assignee:
    Gabriel Roldan
    Reporter:
    Chris Holmes
Vote (1)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: