Tampilkan postingan dengan label GEO. Tampilkan semua postingan
Tampilkan postingan dengan label GEO. 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,


Jumat, 13 April 2012

State of GeoServer presentation from FOSS4G-NA


Dear all,
we wanted share the slides from another presentation that Andrea Aime and Justin Deoliveira gave recently at the FOSS4G North America conference about the state of GeoServer.

Here below you have the complete presentation.

The GeoSolutions team,

Rabu, 11 April 2012

Unveiling upcoming GeoServer 2.2 release

Dear all,
we have created this post to share the slides from the presentation that Andrea Aime and Justin de Oliveira gave recently at the FOSS4G North America conference about the new feature that will be available in the upcoming 2.2 release of the GeoServer.

A lot of work has been performed since the first beta release of the 2.1 release, almost 2 years ago, quickly summarising some of the most interesting ones we can enumerate:
  • improved WPS
  • rendering transformation, to perform transformation on-the-fly during rendering
  • improved security subsystem
  • support for bigtiff
  • support for oracle georaster
  • support for TIME and ELEVATION in WMS and WCS
and many more.

For a complete cover of all these features, here you have the complete presentation.



View more presentations from GeoSolutions



The GeoSolutions team,

Senin, 02 April 2012

Saving the world one application at a time: Atlas of Tuna and Billfish Catches

This blog post covers some work we have done to support the FAO Fishery and Acqualture Department, specifically the FIGIS group with information dissemination about catches of Tuna and Billfish over the last 60 years globally

As stated on their website:
"... the Atlas presents the global distribution of catches by gear from 1950 to 2010, 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."

Atlas of Tuna and Billfish catches website


Using Geoserver, OpenLayers and Ext-JSwe built for them a simplfied viewer that allow users to access dynamically their statistics and to map them by multiple dimensions:

  • by gears (one or more)
  • by species (one or more)
  • for a certain years' range
  • for a certain quarters' range
Moreover users can decide to view the following indicators:
  • Cumulative catches across years
  • Average catches across years 
  • Average catches across quarters
The selections made by users are reflected directly on the visualization combining data from various sources through the GeoServer; animations can be created across years as well as years' quarters to show the evolution of the catches. The result can be seen here and in the pictures below.










Let's take a look at the implementation.
Background maps are served via GeoWebCache, nothing too sophisticated there, while the maps are generated on the fly by GeoServer connected to the FAO corporate Oracle instance via SQL Views that are performing join and aggregations on the fly between tables containing live information about catches and tables containing ancillary information like species and gear types. In addition, users can print the current map (together with the eventual result of a request for info on the map), as shown here below,


or they can request to generate an animated GIF, leveraging on the WMS Animator work (see this page for additional info) using a specific panel shown below where multiple dimensions can be again controlled:


Here below the resulting animations is shown.



Let us now summarise a few points for this project:
  • background maps are served with GeoWebCache which is shared with all the others mapping applications in places withing the department
  • most of the data is stored inside the corporate instance of Oracle Spatial, demonstrating perfect integration of Open Source with COTS
  • extensive usage of CQL filters and SQL Parametric Views has been made to generate dynamic maps and animations
Last but not least, we believe it is worth to mention that this work was performed via our GeoSolutions Enterprise ServicesTherefore, if you'd like to know more about what we could achieve together, do not hesitate and get in touch with us!

The GeoSolutions team,

Senin, 26 Maret 2012

Developer's Corner: Authenticating dummy clients in GeoServer

In this blog post we'll introduce a simple authentication method we developed for GeoServer that allows to deal with security unaware clients.

GeoServer can be configured to force a user to authenticate, either directly when trying to access the capabilities document (challenge mode) or when trying to access a protected resource (mixed mode). GeoServer will send a "http basic authentication" challenge, that will force browsers to show up the "username/password" authentication dialog, and make other desktop application ask and send over the user credentials.

