This summer I've spent some of my time playing around with a personal project called POIProxy.

POIProxy is a service that handles requests to any public POI service providing a well defined REST API. It's able to parse JSON and XML responses and serve standard GeoJSON format, just providing a configuration file containing the URL and response format of the POI service to consume. And the best part, it's free software ;)

So, the service can be consumed by any GIS client, for example it's being used at this demo of OpenLayers social that @jacarma, @xurxosanz and @visancal developed for this year's FOSS4G. Although one of my pending tasks was giving support to gvSIG Mini to load the data provided by POIProxy, and that's what I've done this weekend.

At the moment it's just a "Proof of Concept" as I have no more time to spend on that (but I needed to see all that POIs on Android :P). So gvSIG Mini now is able to load, display the points and alphanumerical data of any layer provided by POIProxy and cache the data on disk, to speed up the data load after the first download.

As POIProxy is able to serve points from any WFS layer, now gvSIG Mini has also that capability. This is a snapshot loading the sample "world:cities" layer that comes into a standalone geoserver distribution.

Next step should be support search and reverse geocoding from POIProxy to gvSIG Mini, so we can finally replace the retired Namefinder service.

These days, @fergonco and me have been refactoring gvSIG Mini. The refactor was intended to decouple the MapView from any Activity, so it can be a (more) reusable widget.

Well, that goal has been fully accomplished, so while @fergonco has been giving support to add controls to the map (in the OpenLayers way), I've been playing around with the brand new vector API and adding support to load several tiled layers to the MapView. The result seems (in my opinion) very promising, besides there's some work left to have it fully working.

Here are some snapshots of gvSIG Mini loading two raster tiled layers and several local and remote KML files (some of them from the Geoportal de la Comunitat Valenciana, developed by Prodevelop some months ago)

PNOA (TMS) + Cartociudad (WMS)

PNOA (TMS) + Cartociudad (WMS) + KMLs

OSM + Google Maps transparent layer + KMLs

OSM + Google Maps transparent layer + KMLs

I will try to have all that features available in gvSIG Mini (at least for a demo) for the 7th gvSIG conference next December.

After 4 months of work Google Summer of Code has finished. I'm really happy with the final results. Fernando finally finished all the tasks scheduled and the first tests I've made with the code he has written look promising. After all there's some work left for both of us. While he is going to contribute gvSIG Desktop with the GPX provider and some patches to the GPE library. I'm going to integrate all his work for the next release of gvSIG Mini, so it will be able to load local vector data; a great feature in my opinion.

All the documentation written during this summer can be found at the project wiki. The source code at the Subversion repository. And these are some preview snapshots of the project:

Regarding my own impressions about this summer I have to say I'm really satisfied with the experience. My personal motivation since the beginning was continue working for gvSIG Mini and try to join others to work also for it, so that goal has been fully acomplished. On the other hand, being a mentor there's also a path to learn. During this summer I've learned to teach others in topics that were unknown for them, to manage and track their tasks. I've learned also a bit of Kanban and of course I've coded a lot.

Apart from this, the very real motivation was to give my father the GSoC t-shirt :P

The second month passed by and with it the mid-term evaluation. I guess this has been the first time in my life I have had to evaluate someone, so I’ve read a lot about the experience of other mentors in previous years, which are the ‘minimum requirements’ to pass someone, etc. and finally, besides I knew very well both students, I decided to be as objective as I could in the evaluation.

Unfortunately, being objective, I could not pass both of them. Failing a student is always bad news but as someone said once: “a lesson lived is a lesson learned”. When failing someone it’s important for the student to know exactly the reasons, and for the mentor, think about what he/she could have done to help the student. I’ve also talked with org admins to try to find paths to avoid that situation next years.

I’m sure all of us (mentor, student and org admins) have learned something useful :) and I have to thank him for applying. Finally I hope I could mentor him in future years.

On the other hand the gvSIG Mini GPE project is going on very well. The student has finished the support of GPE events and during the second part of the program is planned to develop some Android related tasks: building UI to list features and show details of a single feature. Also we have gained a GPE developer as he is ready to send a patch to the gvSIG tracker, so I’m very happy with this situation.

As for me, I’m taking advantage of this GSoC to refactor the architecture of gvSIG Mini. I’m mavenizing the Android projects and uploading to Maven central some artifacts, so it would be easier building a workspace and manage the different gvSIG Mini based applications.

Finally I’m also trying to refactor the core of gvSIG Mini, as the Android UI and Map components were a bit coupled. That is indeed a big refactor that I'm hoping to have finished by the end of the year.

I've decided to monthly write a post on my experience as a mentor during this Google Summer of Code.

This year I posted two ideas on the gvSIG Mini ideas page. The point is to make gvSIG Mini a vector data viewer of standard vector formats (GPX, KML, GML) and of non standard services that provide geo-located data such as Flickr, Foursquare, etc. Having such functionality, gvSIG Mini will become a map viewer of different sources (OSM, TMS, WMS, WMS-c) but also a vector viewer of many other sources. Of course any student could propose his own idea.

The application stage, was in my opinion successful: Five studentes applied for gvSIG Mini and I decided willing to mentor 4 of them (one not because he simply copy-paste my idea into his application form). The decision of the selected students was made by the gvSIG's board, that finally selected 2 students and both of them had a free slot to participate in the GSoC under the OSGeo umbrella.

The communty bounding period

The GSoC starts with a period where the students, can start to know the project and the community. They can introduce themselves, read documentation, plan his summer, know their mentors, etc.

During this period I proposed "my students" to introduce themselves to the community and to stay in touch with it during the summer.

Also we talk about the goals of this summer. gvSIG Mini is a great project to work for if you are a student because is not a huge project like others, this is not gvSIG Desktop or Drupal or whatever gigantic project. Either this is not a very complicated project, this is not the Linux Kernel :P. But in the other hand it fills all the requisites for a GSoC project. It's a free software project, with a community behind, actively maintained and very atractive for mobile developers.

So having this said, my idea for the GSoC is not to have a lot of work done (of course they'll have to code hard :P) but to have "usable" work done. I mean I want code that can be integrated into gvSIG Mini with less effort. I told this to them because I know how frustrating is to write code that is not integrated in a software, or used by no one, instead of that, to write code that can be used by thousand of users will suppose an extra of motivation.

Finally at the end of this period I had a meeting with each of them to discuss the scope of their projects. I gave them the big picture, drawing some component diagrams and thinking in use cases. I decided to make a Kanban table for each project, I divided the work in small tasks of 1/2 days that could be affordable by them; each task is analyzed by me, developed by them and finally validated by me and finished.

Of course I encouraged them to use the wiki and the SVN, so I can take a look to their progress remotely. To ask any problem to me (by Skype or mail) or to the mailing lists. And we agree to have a weekly meeting to review their progress.

First coding month

The first coding month is being quite different for both students.

While one of them is having a great time: He's writing usable code (even by gvSIG Desktop), he's having problems and asking to me and to the developers list, he's carrying out all the tasks at the time and getting involved too fast into the project. He's "giving me a lot of work" but that's great and he feels motivated.

The other is having too many problems: delayed tasks, no code at the SVN, weekly meetings also delayed. And that's, in my opinion, due to the lack of time and programming skills. This week I've encouraged him to ask doubts and finish some of the initial (trivial) tasks on the Kanban. I've also reduced his amount of work and clearly defined the scope of his project to give him an extra of motivation.

Well, it's a month left to the mid-term evaluation and I will love to pass both of the students, that will mean that they are doing a great job and gvSIG Mini is growing. Let's see what happens :)