[Geoserver-devel] SQL views and performance

Hi all,

Some questions about Geoserver performances when using SQL views as layers. I've got many layers that are defined from SQL views directly on Geoserver (no viewson the database), from Postgres. It seems that each time the Geoserver receive a query (single WMS, or multi WMS coming from tiled queries in OpenLayers), it does the wole SQL query for each GET. And then return the image from the BBOX.
When I query a GetMap for a small area, the whole country is queried just to have a small extent.

I tried a new SQL view with a %polygon% attributes : this adds "AND ST_Intersects() " between the geometry from this polygon, and the geometry of the table. Now I have a strange change :
- for largest images (a whole city), the return time for GetMap is divided by 6 (6000ms -> 1000ms)
- for smallest images (a district), the return time for GetMap is multiplied by 3 (100ms -> 300ms)

The SQL with the ST_Intersects and the Bbox takes 300ms, so I guess the GetMap won't be faster than this...

Thanks for the advice !

Gabriel Vatin

Hi Gabriel,
it seems your database of choice has real trouble figuring out a good access plan
for those queries. Hard to say if the db should be able to just figure out that the
outer spatial index can be executed directly in the inner query or not without seeing the query.

Normally postgis/postgresql is pretty good with planning, while Oracle and SQL Server are
rather poor.

Some systems allow to add a place where the current “bbox” can be expanded as a parameter
transparently (without explicit support). GeoServer could have it too with some development effort:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

That said, in your case it seems it’s not always a win, I guess it’s a matter of figuring out
how many zoomed in vs zoomed out requests you need to produce.
Maybe you could create two views, one with, one without, bind them in a layer group, and use scale dependencies to
switch from one to the other.

Cheers
Andrea

···

On Mon, Mar 20, 2017 at 3:55 PM, Gabriel Vatin <gabriel.vatin@anonymised.com> wrote:

Hi all,

Some questions about Geoserver performances when using SQL views as
layers. I’ve got many layers that are defined from SQL views directly on
Geoserver (no viewson the database), from Postgres. It seems that each
time the Geoserver receive a query (single WMS, or multi WMS coming from
tiled queries in OpenLayers), it does the wole SQL query for each GET.
And then return the image from the BBOX.
When I query a GetMap for a small area, the whole country is queried
just to have a small extent.

I tried a new SQL view with a %polygon% attributes : this adds "AND
ST_Intersects() " between the geometry from this polygon, and the
geometry of the table. Now I have a strange change :

  • for largest images (a whole city), the return time for GetMap is
    divided by 6 (6000ms → 1000ms)
  • for smallest images (a district), the return time for GetMap is
    multiplied by 3 (100ms → 300ms)

The SQL with the ST_Intersects and the Bbox takes 300ms, so I guess the
GetMap won’t be faster than this…

Thanks for the advice !

Gabriel Vatin


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

==
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 di Montramito 3/A
55054 Massarosa (LU)
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.


Thanks Andrea for the quick answer. What I can’t really guess for now, is when and how is the SQL view executed : does the BBOX attribute of GetMap queries affect this SQL view (when no parameter in the view definition) ?

The type of query to create a new layer is done so : I have a whole “goi” table with attributes such as name etc., and a table with all geometries (stored in geo_data column, which is a Geometry,4326 with GIST index). Each layers of my GeoServer changes with the “got_id” (layer theme ID), stored on the goi table. Here is the whole view

SELECT id, id_ori, name, geo_data
FROM geometrie
LEFT JOIN goi USING (goi_id)
WHERE got_id = 105

I add this extra line for the 2nd version, where the POLYGON is view parameter generated from the client :

AND St_Intersects(geo_data,St_Transform(ST_GeomFromText(‘POLYGON((808771 5420870,810771 5420870,810771 5422870,808771 5422870,808771 5420870))’,3857),4326))

(attachments)

logo_kinaxia_pastel_v_seul_162x80.gif

···

Le 20/03/2017 à 17:00, Andrea Aime a écrit :