There are surely more secure means to authenticate a user, yet basic http authentication is the minimum common denominator, something that most clients support, and coupled with HTTPS transport it provides a good starting point for a secured site.

Unfortunately there are clients out there that cannot even deal with basic authentication.
Some of the existing solutions deal with this by making you install a little desktop proxy software that the other software can connect to, with the proxy dealing with all security considerations. That is fine when you are in control of the client side, but not practical when the user is not able, willing, or allowed to install extra software on their machine.

To allow for some level of authentication and security in those cases we developed a community module called "authkey", or "Key authentication module", where all that is requested to the client is to add a unique key indentifying the user into the capabilities request.
Something like:
http://myhost/geoserver/wms?service=WMS&request=GetCapabilities&authkey=ef18d7e7-963b-470f-9230-c7f9de166888
And voilà, the user associated to that code will be recognized. The capabilities document returned will also contain back links to GeoServer that replicate the same code, so that also GetMap and GetFeatureInfo requests will work under that same user.
This way the authentication is done without the software having to willingly participate in the authentication mechanism.

The default implementation of the module will look for a property file that configures the associations between the unique codes and the existing users, but different solutions can be plugged in that allow for authentication via hardware code tokens, or daily tokens, or whatever solution you might come up with: see the documentation for more details on the configuration and instructions on how to write your own plugin.

Of course the solution is simple, but coupled with HTTPS it's more or less as secure as using basic authentication, and allows a wider range of client software solutions to participate in the game.

What about you, looking for some missing GeoServer security features? Interested in knowing more about our Enterprise Services? Let us know!

The GeoSolutions team,

Selasa, 20 Maret 2012

Saving the world one application at a time: FAO Regional Fishery Bodies Viewer

At GeoSolutions we believe that success stories about important organizations and Open Source Software should be openly shared and they can be used as a measure of OSS success in the formal enterprise environment.  In this blog post we are going to quickly introduce some work we have done for the Fishery and Acqualture Department of the Food and Agriculture Organization (FAO) of the United Nations (UN).

The FAO Fishery and Acqualture Department, specifically the FIGIS group; is involved in many efforts geared towards the conservation of the marine ecosystem and GeoSolutions is honored to work with them on some of the mapping applications they need in order to create effective querying and visualizations of the data they manage.

This blog post covers some work we have done to support information dissemination about Regional Fishery Bodies (RFB). As stated on their website:
"Regional Fishery Bodies (RFB) -- a group of States or organizations that are parties to an international fishery arrangement -- work together towards the conservation and management of fish stocks.
RFB can play a critical role in promoting longterm sustainable fisheries where international cooperation is required in conservation and management."


Using Geoserver and OpenLayers we built with them a comprehensive web based API to create on the fly maps with the relevant information for each resource with just a couple of lines of Javascript code. Maps are embedded in the FIGIS portal, as can be seen here and in the pictures below,



but also a specific RFB Viewer can be used to quickly show the RFBs' coverage on a map as shown at this link and in the screenshot below.


Let's take a deeper look at the implementation.
Interacting with GeoServer's WMS module we dynamically build the map with the continental layer, the member countries, the coast lines and the fishery boundaries. The API supports 3 different projections: WGS84 (EPSG:4326), Google Mercator (EPSG:900913) and Polar Stereographic (EPSG:3031).
For each of the regional fisheries body selected in first drop down menu, we generate an embed code as pictured below, this is used by the Fishery department web designers to replace what previously were static images representing the resources distribution and limits. It could also be used by an external website to embed these maps into their site.


More could be said about this project regarding its infrastructure, let's summarise a few interesting points:
  • background maps are served with GeoWebCache
  • most of the data is stored inside the corporate instance of Oracle Spatial, demonstrating perfect integration of Open Source with COTS
  • Extensive usage of CQL filters to drive the dynamic maps is used
Last but not least, we believe it is worth to mention that this work was performed via our GeoSolutions Enterprise Service. Therefore, if you'd like to know more about what we could achieve together, do not hesitate and get in touch with us!

