[Geoserver-devel] App-schema layer.xml question

GeoServer GeoServer Developer
1

Hello app-schema enthusiasts,

I have a question regarding layer.xml. Feature chaining lets us break up mappings for different types, including non-feature types, eg. data type (so they can be reusable, ie. if a non-feature type A is nested inside type B and C, I only need to create the config once). The problem is these non-feature types also appear inside feature type list in GetCapabilities output.
I spoke to Gabriel during his visit in Perth, and he said that if the layer is disabled, the type shouldn’t appear in GetCapabilities.
This makes sense to me, since enabled layers would let us run getFeatures on the type via the UI. So if we can’t see the features (ie. the layer is disabled), why should it show in GetCapabilities.
The problem is, regardless of whether or not the layer.xml is disabled, or non-existent, all types would still appear in GetCapabilities.
Is this a bug? Can someone tell me the true purpose of this layer setting…

Cheers
Rini

2

Rini.Angreani@anonymised.com ha scritto:

Hello app-schema enthusiasts,
I have a question regarding layer.xml. Feature chaining lets us break up mappings for different types, including non-feature types, eg. data type (so they can be reusable, ie. if a non-feature type A is nested inside type B and C, I only need to create the config once). The problem is these non-feature types also appear inside feature type list in GetCapabilities output.
I spoke to Gabriel during his visit in Perth, and he said that if the layer is disabled, the type shouldn't appear in GetCapabilities.
This makes sense to me, since enabled layers would let us run getFeatures on the type via the UI. So if we can't see the features (ie. the layer is disabled), why should it show in GetCapabilities.
The problem is, regardless of whether or not the layer.xml is disabled, or non-existent, all types would still appear in GetCapabilities.
Is this a bug? Can someone tell me the true purpose of this layer setting..

The resource/publishing split is not done, this means the current
catalog behaves a lot like the old one.
WFS and WCS services are still coded against the resources, the layer
is almost ignored, so I guess you'll have to disable the resources in
order to avoid having them show up in the capabilities.
Now, when you do that, I'm not sure you'll still be able to grab
feature sources out of them thought (did not check)

Cheers
Andrea

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

3

Hi Rini,

you're right, it should be true that if the layer is disabled it should not show up on getcaps. If it's not it's a bug ans as Andrea pointed out one quite possibly left there as the result of the resource/publish split not yet being finished.

Still, remember that's not the ideal solution for your problem. In which you are interested in publishing one feature type, but given the current configuration structure for app-schema you need to configure the related feature types. But that's coincidential and we shouldn't be relying on that at all, since it means relying on a side effect. The side effect being that the only way to load the related featuretypes in the app-schema type registry is for geoserver to somewhat load their configurations, so they register themselves on the app-schema registry.

This is obviously less that desired, and means we need some sort of configuration include procedure so a given app-schema mappings file can refer to it's related ones. Then they can be ingested at once without the need to publish nor configure them on geoserver.

Does that make sense?

If so you can maybe add an include element in the app-schema mappings file xsd and instruct the config loader to ingest included mappings too. Something on the lines of:

<AppSchemaDataAccess>
   <include url="../CGITermValue.xml">
   <include url="CompositionPart.xml">
...

Cheers,
Gabriel
Andrea Aime wrote:

Rini.Angreani@anonymised.com ha scritto:

Hello app-schema enthusiasts,
I have a question regarding layer.xml. Feature chaining lets us break up mappings for different types, including non-feature types, eg. data type (so they can be reusable, ie. if a non-feature type A is nested inside type B and C, I only need to create the config once). The problem is these non-feature types also appear inside feature type list in GetCapabilities output.
I spoke to Gabriel during his visit in Perth, and he said that if the layer is disabled, the type shouldn't appear in GetCapabilities.
This makes sense to me, since enabled layers would let us run getFeatures on the type via the UI. So if we can't see the features (ie. the layer is disabled), why should it show in GetCapabilities.
The problem is, regardless of whether or not the layer.xml is disabled, or non-existent, all types would still appear in GetCapabilities.
Is this a bug? Can someone tell me the true purpose of this layer setting..

The resource/publishing split is not done, this means the current
catalog behaves a lot like the old one.
WFS and WCS services are still coded against the resources, the layer
is almost ignored, so I guess you'll have to disable the resources in
order to avoid having them show up in the capabilities.
Now, when you do that, I'm not sure you'll still be able to grab
feature sources out of them thought (did not check)

Cheers
Andrea

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

Gabriel Roldan ha scritto:

