Parameter standardization for SQL fed queries through WMS/WFS?

Web map services are not straightforward any more. Some are based on complex queries to database like Oracle, MSSQL and PostGIS. This makes it possible for the services to provide highly specialized data views to their clients. Sometimes this is done by having the web map service accepting or forwarding non-standardized parameters. It’s beautiful and confusing at the same time.

My major problem with this practice is not that it is being done, but the lack of standardizations of parameters. I frankly think this is a problem and I am foreseeing it becoming more so as time goes by without any action taken.

Earlier this year I was at a meeting in Tromsø, Norway. We were discussing a portal system aiming at forwarding sets and subsets of data from different partners. It is not the first one, and it certainly will not be the last one.

The portal will retrieve information from many different web map services. Nothing new there. One of our potential feeds into the portal is based on information we are currently using in one of our own projects. We are using a combination of Geoserver, OpenLayers and MSSQL to pull this off. The results are nice maps with highly specialized information like in this map:

Our map service is set up so that it provides data based on non-standardized parameters in the getmap-request. An example of parameter’s used separately or in combination is listed here:

  • month:1
  • group:0
  • species:23
  • valuelevel:0

The getmap request in geoserver flavor looks like this:


This invokes an SQL query that will supply the geographical objects with properties. Below you will see how the query defined in Geoserver uses the “% month%” and “% Group%” parameters.

select Square_id, Geometry, Value from (select Square_id, max (value) as Value from SAValue, Species WHERE Month =% month% and SAValue.Species_Id = Species.Id and Species.Gruppe_id =% group% group by Square_id) as X, route WHERE X. Square_id = Square.Id

Editing it in Geoserver looks like this:

I am assuming that this is done in a fairly similar way in ArcGIS Server and Mapserver.


Looking forward I predict a  more extensive use of more such multidimensional services. Particularly because external portal solutions might need to provide it’s users with subset data from provider services.

The problem from a client perspective (here the portal facilitator) that it quickly becomes confusing and difficult to manage if one should pass parameters to many different WMS services without parameter standardization and some predictable metadata description of the capabilities for such services.

Currently, this is not a problem for us as the service owner. In our system we have established a well known naming conversion based on our developers own standards, randomness and uther unspecified causes. It works fine for internal use.

But in the long and in a larger scale this will be horribly complicated to administer. At some point in time it will be just too compex – and it will fail.

To keep my workplace and boring details outside this article I have prepared an example situation where someone made an International Unicorn Portal. In this example the intention of the portal is to collect all available unicorn data from the partners in the International Unicorn Network.

As we can see in the figure above the International Unicorn Network  will end up in a quite messy situation when they request data from different databases through the wms-standard. Not only are the species codes different, but the reference parameters, here “species”, “art”, “ref1” and “p_meter”, are different.

How do we solve the problem? This is probably something which should be standardized above the national level. Maybe protocol related, or maybe even cross protocol. I am guessing that OGC is the best adressee to solve this issue.

Feel free to comment here. Should there be any interest I would be more than happy to present this issue in a wider fora.

3 thoughts on “Parameter standardization for SQL fed queries through WMS/WFS?

  1. Jørn-Vegard Røsnes

    Probably not what you are looking for, but a possible workaround is to utilize Map Vendor Parameter in GeoWebCache

    You will end up with many layers from GeoWebCache (one per permutation of group, species, month, etc.), but if caching is crucial, maybe it’s worth it. Maybe some species/month are more accessed/interesting than others, and worth to cache.

    With (OpenLayers/)Javascript you can make an application that hides the complexity for the end-user.

  2. Martin Davis

    Is there actually two issues here?

    1) Different semantic models for datasets in different organizations
    2) Different WMS syntax for parameterizing queries

    1 is not something that WMS can solve – it’s a business-level issue.

    As for 2, a partial solution is to use a more standard way of specifying query parameters, such as encoding queries using the filter parameter and the Filter Encoding specification.

    Granted, Filter Encoding is awkward and not very readable, which is why GeoServer added the ability to express filters in ECQL as well. And even then, filters are not as expressive as full parameterized SQL (for instance, you can’t express grouping as in your example). So it would be nice if the OGC was able to provide a more comprehensive standard to allow easy cascading such as your example.

    1. ragnvald Post author

      1) I agree it is a business level issue, thoug it has national if not international level consequences. It might be rational for the different stakeholders to agree on it outside the WMS-standard, still as a standard. OGC?

      2) My experiences from working in a shared ArcGIS and Geoserver environment is that we after starting using Geoserver are more aware of differences in implementations of WMS. However nice it is to have the vendor specific SQL parametrization from Geoserver we still would like our implementatios to be cross-platform.

      Thanks for replying Martin! 🙂


Leave a Reply

Your email address will not be published. Required fields are marked *