The GeoSolutions team,

Rabu, 29 Februari 2012

Articolo di GeoSolutions su GeoServer ad ASITA 2011

Salve a tutti,
con colpevole ritardo, mettiamo a disposizione dei nostri lettori l'articolo presentato alla conferenza ASITA dell'anno scorso.
Una versione in pdf può essere scaricata qui.

The GeoSolutions team,

Selasa, 31 Januari 2012

Developer's Corner: First Official Release of GeoNetwork-Manager library

During our work we support many clients with their GeoNetwork  installations, as a consequence we have found ourselves many times in the position to perform massive operations on metadata, e.g. when ingesting data in real-time via GeoBatch or when importing existing metadata in batch. In the past we have noticed that we were de-facto reusing and growing a small but useful codebase of common methods to interact with GeoNetwork therefore we decided to share them with the world (yeah, we are a bit ambitious :) ) and therefore we created the geonetwork-manager project for this purpose.

geonetwork-manager  is a Java library for interacting with GeoNetwork programmatically. It uses the GeoNetwork's admin services for the backend communication part, but the HTTP machinery  is completely hidden by the  geonetwork-manager  API itself. Last but not least  geonetwork-manager  is released under the MIT license. By the way, release 1.0 has just been cut and can be found on our maven repository.

In case you are interested in having support for your GeoNetwork installation, Talk to us first!
The GeoSolutions team,

Senin, 30 Januari 2012

Developer's Corner: Introducing Database Level Security in GeoServer

During our work we support manu GeoServer Enterprise installations which pull data from a spatial database of some sort, normally via a connection pool, a tool that keeps database connections around so that we don't have to open and close them at every request (something that could be very expensive).
The pool accesses the database via a shared user, that all GeoServer requests end up using. Some requests only require data reading (WMS GetMap), others modify data (WFS Transaction), some even create new tables (RESTConfig data uploading for example).
The pool user must be able to perform all and any of the operations that GeoServer needs, meaning that more often than not it has very wide powers of what it can do on the database.

GeoServer built in security, as well as extensions such as GeoRepository, allow to control what specific users can do and shield the database from security issues.
However in some enviroment the preferred security management policy is to have security restrictions operate at the database level instead, with the pool user being given minimal rights (normally, to list and describe the tables, but without any actual access to them). This has some advantages:
  • the security is setup just once for the variety of applications that might access the database
  • each user can actually perform only the operations that he/she was allowed to, regardless of eventual bugs/security holes in the application level software
  • leverages the DBA expertise
GeoSolutions recently implemented the ability to use DBMS session startup and teardown scripts that can be used to alter the user accessing the database for the duration of the current request, turning back to the pool user when the request is complete.
These commands can be specified in the configuration User Interface while setting up the data store. For example, if we wanted to have each and every PostgreSQL session use the credentials of the current GeoServer user we'd use the following setup:

Different databases will of course use different commands, or custom, in house package calls, to setup the current session user. See the GeoServer documentation for more details on how this new functionality can be used.

We'd like to thank Astrium GEO-Information Services for sponsoring this improvement and sharing it with the GeoServer and GeoTools communities.

Application security is certainly one of the topics we like to deal with. There is of course a lot more to explore and improve, this topic is both rich and interesting. Want for example CAS or Shibboleth security in your GeoServer intallation? Maybe integration with Active Directory? Talk to us first!

The GeoSolutions team,

Kamis, 26 Januari 2012

Improving GeoServer SQL Server support

Dear All,
in recent times we were hired to improve GeoServer SQL Server support story.

The SQL Server store was created and maintained during spare time by Justin DeOliveira, however due to lack of production usage, and work time to pour on it, it failed to reach to the same level of robustness and speed as the best supported stores, such as Oracle and PostGIS.

