[Geoserver-devel] Specifying scale ranges for layers in layer groups (GEOS-7063)

GeoServer GeoServer Developer
1

I’m looking at ways we could make it easier to manage scale based visibility of layers in a layer group.

At the moment I’m thinking the best way to do it would be to add a list of scale ranges to layer groups in parallel to the existing lists of publishables and styles with the same pair of accessors (one for children, one for a flattened list of descendants)

Then in the WMS module when the StyleInfo objects are retrieved and used to get the Style objects (Happens in two places, one for GetMap, one for GetLegend), a StyleVisitor could be sent over the styles to adjust the scale rules so they are suitably restricted.

This would simplify the process of building complex layer groups as it would place all the scale dependant visibility information in one place instead of having to coordinate it across multiple styles.

This would either require a new kind of layer group that the WMS module would have to detect, or a change to the LayerGroupInfo interface to add new methods. I expect the latter would call for a GSIP.

Does anyone have any thoughts?

···

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

2

An alternative to changing the layer group info is to change the layer to include min/max scale information. Ideally do to DRY (do not repeat yourself) I would like to see the min/max scale calculated from the style … and refreshed each time the style is changed.

I guess it is tricky as the scale based on which style the user has requested; or in this case the layer group has been configured with.

In the WMS module during a GetMap request (rather than adjust the styles using a style visitor) you could discard layers that do not match the current scale from further processing

···

On 12 June 2015 at 11:43, Kevin Smith <ksmith@anonymised.com> wrote:

I’m looking at ways we could make it easier to manage scale based visibility of layers in a layer group.

At the moment I’m thinking the best way to do it would be to add a list of scale ranges to layer groups in parallel to the existing lists of publishables and styles with the same pair of accessors (one for children, one for a flattened list of descendants)

Then in the WMS module when the StyleInfo objects are retrieved and used to get the Style objects (Happens in two places, one for GetMap, one for GetLegend), a StyleVisitor could be sent over the styles to adjust the scale rules so they are suitably restricted.

This would simplify the process of building complex layer groups as it would place all the scale dependant visibility information in one place instead of having to coordinate it across multiple styles.

This would either require a new kind of layer group that the WMS module would have to detect, or a change to the LayerGroupInfo interface to add new methods. I expect the latter would call for a GSIP.

Does anyone have any thoughts?

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

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

–
Jody Garnett

3

I considered putting the scale range on the layer rather than the layer group, but it seems less useful. A layer may be used in multiple layer groups with the same style differing only in the scale range it’s used at. For one layer in isolation, saving on scales across the rules in a style is fairly minor compared to doing that across multiple layers in a group, in a group specific way.

The style change would be filtering at the point where the style is being loaded for rendering, not a change to the stored style. Conceptually the scale range on the layer and scale ranges used in styles would be separate things. Implementing the former by tweaking the latter would be an implementation detail. It’s just that it looks to me like the easiest way to manage this. An alternative would be to calculate the scale and then remove any sublayers that are out of scale. As far as the user and the catalog are concerned, whether it’s layers being removed, or styles being filtered should be irrelevant.

···

On 12 June 2015 at 12:28, Jody Garnett <jody.garnett@anonymised.com> wrote:

An alternative to changing the layer group info is to change the layer to include min/max scale information. Ideally do to DRY (do not repeat yourself) I would like to see the min/max scale calculated from the style … and refreshed each time the style is changed.

I guess it is tricky as the scale based on which style the user has requested; or in this case the layer group has been configured with.

In the WMS module during a GetMap request (rather than adjust the styles using a style visitor) you could discard layers that do not match the current scale from further processing

–

–
Jody Garnett

On 12 June 2015 at 11:43, Kevin Smith <ksmith@anonymised.com> wrote:

I’m looking at ways we could make it easier to manage scale based visibility of layers in a layer group.