Hi Rini,

you're right, it should be true that if the layer is disabled it should not show up on getcaps. If it's not it's a bug ans as Andrea pointed out one quite possibly left there as the result of the resource/publish split not yet being finished.

Oh boy. The bug is in this broken understanding that layer and resources
are somewhat decoupled in the current trunk. They are not, this has been
states a number of times already.

Workspaces and namespaces are one.
Layer and resources are one. A layer cannot be disabled without disabling the resource as well, if this is allowed, then this is the bug, not otherwise.
Repeat with me: there is no resource/publish split in act.

The current situation is transitional, to avoid making too many changes
in one go and be stuck for 6 months recovering from the changes.

I hope this clarifies things a little
Cheers
Andrea

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

5

Andrea Aime wrote:

Gabriel Roldan ha scritto:

Hi Rini,

you're right, it should be true that if the layer is disabled it should not show up on getcaps. If it's not it's a bug ans as Andrea pointed out one quite possibly left there as the result of the resource/publish split not yet being finished.

Oh boy. The bug is in this broken understanding that layer and resources
are somewhat decoupled in the current trunk. They are not, this has been
states a number of times already.

Workspaces and namespaces are one.
Layer and resources are one. A layer cannot be disabled without disabling the resource as well, if this is allowed, then this is the bug, not otherwise.
Repeat with me: there is no resource/publish split in act.

The current situation is transitional, to avoid making too many changes
in one go and be stuck for 6 months recovering from the changes.

I hope this clarifies things a little

Disregard you think I don't yet understand that. I should have said the split not existing yet, my fault. My point was helping Rini take a direction where she doesn't need to depend on a collateral effect of a higher level entity (geoserver) to get her lower level one (the DataAccess) to find the related resources it needs.

Cheers,

Gabriel

Cheers
Andrea

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

6

Gabriel Roldan ha scritto:

Andrea Aime wrote:

Gabriel Roldan ha scritto:

Hi Rini,

you're right, it should be true that if the layer is disabled it should not show up on getcaps. If it's not it's a bug ans as Andrea pointed out one quite possibly left there as the result of the resource/publish split not yet being finished.

Oh boy. The bug is in this broken understanding that layer and resources
are somewhat decoupled in the current trunk. They are not, this has been
states a number of times already.

Workspaces and namespaces are one.
Layer and resources are one. A layer cannot be disabled without disabling the resource as well, if this is allowed, then this is the bug, not otherwise.
Repeat with me: there is no resource/publish split in act.

The current situation is transitional, to avoid making too many changes
in one go and be stuck for 6 months recovering from the changes.

I hope this clarifies things a little

Disregard you think I don't yet understand that. I should have said the split not existing yet, my fault. My point was helping Rini take a direction where she doesn't need to depend on a collateral effect of a higher level entity (geoserver) to get her lower level one (the DataAccess) to find the related resources it needs.

This confusion popped up a number of times and seeing it once again
raised blood to my brain. Apologies for being rude :frowning:

Cheers
Andrea

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

7

Gabriel,
You are right. If the related types aren't loaded before the containing type, then it won't work.
Thank's for the suggestion. This certainly takes precedence over hiding non-feature types in getCapabilities.

Cheers
Rini

-----Original Message-----
From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Tuesday, 30 June 2009 8:10 PM
To: Andrea Aime
Cc: Angreani, Rini (E&M, Kensington); geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] App-schema layer.xml question

Hi Rini,

you're right, it should be true that if the layer is disabled it should
not show up on getcaps. If it's not it's a bug ans as Andrea pointed out
one quite possibly left there as the result of the resource/publish
split not yet being finished.

Still, remember that's not the ideal solution for your problem. In which
you are interested in publishing one feature type, but given the current
configuration structure for app-schema you need to configure the related
feature types. But that's coincidential and we shouldn't be relying on
that at all, since it means relying on a side effect. The side effect
being that the only way to load the related featuretypes in the
app-schema type registry is for geoserver to somewhat load their
configurations, so they register themselves on the app-schema registry.

This is obviously less that desired, and means we need some sort of
configuration include procedure so a given app-schema mappings file can
refer to it's related ones. Then they can be ingested at once without
the need to publish nor configure them on geoserver.

Does that make sense?

If so you can maybe add an include element in the app-schema mappings
file xsd and instruct the config loader to ingest included mappings too.
Something on the lines of:

<AppSchemaDataAccess>
   <include url="../CGITermValue.xml">
   <include url="CompositionPart.xml">
...