Our work this week tried to close this gap with a number of little and big improvements that make the code run faster and in a more reliable way:
  • add support for connection validation (very important for SQL Azure, which is very keen on closing pooled connections in your face)
  • use binary encoding, instead of text, to transfer geometries from the database
  • support for data paging at the database level
  • make sure the rich database test suite we have in GeoTools is fully implented for SQL server, ensuring good support for use cases such as dynamic SQL views, proper date/time encoding in filters, and the like, both on the development series and on the stable series
Our develoment focused on testing the code against both SQL Server 2008 and SQL Azure. SQL Azure is the SQL database one can use in the Microsoft Azure cloud system: while it does look a lot like SQL Server 2008, it does not quite behave the same way in all cases, and requires a specific JDBC driver to work properly.

There are still some improvements missing on the table, such as geography columns support, but we're sure you'll be able to get more out of a production usage of GeoServer and SQL Server now.

Interested in sponsoring further improvements? Looking for professional support service that deliver for your group? Let us know!

The GeoSolutions team,

Senin, 23 Januari 2012

GWT-OpenLayers release 0.7

Dear All,
we would like to inform you that the new release 0.7 for the GWT-OpenLayers project is available.

The releases is ready for the download and can be found here.

Notable improvements with this release are as follows:
  • Upgrade to GWT 2.4.0
  • Support to Google Maps V3
  • Improved source code formatting
  • Added and fixed several base methods and bindings such WMS Params, Layer methods
Alessio Fabiani has taken care of the 0.7 release as an active committer and administrator of the project.
We would like to thank all the other committers for their dedication and hard work!

Regards,
the GeoSolutions Team.

Selasa, 17 Januari 2012

BRISEIDE Project, Geoserver, GeoNetwork and GeoBatch for the management of dynamic MetOc data

Dear All,
In this post I wanted to talk about the work we are doing for the BRISEIDE european project.

The ambitious aim of the project, as stated on its website, is the delivery of:
  • time-aware extension of MetOc data models developed in the context of previous/ongoing EU INSPIRE related projects (e.g. in the context of GMES, eContentPlus)
  • application (e.g. Civil Protection) based on the integration of existing, user operational information
  • value added services for spatio-temporal data management, authoring, processing, analysis and interactive visualisation
Within the context of the project, GeoSolutions will work under the leadership of SinerGIS in order to provide near-real time ingestion, cataloging and publishing of meteorological data provided by the stakeholders to be used as inputs for running processes to perform, as an instance, fire propagation models in emergency situations.

The infrastructure we are setting up is depicted in the deployment diagram here below. Basic building blocks are as follow:
  • GeoServer for providing WMS, WCS and WFS services with support for the TIME dimension. It is worth to point out that it will also provide WPS capabilities.
  • GeoNetwork, for publishing metadata for all data with specific customizations for managing the TIME dimensions in the dataset (we are going to biriefly describe them later on)
  • GeoBatch, for performing preprocessing and ingestion in near real time of data and related metadata with minimal human intervention.
** PLEASE DESCRIBE THIS IMAGE **

For this project we have customized the metadata indexing (thanks Lucene!) in GeoNetwork in order to be able to index meteorological model runs in terms of their run time as well as in term of their forecast times. Generally speaking the data we are dealing with is driven by a meterological model which produces daily a certain number of geophysical parameters with forecast valid for around 5 days, moreover some additional fire risk indexes are produced by processing these results in near real time. As days go by forecasts from different runs of the model are available as indicated in the picture below.

** PLEASE DESCRIBE THIS IMAGE **

To achieve our gaols we have slightly customized the indexing configuration as well as the user interface in order to be able to make searches on run times and forecast times fast. If you are interested in having a look at one of the ISO metadata XML documents that we are publishing, here you can find an example here.

Here below you can find a diagram depicting the automatic ingestion flow we have created for the BRISEIDE project (actually, one of the few we have created) using the GeoBatch framework (we will soon release version 1.0 on which we are working in our own repository).



