[Geoserver-devel] GSIP 36, resource/publishing split

[Andrea_Aime3]

Hi all,
I'm writing this mail to ask everybody to read and review the latest
GSIP, this time dealing with the split between resource management
and data publishing.
The proposal has been made by Justin, it's clear enough that it
does not require further introductions in this mail,
so I'm just presenting it to you while Justin is not around (holidays).

Anyways, I've talked with Justin about it so I guess I can try
and answer questions and provide, if nothing else, my personal feedback
on the matter.

Soo... read it and bring in your comments.
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Ben_Caradoc-Davies]

Andrea Aime wrote:

I'm writing this mail to ask everybody to read and review the latest
GSIP, this time dealing with the split between resource management
and data publishing.

And here is the link:
http://geoserver.org/display/GEOS/GSIP+36+-+Resource+-+Publishing+Split+and+Virtual+Configuration

I think these are welcome changes. I have three remarks.

(1) This is an opportunity to expunge remaining assumptions that there is one only namespace per store.

(2) Profiles would be a good enhancement. WFS limits us to one collection of a given feature type per service URL. For example, there can be only one collection of gsml:MappedFeature. Advocates of this approach would like to see all queries made on properties, but this does not support different approaches to encoding complex responses. In the GeoSciML community there are two factions: those who support nesting properties by value and those who prefer nesting by reference. The use of profiles in the service URL (I like the context path element option) would permit one GeoServer instance to serve both a nested-by-value and a nested-by-reference gsml:MappedFeature. At the moment, we are stuck either wrapping type (e.g. gsml:MappedFeatureUseCase2A) names or having multiple GeoServer instances.

(3) The implementation of app-schema feature chaining requires each AppSchemaDataAccess instance to be aware of those containing properties it would like to nest. At the moment, we use a private registry. It would be better if there were more generic approach of inter-DataAccess communication. This would require, at the minimum, a catalog interface in GeoTools. Should the core catalog classes be pulled into GeoTools? Are they sufficiently generic? What does uDig use?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[jive]

Thanks for your reply Ben; I have been struggling with my own
feedback. The idea of splitting up resoruce from layer is great.
The details of workspace / map and profile are a bit blurred for me.

I do not like the idea of a Map (in the mapserver sense). A map server
mapfile resulting in a different view (or entirely different
presentation) coming out of the same server GetCapabilities end point.
This always struck me as an implementation detail being made public.
And perhaps that is the point here - with the goal of publishing
related information as a group? This could be viewed as a shortfall of
each specification (WMS can group information into parent layers; WFS
kind of publishes by application schema but the relationship is not
explicit).

Contrasted with the idea of revealing a profile; as part of the url;
result in a clean service location for end users. I understand this
difference is only a technicallity; perhaps this is the technicallity
I am getting hung up about.

From an end user standpoint both profiles and maps appear to operate

in the same manner; resulting in a different capabilities document. I
am concerned that it would not be clear which combinations are
allowed; and what the options are.

Jody

On Tue, Apr 28, 2009 at 12:30 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

Andrea Aime wrote:

I'm writing this mail to ask everybody to read and review the latest
GSIP, this time dealing with the split between resource management
and data publishing.

And here is the link:
http://geoserver.org/display/GEOS/GSIP+36+-+Resource+-+Publishing+Split+and+Virtual+Configuration

I think these are welcome changes. I have three remarks.

(1) This is an opportunity to expunge remaining assumptions that there
is one only namespace per store.

(2) Profiles would be a good enhancement. WFS limits us to one
collection of a given feature type per service URL. For example, there
can be only one collection of gsml:MappedFeature. Advocates of this
approach would like to see all queries made on properties, but this does
not support different approaches to encoding complex responses. In the
GeoSciML community there are two factions: those who support nesting
properties by value and those who prefer nesting by reference. The use
of profiles in the service URL (I like the context path element option)
would permit one GeoServer instance to serve both a nested-by-value and
a nested-by-reference gsml:MappedFeature. At the moment, we are stuck
either wrapping type (e.g. gsml:MappedFeatureUseCase2A) names or having
multiple GeoServer instances.