At the moment I’m thinking the best way to do it would be to add a list of scale ranges to layer groups in parallel to the existing lists of publishables and styles with the same pair of accessors (one for children, one for a flattened list of descendants)

Then in the WMS module when the StyleInfo objects are retrieved and used to get the Style objects (Happens in two places, one for GetMap, one for GetLegend), a StyleVisitor could be sent over the styles to adjust the scale rules so they are suitably restricted.

This would simplify the process of building complex layer groups as it would place all the scale dependant visibility information in one place instead of having to coordinate it across multiple styles.

This would either require a new kind of layer group that the WMS module would have to detect, or a change to the LayerGroupInfo interface to add new methods. I expect the latter would call for a GSIP.

Does anyone have any thoughts?

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

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

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

4

How do we plan to expose the vendorOptions() for LayerGroups? Given that they will affect how layers are displayed, they should be editable from the GeoServer UI, but an arbitrary Map of values does not really lend itself to a user friendly display.

Exposing these values via the REST API should also be done, but seems much simpler.

Torben

···

On Fri, Jun 12, 2015 at 1:50 PM, Kevin Smith <ksmith@anonymised.com> wrote:

I considered putting the scale range on the layer rather than the layer group, but it seems less useful. A layer may be used in multiple layer groups with the same style differing only in the scale range it’s used at. For one layer in isolation, saving on scales across the rules in a style is fairly minor compared to doing that across multiple layers in a group, in a group specific way.

The style change would be filtering at the point where the style is being loaded for rendering, not a change to the stored style. Conceptually the scale range on the layer and scale ranges used in styles would be separate things. Implementing the former by tweaking the latter would be an implementation detail. It’s just that it looks to me like the easiest way to manage this. An alternative would be to calculate the scale and then remove any sublayers that are out of scale. As far as the user and the catalog are concerned, whether it’s layers being removed, or styles being filtered should be irrelevant.

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

On 12 June 2015 at 12:28, Jody Garnett <jody.garnett@anonymised.com403…> wrote:

An alternative to changing the layer group info is to change the layer to include min/max scale information. Ideally do to DRY (do not repeat yourself) I would like to see the min/max scale calculated from the style … and refreshed each time the style is changed.

I guess it is tricky as the scale based on which style the user has requested; or in this case the layer group has been configured with.

In the WMS module during a GetMap request (rather than adjust the styles using a style visitor) you could discard layers that do not match the current scale from further processing

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

–
Jody Garnett

On 12 June 2015 at 11:43, Kevin Smith <ksmith@anonymised.com> wrote:

I’m looking at ways we could make it easier to manage scale based visibility of layers in a layer group.

At the moment I’m thinking the best way to do it would be to add a list of scale ranges to layer groups in parallel to the existing lists of publishables and styles with the same pair of accessors (one for children, one for a flattened list of descendants)

Then in the WMS module when the StyleInfo objects are retrieved and used to get the Style objects (Happens in two places, one for GetMap, one for GetLegend), a StyleVisitor could be sent over the styles to adjust the scale rules so they are suitably restricted.

This would simplify the process of building complex layer groups as it would place all the scale dependant visibility information in one place instead of having to coordinate it across multiple styles.

This would either require a new kind of layer group that the WMS module would have to detect, or a change to the LayerGroupInfo interface to add new methods. I expect the latter would call for a GSIP.

Does anyone have any thoughts?

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

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

5

Do we have any similar UI examples? Text field would be quick, a table like the layer Metadata Links would be kinder (but harder to implement).

···

On 12 August 2015 at 15:56, Torben Barsballe <tbarsballe@anonymised.com> wrote:

How do we plan to expose the vendorOptions() for LayerGroups? Given that they will affect how layers are displayed, they should be editable from the GeoServer UI, but an arbitrary Map of values does not really lend itself to a user friendly display.

Exposing these values via the REST API should also be done, but seems much simpler.

Torben

–
Jody Garnett