Hi Gabriel,
it seems your database of choice has real trouble figuring out a good access plan
for those queries. Hard to say if the db should be able to just figure out that the
outer spatial index can be executed directly in the inner query or not without seeing the query.

Normally postgis/postgresql is pretty good with planning, while Oracle and SQL Server are
rather poor.

Some systems allow to add a place where the current “bbox” can be expanded as a parameter
transparently (without explicit support). GeoServer could have it too with some development effort:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

That said, in your case it seems it’s not always a win, I guess it’s a matter of figuring out
how many zoomed in vs zoomed out requests you need to produce.
Maybe you could create two views, one with, one without, bind them in a layer group, and use scale dependencies to
switch from one to the other.

Cheers
Andrea

On Mon, Mar 20, 2017 at 3:55 PM, Gabriel Vatin <gabriel.vatin@anonymised.com> wrote:

Hi all,

Some questions about Geoserver performances when using SQL views as
layers. I’ve got many layers that are defined from SQL views directly on
Geoserver (no viewson the database), from Postgres. It seems that each
time the Geoserver receive a query (single WMS, or multi WMS coming from
tiled queries in OpenLayers), it does the wole SQL query for each GET.
And then return the image from the BBOX.
When I query a GetMap for a small area, the whole country is queried
just to have a small extent.

I tried a new SQL view with a %polygon% attributes : this adds "AND
ST_Intersects() " between the geometry from this polygon, and the
geometry of the table. Now I have a strange change :

  • for largest images (a whole city), the return time for GetMap is
    divided by 6 (6000ms → 1000ms)
  • for smallest images (a district), the return time for GetMap is
    multiplied by 3 (100ms → 300ms)

The SQL with the ST_Intersects and the Bbox takes 300ms, so I guess the
GetMap won’t be faster than this…

Thanks for the advice !

Gabriel Vatin


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

==
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 di Montramito 3/A
55054 Massarosa (LU)
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.


Kinaxia

Gabriel VATIN

Docteur en Géomatique
Ingénieur de recherche

Tél : 06.63.92.94.42

Email : gabriel.vatin@anonymised.com

http://www.kinaxia.fr

Hi Gabriel,
If you turn the GeoServer logging level to Geotools-developer level, the log file will then include the SQL query that is sent to the database. This should facilitate debugging this issue.

You can then try running the query against your database’s EXPLAIN syntax - which shows how your database thinks it will run it (or even better, EXPLAIN ANALYZE, which runs it and then says how it ran it). This will let you try and determine where the bottleneck is.
I’ve found this to be a fairly decent tutorial: https://www.depesz.com/2013/04/16/explaining-the-unexplainable/]

Between these you should hopefully be able to determine whether the optimisation scope is GeoServer, PostGres, your query, or some combination thereof.

Cheers,
Jonathan

---- On Mon, 20 Mar 2017 17:34:03 +0000 Gabriel Vatin gabriel.vatin@anonymised.com wrote ----

Thanks Andrea for the quick answer. What I can’t really guess for now, is when and how is the SQL view executed : does the BBOX attribute of GetMap queries affect this SQL view (when no parameter in the view definition) ?

The type of query to create a new layer is done so : I have a whole “goi” table with attributes such as name etc., and a table with all geometries (stored in geo_data column, which is a Geometry,4326 with GIST index). Each layers of my GeoServer changes with the “got_id” (layer theme ID), stored on the goi table. Here is the whole view

SELECT id, id_ori, name, geo_data
FROM geometrie
LEFT JOIN goi USING (goi_id)
WHERE got_id = 105

I add this extra line for the 2nd version, where the POLYGON is view parameter generated from the client :

AND St_Intersects(geo_data,St_Transform(ST_GeomFromText(‘POLYGON((808771 5420870,810771 5420870,810771 5422870,808771 5422870,808771 5420870))’,3857),4326))

Le 20/03/2017 à 17:00, Andrea Aime a écrit :

Hi Gabriel,
it seems your database of choice has real trouble figuring out a good access plan
for those queries. Hard to say if the db should be able to just figure out that the
outer spatial index can be executed directly in the inner query or not without seeing the query.