(3) The implementation of app-schema feature chaining requires each
AppSchemaDataAccess instance to be aware of those containing properties
it would like to nest. At the moment, we use a private registry. It
would be better if there were more generic approach of inter-DataAccess
communication. This would require, at the minimum, a catalog interface
in GeoTools. Should the core catalog classes be pulled into GeoTools?
Are they sufficiently generic? What does uDig use?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[jive]

Okay I have gone through a couple of examples now on paper; my
preference would be to present both profiles and maps as part of the
URL path; but I understand this is just a technicality.

One thing that was mentioned in the proposal page once and not
revisited was the concept of a "workspace". Andrea can you explain how
these are used; right now I am picturing a concept similar to a folder
used to provide a "tree" structure to organize different datastores; I
assume when you are defining a layer for a map you can refer to data
in any workspace used by your profile.

This proposal seems clear; I have my one technical reservation about
the presentation of profile and map as part of the url path; but as it
stands this proposal gets a +1 from me.

Jody

On Tue, Apr 28, 2009 at 2:22 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks for your reply Ben; I have been struggling with my own
feedback. The idea of splitting up resoruce from layer is great.
The details of workspace / map and profile are a bit blurred for me.

I do not like the idea of a Map (in the mapserver sense). A map server
mapfile resulting in a different view (or entirely different
presentation) coming out of the same server GetCapabilities end point.
This always struck me as an implementation detail being made public.
And perhaps that is the point here - with the goal of publishing
related information as a group? This could be viewed as a shortfall of
each specification (WMS can group information into parent layers; WFS
kind of publishes by application schema but the relationship is not
explicit).

Contrasted with the idea of revealing a profile; as part of the url;
result in a clean service location for end users. I understand this
difference is only a technicallity; perhaps this is the technicallity
I am getting hung up about.

From an end user standpoint both profiles and maps appear to operate
in the same manner; resulting in a different capabilities document. I
am concerned that it would not be clear which combinations are
allowed; and what the options are.

Jody

On Tue, Apr 28, 2009 at 12:30 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

Andrea Aime wrote:

I'm writing this mail to ask everybody to read and review the latest
GSIP, this time dealing with the split between resource management
and data publishing.

And here is the link:
http://geoserver.org/display/GEOS/GSIP+36+-+Resource+-+Publishing+Split+and+Virtual+Configuration

I think these are welcome changes. I have three remarks.

(1) This is an opportunity to expunge remaining assumptions that there
is one only namespace per store.

(2) Profiles would be a good enhancement. WFS limits us to one
collection of a given feature type per service URL. For example, there
can be only one collection of gsml:MappedFeature. Advocates of this
approach would like to see all queries made on properties, but this does
not support different approaches to encoding complex responses. In the
GeoSciML community there are two factions: those who support nesting
properties by value and those who prefer nesting by reference. The use
of profiles in the service URL (I like the context path element option)
would permit one GeoServer instance to serve both a nested-by-value and
a nested-by-reference gsml:MappedFeature. At the moment, we are stuck
either wrapping type (e.g. gsml:MappedFeatureUseCase2A) names or having
multiple GeoServer instances.

(3) The implementation of app-schema feature chaining requires each
AppSchemaDataAccess instance to be aware of those containing properties
it would like to nest. At the moment, we use a private registry. It
would be better if there were more generic approach of inter-DataAccess
communication. This would require, at the minimum, a catalog interface
in GeoTools. Should the core catalog classes be pulled into GeoTools?
Are they sufficiently generic? What does uDig use?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Andrea_Aime3]

Ben Caradoc-Davies ha scritto:

Andrea Aime wrote:

I'm writing this mail to ask everybody to read and review the latest
GSIP, this time dealing with the split between resource management
and data publishing.

And here is the link:
http://geoserver.org/display/GEOS/GSIP+36+-+Resource+-+Publishing+Split+and+Virtual+Configuration

I think these are welcome changes. I have three remarks.

(1) This is an opportunity to expunge remaining assumptions that there is one only namespace per store.

