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.