Cheers,
Gabriel
Andrea Aime wrote:

Rini.Angreani@anonymised.com ha scritto:

Hello app-schema enthusiasts,

I have a question regarding layer.xml. Feature chaining lets us break up
mappings for different types, including non-feature types, eg. data
type (so they can be reusable, ie. if a non-feature type A is nested
inside type B and C, I only need to create the config once). The problem
is these non-feature types also appear inside feature type list in
GetCapabilities output.
I spoke to Gabriel during his visit in Perth, and he said that if the
layer is disabled, the type shouldn't appear in GetCapabilities.
This makes sense to me, since enabled layers would let us run
getFeatures on the type via the UI. So if we can't see the features (ie.
the layer is disabled), why should it show in GetCapabilities.
The problem is, regardless of whether or not the layer.xml is disabled,
or non-existent, all types would still appear in GetCapabilities.
Is this a bug? Can someone tell me the true purpose of this layer setting..

The resource/publishing split is not done, this means the current
catalog behaves a lot like the old one.
WFS and WCS services are still coded against the resources, the layer
is almost ignored, so I guess you'll have to disable the resources in
order to avoid having them show up in the capabilities.
Now, when you do that, I'm not sure you'll still be able to grab
feature sources out of them thought (did not check)

Cheers
Andrea

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

8

Ah sorry I misunderstood you. I understand now. The solution is to unpublish the non-feature types, and make them visible only to the containing types (by using includes in the mapping file).
OK, that makes sense. Thank you.

Rini

-----Original Message-----
From: Angreani, Rini (E&M, Kensington)
Sent: Thursday, 2 July 2009 10:49 AM
To: 'Gabriel Roldan'
Cc: geoserver-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] App-schema layer.xml question

Gabriel,
You are right. If the related types aren't loaded before the containing type, then it won't work.
Thank's for the suggestion. This certainly takes precedence over hiding non-feature types in getCapabilities.

Cheers
Rini

-----Original Message-----
From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Tuesday, 30 June 2009 8:10 PM
To: Andrea Aime
Cc: Angreani, Rini (E&M, Kensington); geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] App-schema layer.xml question

Hi Rini,

you're right, it should be true that if the layer is disabled it should
not show up on getcaps. If it's not it's a bug ans as Andrea pointed out
one quite possibly left there as the result of the resource/publish
split not yet being finished.

Still, remember that's not the ideal solution for your problem. In which
you are interested in publishing one feature type, but given the current
configuration structure for app-schema you need to configure the related
feature types. But that's coincidential and we shouldn't be relying on
that at all, since it means relying on a side effect. The side effect
being that the only way to load the related featuretypes in the
app-schema type registry is for geoserver to somewhat load their
configurations, so they register themselves on the app-schema registry.

This is obviously less that desired, and means we need some sort of
configuration include procedure so a given app-schema mappings file can
refer to it's related ones. Then they can be ingested at once without
the need to publish nor configure them on geoserver.

Does that make sense?

If so you can maybe add an include element in the app-schema mappings
file xsd and instruct the config loader to ingest included mappings too.
Something on the lines of:

<AppSchemaDataAccess>
   <include url="../CGITermValue.xml">
   <include url="CompositionPart.xml">
...

Cheers,
Gabriel
Andrea Aime wrote:

Rini.Angreani@anonymised.com ha scritto:

Hello app-schema enthusiasts,

I have a question regarding layer.xml. Feature chaining lets us break up
mappings for different types, including non-feature types, eg. data
type (so they can be reusable, ie. if a non-feature type A is nested
inside type B and C, I only need to create the config once). The problem
is these non-feature types also appear inside feature type list in
GetCapabilities output.
I spoke to Gabriel during his visit in Perth, and he said that if the
layer is disabled, the type shouldn't appear in GetCapabilities.
This makes sense to me, since enabled layers would let us run
getFeatures on the type via the UI. So if we can't see the features (ie.
the layer is disabled), why should it show in GetCapabilities.
The problem is, regardless of whether or not the layer.xml is disabled,
or non-existent, all types would still appear in GetCapabilities.
Is this a bug? Can someone tell me the true purpose of this layer setting..

The resource/publishing split is not done, this means the current
catalog behaves a lot like the old one.
WFS and WCS services are still coded against the resources, the layer
is almost ignored, so I guess you'll have to disable the resources in
order to avoid having them show up in the capabilities.
Now, when you do that, I'm not sure you'll still be able to grab
feature sources out of them thought (did not check)

Cheers
Andrea

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.