Ideally the namespace should be set on the layer as opposed on
the resource, that is, the namespace should become a publishing
configuration. The one in the datastore may stay or may go,
the way I see it we'll do publishing overrides anyways no?

(2) Profiles would be a good enhancement. WFS limits us to one collection of a given feature type per service URL. For example, there can be only one collection of gsml:MappedFeature. Advocates of this approach would like to see all queries made on properties, but this does not support different approaches to encoding complex responses. In the GeoSciML community there are two factions: those who support nesting properties by value and those who prefer nesting by reference. The use of profiles in the service URL (I like the context path element option) would permit one GeoServer instance to serve both a nested-by-value and a nested-by-reference gsml:MappedFeature. At the moment, we are stuck either wrapping type (e.g. gsml:MappedFeatureUseCase2A) names or having multiple GeoServer instances.

Hum, I believe this could be done by maps as well? Profiles are about
service configurations such as the default max features, the cite
compliance settings, the list of srs reported by wms and so on.
Whatever is service specific as opposed to layer specific.

(3) The implementation of app-schema feature chaining requires each AppSchemaDataAccess instance to be aware of those containing properties it would like to nest. At the moment, we use a private registry. It would be better if there were more generic approach of inter-DataAccess communication. This would require, at the minimum, a catalog interface in GeoTools. Should the core catalog classes be pulled into GeoTools? Are they sufficiently generic? What does uDig use?

uDig has its own, there is a sort of a backport in gt2 land contained
in the unsupported gt2-repository package.
The last time I looked into it was two years ago, when I asked it
to be removed from main as it was confusing and completely void
of unit tests.
If you need that you can try to get it back in supported land,
give it enough testing, and make the API simpler and more to the
point. Once you have that adding a GeoServer module that chains
the GeoServer catalog with that one is possible (something
that also Christian was looking for afaik).

Alternatively we can try to backport the GeoServer catalog, but
I have the impression you don't need all the information our
catalog and xxxInfo objects do provide, a simplified version
that can be shared between GeoServer and uDig would be a good
thing in fact.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Andrea_Aime3]

Jody Garnett ha scritto:

Okay I have gone through a couple of examples now on paper; my
preference would be to present both profiles and maps as part of the
URL path; but I understand this is just a technicality.

I share the same view, I would prefer to have profile and map
be part of the URL, thought the OGC specification do allow the
service root to end with an & instead of a ?, so the following
could equally stand in a caps document:

<OnlineResource ... xlink:href="http://host/geoserver/ows?profile=p&amp;map=m&amp;&quot;/&gt;

but the follwing would look nicer:

<OnlineResource ... xlink:href="http://host/geoserver/p/m/ows?&quot;/&gt;

notice how I did put p and m before ows, meaning the profile
and the map should, imho, influence also REST data services
(WFS atompub presentation anyone?)

The default profile could also be omitted resulting in:

xlink:href="http://host/geoserver/m/ows?

(thought this would make for a slightly tricky profile and map
  assignment code in the Dispatcher).

One thing that was mentioned in the proposal page once and not
revisited was the concept of a "workspace". Andrea can you explain how
these are used; right now I am picturing a concept similar to a folder
used to provide a "tree" structure to organize different datastores; I
assume when you are defining a layer for a map you can refer to data
in any workspace used by your profile.

Indeed, workspaces atm are just an organisational facility. They are
also used by the security subsystem as the root by which the data
access is specified.
Not sure if we want to have a different security setup per profile,
that may have to come later thought (the jury is still out on which
security subsystem we want or on how to make that fully pluggable).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Ben_Caradoc-Davies]

Andrea Aime wrote:

Ben Caradoc-Davies ha scritto:

(1) This is an opportunity to expunge remaining assumptions that there is one only namespace per store.

Ideally the namespace should be set on the layer as opposed on
the resource, that is, the namespace should become a publishing
configuration. The one in the datastore may stay or may go,
the way I see it we'll do publishing overrides anyways no?

Hmm, this is a simple feature view of the world.