Normally postgis/postgresql is pretty good with planning, while Oracle and SQL Server are
rather poor.

Some systems allow to add a place where the current “bbox” can be expanded as a parameter
transparently (without explicit support). GeoServer could have it too with some development effort:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

That said, in your case it seems it’s not always a win, I guess it’s a matter of figuring out
how many zoomed in vs zoomed out requests you need to produce.
Maybe you could create two views, one with, one without, bind them in a layer group, and use scale dependencies to
switch from one to the other.

Cheers
Andrea

On Mon, Mar 20, 2017 at 3:55 PM, Gabriel Vatin <gabriel.vatin@anonymised.com> wrote:

Hi all,

Some questions about Geoserver performances when using SQL views as
layers. I’ve got many layers that are defined from SQL views directly on
Geoserver (no viewson the database), from Postgres. It seems that each
time the Geoserver receive a query (single WMS, or multi WMS coming from
tiled queries in OpenLayers), it does the wole SQL query for each GET.
And then return the image from the BBOX.
When I query a GetMap for a small area, the whole country is queried
just to have a small extent.

I tried a new SQL view with a %polygon% attributes : this adds "AND
ST_Intersects() " between the geometry from this polygon, and the
geometry of the table. Now I have a strange change :

  • for largest images (a whole city), the return time for GetMap is
    divided by 6 (6000ms → 1000ms)
  • for smallest images (a district), the return time for GetMap is
    multiplied by 3 (100ms → 300ms)

The SQL with the ST_Intersects and the Bbox takes 300ms, so I guess the
GetMap won’t be faster than this…

Thanks for the advice !

Gabriel Vatin


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

==
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 di Montramito 3/A
55054 Massarosa (LU)
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.


Kinaxia

Gabriel VATIN

Docteur en Géomatique
Ingénieur de recherche

Tél : 06.63.92.94.42

Email : gabriel.vatin@anonymised.com

http://www.kinaxia.fr


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Mon, Mar 20, 2017 at 6:34 PM, Gabriel Vatin <gabriel.vatin@anonymised.com>
wrote:

Thanks Andrea for the quick answer. What I can't really guess for now, is
when and how is the SQL view executed : does the BBOX attribute of GetMap
queries affect this SQL view (when no parameter in the view definition) ?

Yes, just like any other table. With a plain table the query composed is:

select <fields> from <theTable> where <Filters>

where <filters> comes from the OGC request, that is, the bbox, time,
elevation, and the SLD itself.

When working off a sql view it becomes:

select <fields> from (<theSqlViewDefinition>) as _gt_table where <Filters>

In other words, GeoServer uses the SQL you provided verbatim (could be a
stored procedure call too, or whatever database specific mechanism returns
a set of rows) and then applies filters on it.
This should not be interpreted as running sql view definition first and
then filtering on top of it, it's up to the database to figure out an
optimal execution order, depending on the sql involved and database
abilities the bbox filter might be run first before doing the joins in your
sql, and so on. See also https://en.wikipedia.org/wiki/Query_plan

The type of query to create a new layer is done so : I have a whole "goi"

table with attributes such as name etc., and a table with all geometries
(stored in geo_data column, which is a Geometry,4326 with GIST index). Each
layers of my GeoServer changes with the "got_id" (layer theme ID), stored
on the goi table. Here is the whole view

SELECT id, id_ori, name, geo_data
FROM geometrie
LEFT JOIN goi USING (goi_id)
WHERE got_id = 105

See Jonathan's mail about getting the full query and running an explain.
It might just well be that you have index statistics that are out of date,
too, running a "analyze" might help:
https://www.postgresql.org/docs/9.1/static/sql-analyze.html

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 di Montramito 3/A
55054 Massarosa (LU)
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.

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

Great, thanks to both of you. Now I see clearer on how to debug and improve this. If I get something that would be useful to all, after improving the queries, I’ll share the trick!

Gabriel

(attachments)

logo_kinaxia_pastel_v_seul_162x80.gif

···

Le 21/03/2017 à 12:58, Jonathan Moules a écrit :