On Fri, Jun 12, 2015 at 1:50 PM, Kevin Smith <ksmith@anonymised.com> wrote:

I considered putting the scale range on the layer rather than the layer group, but it seems less useful. A layer may be used in multiple layer groups with the same style differing only in the scale range it’s used at. For one layer in isolation, saving on scales across the rules in a style is fairly minor compared to doing that across multiple layers in a group, in a group specific way.

The style change would be filtering at the point where the style is being loaded for rendering, not a change to the stored style. Conceptually the scale range on the layer and scale ranges used in styles would be separate things. Implementing the former by tweaking the latter would be an implementation detail. It’s just that it looks to me like the easiest way to manage this. An alternative would be to calculate the scale and then remove any sublayers that are out of scale. As far as the user and the catalog are concerned, whether it’s layers being removed, or styles being filtered should be irrelevant.

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

On 12 June 2015 at 12:28, Jody Garnett <jody.garnett@anonymised.com> wrote:

An alternative to changing the layer group info is to change the layer to include min/max scale information. Ideally do to DRY (do not repeat yourself) I would like to see the min/max scale calculated from the style … and refreshed each time the style is changed.

I guess it is tricky as the scale based on which style the user has requested; or in this case the layer group has been configured with.

In the WMS module during a GetMap request (rather than adjust the styles using a style visitor) you could discard layers that do not match the current scale from further processing

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

–
Jody Garnett

On 12 June 2015 at 11:43, Kevin Smith <ksmith@anonymised.com> wrote:

I’m looking at ways we could make it easier to manage scale based visibility of layers in a layer group.

At the moment I’m thinking the best way to do it would be to add a list of scale ranges to layer groups in parallel to the existing lists of publishables and styles with the same pair of accessors (one for children, one for a flattened list of descendants)

Then in the WMS module when the StyleInfo objects are retrieved and used to get the Style objects (Happens in two places, one for GetMap, one for GetLegend), a StyleVisitor could be sent over the styles to adjust the scale rules so they are suitably restricted.

This would simplify the process of building complex layer groups as it would place all the scale dependant visibility information in one place instead of having to coordinate it across multiple styles.

This would either require a new kind of layer group that the WMS module would have to detect, or a change to the LayerGroupInfo interface to add new methods. I expect the latter would call for a GSIP.

Does anyone have any thoughts?

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

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

6

The other challenge is trying to fit it in the Layer list table on the LayerGroup page, since each map is associated with one of the layers in the layer group.

Torben

···

On Wed, Aug 12, 2015 at 4:06 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Do we have any similar UI examples? Text field would be quick, a table like the layer Metadata Links would be kinder (but harder to implement).

–
Jody Garnett

On 12 August 2015 at 15:56, Torben Barsballe <tbarsballe@anonymised.com> wrote:

How do we plan to expose the vendorOptions() for LayerGroups? Given that they will affect how layers are displayed, they should be editable from the GeoServer UI, but an arbitrary Map of values does not really lend itself to a user friendly display.

Exposing these values via the REST API should also be done, but seems much simpler.

Torben

On Fri, Jun 12, 2015 at 1:50 PM, Kevin Smith <ksmith@anonymised.com> wrote:

I considered putting the scale range on the layer rather than the layer group, but it seems less useful. A layer may be used in multiple layer groups with the same style differing only in the scale range it’s used at. For one layer in isolation, saving on scales across the rules in a style is fairly minor compared to doing that across multiple layers in a group, in a group specific way.

The style change would be filtering at the point where the style is being loaded for rendering, not a change to the stored style. Conceptually the scale range on the layer and scale ranges used in styles would be separate things. Implementing the former by tweaking the latter would be an implementation detail. It’s just that it looks to me like the easiest way to manage this. An alternative would be to calculate the scale and then remove any sublayers that are out of scale. As far as the user and the catalog are concerned, whether it’s layers being removed, or styles being filtered should be irrelevant.

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