This flow makes extensive use of an orchestration Groovy script that implements specific business logic for the use case. Internally it also make use of various other atomic action for performing tasks like, publishing an ImageMosaic in GeoServer or its metadata in GeoNetwork.


Incoming files are composed by a compressed set of .asc (ascii images) files which are:
  1. Converted into re-tiled GeoTiff images
  2. Embedded overviews are added to each image
The groovy script produces an ImageMosaicCommand which is essentially an xml command which is sent to the ImageMosaicAction which:
  1. Check for the layer existence on the target GeoServer
  2. If success copy all the files to the target directory
  3. Create the Store and the layer to contain the ImageMosaic
  4. Configure the layer on the GeoServer using desired parameters
  5. Produce an XML file with the ImageMosaic properties
The groovy script read the produced ImageMosaic output, enrich it with some other useful information then pass that object to the FreeMarkerAction which using a template and the passed data model will produce the xml metadata file (as described above).

The GroovyScriptAction ends sending this file to the next action which is the GeoNetworkAction which will send the metadata to the target GeoNetwork server using the desired (specified by configuration) options.

If you have questions about the work described in this post or if you want to know more about our services could help your organization to reach its goals, do not hesitate to contact us.


Regards,
the GeoSolutions Team.

Selasa, 10 Januari 2012

GeoNetwork 2.6.4 con traduzione italiana disponibile!

Salve a tutti,
dopo il ticket di rilascio di una versione di preview della localizzazione italiana per la versione di sviluppo 2.6.5 di GeoNetwork (si veda qui per maggiori informazioni), abbiamo effettuato il backport alla versione 2.6.4 stabile. Da questo indirizzo è possibile scaricarne il war. Questo war installerà GeoNetwork versione 2.6.4 con in più la localizzazione in italiano; la pagina principale porterà automaticamente alla versione italiana.




La migrazione di installazioni esistenti sarà effettuata correttamente solo se la versione di partenza è una di quelle attualmente supportate da GeoNetwork standard, ossia 2.4.3, 2.6.0 o 2.6.1. Per le nuove installazioni i dati in italiano saranno normalmente caricati durante il setup del database di GeoNetwork.

The GeoSolutions team,

Selasa, 03 Januari 2012

WFS for the masses: adding support for paging and sorting in GeoServer

Today we are going to introduce you our latest contribution to GeoServer, WFS paging and sorting for retrieving features.

First off, let's take a step back and see what sorting and paging support is available in the official OGC protocols:
  • Neither WMS 1.1 nor WMS 1.3 (or SLD/SE for that matter), have any ability to order the results so that features are painted in a certain order. If features can be organized in categories filters and FeatureTypeStyle elements can do the trick, but that won't work over continous fields
  • Same goes for WPS 1.0, which can return significant amounts of vector data that might be useful to page over
  • WFS 1.0 does not support either, WFS 1.1 supports sorting, WFS 2.0 supports sorting and paging via the sortBy and startIndex/maxFeature parameters
The last stable GeoServer release does not support WFS 2.0, and allows for sorting only on DBMS based stores. In our latest contribution to the stable series we removed all limitations concerning WFS paging and sorting support:
  • WFS 1.0 and 1.1 can now support sorting on top of each and every store kind, using the sortBy parameter as a vendor extension
  • WFS 1.0 and 1.1 support paging on top of each and every store, using the startIndex/maxFeatures parameters
Protocol and paging wise we back-ported the work added on trunk along with WFS 2.0 support, and then we merged in some previous work on generic sorting we did for the aggregating store.

Technically speaking, in case the store does not support sorting natively (e.g., shapefile) we gather the features into an optimized merge/sort algorithm that never keeps more than 1000 features in memory, and uses secondary storage to scale up to larger result sets.

But, enough talking, let's see some examples against the states demo layer, using the CSV as the output format for brevity.

First ten features:
http://localhost:8080/geoserver/topp/owsservice=WFS&version=1.0.0&request=GetFeature
&typeName=topp:states&outputFormat=csv&propertyName=STATE_NAME,PERSONS
&maxFeatures=10

