Monday, January 7, 2013

Course: Java Open Source GIS Development - From the building block to extending an existing GIS application

About one and a half years ago I gave a course about Java Open Source GIS Development at the University of Potsdam for the Geoinformation Research Group, Department of Geography.

I always wanted to publish this material and make it nicer so people could use it... well, busy times and whatever... I ended up never publishing it.
So I simply do it now, without any additions and changes.

The course leads you through the development with geotools, jgrasstools with many code snippets and adding modules to the Spatial Toolbox of uDig.

The course is made of 5 parts, the pdfs are linked here on my slideshare page:






Enjoy and share if you like.

Proposal: Geoscript console in uDig

Recently I proposed to add an Editor to uDig, which would support Geoscript scripting from within uDig. The full proposal (RFC) is here.

Since there were some comments/questions in the community and I think some small missunderstandings, I would like to give a small overview of what is there already and how it should work. I will not repeat here what already mentioned in the RFC.

Currently this is in proposal state and will get into uDig only if the PSC will vote in favour. That said, we are working already on it for a while now, so there is some to show.

1) Open the editor

Two new icons appear, the will allow to open the editor creating a new empty script or to open an existing script.


We will create a new one. The user will be prompted to save the new script to file and an empty editor is opened.






There are a few tool inside the editor, needed to start and stop scripts, or set the heap memory allowed to be used by a script or enable logging.

2) Script away, with command completion and syntax coloring

Inside the editor some basic command completion is available. For geoscript objects, as for example the widely use Geometry:


but also for methods, as for example the fromWKT, a handy way to create geometries on the fly:






You might have noted that first the completion proposals that start with the inserted text are suggested and after those also the once that simply contain the text.

You might also have noted that keywords have a nice syntax coloring, in order to make the script more readable... and often to help users to make sure they have no typos :)


3) run your script

Once you have something you want to run, simply push the start button. The script will be run through the Spatial Toolbox engine and print the output in the console view. Let's create two polygons and intersect them.


4) plot some result - missing imports

Geoscript needs you to define the modules you want to use in your script through the import directive, which is usually placed at the top of the script.

If we try to plot the result by simply adding the plotting directive, it will fail, because the plot module was not imported:


The editor supplies a quick way to import the most common modules, which can be useful for people starting with the scripting and that do not know where the modules are. Push the button at the right of the stop button and the imports are added to the top. After that the script will work:



5) Geoscript

Geoscript allows for some fun, the best way to get into it is to start from the tutorials page. Just to add one more complex example, lets see a script that can render a map, properly styled, to an image:



Guys it is 2013, a GIS needs a scripting engine!!
We started with the JGrass scripting years ago and failed. Now that geoscript is here, this sounds like the way to run.

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.




Monday, November 19, 2012

Il Repertorio Nazionale dei Dati Territoriali





JGrassTechTips inserisce oggi nella sua homepage il link del Repertorio Nazionale dei Dati Territoriali (RNDT). Attualmente questo strumento sta muovendo i primi passi, ma noi desideriamo che entri a fare parte della “cassetta degli attrezzi” di ogni geomatico e, in prospettiva, di ogni cittadino italiano. Non siamo da soli, ma insieme a: