[Geoserver-users] geoserver 2.5 & viewparams

Hi all,

Today I upgraded our geoserver 2.4 instance to the latest stable version (2.5).

After this upgrade I noticed our wms-requests using viewparams (SQL-view based layers) just return empty tiles. Same happens when you preview the layer using e.g. openlayers. Executing exactly the same request to a geoserver 2.4 instance returns the expected tiles.

I checked the log, no errors are shown. Has something changed with regard to using sql-view based layers & viewparams?

When I looked at the request geoserver is receiving I see that the VIEWPARAMS parameter is interpreted correctly and contains the correct value, but the key itself is upper cased (the value is an integer). The parameter in my SQL view is lower case. Could that be a possible cause?

Kind regards,
Roel


Volg Aquafin op Facebook | Twitter | YouTube | LinkedIN

Disclaimer: zie www.aquafin.be P Denk aan het milieu. Druk deze mail niet onnodig af.

On Wed, Apr 2, 2014 at 7:20 PM, Roel De Nijs <roel.denijs@anonymised.com> wrote:

Hi all,

Today I upgraded our geoserver 2.4 instance to the latest stable version
(2.5).

After this upgrade I noticed our wms-requests using viewparams (SQL-view
based layers) just return empty tiles. Same happens when you preview the
layer using e.g. openlayers. Executing exactly the same request to a
geoserver 2.4 instance returns the expected tiles.

I checked the log, no errors are shown. Has something changed with regard
to using sql-view based layers & viewparams?

When I looked at the request geoserver is receiving I see that the
VIEWPARAMS parameter is interpreted correctly and contains the correct
value, but the key itself is upper cased (the value is an integer). The
parameter in my SQL view is lower case. Could that be a possible cause?

I'd suggest you to enable "geotools developer logging" and see how queries
are built.
It may be this issue http://jira.codehaus.org/browse/GEOT-4749, if that's
the case, you can
solve it by installing a nightly build (2.5.1 will be released in May)
http://ares.boundlessgeo.com/geoserver/2.5.x/

This is unfortunate, but apparently no one with sql views tested GeoServer
2.5 in the beta, RC1 and RC2
releases (or if they did, they did not care to report the issue).

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

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

Enabling “geotools developer logging” showed indeed a wrong srid in the query getting executed (2 instead of 31370). Updating the geoserver instance to the latest nightly build (01-Apr-2014 15:42) solved the issue. Thanks for the swift reply (and solution)!

When I look at the issue you mentioned it appears to be a bug against the jdbc-postgis plugin, but our layers are all created from sqlserver tables (and so we add the sqlserver plugin). So although we use sqlserver layers, the postgis plugin is also used (to perform common stuff) and the sqlserver plugin is used to do translations to/from the sql server dialect. Is this a correct assumption?

Kind regards,

Roel

Van: andrea.aime@anonymised.com [mailto:andrea.aime@anonymised.com] Namens Andrea Aime
Verzonden: woensdag 2 april 2014 20:05
Aan: Roel De Nijs
CC: geoserver-users@lists.sourceforge.net
Onderwerp: Re: [Geoserver-users] geoserver 2.5 & viewparams

On Wed, Apr 2, 2014 at 7:20 PM, Roel De Nijs <roel.denijs@anonymised.com3…> wrote:

Hi all,

Today I upgraded our geoserver 2.4 instance to the latest stable version (2.5).

After this upgrade I noticed our wms-requests using viewparams (SQL-view based layers) just return empty tiles. Same happens when you preview the layer using e.g. openlayers. Executing exactly the same request to a geoserver 2.4 instance returns the expected tiles.

I checked the log, no errors are shown. Has something changed with regard to using sql-view based layers & viewparams?

When I looked at the request geoserver is receiving I see that the VIEWPARAMS parameter is interpreted correctly and contains the correct value, but the key itself is upper cased (the value is an integer). The parameter in my SQL view is lower case. Could that be a possible cause?

I’d suggest you to enable “geotools developer logging” and see how queries are built.

It may be this issue http://jira.codehaus.org/browse/GEOT-4749, if that’s the case, you can

solve it by installing a nightly build (2.5.1 will be released in May)

http://ares.boundlessgeo.com/geoserver/2.5.x/

This is unfortunate, but apparently no one with sql views tested GeoServer 2.5 in the beta, RC1 and RC2

releases (or if they did, they did not care to report the issue).

Cheers

Andrea

==

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK

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



Volg Aquafin op Facebook | Twitter | YouTube | LinkedIN

Disclaimer: zie www.aquafin.be P Denk aan het milieu. Druk deze mail niet onnodig af.

On Thu, Apr 3, 2014 at 4:05 PM, Roel De Nijs <roel.denijs@anonymised.com> wrote:

Enabling "geotools developer logging" showed indeed a wrong srid in the
query getting executed (2 instead of 31370). Updating the geoserver
instance to the latest nightly build (01-Apr-2014 15:42) solved the issue.
Thanks for the swift reply (and solution)!

When I look at the issue you mentioned it appears to be a bug against the
jdbc-postgis plugin, but our layers are all created from sqlserver tables
(and so we add the sqlserver plugin). So although we use sqlserver layers,
the postgis plugin is also used (to perform common stuff) and the sqlserver
plugin is used to do translations to/from the sql server dialect. Is this a
correct assumption?

Sort of, the common stuff is in the gt-jdbc module, and the issue was in
that module, which is shared among all database implementations.
The issue was opened against postgis because we discovered it against that
installation.

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
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

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