Monday, December 17, 2012

What if... this was a rasterlite database...?

What if this was a rasterlite database loaded as background map in Geopaparazzi?



Would you be happy? I am :)

Wednesday, December 12, 2012

How to load spatialite layers in Geopaparazzi?


I have to apologize for one really important missing piece in mi previous post: How do you get to view you Spatialite layers????

Thanks to all the nice users that made me kindly notice :)

I dedicated a page on the Geopaparazzi wiki to that. You can find it here.



Sunday, December 9, 2012

Geopaparazzi 3.4.0 is out! Please welcome the Spatialite brothers... and NFC support

At the begin of November Sandro Furieri, known for being the father of the Spatialite project (but also known for being our very personal presidential Fury of the Italian GFOSS association), wrote me an email about a release of spatialite for android.

Well, I was in a real busy moment and struggeling with the preparation of the presentation of the upcoming GFOSS day, the Osgeo Italian chapter gathering of the tribes.

Since I was doing a presentation about a history of the mobile trend, particularly related to Android and GFOSS software, I had to do something. So I spent soem night to integrate spatialite in geopaparazzi. Well, during the presentation I gave at the conference:

I only showed a small joke screenshot, where geopaparazzi was dialoging with Fury to do some transformations (see slide 50).

But from that moment I could not stop to think about a raster+vector format for data exchange between different operating systems and devices.

With Spatialite it would be possible to finally overlay not only points and simple lines, but also polygons and large datasets. The spatial index would help, i knew it would.

So we started to implement a new layer in geopaparazzi: the spatialite dataset layer.

An it seemed to work nicely with the Natural Earth datasets.






As a sidenote, since the map viewport in geopaparazzi is bound to use OSM mercator, Spatialite has to reproject the original dataset into that one.


This also produced a short developer tutorial which can be found here.


We tested this new spatialite enabled version on different devices and out in the Finnish flat/wetlands when checking back watershed boundaries extracted through the JGrasstools libraries (well, that will most probably be the next story). It works incredibly well even if it is not really optimized yet, which is why we decided to release it already.

This is how it looked like when we overlayed on a scanned Finnish orienteering map the results of our hydrologic/hydraulic study: old, new and extracted watershed boundaries and channel lines.






Ah yes, did you notice the new icon under the zoom buttons? That is a query button. Through that one you can draw query boxes on the map and the attrubutes of the intersecting features will pop-up:





Well, this opens up a whole new world for geopaparazzi and mobile development in general. And it will even more when the rasterlite part of Spatialite will be supported for Android!

A big thank goes to Sandro for helping out optimising the spatial queries and for fostering the development through realtime support.

Sure, this is the major news here, but there is one more huge addition to this release. We now support reading of RFID tags through NFC and bluetooth devices. For this feature an activity has been exposed for developers, but normal users can access this feature simply through the forms:





You can enable the tag reader widget and you will get a button, which, once pushed, will open this scanner activity:





The nice thing about this is that it is able to scan tags both through NFC and a bluetooth device connected to geopaparazzi.
Once you see your tag id scanned, push ok and the form textfield will be filled with the tag id.

One downside of the addition of Spatialite to the game, is that adding the native libraries and necessary stuff, brought geopaparazzi from less than 2 megabytes to almost 9 megabytes. We figured that people would not care particularly, since the added value is huge.

Well, I think that is all for this release. Enjoy!




Saturday, December 8, 2012

Android: Incomplete location object, missing timestamp or accuracy - ERROR


 Recently, when using my own Mock GPS Provider, I was getting an exception on my Google Nexus phone:


Incomplete location object, missing timestamp or accuracy

this almost drove me mad, since I could not find any solution out in the net.

Also it seemd to happen only on Jelly Bean Android devices.

So I had to do what I usually do not like a lot... dive in the Android source code. Luckily it was an easy one.

The LocationManager does a check on the Location object (isComplete method). There we have the mess. A check is made for

if (mElapsedRealtimeNanos == 0)

but I am not able to set that variable anywere before JB.
So if you create a Location with an SDK prior to JB and then run the code on JB, it will throw you an exception.

There is a nice method that, as javadoc states, helps backwards compatibility:

  1. /**
  2.      * Helper to fill incomplete fields.
  3.      *
  4.      * Used to assist in backwards compatibility with
  5.      * Location objects received from applications.
  6.      *
  7.      * @see #isComplete
  8.      * @hide
  9.      */
  10.     public void makeComplete()

So what you need to do to make sure your mock LocationManager doesn't break, is simply check at runtime if the method exists through reflection:

Method locationJellyBeanFixMethod = Location.class.getMethod("makeComplete");
if (locationJellyBeanFixMethod != null) {
   locationJellyBeanFixMethod.invoke(location);
}


and if it does, invoke it on the "incomplete" location object.

Since it is anyway a Mock class, I have no problem with that solution. I just wonder if that is the way to go. I assume not, since in that case it would be documented somewhere.

But well, it works. Hope that helps someone out there.