So this discussion does not seem to be finished yet ... and am hesitant of
of folding this in until the REST api is fixed. Can we go half way and
document what we are sure of and what is open for review?
Additional comments inline:
Without looking at the sample requests page, I seem to recall that it is
> already making HTTP requests internally, so it should be pretty easy to
> extend it to allow REST requests. We will probably want to rethink how
> the sample requests are stored on-disk though, to allow for PUTs.
It handles GET and PUT already; if we can just list the initial "rest index"
page there; or link to the rest index page from our welcome screen that
would be fine.
> - structures seems to be datastore then feature type? We have had one
> case where geoserver was configured to "combine" data from two
> cascaded WFS's were combined into the same published featuretype. Do
> we need to consider namespace/featureType as representing the publish
> to WFS (similar to how layer represents publish to WMS)
If I get you right, you're suggesting that we keep the current
> /layers/{layername} endpoint and add a parallel hierarchy for each
> service (/publishedcoverages/{coverageid}
> and /publishedfeaturetypes/{featuretypeid})
I was focused on separating the data access from the data publication. I
wanted to view publishing the vector falvour of a data set as a seperate
concern (similar to the idea of how a layer is defined).
To define a layer we bring together data resource and style. There are a few
more steps like giving the result a title and description.
To define a published feature type we need to bring together a data resource
and some information about namespace/typeName (the same steps of giving the
result a title and description apply).
There are however some more steps that are on our roadmap:
- we can have the result be the aggregation of two data sources (my example
earlier)
- the result can be generated according to a simple restriction (ie filter)
or a more complicated mapping (ie community schemas)
- some operations (ie WPS) may be allowed on this resource
I think we should try to
> better convey the fact that WFS, WCS, and WMS expose different aspects
> of the same data (to avoid having to create a layer config for each
> layer for each service). That is,
> /layers/{layername}/wms would be the wms configuration for some layer,
> with .../wfs and .../wcs for the wfs and wcs configurations
> respectively.
We could have links from the resource data page to the various places it is
published (the same data may be available in many formats and visualized
using several different named styles (and visualized used a user supplied
style if SLD is allowed).
>
>
> This sort of leads into an idea I was briefly discussing with Justin in
> IRC a couple of weeks ago; namely, that of doing away with the idea of
> layergroups, in favor of layers simply allowing multiple resources.
It is too bad you could not consider nested layers to mirror what is going
on in the capabilities document?
/layers/layer1
/layers/layer1/child1
/layers/layer2
> So:
>
> /layers/{layername} would simply be a list of references to resources,
> no extra publishing information except for "what is this layer
> publishing".
That does not really work for me since the layer definition brings together
additional information beyond the resource (name, title, scale, srs, style
settings etc...). It is better to think of it *as* a resoure (namely a
visualization). When you change the settings on that page you are changing
the settings for this visualization.
A mistake we made earlier was to try and load up the resource definition
with too much information (like a default style) bluring the line between
data and layer. We should try and keep it clear.
/layers/{layername}/wms would be the WMS settings: default style,
> alternative styles, default SRS, etc. The 'alternative styles' option
> would probably need to be disabled/prohibited when the layer is
> configured to expose multiple datastores.
>
> /layers/{layername}/wfs would be the WFS settings like maxfeatures, etc,
> and be disabled unless the layer exposed a single featuretype resource.
Yep that is what I am trying to avoid; feature type is not a layer and vice
versa...
> /layers/{layername}/wcs would be the WCS settings (no examples come to
> mind) and be disabled unless the layer exposed a single coverage
> resource.
>
> And so on for whatever future services extensions may provide. I will
> admit to being fairly uninformed with regard to WPS; does it reasonably
> fit into this structure, or are processes sufficiently different that it
> doesn't make sense to talk about them in layers?
How to do wps is fairly clear from the ESRI stuff .... it shows up in your
configuration as what operations you allow for a particular feature type.
And then when you make a page for the feature collection you can have links
to the allowed operations.
Cheers,
Jody
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