Some resources are namespace aware. For example AppSchemaDataAccess provides features of a particular namespace that must not be changed in the publishing layer. It is also possible that DataAccess

Consider also a DataAccess that consumes a non-WFS complex web service and provides many feature types in (potentially) different namespaces. (Hi Russell, I hope you are reading this.) The DataAccess API supports this. GeoServer should not prevent it.

(2) Profiles would be a good enhancement.

[...]

The use of profiles in the service URL (I like the context path element option) would permit one GeoServer instance to serve both a nested-by-value and a nested-by-reference gsml:MappedFeature. At the moment, we are stuck either wrapping type (e.g. gsml:MappedFeatureUseCase2A) names or having multiple GeoServer instances.

[...]

Hum, I believe this could be done by maps as well? Profiles are about
service configurations such as the default max features, the cite
compliance settings, the list of srs reported by wms and so on.
Whatever is service specific as opposed to layer specific.

I am not sure about this. The problem is that some feature types are duplicated, and it would be good to get at the same feature type constructed as different styles of complex feature. I will need to reread GSIP 36

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[Andrea_Aime3]

Ben Caradoc-Davies ha scritto:

Andrea Aime wrote:

Ben Caradoc-Davies ha scritto:

(1) This is an opportunity to expunge remaining assumptions that there is one only namespace per store.

Ideally the namespace should be set on the layer as opposed on
the resource, that is, the namespace should become a publishing
configuration. The one in the datastore may stay or may go,
the way I see it we'll do publishing overrides anyways no?

Hmm, this is a simple feature view of the world.

Some resources are namespace aware. For example AppSchemaDataAccess provides features of a particular namespace that must not be changed in the publishing layer. It is also possible that DataAccess

Consider also a DataAccess that consumes a non-WFS complex web service and provides many feature types in (potentially) different namespaces. (Hi Russell, I hope you are reading this.) The DataAccess API supports this. GeoServer should not prevent it.

Please suggest action items and bring in patches then
This proposal is first and foremost about the publishing part, does
touch the resource part very tangentially (just tries to move some
today's resource properties into layer, publishing ones).

(2) Profiles would be a good enhancement.

[...]

The use of profiles in the service URL (I like the context path element option) would permit one GeoServer instance to serve both a nested-by-value and a nested-by-reference gsml:MappedFeature. At the moment, we are stuck either wrapping type (e.g. gsml:MappedFeatureUseCase2A) names or having multiple GeoServer instances.

[...]

Hum, I believe this could be done by maps as well? Profiles are about
service configurations such as the default max features, the cite
compliance settings, the list of srs reported by wms and so on.
Whatever is service specific as opposed to layer specific.

I am not sure about this. The problem is that some feature types are duplicated, and it would be good to get at the same feature type constructed as different styles of complex feature. I will need to reread GSIP 36

Bring in suggestions, proposals and resources to make what you need
real.
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Justin_Deoliveira]

Ben Caradoc-Davies wrote:

Andrea Aime wrote:

Ben Caradoc-Davies ha scritto:

(1) This is an opportunity to expunge remaining assumptions that there is one only namespace per store.

Ideally the namespace should be set on the layer as opposed on
the resource, that is, the namespace should become a publishing
configuration. The one in the datastore may stay or may go,
the way I see it we'll do publishing overrides anyways no?

Hmm, this is a simple feature view of the world.

Some resources are namespace aware. For example AppSchemaDataAccess provides features of a particular namespace that must not be changed in the publishing layer. It is also possible that DataAccess

I can see the use case for this. I believe this could be solved easily by treating the namespace on a layer as an override. In the case where it is not set it should fall back on whatever namespace the underlying datastore provides, now that type names are qualified.

Consider also a DataAccess that consumes a non-WFS complex web service and provides many feature types in (potentially) different namespaces. (Hi Russell, I hope you are reading this.) The DataAccess API supports this. GeoServer should not prevent it.

(2) Profiles would be a good enhancement.

[...]

