Digital field mapping enhancements

Last week we did a couple of days of digital field mapping with BeeGIS and the students of the University of Urbino.

It has been a quite cool time and good places to see, but it also triggered some bugfixing and enhancements, which is good. Let's have a look at them.

1) the gps tool was not dummy proof

People not used to the tool tend to push every button very often and break things.
So I reviewed the gps tool bar a bit and it looks like that:


That means that no button is enabled until the gps is not logging.

If you push the logging (first from left) button without having connected the gps, it will prompt you for it:


and after properly having set everything you can start to use the tools you like:



2) the layer creation was not gis-dummy proof

When asking people to create a new layer on which to record gps point, line or polygon shapes on, people often got lost by that task. I agree that a person using the tool should know what he is doing and whioch projection he would like to use, but anyway, when you are on the field, things need to go much faster than usual.

That's why I added three new buttons:


Those actions create new layer ready to work with. The user is only asked where (i.e. to which shapefile) to save the layer. The layer is then created with the current's map projection, loaded into the catalog and map on top of the other layers. The created layer contains only two field, both of type string, called name and description. The user is assumed to use these action only at the begin, afterwards the layer creation tool can be used.

3) Give a look at the embedded database

A new view is available in JGrass and BeeGIS.
Go in the window menu:


select the other entry:


and take the database view.

This view connects and performs a login to the embedded database using the database preferences path, user and password:



and gives you a simple yet powerfull tool to browse the embedded database. This browser is usable only when you are using the H2 database, since it is the H2 itself that supplies this great tool.


4) sync your pictures

Whenever the gps is logging, the points are saved in the database with the gps's utctime and position. This information can be used to import a set of pictures taken during the field trip and put them on a map in the proper position wrapped by geonotes.

To do so go under File -> import


and choose import photos.

Tomorrow I will be on a field trip again. I will continue this afterwards, when I have taken tonns of gps points and images, in order to be able to show something real. Stay tuned.


5) unable to load map

We were not yet able to solve that, but finally we have a real error thrown that directed us to the part of code. If you have a map or a crs (seems to happen more often when Italian crs are used) for which the unable to load map always happens, please send it to us, since currently we are not able to reproduce it. But we are very near.

New colormap features

I can't remember exactly how many times I was asked to improve the colormap editor for raster maps.

For several reasons now I had to, so lucky the patient :)

This is how it looks now (in the next build):

We have the usual load from map, but now there is a consistent import and export possibility for colortables in GRASS format.




Also there is a combobox containing predefined colotables:




So if I choose the elevation colortable, I get:


When the colortable is chosen, the colorrules panel in the upper part updates itself, so it would be possible to modify that.

Netcdf is the best that's yet to come?

Hui hui hui!!!

As you might note in the list of accepted applications for the Geospatial Foundation Osgeo, Google is gonna make us all a present... some founding to bring netcdf and temporal navigation support in JGrass-Udig and friends! The doors are open!

Thanks to Jody for taking the burden to mentor me :)



Thanks to Google for the summer of code.



Thanks to Silli for supporting this.


Well, for being also the day I heard about Oracle buying up Sun... well, the day ended better than it started...

Custom crs and startup memory

It seems that if Friday the 17th (in Italy) is ment to be a very bad luck day, then Saturday has to be a very lucky bugfix and hacking day.

I finally got to work on some bugs that were bothering the JGrass and BeeGIS community, and I also got a couple of things that might interest you.

The first is right now for Italians, but I will explain how it might get expanded to interested.
In JGrass we now finally ship a custom epsg database, which is basically extended with some reference systems that we need a lot in Italy.


So as you can see from the pictures, if you now search for Italian Monte Mario, you get also the more precise ones that contain the needed Bursa Wolf parameters (I borrowed them from daddy GRASS :) ).

If you have similar issues and need a particular reference system (existing and documented please :) ), drop a mail in the JGrass mailinglist and I might add it.


The second thing is related to many users having memory issues in JGrass. Since defining the java heap is not always easy in rcp derivates, I finally added a preference page:


Here you can define:

