Greetings from GeoSolutions' CEO

Developers Corner: Improving GeoServer security

Hi,

during the last few weeks we have been thinking a lot about improving the GeoServer security, making it at the same time easier to integrate with external authorization systems and making it more expressive in terms of what kind of security rules can be expressed.

As part of the work we have been re-evaluating how the security can be applied in an ever growing software like GeoServer without having to cripple the available service abilities or to have to run after the developers constantly adding new features to the system.

The evaluation resulted in a (long-ish) comparison of the possible models, including the all popular security proxy as well as the existing GeoServer implementation, and coming up with an approach that extends what we already have for improved overall security and improved pluggability with existing systems.

Read the full comparison and the proposed solution in this GeoSolutions tech report

Interested in advancing GeoServer security subsystem? Let us know!

The GeoSolutions team

Estimating time and space required to build a GeoWebCache on disk cache

An outstanding issue when using GeoWebCache is finding out how much disk space a certain layer will use, on disk, once fully cached, and also how much time it will take to pre-seed the cache up until a certain layer.

The GeoWebCache site used to link to a Google Documents spreadsheet providing such an estimate, but the link is gone from the current documentation and, regardless, we found the spreadsheet to be less than accurate, basically ending up computing at the very least the seeding size of 1/4 of the entire world no matter how small the given area was.

Therefore we set out to create a better replacement that would actually count the tiles needed to seed a specific area. The result works for a cache in WGS:84 and is available for everybody to look at and use on Google Documents: GWC estimation - actual tile counting. The current setup compute the actual cache size for the entire Italy.

The document could probably use some more improvements, we're actually looking forward to hear from you about the results you're getting and possible improvements to the spreadsheet.
Let us know!

The GeoSolutions team

GeoServer Tips & Tricks: Auto alignement of labels within polygons

Labeling polygons can sometimes be tricky. GeoServer ormally places the labels horizontally within the polygon, accepting only labels that "sit" inside the polygon for at least half of their length.
However sometimes the polygons just don't collaborate with that setup, they can be thin and long, but rotated on an non horizontal angle: in this case GeoServer would not label them until the user zoomed in quite a bit in the map.

Some time ago Björn Hartell and Andrea Aime started working on a patch to add a vendor option auto-rotate the labels for those polygons. After a few iterations and work on both sides we ended up with some pleasing results.
Here is a couple of examples from the well known countries map from Natural Earth labelled with the "minimum bounding rectangle" auto rotation option:

Labelling buildings or parcels is another common usage for this option:

The map was obtained using the following vendor options in the TextSymbolizer section of the SLD:

<VendorOption name="polygonAlign">mbr</VendorOption>
<VendorOption name="maxDisplacement">20</VendorOption>
<VendorOption name="goodnessOfFit">1.0</VendorOption>



The patch just landed in GeoTools, meaning it will be available in the next GeoServer 2.1 beta release.Notice that we have more cartographic rendering improvements in the pipe.

Interested in getting better maps on screen, having some hard rendering problem to tackle? Let us know!

The GeoSolutions team

Fun Stuff: Computing circular buffers in geographic coordinates

Finding all the objects within a certain distance from a point is surely a common GIS problem. The problem is normally solved using OGC "dwithin" filters or by computing a buffer and then finding all the intersecting objects.

Very often both of the approaches fail miserably in case the coordinate system is a geographic one, as common libraries, such as JTS and GEOS, are not able to handle the non planar nature of it. As far as "dwithin" is concerned rencent Oracle and PostGIS versions can manage the problem properly, but what to do if they cannot be used?

We had to solve this problem when computing data distribution statistics over raster data cells that are within a certain distance from a given point, and making for an accurate calculation regardless of how long the distance was.

To do that we created a new GeoServer WPS process, "gs:PointBuffers", that can create a set of buffers given a point, a target SRS and a set of distances in meters.

In case the SRS denotes a geographic spatial reference system the GeoTools GeodeticCalculator is used to sample the set of points that are at the given distance, looping over a closed sets of azimuths to cover the entire shape.

Interested in seeing the results? I certainly was.

Let's start with a set of small buffers at a medium latitude: 10, 30, 50 and 100 km buffers around a point located in northern Italy. Here is there result:

As you can see, drawing the result in plain WGS84 (plate carré for the conoisseurs) we get elliptical shapes. This should not come as a surprise if you consider that at 45° one degree of latitude spans 111km, whilst a degree of longitude spans only 78km (see the "Degree length" table at Wikipedia).

What if we pump up the distance significantly? Let's try with 100, 500, 1000, 2000 and 3000km instead. Here is the result:

See the funny shape we get? This is the effect of the size of one degree of longitude shrinking as we move towards north.

It is also a good indicator of how deformed the now common WGS84 maps, often published on the web, are.

If you want to see the same data in a common projection, let's have a look at the same map in EPSG:3857 (aka the Google projection):

Somewhat better, even if the Mercator tendency to inflate areas at high latitudes is well evident.

Well, this is it. The gs:PointBuffers is soon going to land in GeoServer for your testing pleasure.

We'd very much like to tackle the same problem against lines and polygons as well. Interested? Let us know!

The GeoSolutions team

(CAS + LDAP + FTP + LifeRay) ^ GeoSolutions = Enteprise Portal

Recently GeoSolutions has developed for one our biggest clients their new web portal . The long term goal was to rationalize and concentrate all users and applications management in a single entry point, providing them with all the functionalities of a classic web portal.

Use Case and Requirements
The development and deployment of the whole architecture was challenging due to the strict functional and non-functional requirements they put forward.
The use case is quite complex since our client periodically conducts experiments at sea, collaborating with other agencies and research centres, where large amounts of data are collected and stored. Moreover, security is a crucial concern for it and therefore sophisticated and fine grained access control and authorization enforcements mechanisms are required.

Main requirements were as follows:

• introduction of a Single Sign On (SSO) mechanism in order to allow users to share their credentials across all the applications exposed through the web portal
• the system had to be able to distinguish external users from internal users and therefore present a different set of security checks as well as richer or poorer content according to their provenance.
• usage of a single interoperable and open credentials respository for storing users credentials accounting also for the possibility to use them also for FTP A&A as well as for legacy applications.
• fine grained RBAC control capabilities in order to group users according to their needs as well as their provenance

Let us briefly explain the concept and the work done in order to implement such a system.

Single Sign On
We decided to implement the SSO system trough a Central Authentication Service (CAS).
The CAS Service assigns authentication tickets to the users after a successful logon throught HTTP cookies so that an application or a service (like Apache HTTPD for instance) able to communicate with CAS is able to automatically recognize the user and its authentication status.

Authorization
Notice that with CAS we can provide only Authentication, not Authorization. That means that we need some other mechanism able to manage user's authorizations, the choice we made was to use LDAP to implement Role Based Access Control (RBAC).
RBAC was accomplished by creating a specific LDAP users repository and enabling both HTTP and FTP daemons to draw users privileges from it. The LDAP service was provided by an OpenLDAP server with a custom schema for groups and peoples.

The Web Portal
The web portal was implemented through LifeRay. LifeRay was configured to provide authentication through CAS and authorization through LDAP. In other words it imports/exports users and groups from/to the LDAP server. All the others A&A LifeRay mechanisms have been configured accordingly.

Putting it all together
Here below a schema of the entire system and its components.

Let us now explain in more details the architecture above.

Apache HTTP Server sits in front of every direct HTTP access to data configured with “mod_cas” and “mod_ldap” in order to provide A&A. The “mod_rewrite” and “mod_proxy” modules have been also configured in order to both recognize internal/external accesses and forward requests to internal web apps.

Both CAS and FTP services have been configured to get users credentials from LDAP.

In order to provide the customer with a fully functional system allowing him to manage credentials and web applications areas, we also developed a specific portlet for allowing administrators to manage users' credentials in LDAP as well as to provide users with the capability to reset their password.

Final Notes and next steps
We had to customized LifeRay deeply in order to integrate all the above components, but thanks to its flexibility as well as to its extension frameworks we have been able to accomplished what we needed to without touching the source code nor recompiling the standard distribution.
Next steps includes integrating also the GeoServer into this infrastructure and letting it play nice with LDAP and SSO. Stay tuned for more info on the topic.

The GeoSolutions team.

GeoServer workshop available for free!

Dear All,
a quick post to just let you know that GeoSolutions is sharing an introductory workshop on GeoServer 2.0.

The material comprises of:

1. a light Ubuntu-based ISO
2. a preconfigured GeoServer data directory containing data kindly donated by the Municipality of Prato in Italy
3. the workshop itself, as a set of html files

The ISO file can be run either using Virtual Box or the VMWare Player. As an alternative you can burn it on a CD and you can use it as a Live Ubuntu or install it on your system.

Once you get it up and running, the installation contains:

1. An instance of the GeoServer 2.0.x stable nightly with a subset of the Prato's layers with proper styling.
2. PostgreSQL with Postgis
3. UDIG
4. QGis