Hi Gabriel,
If you turn the GeoServer logging level to Geotools-developer level, the log file will then include the SQL query that is sent to the database. This should facilitate debugging this issue.

You can then try running the query against your database’s EXPLAIN syntax - which shows how your database thinks it will run it (or even better, EXPLAIN ANALYZE, which runs it and then says how it ran it). This will let you try and determine where the bottleneck is.
I’ve found this to be a fairly decent tutorial: https://www.depesz.com/2013/04/16/explaining-the-unexplainable/]

Between these you should hopefully be able to determine whether the optimisation scope is GeoServer, PostGres, your query, or some combination thereof.

Cheers,
Jonathan

---- On Mon, 20 Mar 2017 17:34:03 +0000 Gabriel Vatin gabriel.vatin@anonymised.com wrote ----

Thanks Andrea for the quick answer. What I can’t really guess for now, is when and how is the SQL view executed : does the BBOX attribute of GetMap queries affect this SQL view (when no parameter in the view definition) ?

The type of query to create a new layer is done so : I have a whole “goi” table with attributes such as name etc., and a table with all geometries (stored in geo_data column, which is a Geometry,4326 with GIST index). Each layers of my GeoServer changes with the “got_id” (layer theme ID), stored on the goi table. Here is the whole view

SELECT id, id_ori, name, geo_data
FROM geometrie
LEFT JOIN goi USING (goi_id)
WHERE got_id = 105

I add this extra line for the 2nd version, where the POLYGON is view parameter generated from the client :

AND St_Intersects(geo_data,St_Transform(ST_GeomFromText(‘POLYGON((808771 5420870,810771 5420870,810771 5422870,808771 5422870,808771 5420870))’,3857),4326))

Le 20/03/2017 à 17:00, Andrea Aime a écrit :

Hi Gabriel,
it seems your database of choice has real trouble figuring out a good access plan
for those queries. Hard to say if the db should be able to just figure out that the
outer spatial index can be executed directly in the inner query or not without seeing the query.

Normally postgis/postgresql is pretty good with planning, while Oracle and SQL Server are
rather poor.

Some systems allow to add a place where the current “bbox” can be expanded as a parameter
transparently (without explicit support). GeoServer could have it too with some development effort:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer

That said, in your case it seems it’s not always a win, I guess it’s a matter of figuring out
how many zoomed in vs zoomed out requests you need to produce.
Maybe you could create two views, one with, one without, bind them in a layer group, and use scale dependencies to
switch from one to the other.

Cheers
Andrea

On Mon, Mar 20, 2017 at 3:55 PM, Gabriel Vatin <gabriel.vatin@anonymised.com> wrote:

Hi all,

Some questions about Geoserver performances when using SQL views as
layers. I’ve got many layers that are defined from SQL views directly on
Geoserver (no viewson the database), from Postgres. It seems that each
time the Geoserver receive a query (single WMS, or multi WMS coming from
tiled queries in OpenLayers), it does the wole SQL query for each GET.
And then return the image from the BBOX.
When I query a GetMap for a small area, the whole country is queried
just to have a small extent.

I tried a new SQL view with a %polygon% attributes : this adds "AND
ST_Intersects() " between the geometry from this polygon, and the
geometry of the table. Now I have a strange change :

  • for largest images (a whole city), the return time for GetMap is
    divided by 6 (6000ms → 1000ms)
  • for smallest images (a district), the return time for GetMap is
    multiplied by 3 (100ms → 300ms)

The SQL with the ST_Intersects and the Bbox takes 300ms, so I guess the
GetMap won’t be faster than this…

Thanks for the advice !

Gabriel Vatin


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

==
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 di Montramito 3/A
55054 Massarosa (LU)
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.


Kinaxia

Gabriel VATIN

Docteur en Géomatique
Ingénieur de recherche

Tél : 06.63.92.94.42

Email : gabriel.vatin@anonymised.com18…

http://www.kinaxia.fr


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Kinaxia

Gabriel VATIN

Docteur en Géomatique
Ingénieur de recherche

Tél : 06.63.92.94.42

Email : gabriel.vatin@anonymised.com

http://www.kinaxia.fr