MapFish is now an OSGeo project

The MapFish project has satisfied the requirements of the OSGeo incubator and is now an official OSGeo project. The following components are part of the incubated OSGeo project:
- MapFish Python Framework
- MapFish Print
- MapFish Rails Plug-In
The MapFish PSC and community would like to thanks the OSGeo Board and our Mentor Gary Sherman for their confidence.

Usage of MapFish controllers for vector tiling

This blog explains the usage of MapFish server to deliver vector tiles.
Have a look at the demo.
I really like this implementation, great work Jason ! ;-)

MapFish print supports WMTS RESTFul implementation

The Web Map Tile Service OGC standard has been published last year. OpenLayers supports it. MapFish print now also supports the RESTFul implementation of the WMTS standard.
The KVP implementation is not supported, but this wouldn't be a big deal to implement it. Patch welcome ;-)

Summary of FOSSGIS 2011

After 3 days in Heidelberg, here are some thoughts about this year's edition of FOSSGIS, the german speaker FOSSGIS conference. After reading the programm, we can see that the hot topics are web mapping (particularly performance and harvesting), open data, crowd sourcing and 3D. I was a bit suprised not to see a lot of presentations about mobile technologies.

Several presentations discussed the possibilities of harvesting or aggregation of geospatial sources. For the metadata, several systems are working well, but for the aggregation of goservices of geodata, there is, for now, no real solutions. The usage of MapProxies is one option, cascading geoservices is another option but both face technical and organizational issues. Still some work to do ;-)

LinkedData or GeoLinkedData (spain example) is also an area where a lot of works need to be done. I particularly like the idea to use the complete power of the web to access/find geo data.

Finally, it's great to see that a lot of works are done around performance. The web user doesn't like to wait and it's very important to deliver the geographical information very fast. Javascript compression, MapProxies or WMTS need to be used to satisfy the end user.

On the MapFish side, a lot of presentations mentionned this framework (for example http://www.energieatlas.org/) and the workshop was overbooked. GeoExt is also very widely used.

Great summaries here and some tweets here.

MapFish 2.1 is out !

Version 2.1 of MapFish Framework is out!

The highlights of the release include:

- re-licensing from GPL to BSD
- great performance improvement for bulk inserts (thanks Jorge Gustavo
Rocha for your help with that)
- now relying on GeoAlchemy 0.5 within_distance implementation

The full list of enhancements, bug fixes, and API changes, can be
found in the Release Notes [1]. The new documentation is online [2].

Thanks to everyone who contributed.

Studio Documentation

The documentation of Studio has been published.

First official release of Studio

Camptocamp just announced the release 0.5 of Studio. This initial release allow the editing of MapServer Mapfiles, with a WYSIWYG editor. You can test it here: http://demo.mapfish.org/studio/


Feedback welcome !

Playing with the HTML5 Geolocation API

I spent some time last week to explore the possibilities of the Geolocation API and I ended up by creating an OpenLayers control.



Practical considerations

The Geolocation API is very well documented and quite easy to use.

Regarding browser support, it works well on Firefox, Chrome, Safari, recent Android and Blackberry browsers. With Gears installed, IE and Opera Mobile can also support this specification. I didn't used Gears, since it is now deprecated.

The Geolocation API doesn't rely on one location technology. The browser can decide which method it will use. Several methods exist:
- Of course, GPS
- Assisted GPS
- WIFI positioning (WPS)
- Cell information
- IP Address
- Carrier connection
- Language
- Indoor location
The accuracy of these methods is very variable, from cm to hundred of kilometers. The Geolocation API provides an information about accuracy, but I have observed a kind of randomness in these values. I would consider it as a magnitude and not as a precise value (like a standard deviation, for example). From the specification "The accuracy and altitudeAccuracy values returned by an implementation should correspond to a 95% confidence level": the "should" is here important.

Implementation considerations

An example of the usage of the Geolocation API control can be seen here (in debug mode, so it can take some time to load). I use the excellent code provided by Camptocamp mentionned here. This should work on mobile and desktop browsers that support the Geolocation API.

In order to test the Geolocation API control, the following code can be used (complete code):

var GeolocationAPIControl = new OpenLayers.Control.GeolocationAPI({
   mode: 'position',
   displayPosition: false,
   displayAccuracy: true,
   geolocationOptions: {timeout:3000}});
map.addControl(GeolocationAPIControl);
GeolocationAPIControl.activate();

In this case, the Geolocation API will determine the position of the browser and center the map according to the accuracy extent. A circle will be represented in order to give an idea of the accuracy.
Instead of using the "position" mode, it is possible to use the "tracking" mode. In this case the position of the browser is tracked and the map is centered accordingly.

The Geolocation API functions "navigator.geolocation.getCurrentPosition" and "navigator.geolocation.watchPosition" accepts three parameters:
- a success callback function used to implement the behaviour of the application when a position is determined.
- an optional error callback function used to implement the behaviour of the application when the browser can't determined its position (also if the user doesn't accept to share its location)
- optional options used to configure the positioning. Three parameters can be used:
   * enableHighAccuracy: provides a hint that the application would like to receive the best possible results.
   * timeout: denotes the maximum length of time (expressed in milliseconds) that is allowed to pass from the call to getCurrentPosition() or watchPosition() until the corresponding successCallback is invoked. Be aware that it can take a long time to get a position.
   *- maximumAge: indicates that the application is willing to accept a cached position whose age is no greater than the specified time in milliseconds.