• the workspace path: where your projects are by default created
• the locale: the language code that defines the user interface translation
• the memory: the memory in megabytes that you want JGrass to use

PS: the new versions of jgrass and beegis are right now uploading and it will take several hour from my home connection, so please wait until Monday :)

geonotes export, import and sending

In the following I will assume that you are familiar with the geonotes and fieldbook concepts.

Good, at some point there was the need to be able to export geonotes and import them back into another beegis session. The best would have been to be able to send them via email.

Alright, let's go throught the various steps.

1) the start situation: two geonotes with some drawing on it, some text and some multimedia files



2) export a note in human readable format: Dump geonotes


The dump geonotes command will ask you for a folder into which to dump the selected geonotes.
In my case I chose /home/moovida/TMP/dumpgeonote and what I got was the following structure:


As you might note from the names, what happens is that a folder with the name of the title of the note is created and inside we find

• the drawing in png format: geonote_paintbox.png
  
• the text box saved as text file: geonote_textbox.txt
• the mediabox as folder containing all the media of the geonote, in my case a png and a pdf
• a file containing informations about coordinates, projection, date

3) export a note in BeeGIS readable format: Dump geonotes binary

Again you will be asked for a folder into which to same the dumped note. I choose the same folder as before and this time a new file geonotes.zip is created. This file is a binary format that can be used by beegis to import geonotes.

To show the behaviour, I will now remove all the geonotes:



and

4) import one back again: Import geonotes archive



you will be asked for the geonotes archive. Once selected you should have the following situation:


Great, then let's assume we want to

5) send a geonote via email: Send geonotes

Before we play with the send geonote command, you probably feel that somewhere you should enter the information about email addresses, smtp server and similar.

You are right, for this we have a preferences page:


that needs you to insert:

• the smtp server used to send the email
• the server port used
• the user login for the email account
• the password for the above
• the email address to which to send the note
• a flag to define if beegis should use authentication

I have tried this all just with my gmail account, for which you need the 465 port and authentication set to true.

Alright, now we are ready to send a geonote throught the Send geonotes popup menu entry.

You should see some progress like:




and your mailbox should have a new email which looks like:


Cool, download the archive DON'T EVER RENAME IT (for this first draft version the internal folder has to be named the same way as the archive), and finally repeat the step 4) to import the note into the fieldbook.

Almost I forgot, since we want things to be easy, you can also drag the note into the fieldbook.

That's all about export, import and emailing of geonotes I guess. Enjoy!

PS: Just for info, I tested this on linux and windows. No Mac.

How to add a shortcut binding to JGrass

Alright, I wanted to be able to open the console editor by shortcut.
Here the steps to to achieve it.

1) create a command. Use the org.eclipse.ui.commands extention point to do so.

2) create a category for your new command(s) if you do not have one already. Rightclick on the extention point of point 1) , choose new and then category.

3) create a new command by rightclicking on the extention point as in point 2).

4) fill in some basic info, as name, description, category and a unique id for the command.

It should look like the following:


keep in mind the green part, we will need it later.

5) create an actionset with your action in it. Use the org.eclipse.ui.actionSets extention point.

Filling in the basic stuff will lead to the following:


Note that the blue part is the class that will actually exacute the action.

Instead the green part is the id of the command created before. The command will be the link to the shortcut binding, which we will create now.

6) create the shortcut throught the org.eclipse.ui.bindings extention point.

That would look like:



Only two things to note here:

1. commandid, which is again the id of the command created in 1)
2. the shortcut definition in sequence: ESC M1+E which results in a vi-like shortcut: first press ESC and then ALT-E
   

That should be all I think.

JGrass loves Worldwind

Lately I had the need to look a bit more deep into Nasa World Wind.

With the help of the amazing examples of Patrick Murris I have been able to connect a map from a GRASS workspace to be automatically visualised and tiled for WW.

The funky thing is that while tiled, a cache is created, so it is slow only the first time.



and the same with transparency:




I am still looking for a way to substitute the elevation model of WW with a custom one on the fly.

For now this is all about prototyping and documenting, but it looks great.
Would be good to have it embeded in JGrass/uDig as its default 3D viewer?
Who knows... :)