The use of profiles in the service URL (I like the context path element option) would permit one GeoServer instance to serve both a nested-by-value and a nested-by-reference gsml:MappedFeature. At the moment, we are stuck either wrapping type (e.g. gsml:MappedFeatureUseCase2A) names or having multiple GeoServer instances.

[...]

Hum, I believe this could be done by maps as well? Profiles are about
service configurations such as the default max features, the cite
compliance settings, the list of srs reported by wms and so on.
Whatever is service specific as opposed to layer specific.

I am not sure about this. The problem is that some feature types are duplicated, and it would be good to get at the same feature type constructed as different styles of complex feature. I will need to reread GSIP 36

Kind regards,

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

[Justin_Deoliveira]

Jody Garnett wrote:

Thanks for your reply Ben; I have been struggling with my own
feedback. The idea of splitting up resoruce from layer is great.
The details of workspace / map and profile are a bit blurred for me.

I do not like the idea of a Map (in the mapserver sense). A map server
mapfile resulting in a different view (or entirely different
presentation) coming out of the same server GetCapabilities end point.
This always struck me as an implementation detail being made public.
And perhaps that is the point here - with the goal of publishing
related information as a group? This could be viewed as a shortfall of
each specification (WMS can group information into parent layers; WFS
kind of publishes by application schema but the relationship is not
explicit).

Contrasted with the idea of revealing a profile; as part of the url;
result in a clean service location for end users. I understand this
difference is only a technicallity; perhaps this is the technicallity
I am getting hung up about.

From an end user standpoint both profiles and maps appear to operate

in the same manner; resulting in a different capabilities document. I
am concerned that it would not be clear which combinations are
allowed; and what the options are.

I am sort of thinking that we should retract on allowing people to embed map/profile info in the base url. The reason being exactly what you state, what combinations are allowed?

Instead, what I think makes sense is to push this off to perhaps a more restful type uri style:

geoserver/profiles/myProfile?request=getCapabilities&...
geoserver/map/myMap?request=getCapabilities&...
geoserver/profiles/myProfile/maps/myMap?request=getCapabilities&...

More verbose, but non-ambiguous.

Jody

On Tue, Apr 28, 2009 at 12:30 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

Andrea Aime wrote:

I'm writing this mail to ask everybody to read and review the latest
GSIP, this time dealing with the split between resource management
and data publishing.

And here is the link:
http://geoserver.org/display/GEOS/GSIP+36+-+Resource+-+Publishing+Split+and+Virtual+Configuration

I think these are welcome changes. I have three remarks.

(1) This is an opportunity to expunge remaining assumptions that there
is one only namespace per store.

(2) Profiles would be a good enhancement. WFS limits us to one
collection of a given feature type per service URL. For example, there
can be only one collection of gsml:MappedFeature. Advocates of this
approach would like to see all queries made on properties, but this does
not support different approaches to encoding complex responses. In the
GeoSciML community there are two factions: those who support nesting
properties by value and those who prefer nesting by reference. The use
of profiles in the service URL (I like the context path element option)
would permit one GeoServer instance to serve both a nested-by-value and
a nested-by-reference gsml:MappedFeature. At the moment, we are stuck
either wrapping type (e.g. gsml:MappedFeatureUseCase2A) names or having
multiple GeoServer instances.

(3) The implementation of app-schema feature chaining requires each
AppSchemaDataAccess instance to be aware of those containing properties
it would like to nest. At the moment, we use a private registry. It
would be better if there were more generic approach of inter-DataAccess
communication. This would require, at the minimum, a catalog interface
in GeoTools. Should the core catalog classes be pulled into GeoTools?
Are they sufficiently generic? What does uDig use?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

[jive]

Instead, what I think makes sense is to push this off to perhaps a more
restful type uri style:

geoserver/profiles/myProfile?request=getCapabilities&...
geoserver/map/myMap?request=getCapabilities&...
geoserver/profiles/myProfile/maps/myMap?request=getCapabilities&...

More verbose, but non-ambiguous.

I agree it is more clear; but I am still having fun sorting out as a
user what I would expect from the different combinations Both
appear to be ways of changing the capabilities document somehow...