FID,STATE_NAME,PERSONS
states.1,Illinois,11430602
states.2,District of Columbia,606900
states.3,Delaware,666168
states.4,West Virginia,1793477
states.5,Maryland,4781468
states.6,Colorado,3294394
states.7,Kentucky,4551524
states.8,Kansas,2477574
states.9,Virginia,6180651
states.10,Missouri,5117073

The next 10 features:
http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature
&typeName=topp:states&outputFormat=csv&propertyName=STATE_NAME,PERSONS
&maxFeatures=10&startIndex=10

FID,STATE_NAME,PERSONS
states.11,Arizona,3665228
states.12,Oklahoma,3145585
states.13,North Carolina,6628629
states.14,Tennessee,4829958
states.15,Texas,17122020
states.16,New Mexico,1379559
states.17,Alabama,4040587
states.18,Mississippi,2573216
states.19,Georgia,6457339
states.20,South Carolina,3486703

The first ten states with most people (sort on PERSONS, descending):
http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature
&typeName=topp:states&outputFormat=csv&propertyName=STATE_NAME,PERSONS
&maxFeatures=10&sortBy=PERSONS%20D

FID,STATE_NAME,PERSONS
states.47,California,29760021
states.39,New York,18235907
states.15,Texas,17122020
states.23,Florida,12937926
states.40,Pennsylvania,11881643
states.1,Illinois,11430602
states.48,Ohio,9980887
states.24,Michigan,9295297
states.43,New Jersey,7484736
states.13,North Carolina,6628629

The second page of the above result set:
http://localhost:8080/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature
&typeName=topp:states&outputFormat=csv&propertyName=STATE_NAME,PERSONS
&maxFeatures=10&startIndex=10&sortBy=PERSONS%20D

FID,STATE_NAME,PERSONS
states.19,Georgia,6457339
states.9,Virginia,6180651
states.37,Massachusetts,6016425
states.44,Indiana,5544159
states.10,Missouri,5117073
states.49,Washington,4866692
states.14,Tennessee,4829958
states.30,Wisconsin,4796441
states.5,Maryland,4781468
states.7,Kentucky,4551524

These modifications are already available in the GeoServer 2.1.3 release.

There is more work to be done in this area, ordering features before paiting them in WMS, and paging WPS results would both be nice additions. Interested? Let us know!

The GeoSolutions team,

Kamis, 29 Desember 2011

Robust Clustering Solution for GeoServer

Dear All,
in this post we'd like to introduce some work that we have performed in order to provide robust support support for clustered GeoServer deployments with an emphasis on publishing new layers in real-time.

As you might know there are various approaches with GeoServer that can be used to implement a clustered deployment, based on different mixes of data directory sharing plus configuration reload. However, these techniques have intrinsic limitations therefore we decided to create a specific GeoServer Clustering Extension in order to overcome them. It is worth to point out that what we are going to describe is designed to work with GeoServer 2.1 stable series.

In the picture below our approach is shown. We propose a robust Master/Slave approach which leverages on a Message Oriented Middleware (MOM) where:
  1. The Masters (yes, we can have more than one, read on...) receive changes to the internal configuration, persiste them on their own data directory but also forward them to the Slaves via the MOM
  2. The Slaves do not accept changes to their configuration from eithe REST or the User Interface, but are configured to inject configuration changes disseminated by the Master(s) via the MOM
  3. The MOM is used to make the Master and the Slave exhange messages in a durable fashion
  4. Each Slave has its own data directory which it is responsible for keeping it aligned with the Master's one. In case a Slave goes down when it goes up again he might receive a bunch of messages to align its configuration to the Master's one.
  5. A Node can be both Master and Slave at the same time, this means that we don't have a single poinf of failure, the Master itself



Improved Clustering in Action

In the following we provide a few additional technical details on our solution, describing a deployment which we use for our tests (as such, it is designed to show every possible combination as opposed to be a best practice for deploy). We will refer to the following picture.






This deployment is composed by:
  • A pure Master GeoServer(s), this instance can only send events to the topic.It cannot act as a slave
  • A set of Geoserver which can work as both Master and Slave. These instances can send and receive messages to/from the topic. They can work as Masters (sending message to other subscribers) as well as Slaves (these instances are also subscribers of the topic).
  • A set of pure Slaves GeoServer instances whic can only receive messages from the topic.
  • A set of MOM brokers so that each GeoServerinstance is configured with a set of available brokers (failover). Each broker use the shared DB as persistence. Doing so if a broker fails for some reason, messages can still be written and read from the shared database.
We are now going to illustrate, step by step, how to publish a layer from a GeoTiff file using the GeoServer User Interface of the Pure Master instance. The resulting layer will be published on all the active GeoServers.

Manually create the GeoTiff store using the User Interface:




Publish the layer





Click save and check results on the clients




Now check the result using the LayerPreview:



As expected using the pure Master to publish the GeoTiff file, the resulting layer will be published automatically on the salve instances with no intervention. There is one thing to notice, we are not moving data around but only their configuration (styles included) since we are assuming that all instances sees the same resources with the same absolute paths, which is common in distributed and cluestered set ups where resources are shared among multiple servers, like for example network storage.


Conclusions
If you are responsible for administering a a series of GeoServer instances and/or you are publishing lots of data in real-time then this extension is a perfect fit for your organization.

In case you are interested in test-driving this extension in your own set-up, you might want to know that we are going to provide this extension free of charge to clients who will subscribe to our  GeoServer Professional Services for the 2012 as well as to our partners. Contact us if you are interested!

Regards,
the GeoSolutions Team.


Senin, 05 Desember 2011

Job offer @ GeoSolutions



GeoSolutions is looking for talented software engineers to fill a couple of positions which would mainly involve designing and implementing web-based geospatial applications. Qualifications are as follows:
  • Working knowledge of web 2.0 UI  frameworks like GWT, Ext-GWT, JQuery,  Ext-JS
  • Working knowledge of Java (JEE and JSE)
  • Working knowledge of GeoServer  and OpenLayers is a plus
  • Knowledge of web development with Python is a plus
  • At least 1 year of experience 
  • Being fluent in English, both written and spoken
We offer a variety of contracts but, please, notice that our intention is to establish a long term relationship, therefore this is not a position for freelance consultants.

Working remotely is an option, although we will give priority to candidate closer to our office.

Please send a detailed resume together with a letter of presentation at jobs_at_geo-solutions.it.

The GeoSolutions team,

Rabu, 30 November 2011

GeoServer and GeoSolutions @ gvSIG Days 2011

GeoSolutions will attend the 5th edition of the gvSIG Conference, organized by the Regional Ministry of Infrastructure and Transport (CIT) from December 2nd until December 4th at the Feria Valencia Convention and Exhibition Center.  


Ing. Simone Giannecchini will provide an introductive workshop on GeoServer, therefore make sure you take note of the exact time on the conference program and you make room in your schedule for attending the event.
Check this link for more details.

See you in Valencia!

The GeoSolutions team.


Selasa, 22 November 2011

GeoServer e GeoSolutions al GFOSS Day 2011

GeoSolutions sarà presente alla conferenza GFOSS DAY 2011 che si terrà a Foggia il 24 e 25 Novembre presso la Università degli Studi.



Oltre ad essere sponsor Silver della manifestazione, GeoSolutions sarà presente con un workshop gratuito introduttivo ed una presentazione su GeoServer che si terranno entrambi nella giornata del 25 (si veda per dettagli il programma della manifestazione).

Quindi, se volete essere aggiornati sugli sviluppi del GeoServer o se volete essere introdotti al suo utilizzo da uno dei suoi creatori non vi resta che farci visita a Foggia!

The GeoSolutions team.