[Geoserver-devel] New feature: hiding layers from capabilities

Hi,
I'd like to propose (and implement) a new feature for the GeoServer
configuration,
the ability to hide a layer from the capabilities: simple checkbox
making the layer
available, or not.

A hidden layer can be useful in some cases:
- the layer should be part of a group, but we want to show the group,
not the inner
  layers, to the world
- the layer is temporary and somehow linked to a user session, we don't want
  to show it to the wide world yet we need it to be around and usable from
  OGC service calls
- the layer is going to stay there, but it's a service one, something that a
  particular application uses under covers but that we don't want normal clients
  to see and use (not for security issues, but just to avoid
  making the capabilities contents too verbose/confusing)

The idea would be to add the flag to LayerInfo, as a new method in the API.
Yet I'd need to have this in 2.1.x too (this would be a sponsored feature),
and we have had a number of these issue in the past... I think I have
a solution:
- on 2.1.x add the property in the interface, but make it a derived one picking
  on the user map
- on trunk add the field as a Boolean, and inspect the user map as a fallback
  when the field is not set

Opinions?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

+1 on the idea, i actually ran into this problem recently and this would have been quite useful. So I guess this means all the capabilities transformers will have to be updated as well… which at this point is quite a few. And what does “hidden” mean when it comes to the other requests… GetFeature, GetMap, etc… should the services check the hidden flag when those resources are accessed individually?

The idea I had before was to try and use a thread local catalog approach to this, similar to how the virtual services hide layers not in the local workspace. Basically an filter/callback/etc… would set up a thread local view of the catalog (with a custom resource access manager, etc…) that would prevent access to hidden layers. The benefit of this approach being that no service code would really have to be updated at all.

$0.02

-Justin

On Tue, Sep 6, 2011 at 1:22 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I’d like to propose (and implement) a new feature for the GeoServer
configuration,
the ability to hide a layer from the capabilities: simple checkbox
making the layer
available, or not.

A hidden layer can be useful in some cases:

  • the layer should be part of a group, but we want to show the group,
    not the inner
    layers, to the world
  • the layer is temporary and somehow linked to a user session, we don’t want
    to show it to the wide world yet we need it to be around and usable from
    OGC service calls
  • the layer is going to stay there, but it’s a service one, something that a
    particular application uses under covers but that we don’t want normal clients
    to see and use (not for security issues, but just to avoid
    making the capabilities contents too verbose/confusing)

The idea would be to add the flag to LayerInfo, as a new method in the API.
Yet I’d need to have this in 2.1.x too (this would be a sponsored feature),
and we have had a number of these issue in the past… I think I have
a solution:

  • on 2.1.x add the property in the interface, but make it a derived one picking
    on the user map
  • on trunk add the field as a Boolean, and inspect the user map as a fallback
    when the field is not set

Opinions?

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Special Offer – Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you’ll get a free “Love Thy Logs” t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


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

On Tue, Sep 6, 2011 at 4:57 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

+1 on the idea, i actually ran into this problem recently and this would
have been quite useful. So I guess this means all the capabilities
transformers will have to be updated as well... which at this point is quite
a few. And what does "hidden" mean when it comes to the other requests...
GetFeature, GetMap, etc... should the services check the hidden flag when
those resources are accessed individually?

Hidden would hide just from the capabilities, which yeah, would require the
caps transformers to be modified, but I don't believe it's a big deal, it's
4-5 classes?

But all other code would not be affected, you'd see the layer directly.

The idea I had before was to try and use a thread local catalog approach to
this, similar to how the virtual services hide layers not in the local
workspace. Basically an filter/callback/etc... would set up a thread local
view of the catalog (with a custom resource access manager, etc...) that
would prevent access to hidden layers. The benefit of this approach being
that no service code would really have to be updated at all.

Right... check if the current request is GetCapabilities and make those
layers disappear.
Would work indeed. Wondering, that would start making for the third
wrapper around the catalog... sounds like we need some sort of
extension point for catalog interceptors?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Nice feature Andrea,

Thanks for continuous improvements

2011/9/6 Andrea Aime <andrea.aime@anonymised.com>

On Tue, Sep 6, 2011 at 4:57 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

+1 on the idea, i actually ran into this problem recently and this would
have been quite useful. So I guess this means all the capabilities
transformers will have to be updated as well… which at this point is quite
a few. And what does “hidden” mean when it comes to the other requests…
GetFeature, GetMap, etc… should the services check the hidden flag when
those resources are accessed individually?

Hidden would hide just from the capabilities, which yeah, would require the
caps transformers to be modified, but I don’t believe it’s a big deal, it’s
4-5 classes?

But all other code would not be affected, you’d see the layer directly.

The idea I had before was to try and use a thread local catalog approach to
this, similar to how the virtual services hide layers not in the local
workspace. Basically an filter/callback/etc… would set up a thread local
view of the catalog (with a custom resource access manager, etc…) that
would prevent access to hidden layers. The benefit of this approach being
that no service code would really have to be updated at all.

Right… check if the current request is GetCapabilities and make those
layers disappear.
Would work indeed. Wondering, that would start making for the third
wrapper around the catalog… sounds like we need some sort of
extension point for catalog interceptors?

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Special Offer – Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you’ll get a free “Love Thy Logs” t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Francesco Izzi
CNR - IMAA
geoSDI
Direzione Tecnologie e Sviluppo

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3203126609
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

On Tue, Sep 6, 2011 at 10:32 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Sep 6, 2011 at 4:57 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

+1 on the idea, i actually ran into this problem recently and this would
have been quite useful. So I guess this means all the capabilities
transformers will have to be updated as well… which at this point is quite
a few. And what does “hidden” mean when it comes to the other requests…
GetFeature, GetMap, etc… should the services check the hidden flag when
those resources are accessed individually?

Hidden would hide just from the capabilities, which yeah, would require the
caps transformers to be modified, but I don’t believe it’s a big deal, it’s
4-5 classes?

But all other code would not be affected, you’d see the layer directly.

Ok, maybe “hidden” is not the best term then. Maybe something like “isDeclared” or something… just brainstorming.

The idea I had before was to try and use a thread local catalog approach to
this, similar to how the virtual services hide layers not in the local
workspace. Basically an filter/callback/etc… would set up a thread local
view of the catalog (with a custom resource access manager, etc…) that
would prevent access to hidden layers. The benefit of this approach being
that no service code would really have to be updated at all.

Right… check if the current request is GetCapabilities and make those
layers disappear.
Would work indeed. Wondering, that would start making for the third
wrapper around the catalog… sounds like we need some sort of
extension point for catalog interceptors?

Yeah agreed. Good idea. It would be nice to have one resource wrapper capable of hiding resources based on the extension point.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



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

Hidden would hide just from the capabilities, which yeah, would require the
caps transformers to be modified, but I don’t believe it’s a big deal, it’s
4-5 classes?

But all other code would not be affected, you’d see the layer directly.

Ok, maybe “hidden” is not the best term then. Maybe something like “isDeclared” or something… just brainstorming.

How about “listed”

The idea I had before was to try and use a thread local catalog approach to
this, similar to how the virtual services hide layers not in the local
workspace. Basically an filter/callback/etc… would set up a thread local
view of the catalog (with a custom resource access manager, etc…) that
would prevent access to hidden layers. The benefit of this approach being
that no service code would really have to be updated at all.

Right… check if the current request is GetCapabilities and make those
layers disappear.
Would work indeed. Wondering, that would start making for the third
wrapper around the catalog… sounds like we need some sort of
extension point for catalog interceptors?

Yeah agreed. Good idea. It would be nice to have one resource wrapper capable of hiding resources based on the extension point.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



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


Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Wed, Sep 7, 2011 at 2:05 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hidden would hide just from the capabilities, which yeah, would require the
caps transformers to be modified, but I don't believe it's a big deal, it's
4-5 classes?

But all other code would not be affected, you'd see the layer directly.

Ok, maybe "hidden" is not the best term then. Maybe something like
"isDeclared" or something... just brainstorming.

How about "listed"

Advertised?

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On Wed, Sep 7, 2011 at 7:08 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Sep 7, 2011 at 2:05 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hidden would hide just from the capabilities, which yeah, would require the
caps transformers to be modified, but I don’t believe it’s a big deal, it’s
4-5 classes?

But all other code would not be affected, you’d see the layer directly.

Ok, maybe “hidden” is not the best term then. Maybe something like
“isDeclared” or something… just brainstorming.

How about “listed”

Advertised?

Yup, like this one the best.

Cheers
Andrea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



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