Hello,
/Geoserver/ offers to use parametrized SQL views
<https://docs.geoserver.org/stable/en/user/data/database/sqlview.html> for
WMS requests, and this is very convenient. On our web side, for the WMS
request, the parameters are put in a /viewparams /field and then on
/Geoserver/ side they are received and used by the SQL request.
However, we discovered that Tiled WMS (WMTS) doesn't have that /viewparams
/field WMS has.
How can we send our parameters to the /Geoserver/ SQLViews when using a WMTS
request ?
Regards,
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.html
Hi mlebihan
I haven’t tried this myself, but I expect it to work:
In the Edit Layer page, select the Tile Caching tab. Towards the bottom, under Add filter, select VIEWPARAMS and a type.
ref: https://docs.geoserver.org/latest/en/user/geowebcache/webadmin/layers.html#adding-a-filter
Let us know if this works.
Peter
On Wed, 12 Dec 2018 at 15:51, mlebihan <mlebihan29@anonymised.com> wrote:
Hello,
/Geoserver/ offers to use parametrized SQL views
<https://docs.geoserver.org/stable/en/user/data/database/sqlview.html> for
WMS requests, and this is very convenient. On our web side, for the WMS
request, the parameters are put in a /viewparams /field and then on
/Geoserver/ side they are received and used by the SQL request.
However, we discovered that Tiled WMS (WMTS) doesn’t have that /viewparams
/field WMS has.
How can we send our parameters to the /Geoserver/ SQLViews when using a WMTS
request ?
Regards,
–
Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.html
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this list:
If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
My problem is that the url parameters send by the browser in viewparams and
that are automatically split by geoserver in WMS mode and given to its SQL
views that way : SELECT * FROM TABLE where a= ... AND b = ...
(and may change each time the user do a call to that layer through his web
browser. Example : cityCode and year who would varying each call),
aren't taken into account when the a WMTS service is targeted instead.
What troubles me is that if the way of sending parameters is well
documented, and it should not have been an easy thing to develop for the
geoserver team, the way for doing so for a WMTS layer should be known by
someone.
I'm searching the official way to do so. I am not alone over the Internet
who have met that problem. It would be strange if I was discovering it in
the end of 2018, have to do experiments and offer a solution that would
surely not convince my development team. They wouln't allow my code to go in
production if I attempt to use an undocumented practice.
I am not the one who can discovery it now. I must rely on official knowledge
about linking parameters send in WMTS mode and SQL requests in geoserver.
Maybe, if nothing is known, I will open an improvment request, but I don't
have the right (due to our quality checkings here) to attempt an
undocumented trick never experienced by anyone. Because my quality service
would reply to me : "/How many days will it works ?/", "/Where have you read
about this practice ?/". If I reply : /"I have hacked it, but saw noone do
the same before/", my commit will be rejected for sure.
Regards,
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.html
It makes no sense to use a wmts service with variable parameters as the whole point of tiling is to allow you to cache the response. If everyone makes a different request each time there is no point in caching the tiles.
Ian
On Thu, 13 Dec 2018, 17:17 mlebihan <mlebihan29@anonymised.com. wrote:
My problem is that the url parameters send by the browser in viewparams and
that are automatically split by geoserver in WMS mode and given to its SQL
views that way : SELECT * FROM TABLE where a= … AND b = …
(and may change each time the user do a call to that layer through his web
browser. Example : cityCode and year who would varying each call),
aren’t taken into account when the a WMTS service is targeted instead.
What troubles me is that if the way of sending parameters is well
documented, and it should not have been an easy thing to develop for the
geoserver team, the way for doing so for a WMTS layer should be known by
someone.
I’m searching the official way to do so. I am not alone over the Internet
who have met that problem. It would be strange if I was discovering it in
the end of 2018, have to do experiments and offer a solution that would
surely not convince my development team. They wouln’t allow my code to go in
production if I attempt to use an undocumented practice.
I am not the one who can discovery it now. I must rely on official knowledge
about linking parameters send in WMTS mode and SQL requests in geoserver.
Maybe, if nothing is known, I will open an improvment request, but I don’t
have the right (due to our quality checkings here) to attempt an
undocumented trick never experienced by anyone. Because my quality service
would reply to me : “/How many days will it works ?/”, “/Where have you read
about this practice ?/”. If I reply : /“I have hacked it, but saw noone do
the same before/”, my commit will be rejected for sure.
Regards,
–
Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.html
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this list:
If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
And you are absolutely right : in term of displaying map, continue to use
viewparams in WMTS have no sense.
But, at the same time the viewparams field were used to do so with the WMS
protocol, Geoserver used it also to provide parameters the the SQLView used
to choose what you want to select and display from your underlying TABLE or
VIEW layer.
And this is this ability given by the viewparams field to customize select
data selection that is now missing to me with WMTS protocol.
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GeoServer-User-f3786390.html
But it is not missing, and you already had the correct answer, you have to setup a parameter filter for it, each value of this parameter
will generate a separate cache on disk.
The documentation about parameter filters is here:
https://docs.geoserver.org/latest/en/user/geowebcache/webadmin/layers.html#parameter-filters
If you’re looking for a tutorial or doc specifically mentioning usage of viewparams in combination of WMTS,
you may not find it, for the simple reason that the above documentation should suffice, it’s not practical to have a specific
tutorial for each and every WMS parameter that can change the tile contents.
If the above page is not clear enough, you can add small changes to it via this procedure:
https://docs.geoserver.org/latest/en/docguide/contributing.html
If your organization needs a full blown tutorial instead, you can contribute it, that’s how open source evolves (those who in need
of something contribute it and then it’s available for everybody). See here:
https://docs.geoserver.org/latest/en/docguide/contributing.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 ------------------------------------------------------- Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.