Tampilkan postingan dengan label wms. Tampilkan semua postingan
Tampilkan postingan dengan label wms. Tampilkan semua postingan

Senin, 16 April 2012

Dynamic WMS styling with GeoServer: SLD and library mode

Hi all,
today I want to delve a bit in the dynamic styling abilities that GeoServer provides.

GeoServer fully supports a client's ability to specify a custom SLD 1.0 style instead of a built-in named style, this can be done in different ways:
  1. adding a reference to a internet accessible sld file via the &sld=url parameter
  2. specifying the full SLD, url-encoded, in the request URL via the
  3. SLD_BODY=fullStyleDefinitionHere parameter
  4. POST-ing a GetMap XML document, as defined by the SLD 1.0 spec
  5. POST-ing the usual GET request, where each KVP parameter is sent over as a form parameter (this is a GeoServer extension)
Let's have a look at case 3) since it's a bit different than the others. In that case you need to post a XML document just like in WFS/WCS requests, the document looks as follows:


As you can see it's pretty much the usual GetMap request, but expressed in XML format, with the ability to embed UserStyle objects in it, which make it fully dynamic.

Ways 1, 3 and 4 rely on most of the usal GET parameters, and allow you to specify a custom SLD file, but the way the SLD file it's interpreted is radically different depending on whater you did specify the layers and styles param in your request, or not.

The simpler behavior is obtained if you don't specify layers and styles: the NamedLayer objects refer to layers in the server, the NameStyles to styles in the server, and UserStyle allow you to specify your custom style. Each layer is rendered with the style associated to it, and that's it.