The topics covered in this workshop are as follows:

• Installing and running GeoServer: describes how to install and run GeoServer

• Adding Data to GeoServer: explains how to manage the GeoServer Data Directory as well as how to add the base data types into GeoServer, like ShapeFile, GeoTIFF as well as PostGIS data

• Pretty maps with GeoServer: describes how to manage the GeoServer maps visualizzation. All aspects related to styles, layer groups and other interesting GeoServer features affecting the WMS protocol will be introduced

• Google Earth and Maps support: introduces GeoServer support for KML and Google Earth. The reader will learn how to view GeoServer data in Google Earth, and will be exposed to some of the more advanced features of KML output.

You can download the workshop from here:

In case you find errors or issues, or in case you want to know more about our services with regards to training, please contact us!

The GeoSolutions team,

Presentation on GeoServer @ Gfoss Day 2010

Dear All,
a quick blog post to share the presentation Simone Giannecchini is going to give at the Italian GFOSS Day 2010 tomorrow morning about GeoServer.

Gfoss 2010

View more presentations from GeoSolutions.

The GeoSolutions team,

GeoSolutions helps GeoServer WPS going mainstream

GeoSolutions is funding Andrea Aime's time to bring the GeoServer Web Processing Service (WPS) module to become an officially supported extension. A proposal has been submitted and is being voted on by the Project Steering Committe; you can track the progress here.

For those who have no idea of what WPS means I can cite part of the description I have found in wikipedia, which is very informative:
"The (WPS) is designed to standardize the way that GIS calculations are made available to the Internet. WPS can describe any calculation (i.e. process) including all of its inputs and outputs, and trigger its execution as a Web Service. WPS supports simultaneous exposure of processes via HTTP GET, HTTP POST, and SOAP, thus allowing the client to choose the most appropriate interface mechanism. The specific processes served up by a WPS implementation are defined by the owner of that implementation. Although WPS was designed to work with spatially referenced data, it can be used with any kind of data.
WPS makes it possible to publish, find, and bind to processes in a standardized and thus interoperable fashion. Theoretically it is transport/platform neutral (like SOAP), but in practice it has only been specified for HTTP.
WPS defines three operations:

1. GetCapabilities returns service-level metadata
2. DescribeProcess returns a description of a process including its inputs and outputs
3. Execute returns the output(s) of a process"

GeoSolutions plans for the WPS module in GeoServer extend beyond simply making it an official extension; in the short term we intend to publish a set of processes that we have developed for FAO which will add support for sophisticated statistics on both raster and vector data as well as other more specific processes (raster crop by polygon to name one).

In the longer term our goals include the following items:

• Exposing GDAL utilities (e.g. gdalinfo) as WPS processes
• Exposing Octave functions as WPS processes
• Exposing IDL routines as WPS processes
• Raster Algebra support via JAI-Tools
• Improving support for grid processing
• Improving support for clustered processing for superior scalability

Stay tuned for more information and, if you want to know more, you can always contact us directly!

The GeoSolutions team.

SimpleFeatureService: yet another attempt to simplify vector data dissemination - Part I

In the current web gis world the most common standard protocol to disseminate vector data is the OGC Web Feature Service (WFS). While the protocol is fine, it has a number of shortcomings if we focus on the simple features dissemination case:

• the protocol is complex, writing a client is often hard and error prone, same goes for implementing a new WFS server
• the axis order issue makes it difficult, even today, to know what the axis order of the data returned by a WFS is
• usage of GML implies there are many ways to present the same information or the same geometry (think polygon vs surfaces, or the issue that sometime arise with the feature built in attributes, such as name and location, with the ones that the application wants to publish)

