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:grol...@opengeo.org] 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.angre...@csiro.au 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. ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
