First small JGrass tools migrate to uDig

You might be thinking I am crazy, but I was waiting for this post since at least 2 years now, i.e. from the day I decided to merge JGrass into the uDig community. I never did regret the move, but I had hard times to get at least the general purpose GIS stuff of JGrass into uDig. But that last hurdle seems to be gone now.

So let me do a quick summary of what got already into the udig core (i.e. next udig releases will show them) and what will come next:

1) one of the most important one for me was having support for the GRASS format. And here it is finally.

You can now import grass locations into uDig directly and visualize/use the rasters contained.



Also you can define colorrules and (!) categories.



2) The csv import tool

Not much to say, you have a comma separated values file that contains point coordinates, go to the import wizard, check csv import



configure how you want the resulting feature layer and you are done



3) Coverage export

It is now possible to export coverage layers to geotiff or esrii ascii maps. Starting from the export wizard



it is also possible to perform a reprojection during the export.



4) View line orientations

This might be of few help to some, but might be life/time saving to others. I much to often need to know the orientation of the lines that were digitalized. By selecting a line layer and opening the operations menu



this is now shown to you through arrows




5) The coverage info tool

The info tool now also understands coverages. Therefore if you pic with the info tool over a map, now also the coverage layers are taken into account




6) The profile tool

A profile tool for raster maps is now available. It is available under the info tools (the one with the red icon, indicating that there is a problem with the icon, has to be solved still)



Once activated, the selected layer's coverage is read and we can use the tool to draw lines (same as with the distance tool). The profile view opens up and the resulting profile is shown as it proceeds. Red markers are shown in the click points.



There is also a second mode to use the profile tool, which is through an existing feature.
To use that you have to select the feature layer and the raster layer you want to use for the elevations. Then you select the line feature you want to use for the profile.
From the operations menu choose: Feature on Coverage profile
You will get something like the following, having a marker in every node of the line




I feel good, I knew that I would!
Next are all the advanced style features and the netcdf format support.

The form editor - work in progress

I want to give a small preview of what the new form editor for creating dynamic and flexible forms in BeeGIS will look like. On one hand because it is coming quite nice and on the other to show to those that pay us on this (ARPA Piemonte) that we are getting closer.

Well, what would a form editor be? A tool to create forms to make surveying easier and also more standard. Once a form is defined for a certain shapefile, attributes of the features in the file can be modified in the same way by everyone through the form. I do not want to describe further here, that will be a task for the manual writers.

Let's see where we are now.

The "form language" has been defined on an xml base, so a file that looks like that



will produce a graphcial interface for feature editing like this one



This is a quite complex one and has more then one tab



Comboboxes can be described in a human readable way, while they modify the attributes with codes:




Well, yes, who would write such an xml to get a complex form? How long would it take. It took me about 2 hours to create the one I am showing here, but do not despair, we won't let users alone.

In fact there is also a form editor in progress that will make the generation of form files easy.

I will make the huge error to show you what it will more or less look like, but I also warn you that this is just a first draft prototype, things might change at least a bit.

Geopaparazzi is out!

Today we finally released the first version of Geopaparazzi on the android market. The project is released under GPLv3 an available on the homepage of the project.

Geopaparazzi is a tool developed to supprot very fast qualitative engineering/geologic surveys. It integrates completely with the BeeGIS digital tablet extentions, i.e. the data are imported straight into the GIS from the phone for further processing. See this link for an example.

Geopaparazzi is sold on the Android market and supports the development of Geopaprazzi itself as well as the projects developed by the same team: JGrass, JGrassTools and BeeGIS.

That said, I leave you to the documentation on the main website.

Distributing 'em around: hg and git

Well, well, finally it seems that we are all moving to distributed versioning systems...



uDig is now out at: http://gitorious.org/udig




together with JGrass as subproject: http://gitorious.org/udig/jgrass





jgrasstools home is: http://www.jgrasstools.org




beegis is slowly settling at: http://code.google.com/p/beegis




geopaparazzi is at: http://www.geopaparazzi.eu



Guess this is it, quite evenly distributed between git and mercurial.