In SOA architectures it is common to have different pieces of the overall system written in different languages, and sometimes there is a need for some part to exchange simple vector data information: we were looking for a quick to implement protocol that would get the job done without the extra complications of WFS (btw, we're not throwing away standards, in fact GeoServer WFS would be used to cascade the simpler protocol into the more complex, but standard compliant, WFS 1.1).

A quick research showed that GeoJSON would have been a very good candidate for data transport, since there are ready made parsers and encoders for the most common languages. The existing Mapfish data query protocol also seemed to fit the bill quite nicely, however we found some limitations that make it hard to use the protocol as a source of data to be cascaded via WFS:

• there is no entry point that lists all the available layers
• there is no way to know in advance what attributes will be returned and what is the spatial reference system of the geometries, nor is the axis order known (we want that to be explicit, just to make sure we avoid the same issues we're seeing in WFS)
• there is no way to quickly get just the bounds and count of the features satisfying a certain filter
• there is no recognized way to eventually transport vendor specific parameters (in our case, a multidimensional query for OLAP systems)
• the pure restful-ness of the protocol does not allow to pass over many parameters

What we did was to extend the protocol a bit to support the above requirements, making it into a very simple OGC like service, and making concessions to the usage of POST requests to gather data.

Well, we can already hear the restful purists yelling about the usage of POST requests to get data. We're aware that it would have been possible to handle that, but each solution would have had drawbacks:

• storing the query as a resource would have required to add urls to handle such resources, and some way to expire them (can't trust the client to orderly go and remove them manually)
• providing a link back to the full query would have implied the client can publish resource and that the server can link back to them, both cases are not always met in practice

The focus of this protocol is implementation simplicity, so that a diversity of implementors in different languages can quickly get a simple feature service up and running, so we believe that in this case pragmatism needs to have the upper hand over religion. If it's possible to implement the service quickly and without ambiguities we basically reached our goal, any other improvement can be of interest provided it does not hamper this primary objective.

A PDF document describing the current layout of the simple feature service procotol is available. There are a few questions that we feel are still open:

• the layout of the urls could probably follow a more hierarchical structure
• the data type conventions could be fleshed out in more detail (thinking about date/time/timestamp for example)
• the feature attributes is an unordered set, however cascading by WFS will result in some order being chosen. Wondering if the order should be established at the simple feature service protocol directly (by using an array of attributes in the describe layer output)
• the documents may be linking each other (this would be make the service crawlable by search engines, assuming that is even a goal and not, on the contrary, an undesirable feature)
• the capabilities could be turned into a simple list of names and we could have the describe resource provide also the spatial reference system and bounds informations

Let us know what you think!

Regards,
the GeoSolutions Team

WorldFile explained (or at least we tried!)

There is a lot of confusion around about what world file represents therefore we thought it would have been nice to put together a couple of clarifications.


The World File
World File is a de-facto standard from early days of ESRI desktop GIS applications. Originally it was composed by at least two files, a raster file, let' say a file.tiff,  and another file (most part of the times called file.wld)  that contains numbers that define the affine transformation between the image and the target spatial reference system. This implicitly means that we are talking about georectified raster data. This wld file is what should be properly called the world file. Other extensions that could be used on behalf of tfw are wld tifw, etc... Moreover some other formats beside tif can be used, like gif, png, jpeg, jpeg2000, etc..and the extensions for the world file become pretty fancy (gifw, pgw, etc..).

The concept behind this couple is as follows. An image (e.g. a tif) plus its world file represent a geospatial georectified raster in some spatial coordinate reference system (CRS). The mapping between the raster space (the intrinsic Image space of rows and cols) and the associated model space is represented by an affine transformation whose coeffficients are contained inside the accompanying world file (see here ). This way, practically any image format can be made spatial-aware just adding a world file containing an affine transform that maps image points onto a crs. Here is a good explanation of what a world file contains.

The Projection File
One would now ask, ok, but what coordinate reference system I am supposed to use. The best answer would be "the one the person who produces the image + the world file was using"! Seriously many people make assumptions on the CRS used for the georeferencing affine transform contained in the world file, but in fact this can lead to all sort of problems. The best way to transmit the information about the spatial coordinate reference system is providing a third file with extension prj which contains the well known text (WKT more info can be found here) representation of the user spatial CRS. The Spatial Reference website can be extremely useful for associating the proper WKT to a certain CRS.


Recommendation
Notice that usually the raster space has x going right and y going down while in model space things DEPEND on the spatial CRS, specifically, axes order and axes directions!
ALWAYS ASK YOUR DATA PROVIDER TO DESCRIBE EXACTLY THE SPATIAL COORDINATE REFERENCE SYSTEM THAT WAS USED TO GEOREFERENCE YOUR DATA.

The GeoSolutions Team,

GeoSolutions ad ASITA 2010

GeoSolutions sara' presente nella giornata di mercoledi 10 Novembre 2010 alla 14esima conferenza nazionale ASITA  che si terrà a Brescia dal 9 al 12 Novembre 2010. Simone Giannecchini, fondatore di GeoSolutions, sarà presente per visitare alcuni dei nostri clienti e sarà disponibile per tutto il giorno per eventuali approfondimenti sulle nostre attività. Chi volesse, puo' contattarci per esprimere il suo interesse qui.

Il team di GeoSolutions

.

GeoSolutions sponsorizza il GFOSS Day 2010

GeoSolutions è orgogliosa di annunciare la sua partecipazione come sponsorSILVER alla terza conferenza italiana sul software geografico libero, GFOSS DAY 2010 che si terrà a Foligno (PG) il 18 e 19 Novembre 2010.

GeoSolutions proporrrà inoltre un workshop di due ore sul GeoServer.  
Per iscriversi al workshop è necessario registrarsi alla conferenza in quanto la partecipazione al workshop  è limitata dalla disponibilità di computer. 

Il team di GeoSolutions

.

Workshop su GeoServer al GFOSS DAY 2010

GeoSolutions will hold a 2 hours GeoServer workshop at GFOSS DAY 2010,  the annual gathering of the Italian FOSS4G crowd.

The workshop will provide a quick introduction to the GeoServer framework and will mainly focus on:

• basic installation
• basic data configuration and publishing
• basic data exploitation

In case you are around and you want to attend the workshop, make sure to register for the conference since seats are limited!

The GeoSolutions team.

A new file chooser for GeoServer

Creating a new shapefile or directory store in GeoServer is nowadays quite easy, you basically just have to specify the path to the file or the directory and GeoServer figures out the rest. However, that still requires you to hand type the path to the file.

I normally don't mind when running GeoServer locally, but it sure gets annoying when GeoServer is deployed on a remote host and a ssh session is needed to pick up the exact paths.
However it's really doing GeoServer workshops that one sees poeople used to desktop software getting out of their comfort zone with this "type a path" thing.

So lately we've been developing a patch adding an interactive file chooser that allows you to pick a file or a directly but simple point and click. Let's have a look:

1. The new shapefile store dialog provides with the "browse" button that will open the file chooser:
   
   
   
2. The file chooser in action, picking up a shapefile:
   
   

   

   
   
3. Choosing a directory of shapefiles instead:
   
   

   
4. The result of picking up the directory. As you can see we've choosen a directory inside of the GeoServer data directory and a relative path has been created (ensuring the data directory configuration remains portable among machines)

If you want a more dynamic display ve've also made a quick screencast (apologies for the low quality of it) that you can download from the GeoSolutions demo server. If you are on Linux you should be able to display the OGG Vorbis format directly, on other platforms you can install VideoLan to play it.

This new functionality will soon land into a GeoServer 2.1.0 near to you :-) .

The GeoSolutions Team,

"Geoserver for the masses" from the Tanzanian GIS User Group

Dear All,
just spreading the word on this nice article that evaluates/introduces GeoServer as a tools to easily disseminate geosaptial data. We are actually very proud to hear the following:

Although GeoServer will not find the same audience as Google Earth it helps by leveling the field when it comes to providing spatial data by the use of servers. Where one earlier would need detailed knowledge (and funding) to set up ESRI products, one may now do the same investing only a couple of hours of work. Within hours you could be able to present spatial data within your own organization, or even externally using a web server.

If you are interested in reading the full article, which also contains a small intro on how to publish and style data with GeoServer, you can find it here.

The GeoSolutions Team.

WMS cascading in latest GeoServer

One of the new exciting features in the GeoServer 2.1 series is WMS cascading.

For those that are not familiar with it, cascading allows to expose layers coming from other WMS servers as if they were local layers. This provides for some interesting advantages:

• Clients connecting to your SDI need to care about less points of origin, which might be important for high security networks
• It is now possible to ask for maps in formats not supported by the original server, or to reproject the maps in projections not supported by the original server (GeoServer supports out of the box almost 5000 different coordinate reference systems)
• It is now possible to mix the layers with local ones to generate print oriented formats such as PDF
• It is now possible to provide more informations about the layer, such as a better description, more keywords, which will benefit all clients, in particular catalogs harvesting informations from your capabilites document

Configuration

The configuration as usage of the cascaded layers follows GeoServer traditional ease of use.

The first step is to configure a new WMS server to be cascaded. In GeoServer terms that means configuring a new store, a WMS store in particular.

The only parameter needed is the capabilities document of the cascaded server, in this case, the DEMIS one (http://www2.demis.nl/wms/wms.asp?wms=WorldMap&request=getcapabilities&version=1.0.7)

Past this point it's business as usual, one just need to choose which layers to cascade using the normal layer configuration workflow:

Result

Here is GeoServer map preview showing two layers, Topography and Borders:

Of course it is also possible to mix in some local vector layers, such as, for example, the Tasmania layer group:

As said, one of the nice things about cascading is that one can add a few features, such as reprojection, transparently. The original modis server does not advertise reprojection abilities, yet GeoServer can reproject the data into EPSG:3785 on the fly for us:

Missing Features
There is still a number of things that can be done vs cascading:

• Support for secured remote servers
• Support for vendor parameters in cascading, including custom styling
• Better networking support, with HTTP 1.1 persistent connections, limitations on the number of parallel requests to the cascaded server, and configurable timeouts
• Support for choosing the cascading format (right now PNG is used)
• Support for GetFeatureInfo cascading on servers that do not provide GML output (if the GML GetFeatureInfo output is there full cascading is already in place and working!)
• Cascading WMS 1.3 servers
• Auto configuration of the layers exposed by a remote server, so that new layers are automatically exposed by GeoServer without any manual intervention

Are you interested in any of the above features? Let us know!

Regards,
the GeoSolutions team.

GeoServer Workshop at GFOSS DAY 2010

GeoSolutions will hold a 2 hours GeoServer workshop at GFOSS DAY 2010,  the annual gathering of the Italian FOSS4G crowd.

The workshop will provide a quick introduction to the GeoServer framework and will mainly focus on:

• basic installation
• basic data configuration and publishing
• basic data exploitation

In case you are around and you want to attend the workshop, make sure to register for the conference since seats are limited!

The GeoSolutions team.

Latest on JPEG2000 Improved Support for the Java world

Dear all,
We would like to take the occasion to describe more in details some improvements that were implemented with the ImageI/O-Ext 1.0.8 release (which is now supported by GeoServer 2.0.2, 2.7.x and GeoTools 2.6.4 and 2.7.x) as well as with the previous ones.

Reader Improvements
Various improvements have been implemented for the JPEG2000 Kakadu reader in order to enhance its speed and robustness:

• More checks on stripe decompression
• Improved Warning Messages at startup
• Improved subsampling factor computation 

Writer Improvements
Various improvements have been implemented for the JPEG2000 Kakadu writer in order to enhance support for very large imagery writing in terms of more control options as well as in term of reduced footprint during the writing process itself.
Specifically we have added the following:

• Support for writing the GeoJP2 box
• Support for writing tile oriented images
• Support for Corder
• Support for ORGgen_tlm
• Support for ORGgen_plt
• Support for ORGt_parts 

Sample Code
At the following link you can find an example that tells you how to read/write JPEG2000 data using ImageIO-Ext:
http://pastebin.com/uY2n17Gz

ArtifactsReleased
Artifacts for Imageio-Ext have been deployed on the GeoSolutions maven repository, as well as on the OSGEO one.

Regards,
the GeoSolutions Team

Servizi di Supporto Professionale offerti da GeoSolutions

GeoSolutions è orgogliosa di offrire quattro piani di servizi enterprise incentrati sulla piattaforma GeoServer per aiutare i propri clienti a costruire una SDI (Spatial Data Infrastructure) di classe enterprise, attraverso l'integrazione e l'armonizzazione dei migliori framework geospaziali offerti dal mondo Open Source, la OpenSDI suite.

GeoSolutions grazie alla sua vasta esperienza nella costruzione e nel supporto di infrastrutture geospaziali di classe enterprise, fornirà alla vostra azienda uno straordinario livello di supporto durante tutto il ciclo di vita del progetto per ottenere con facilità un deployment ben riuscito!


Maggiori informazioni possono essere reperite qui.
Ci potete contattare qui.

ImageI/O-Ext 1.0.8 released!

Dear all,
GeoSolutions is pleased to announce the ImageI/O-Ext 1.0.8 release.

Some minor changes with respect to 1.0.7:
- More and improved write parameters for the JPEG2000 Kakadu plugin
- Minor clean up in GDAL base framework

This release still leverage on GDAL 1.4.5, therefore no changes are required on native libraries with respect to version 1.0.5, 1.0.6, 1.0.6-1, 1.0.7.

Released artifacts have been deployed on the GeoSolutions maven repository, as well as on the OSGEO one.

Regards,
the GeoSolutions Team

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 Java (JEE and JSE)
• Working knowledge of web 2.0 JavaScript frameworks like Ext-JS, GWT, Ext-GWT, JQuery
• Working knowledge of GeoServer  and OpenLayers
• Knowledge of web development with Python is a plus
• Good Knowledge of most important OGC specifications and concepts (WMS,
• WFS, WCS, coverage, etc...)
• 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.