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:
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:
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.