I would be happy to receive feedback and feature requirements about this control.

Update
A control is now part of the OpenLayers code base. Test it here: http://www.openlayers.org/dev/examples/geolocation.html

Seven 2011 geo predictions

Let's try to make a difficult exercise: the predictions. Here are some thoughts about what could happen next year. Of course these opinions are mine (so not of my employer or the MapFish community) and I don't pretend to cover all the geo world.

PS: it's not really related to MapFish, but some trends will of course have an impact on MapFish.

First 2011 geoprediction: the geospatial mobile year
We all want to use our favourite geo application on our smartphone, but this is often not possible. The main reason for that is the the lack of libraries supporting the very (too ?) wide varieties of mobile devices.
Several works on OpenLayers have already been done and I hope to see in 2011 a joint effort to make OpenLayers the reference in the geo mobile world. Another hope is to see a consensus regarding the user interaction models for geo applications on mobile devices.

Second 2011 geoprediction: always more cloud gis applications
We read all and its contrary about cloud computing. One key think to understand about cloud computing is that you can't simply "copy/paste" an application in a cloud infrastructure. In order to use the advantage of cloud computing, the applications need to be rearchictectured. I believe that the understanding of cloud computing will grow in 2011 and the advantages like low cost, scalability or reliability will make cloud computing the best solution for a large number of geo application.


Third 2011 geoprediction: the start of the end of heavy clients
Technologies like Silverlight or Flash/Flex will start to decline.
The main reason is of course the emergence of HTML5 and all the nice associated features like Geolocation API, CSS3, Canvas etc, etc...

Fourth 2011 geoprediction: clear separation between web mapping and web gis
It's always difficult to categorize the applications, but I believe that a geo application for all citizen can't be the same like a geo application for specialists. That's where I see the difference between web mapping and web gis. The ergonomy is key for web mapping and the functionality is key for web gis, but this doesn't mean that ergonomy is not important for web gis. I have seen often applications trying to cover the needs of ALL users. We'll see probably in the future more specifics and dedicated geo applications.

Fifth 2011 geoprediction: geoservices for all and everything
The vision of programms like INSPIRE is to allow the interconnection of Geo Services. This vision will soon be reality and we'll see always more Spatial Data Infrastructure delivering Geo Services.

Sixth 2011 geoprediction: REST, RESTFull and (Geo)JSON
The simplicity of the REST principles, the lightness of the JSON format and the possibility to workaround the cross domain issues will make that the usage of XML or SOAP, at least in a web context, will decline. And I hope that the future geo web standards will use REST and GeoJSON.

Seventh 2011 geoprediction: WebGL will allow fantastic 3D applications
The usage of plugin is always difficult to manage. With the emergence of WebGL, it is now possible to develop 3D viewer using directly the browser capabilities. Let's hope that this chance will be used !

I wish you all the best for 2011 !

MapFish Tutorial and Python Workshop

As mentionned in the Camptocamp blog, you can now access a Python Workshop and a MapFish Tutorial.