However, if you specify layers in the request, the SLD document is downgraded to a "style library", this is known as library mode. Here is how this works:
  • each layer in the layers parameter is drawn in order
  • for each layer, if styles is present the name of the style is picked, otherwise the "default" style is looked for (same happens if you don't specify the style name for that layer)
  • given the layer name and the style name, a layer is searched in the SLD file that has the same name, and the styles inside it are searched for a style with the specified name. If none is found, the server is searched, if the style is not even there, an error is thrown
  • given a layer name and the indication to search the default style, a layer is searched in the SLD file that has the same name, and the user styles inside it are searched for one that has the 1 element making it the default style. If none is found the default style defined on the server side is picked instead, ignoring the SLD file contents.
Given the fact that the library mode is certainly more complex, and that you need to line up layer and style names properly, it is of course recommended not to specify the layers parameter and fall back on the simpler mode.
However, the library mode comes in handy if you are making a complex request, with many layers, and you want to provide a custom style for just a few of them: you just need to add the styles for those few in the SLD file, all the others will fall back to use the server side styles instead.

This is just one of the many ways GeoServer allows to dynamically alter the way maps are being built, others are SLD parameter substitution, dynamic filtering, and rendering transformations.

Want to hear more about dynamic styling? Let us know!

The GeoSolutions team,


Kamis, 10 November 2011

Animate your maps with GeoServer Animator Tool

In this blog post we'd like to introduce you to a new GeoServer feature, the WMS animator.
The animator follows in the footsteps of the WMS reflector, allowing a client to build an animated map with a relatively compact syntax.

An animation is built as a set of frames, and each frame is a separate WMS GetMap call, similar to the others in the set, but with a different value in one of the parameters.
The animator allows you to specify the parameter that will vary and its value via the aparam and avalues request parameter.

For example, let's say we have a dataset with time support enabled, in particular a small set of blumarble images for the different months in the year. A call to get a continuously animated progression would look like:


The aparam in this request is the WMS time parameter, while the avalues list a number of possible times, in particular a few months of the year. Also notice the output format, asking for an animated GIF that loops continously. The result is as follows:


Time and elevation are obviously prime candidates to drive an animation, but in fact every WMS request parameter can be used to drive the animation.
For example, we could change the bounding box and have the map move:




The actual reason the animator was developed was to allow building animation of tuna catches by ocean area over different types of aggregation factors, that are passed down to a parametrized SQL view building all the little squares you see in the map.
Here is an example showing the evolution of catches of a particular tuna spieces over the years:

http://localhost:8080/geoserver/wms/animate?layers=UN_CONTINENT,GRID_G5,TUNA_YEARLY_CATCHES,FAO_MAJOR,UN_CONTINENT&
format=image/gif;subtype=animated&aparam=viewparams:YR_TA&avalues=1990,1991,1992,1993,1994,1995&
width=512&format_options=layout:message;gif_loop_continuosly:true&viewparams=CD_GEAR:801\,802\,803;FIC_ITEM:2496\,3296\,3305\,2498;QTR_TA:1\,2\,3\,4;OP:sum




As you can see some of the maps include the indication of the year in the lower left. This is a recent addition to the animator framework, it uses a text WMS decoration to embed in the image the current avalue. See the animator documentation for details on how this can be achieved.

At the time of writing the only possible output format is animated GIF, but other formats could be written and plugged in, for example AVI or Flash, and transition effects could be added too.
Interested? Let us know!

The GeoSolutions team,

Rabu, 12 Oktober 2011

GeoServer News: Hiding layers from the capabilities document

Hi all,
in this blog post we would like to talk about a new functionality that we has just introduced in GeoServer, the layer "advertised" flag.

As you know, ignoring security settings for the moment, all enabled layers configured in GeoServer are made available though all the OGC services for which they make sense: vector layers are published automatically to WMS and WFS, raster layers to WMS and WCS.

This is a fine default behavior, but in some cases one would like that the layer was there, but without making the layer known to the general public. Tipical use cases:
  • you want to expose a set of layers as a layer group, but you don't want to publish the layers separately
  • some application needs to setup a temporary layer, maybe the result of some computation, without having the whole world know about it
  • the administrator wants a layer to be available for testing, but not have the whole world hit it yet (maybe because the layer configuration/styling is not done)
Up until GeoServer 2.1.1 the above was only partially possible by making the layer available only to certain users via the security setup, but in 2.1.2 it got just a lot easier, there is a new publishing flag, "advertised", that you can uncheck to hide the layer:

Once un-ckecked the layer won't appear anymore into the capabilities documents, nor in the layer preview table, but will still be available for all other service requests.

There are other things that could be done to improve layer management, such as attribute renaming, easier association with styles, publishing of a layer only towards certain OGC services and the like. Interested in getting any of that happen today? Let us know!



Regards,
the GeoSolutions Team.

Jumat, 18 Februari 2011

Developers Corner: Support for TIME in GeoServer WMS

Dear All,
at GeoSolutions lately we are working on improving support for the TIME dimension in GeoServer.

While the work is still ongoing we wanted to share with you a preview of what we are doing, therefore we created the video below.



Like this feature? Interested in funding this development? Drop us a line!

The GeoSolutions team

Selasa, 01 Februari 2011

Developers Corner: Improving GeoServer WMS Cascading Support

Hi all,
The ability to server WMS layers from a remote WMS server through a Geoserver installation (a.k.a. Cascading WMS) has been one of the latest improvements in Geoserver world in last couple of months. You can read about it more in one of our previous blog, where the basics have been explained already.

GeoSolutions team has since been improving the existing state and introduced some new features. A few patches have been created to fix some important issues:
  • Enabling cascading layer to be included in layer groups (GEOS-4273)
  • Make GetFeatureInfo requests work again on cascading servers (GEOS-4301)
  • Make GetFeatureInfo requests work on older version of geoservers (GEOT-3383)
  • Include "image/png; mode=24bit" to the tentative transparent formats used in WMSLayer (Mapserver transparent png support - GEOT-3393)
  • Other smaller bug fixes (GEOT-3361, GEOS-4295, GEOS-4286).
Batch import
The main improvement GeoSolutions has been working on, it's been the possibility to perform batch import of layers from a remote WMS (GEOS-4296) through the user interface. This development allow users to try and publish all layer, or only a certain subset, all at once. After the WMS store has been configured, new link providing batch import is shown.

Selecting batch import takes us to a new page where multiple layers can be selected and configured with a single mouse click.

Clicking on “Import selected” button imports selected layers and prints out simple status report on imported layer. Notice that the Published Icon is update accordingly.



We have made a video showing how to use the batch import of WMS servers into Geoserver. You can download it from here.

Do not hesitate to try it out and stay tuned for more WMS Cascading improvements!

The GeoSolutions team.

Kamis, 10 Desember 2009

Adding TIME support to GeoServer and Mosaic plugin

Ciao a tutti,
lately I have been working on adding support in GeoServer for the TIME keyword in GetMap requests by updating the ImageMosaic plugin. The work is being performed on trunk but I might backport to 2.0.x, funding permitting, when it will be ready to roll.

The goals are as follows:
  • Ability to select a certain number of granules from the mosaic index based on the actual values of a TIME attribute
  • Make the TIME mechanism transparent if not needed
  • Allow users to update the granule index over time adding new granules
The scenario I am trying to cope with is the following:
  • I have a tool that does radar coverage predictions routinely (every 12 hours)
  • Each prediction is specular to the others except for the time when it was generated (same georeferencing, same raster characteristics)
  • We want to be able to show either the latest perdition or an old one
Now, some pictures to show that the work is proceeding.
I have taken 7 geotiffs for the BlueMarble series of 2004, from jan to Jul from here since you can visually notice that over time as the Summer approaches the ice/snow moves north.


I have ingested it (Did I say that I am also adding a mechanism to automagically populate the time attribute based on the file properties, like name, metadata, etc.. :-) ?)

