This will be a bit long and a bit for developers. But it might be a good read for anyone interested in the future of geopaparazzi.
Last week we meet up with the guys of
Scolab to investigate, develop and plan future geoapaparazzi activities.
We had a way to big agenda, but we were positive we could do at least part of it:
- investigate a map renderer upgrade (mapsforge 0.7.0 or Nasa World Wind Android)
- make geopaparazzi pluggable to allow easier branding and customization
- investigate the possibility to use forms also for spatialite layers/features
Investigation of a map renderer upgrade
This is not exactly strategic at the time, but it would be good to have. Geopaparazzi now has support for some basic feature editing and the current workarounds to have this going are not all that nice.
So we gave a good test to Nasa World Wind.NWW is easy to understand, nicely coded and allows for a clean integration of mapping tools. It has built in support for WMS and it really looks as if it has all we need. There are a few problems though. It only seems to support geographic projection WGS84. We tried to implement a mapsforge offline maps provider, which worked out well, but then was impossible to finalize due to the missing mercator projection.
All the created code is available on my NWW clone. You can find the simple
create lines tool here and the
mapsforge integration here.
Another problem of the NWW project is the low response rate on the forum. It is an open source project so we can't blame it, but it sure has an impact on the choice. I tried to post two questions on the
android support forum, but there has been no reaction at all. It really is a pity, because we would love to use that project as next geopaparazzi renderer.
We also gave mapsforge 0.7.0 (the current) a go. There are a ton of examples available in the demo app. One problem is that the app crashes constantly while switching between examples. The other one is that the API has changed a lot from the version we are using in geopaparazzi. That means that we would have to start from scratch.
We had to stop on this due to time constraints. We now have more insight, but no clear ideas at all. This is a major work that needs to be done at some point but can't be done without the proper resources. Should we have them at some point, this investigation will sure help to get started.
Geopaparazzi plugins system
We then started to investigate possibilities to make plugins installable from the play store. This has been proven to be quite difficult and resources demanding while trying to make plugins thin and generic.
So we decided to make a first intermediate step. We created a plugin system that would be based on intent services and libraries. This means that it is possible to package a version of geopaparazzi that is branded and presents functionalities that the official version does not.
Branding isn't actually a plugin, but falls anyways into this pot of customization, so I will quickly explain it.
Branding
To brand geopaparazzi with an own name and style it is now possible to create a simply minimalistic android application.
Previously the geopaparazzi application was completely contained inside the android module named geopaparazzi.app while only the reusable code pieces were in their own modules:
- geopaparazzilibrary
- geopaparazzimapsforge
- geopaparazzimarkerslib
- geopaparazzispatialitelibrary
Now the logic of the app has been moved to the module
geopaparazzi_core, while a minimalistic app wrapper is contained in the
geopaparazzi.app module.
Looking into the wrapper modules shows that there is only one class containing:
| public class GeopaparazziActivity extends GeopaparazziCoreActivity { |
| } |
This means we just extend the main class and that is it.
In the same module we can define the app name and a custom style, as well as a custom icon for the app.
This minimalistic module makes it possible to maintain your own branded app in a very simple way.
Sure, plugins are necessary to make it really yours. :-)
Since the refactoring was in process we also decided to make the core module less dependent from the company that gave birth to the project,
HydroloGIS. This module was the last one containing the
eu.hydrologis.geopaparazzi namespace, which was changed to
eu.geopaparazzi to better stress the importance of openness. So if you were depending on this code, you will need to change the import removing the reference to hydrologis.
Plugins
As written before the plugin system is based on intent services. We have created during this code sprint
2 first extension points that allow to customize import and export menus and actions.
There is now
a folder named plugins, that contains available import and export plugin. If you do not include those in your app, then the import and export views will be empty.
Have a look at the plugins, simply look in the simple ones create in the plugins folder. It is quite easy to create one. If you need help, please write to the mailinglist of geopaparazzi.
gvSIG Mobile
The result of this first implementation of the plugins and branding is the first version of gvSIG Mobile.
While geopaparazzi will always exist and be developed, gvSIG Mobile is the app maintained by the gvSIG Association as the mobile solution of there stack:
As you can see from the screenshots it is quite simple to brand the app with a custom style and name.
Right now geopaparazzi and gvSIG Mobile are very similar, but this will change with the use of the plugin system. Right now there is already a big difference between geopaparazzi and gvSIG Mobile. gvSIG Mobile has the possibility to synchronize spatialite databases with gvSIG Online, which makes it possible to centralize data surveys.
Soon Scolab will also add the possibility to synchronize geopaparazzi projects to gvSIG Online to create online projects. This will make surveying even more fun and simple.
With time and resources (based on the jobs we do on this) we will slowly add extension points to provide dashboard actions, context menu entries and even map tools.
Forms for spatialite layers
This should have been an investigation of the effort necessary to allow the use of the complex forms of geopaparazzi also for spatialite layers. Also, it should be possible to create a tools for simple forms creation in gvSIG Online.
Sadly we didn't have time to even talk about this during the code sprint, time was too short.
Wrap up
It has been good to sit down with other developers and work together on common goals for a tiny project as geopaparazzi. I see the project growing slowly but constantly, which fills my hear with joy. The creation of the twin gvSIG Mobile is an important step and makes geopaparazzi the first choice in a GIS stack that is used all over the world.
Well, we'll see what the future brings. :-)
A quick image of the first visualization of gvSIG Mobile on an Android phone (one day this image will be important :-D ). With Jose^2 and Alvaro. Cesar is hidden somewhere :-)