Could we define a "geoserver" and list them; and as part of the
geoserver have people configure which profile and map are used ...
that way from a user standpoint it appears as if there is simply
several entry points; each with their own capabilities document.

Jody

[Ben_Caradoc-Davies]

Jody Garnett wrote:
> Justin wrote:

Instead, what I think makes sense is to push this off to perhaps a more
restful type uri style:

geoserver/profiles/myProfile?request=getCapabilities&...
geoserver/map/myMap?request=getCapabilities&...
geoserver/profiles/myProfile/maps/myMap?request=getCapabilities&...

More verbose, but non-ambiguous.

I agree it is more clear; but I am still having fun sorting out as a
user what I would expect from the different combinations Both
appear to be ways of changing the capabilities document somehow...

Could we define a "geoserver" and list them; and as part of the
geoserver have people configure which profile and map are used ...
that way from a user standpoint it appears as if there is simply
several entry points; each with their own capabilities document.

Or you could publish the configured URLs in a catalog.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[Andrea_Aime3]

Jody Garnett ha scritto:

I agree it is more clear; but I am still having fun sorting out as a
user what I would expect from the different combinations Both
appear to be ways of changing the capabilities document somehow...

Could we define a "geoserver" and list them; and as part of the
geoserver have people configure which profile and map are used ...
that way from a user standpoint it appears as if there is simply
several entry points; each with their own capabilities document.

Well, the idea is exactly that, to provide several entry points,
everybody managing a big SDI (and his dog too) is asking for it.

Maybe the issue you have is about the multiplicity of profile/map
association? Like, any map and any profile can be combined?
Or a profile owns maps?

MapInfo does not have a profile property, and ProfileInfo has
a list of maps. This leaves us with two possibilities:
- a profile owns the maps
- multiple profiles can share the same map (cross product)

From a very cursory re-read of GSIP-36 I cannot tell which
is the right answer

Cheers
Andrea

[jive]

Well, the idea is exactly that, to provide several entry points,
everybody managing a big SDI (and his dog too) is asking for it.

Agreed.

Maybe the issue you have is about the multiplicity of profile/map
association? Like, any map and any profile can be combined?
Or a profile owns maps?

Yes; the subject of profiles and maps seems a bit much to expose to
users. I would rather expose them "geoservers" and leave the
definition of a geoserver (in terms of a profile+map) as something
that the only viewable in the configuration screen.

Information hiding; I do not want to admit to the idea of profiles and
maps to end users; I just want to admit that I have some OGC services
available.

MapInfo does not have a profile property, and ProfileInfo has
a list of maps. This leaves us with two possibilities:
- a profile owns the maps
- multiple profiles can share the same map (cross product)

From a very cursory re-read of GSIP-36 I cannot tell which
is the right answer

Cheers
Andrea

[Justin_Deoliveira]

Jody Garnett wrote:

Instead, what I think makes sense is to push this off to perhaps a more
restful type uri style:

geoserver/profiles/myProfile?request=getCapabilities&...
geoserver/map/myMap?request=getCapabilities&...
geoserver/profiles/myProfile/maps/myMap?request=getCapabilities&...

More verbose, but non-ambiguous.

I agree it is more clear; but I am still having fun sorting out as a
user what I would expect from the different combinations Both
appear to be ways of changing the capabilities document somehow...

Could we define a "geoserver" and list them; and as part of the
geoserver have people configure which profile and map are used ...
that way from a user standpoint it appears as if there is simply
several entry points; each with their own capabilities document.

If we move to more restful style, we could have a GET request to http://…/geoserver (specifying perhaps a particular Accepts header) return an xml document which enumerates all the top level profiles and/or maps:

<geoServer>
   <profiles>
     <profile>http://…/geoserver/profiles/foo</profile>
     <profile>http://…/geoserver/profiles/bar</profile>
   </profiles>
   <maps>
     ...
   </maps>
</geoServer>

And so on and so forth. Anyways, luckily the view we put on virtual configurations to the outside world can be flexible, and I don't think we have to completely hash it out now. Most of the interesting stuff for this proposal goes on internally.

Jody

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.