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.