Then I have started to send queries, for January

then for March
then for July
Notice that we also support the "current" keyword to automatically get the latest raster available.

I think it is pretty neat and thanks to the GeoTools infrastructure it is not being too hard to implement.

The additional features we could add are quite many:
  • Filtering via CQL on additional properties
  • ELEVATION support
  • Create an animation given a set of time instants
  • Properly expose time as part of the WMS GetCap
  • Wire TIME and ELEVATION support for WCS as well

If you are interested in funding this development or in adding more features I did not think of, please contacts us!

Rabu, 08 Juli 2009

Supporting FAO Fishery department with a custom GeoServer DataStore for Oracle

GeoSolutions is collaborating with FAO Fishery department in order to improve the statistical GIS application "Atlas of Tuna and Billfish Catches".

The interactive version of the Atlas of Tuna and Billfish Catches presents the global distribution of 1950 to 2003 catches, at 5° latitude by 5° longitude resolution, of those tuna and tuna-like species for which this distribution is generally well known on the global scale. These species consist of the so-called principal market tunas and some billfishes.
Its refactoring mainly consists into switching the actual architecture which produces static snapshots of the statistic requested by the users through a parameter selection form, into a fully dynamic GIS map client based upon the OpenLayers served by a GeoServer/GeoTools/GeoWebCache stack working on top of an Oracle database.

Here is a common use case to solve.
Consider a table which contains the yearly catches of several fish species around the world by using different kind of gears; the user may want to issue several kind of statistical requests like for instance the total sum of the yearly catches grouped by gears and species over a specific time-range. Moreover the user wants to be able to compute these statistics on a defined by a lon,lat grid so that in the end he can either map the squares for the grid with different colors depending on the catches' statistics. In the normal approach we should create a new view which joins the catches table with the lon,lat grid table and performs the requested aggregate functions on the result.

The main issue when coping with such a complex use case was to allow GeoServer to work with an underlying complex databases structure, joining tables on the fly depending on some parameters selected by the users and being able to apply statistics function by aggregating resulting records for criteria like across years or quarters of the catches. One of our goals was to not generate views on the fly inside the database as well as not to create new layers inside GeoServer on the fly, because such an approach would have, on a side,consumed a lot of resources and on the other side, it would have required a sort of clean-up mechanism to remove old, unneeded views and GeoServer layers; in a word a nightmare.


At the end of the analysis we have come out with an architecture proposal based upon a brand new GeoTools driver capable of producing Aggregate DataStore
s on the fly, by analyzing and rebuilding the SQL at run-time and also a CQL filter adapter for GeoServer able to understand Aggregate Filters to be forwarded to the Aggregate Driver.

The proposed architecture, as depicted in the drawing aside, consists of several components:
  • A Proxy which intercepts the client request and traduces the parameters selection into an appropriate Aggregate CQL filter
  • The Aggregate DataStore which dynamically changes the FeatureType structure on GeoServer
  • The Business logic which performs dynamic queries to the DB by merging statistical and GIS datasets.

This approach can be generalized to similar problems. The proposed architecture, in fact, aims to be the base for future GIS statistical mapping application of the Fishery department.

Actually we based the driver on the Oracle NG plugin, but with some more effort it could be extended to the JDBC one allowing it working with other Databases like for instance PostGis.

The results of the plugin are shown in the screenshots below:



Selasa, 07 Juli 2009

GeoSolutions is supporting the G8 meeting @ l'Aquila

GeoSolutions, in coordination with the geoSDI team, has helped to build and set up the geospatial portal and SDI used by the Italian Civil Protection and the G8 help desk, as you can see here and here, to support the G8 meeting at L'Aquila, Italy. The building blocks are well-known open source projects, GeoServer, GeoNetwork, geoSDI-ERA, OpenLayers, Hibernate.

For those of you that don't have access to the portal I am posting here below some screenshots of the portal showing data from various WMS servers.



In the pictures above you can se the portal overlaying WMS layers from differentWMS servers which have been accessed and catalogued to gain access to a wide range of information.

A special thanks goes to Dr. Dimitri Dello Buono, the head of the geoSDI project and to Francesco Izzi, the leader of the technical team, working with them on these challenging scenarios is always a pleasure.