SWT, Tabfolder and ScrolledComposite

Every time I have to create a scrolled tabfolder, it is the same. I have to fiddle around to make it work nicely. Around the net I can't find a good and complete example.

So here is how I solved it. Didn't have time to clean the code up. Remove objects you don't need and if you have troubles, just ping me. Hope this helps someone.
Here we go:


// create the tab folder
final CTabFolder folder = new CTabFolder(parent, SWT.BOTTOM);
folder.setUnselectedCloseVisible(false);
folder.setLayout(new FillLayout());

// for every Tab object create a tab
List orderedTabs = form.getOrderedTabs();
boolean first = true;
for( Tab orderedTab : orderedTabs ) {

// the tabitem
CTabItem tab = new CTabItem(folder, SWT.NONE);
tab.setText(orderedTab.text);
if (first) {
// select the first tab
folder.setSelection(tab);
first = false;
}

// we want the content to scroll
final ScrolledComposite scroller = new ScrolledComposite(folder, SWT.V_SCROLL);
scroller.setLayout(new FillLayout());

// the actual content of the tab
Composite tabComposite = new Composite(scroller, SWT.NONE);
tabComposite.setLayout(new MigLayout(orderedTab.layoutConstraints, orderedTab.colConstraints));

// which goes as content to the scrolled composite
scroller.setContent(tabComposite);
scroller.setExpandVertical(true);
scroller.setExpandHorizontal(true);
scroller.setMinHeight(folder.computeSize(SWT.DEFAULT, SWT.DEFAULT).y);
scroller.addControlListener(new ControlAdapter(){

public void controlResized( ControlEvent e ) {
// recalculate height in case the resize makes texts
// wrap or things happen that require it
Rectangle r = scroller.getClientArea();
scroller.setMinHeight(folder.computeSize(SWT.DEFAULT, r.height).y);
}

});

// the scroller gets the control of the tab item
tab.setControl(scroller);


// add things to the tab composite
List< ? extends FormElement> orderedElements = orderedTab.getOrderedElements();
for( FormElement orderedGuiElement : orderedElements ) {

FormGuiElement formGui = FormGuiFactory.createFormGui(orderedGuiElement);
formGui.makeGui(tabComposite);

}

}

Labels and Raster color masks

A quick update on the style editors for uDig for those who care.
The labels part and a raster color mask is now there for testing.

1) Example about lines labels

Now all the feature style panels have a labels panel added:



from there you can do several stuff, I will just show the labelling of lines here.

More or less I tried to support everything that gepotools does (some of it is taken from the sld cookbook of the geoserver community).

So the result would be:



2) Another thing that has been missing for a while in uDig is the possibility to create an alpha mask based on a color for imagery.

If for example I have a tecnical map:



which I would love to see in overlay with an ortophoto, I now can go into the style options and set a color to alpha:



Which then would lead to have the wanted overlay:




Sadly this last is not something that is supported in the SLD specs (so they tell me), so it can't be persisted in a sld file. However it might be added to geotools as a vendor option. That would be awesome. For now, I'll enjoy it in uDig...

svn merges from trunk

How easy is it to merge fixes from trunk into a stable version you did before?

With mercurial or git really easy, with svn it might be really easy :)

I have been lucky, having to merge fixes from the uDig trunk into the uDig 1.2.0 release tag, which, as it seems, was not really ready and didn't pass the QA.

Few steps to do the merge:

1) checkout the tag into which the new changes have to go

svn co http://svn.refractions.net/udig/udig/tags/1.2.0 udig1.2.0tag

that creates a folder udig1.2.0tag with the tag code in it.

2) cd into that folder and check for the differences with trunk:

svn diff http://svn.refractions.net/udig/udig/trunk -r31936:31952

31936:31952 are the revisions that were added to trunk after the tag.

Check the changes and see if the patch can work out for you or.... if you nothing scares you....

3) do the merge! :)

svn merge -r31936:31952 http://svn.refractions.net/udig/udig/trunk

Well, if you are lucky you have no conflicts, else just open up your IDE and fix them. Then commit. Your merge is done. Hmmmm, why is this always so scary?