On 12 June 2015 at 12:28, Jody Garnett <jody.garnett@anonymised.com> wrote:

An alternative to changing the layer group info is to change the layer to include min/max scale information. Ideally do to DRY (do not repeat yourself) I would like to see the min/max scale calculated from the style … and refreshed each time the style is changed.

I guess it is tricky as the scale based on which style the user has requested; or in this case the layer group has been configured with.

In the WMS module during a GetMap request (rather than adjust the styles using a style visitor) you could discard layers that do not match the current scale from further processing

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

–
Jody Garnett

On 12 June 2015 at 11:43, Kevin Smith <ksmith@anonymised.com> wrote:

I’m looking at ways we could make it easier to manage scale based visibility of layers in a layer group.

At the moment I’m thinking the best way to do it would be to add a list of scale ranges to layer groups in parallel to the existing lists of publishables and styles with the same pair of accessors (one for children, one for a flattened list of descendants)

Then in the WMS module when the StyleInfo objects are retrieved and used to get the Style objects (Happens in two places, one for GetMap, one for GetLegend), a StyleVisitor could be sent over the styles to adjust the scale rules so they are suitably restricted.

This would simplify the process of building complex layer groups as it would place all the scale dependant visibility information in one place instead of having to coordinate it across multiple styles.

This would either require a new kind of layer group that the WMS module would have to detect, or a change to the LayerGroupInfo interface to add new methods. I expect the latter would call for a GSIP.

Does anyone have any thoughts?

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

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

7

On Thu, Aug 13, 2015 at 12:56 AM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

How do we plan to expose the vendorOptions() for LayerGroups? Given that
they will affect how layers are displayed, they should be editable from the
GeoServer UI, but an arbitrary Map of values does not really lend itself to
a user friendly display.

Exposing these values via the REST API should also be done, but seems much
simpler.

What about creating a parallel list of scale ranges instead? Might not be
super, but
follows the current paradigm and won't break REST api backwards
compatibility.
The current structure in LayerGroupInfoImpl is:

    protected List<PublishedInfo> publishables = new
ArrayList<PublishedInfo>();
    protected List<StyleInfo> styles = new ArrayList<StyleInfo>();

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

8

I am kind of keen for vendor options so we could do a CQL filter and stuff.

···

On Thu, Aug 13, 2015 at 12:56 AM, Torben Barsballe <tbarsballe@anonymised.com…> wrote:

How do we plan to expose the vendorOptions() for LayerGroups? Given that they will affect how layers are displayed, they should be editable from the GeoServer UI, but an arbitrary Map of values does not really lend itself to a user friendly display.

Exposing these values via the REST API should also be done, but seems much simpler.

What about creating a parallel list of scale ranges instead? Might not be super, but
follows the current paradigm and won’t break REST api backwards compatibility.
The current structure in LayerGroupInfoImpl is:

protected List publishables = new ArrayList();
protected List styles = new ArrayList();

Cheers
Andrea

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

9

On Thu, Aug 13, 2015 at 8:49 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

I am kind of keen for vendor options so we could do a CQL filter and stuff.

Ok... let's not call them vendor option though, this is the geoserver
configuration, not
a stanard being extended.
In the rest of the configuraton an open ended map is called simply
metadata, and it
has already xstream converters dedicated to it.
LayerGroupImpl already has one, but I guess you want to add an array of
them,
one per layer.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

10

Good point … options or parameters or “more…” In the UI.

···

On Thu, Aug 13, 2015 at 8:49 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I am kind of keen for vendor options so we could do a CQL filter and stuff.

Ok… let’s not call them vendor option though, this is the geoserver configuration, not
a stanard being extended.
In the rest of the configuraton an open ended map is called simply metadata, and it
has already xstream converters dedicated to it.
LayerGroupImpl already has one, but I guess you want to add an array of them,
one per layer.

Cheers
Andrea

–

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.