Epl-Gpl discussion from 2011

In 2011, driven by the need to better understand how to make GPL and uDig work together, I wrote an open letter to the Eclipse Foundation and the Free Software Foundation. I collected thoughts and results in the wiki of JGrass. Recently I had to migrate it and found this again. I want to keep it here for reference... and maybe it is also usefull to others.

Mind that this is pretty much a copy/paste of the original wiki page.


 
Here we go:

---

This wiki page contains informations, email exchanges and useful links regarding the possibility to mix and distribute code licensed under the GPL and the EPL.

Open letter for request of clarification to the Free Software Foundation Europe regarding the coexistence of GPL and EPL licensed code

To gain better understanding of the GPL-EPL compatibility problem, we wrote the following open letter to the Eclipse Foundationd and the FSF.

Introduction

My name is Andrea Antonello and I am an active member of the free and open source software (from now on FOSS) community for years now. I am member of the Open Source Geospatial Foundation (www.osgeo.org) and active developer and steering comittee member in a couple of FOSS GIS projects based on the eclipse rcp (from now on RCP).

For better understanding of the usecases I will ask you clarification of, let me give some introductory explanation.

Eclipse RCP doesn't need much presentation. It is the Rich Client Platform, released under the Eclipse Public License (from now on EPL) and the source of many doubts in licensing issues. uDig is a FOSS GIS and a GIS development kit released under lesser general public license (from now on LGPL). uDig is heavily based on the RCP. JGrass is a set of plugins for uDig and RCP released under LGPL. JGrass is heavily based on the RCP.

It is clear that this situation has no issues, since EPL and LGPL are compatible licenses.

I should mention that in the following cases GPL refers to the GPL version 3.

Motivations

JGrass is a highly scientific project, and as such it has difficulties in exploiting the real power of FOSS, since many scientific project that JGrass could use or connect to are released under general public license (from now on GPL).

This is the reason for which the JGrass team would like to release its plugins under the GPL license.
Given the incompatibility of EPL and GPL, many discussions were raised which lead to lot of confusion and potential border cases that may harm both the project's community and the involved commercial partners.

This letter is meant to request some clarification once and for all by proposing a couple of use cases of development and deployment of the above mentioned applications. I apologize in advance for  having inserted some obviously incompatible cases. The reason for this is that I would like to create a document for the above communities (and not only) to give more clearness and to assure many community members that have had problems with freeing their code to the above RCP based projects.

Use cases

Of the following 5 use cases, the first 4 all assume the following:
I write a simple rcp plugin (from now on called MYPLUGIN) to be used for uDig (for example like explained here). Developed in such a way the plugin contains imports of libraries from both the RCP:

•  org.eclipse.ui
•  org.eclipse.core.runtime

and uDig:

•  net.refrations.udig.project.ui

It is important to note that the MYPLUGIN contains only plugin specific code, which relies on implementations that reside in the referenced packages

•  org.eclipse.ui
•  org.eclipse.core.runtime
•  net.refrations.udig.project.ui

and are present in the target environment (uDig or RCP).

To be clear, in this case import is meant really as the java statement to declare which packages of external libraries shall be used by MYPLUGIN.

Use case one: writing a RCP based plugin and releasing it under GPL

I license MYPLUGIN under GPL, create a small jar archive of MYPLUGIN, put it on a website with installation instructions for putting it into uDig.

Can this be done?

Use case two: writing a RCP based plugin, releasing it under GPL and deploy it as an application

I license MYPLUGIN under GPL, package it with the uDig application, which I brand and bundle in one ready-to-use installer. I then put it on a website where users can download and use it.

Can this be done?

Use case three: writing a RCP based plugin, releasing it under GPL and install it as an application for a customer

I license MYPLUGIN under GPL and put it on a website as in use case one.

Assuming I wrote MYPLUGIN for a customer,  which of the following options are legal?

•  subcase 1: make a cd with both the uDig application and MYPLUGIN (but separate), and put on the cd installation instructions.
•  subcase 2: make a cd with uDig incorporating MYPLUGIN within a single installation file.
•  subcase 3: go to the customer site and install uDig and MYPLUGIN, creating an application ready for the customer's use.

Use case four: writing a RCP based plugin, releasing it under GPL and making it available via the eclipse rcp update site engine

I license MYPLUGIN under GPL.

I want to use the RCP's own installation manager to make MYPLUGIN available to both community and customers.

Can this be done?

Use case five: writing plugins using the Osgi framework

The following use case is a bit different from the above ones.

I want to develop a library based on the framework. Since through the uDig and RCP development I am very bound to the eclipse RCP, I decide to use the  Equinox framework to create the plugins that compose my library (instead of for example Apache Felix, which would have compatible license).

The library I produce will therefore contain imports of the equinox framework.

Which of the below can I do?

•  subcase 1: I deliver my library and the user will have to download the osgi framework on his own.
•  subcase 2: I deliver my library packaged together with the osgi framework libraries.

Conclusions

I feel that there is much confusion on the user's part when it comes to certain licenses. The EPL and GPL mixture is a real headache and still I'm not able to find someone that would assure me regarding this topic.

This letter is born of the opinion that a FOSS project comittee has to be able to give clear information about what can and cannot be done to potential developers and investors of the project.


Thanks in advance for the clarifications that the Free Software Foundation can give us.

Warmest regards
Andrea Antonello

on behalf of at least:

•  the uDig community
•  the JGrass community
•  the BeeGIS community
•  the Java User Group Trentino-Altoadige
•  and several commercial FOSS based companies

EPL-GPL: the verdict - UPDATE 2010/04

Through the below letter we got several email exchanges directly with the Executive Director of the Eclipse Foundation, Mike Milinkovich, who was very helpful in getting a good picture of what the problems are.

At the time of sending my email, Eclipse Foundation and FSF were discussing the GPL/EPL issue, so I didn't get a direct answer to the questions in the open letter, but now there is a public answer about the issues available:

Here the point of view of the Eclipse Foundation can be found.

And here the public statement of the FSF.

 

Comments and conclusions

After long discussions we think that the following applies:

•  it is not possible to create a pure GPL eclipse plugin. That makes one wonder why so many exist in the eclipse marketplace...
•  since an eclipse plugin is compatible only in the case in which an exception is added to the license (remember the classpath exception?)
•  and to create such an exception every author involved in the linked code has to agree on the exception
•  also because derived works inherit the license together with the exception, which basically is what the FSF states in the last part of its blog post: "...can address this issue by providing an additional permission with their license that grants users permission to combine their work with Eclipse in this way..."

HydroloGIS, 10 years of proud Italian Scientific Geographic Open Source and Environmental Engineering

I still remember it as if it was yesterday. We were sitting in the lab of Unitn (the Faculty of Evironmental Engineering of the University of Trento, where we were doing research for professor Rigon) and we were thinking about what to do. Money was running out in universities and the figure of external research staff was being obsoleted. Italy was going to face one big economical crisis.

I remember Silvia saying that she wanted to do a couple of years of research and then head off to do missionary work in Africa.

I remember not knowing exactly what I wanted to do. I had just found what I loved to do: developing open source GIS. It was not just developing anything. It had to be science and it had to be open. I remember dreaming about being able to develop any kind of tool for anyone and for free... right where big big companies were charging in an unfair way. I remember thinking that research should be for everyone out there. And I remember professor Rigon being of the exact same idea. 

At that time the slogan was: All in a aGIS!

We had figured that when it comes to environmental sciences, the glue to keep them all together could only be the GIS. With Riccardo we always joked about taking over ESRI at some point. Well, that one didn't work out that well. :-)

The first logo of HydroloGIS.

The second logo of HydroloGIS.

The current logo of HydroloGIS.

I told Silvia I thought she would be wasted for “normal” missionary work and that she should push her talents hard to do what many others would not be able to: create useful tools and then bring them developing countries together with training for it. And somehow I convinced her on something she didn't need to :-). 

I remember her telling me that most probably in about 5 years from that moment she would leave HydroloGIS anyways to follow her path in development countries.
I remember thinking: "It's ok even like that!". Being able to share a sparkling new experience with a pal that didn’t care a fig about making money exactly as I did, with the only wish to make science tools to release open source for the people… well, that was something that would not be easy to find again. We had to give it a try.

At that time she was following a master about project planning in Padova. One evening I was in the lab and she called me from Padova: “Are you serious about trying to create a company? There is this startup competition here... we could participate… everything needs to be delivered by midnight of today”. We chatted around for a short while, she gave me the link to the competition and then her cellphone battery died with her being spending the evening out (and not being easy to charge phones back then). I had no idea where to contact her again. I didn’t even know her home address at the time. I had to look up her parent’s phone in the paper phonebook (remember?) and call them to get Silvia's data for the contest. The lord meant it good to us, since during the following hours of struggle to write down the business plan idea and completing the competition bureaucracy also a name for the new company had to be chosen. Man, am I happy that HydroloGIS came that natural!

HydroloGIS at "Startcup"

Funny thing is that we wanted to try a startup competition to have confirmation about how good our idea was: Bring innovative open source technologies from the university to the professional world in order to make the world a better place. Sounds just about right, doesn't it?!?!?
Well, we didn’t even pass the first round!!! I remember project N.1 being a portable DNA analyzer device (I wonder where that company is today). We were so angry! How could they not understand!!!! So we decided to prove them wrong. And that is how HydroloGIS got born.

The really empty office of HydroloGIS at day 0. Those who now it now, would not recognize it.

We found shelter at the TIS Innovation Park Southtirol. At that time it was called BIC, the Business Innovation Center, which was an incubator and highly supportive for ideas both based on Environment and Open Source.

HydroloGIS, John Preston from the Jamaican reserach center ICENS and the University of Trento developed together JGrass, the open source GIS that wanted to be a userfriendly graphical interface for GRASS and specialize on hydro-geomorphological processing based on professor Rigon's past decade of research. 

The first JGrass logo, based on GRASS' logo

At that time the only development sponsorship to JGrass came from the MIGG course that we held with Rigon's team each year at the University of Trento.

And this was the first team preparing the course right after the MIGG2005 edition:

Andrea Cozzini, Erica Ghesla, Silvano Pisoni and HydroloGIS

Here the first JGrass versions have been developed.

One thing we have always been bad at was looking for work. At the very beginning we tried some commercial campaigns to sell HydroloGIS products around the region. Eventually we figured that it didn’t work. We have never been able to explain what we do properly and we simply didn’t have the skills to sell.

Luckily for us at the start there were some rather badly paid, but extremely interesting, projects with the university. Then later some jobs for government agencies came in. Interesting enough, we never looked for a job since then. The jobs just came to hunt us. And I mean it when I say "hunt". People started to come to us when they didn’t know where to head to solve their problems, usually after having tried for a while, hence burning both avaliable time and budget. And we took all those jobs, once again, bad paid and sometimes so demanding, that we had to work for free a long time to finish the job. Those were (hard but) great times, in which we grew incredibly from a professional point of view. But those were also hard times. And I exactly remember getting at the end of the year not having enough money to pay taxes. After a year spent working on average 15 hours a day!

But still we stuck to the plan: do everything the open source. It had to work!

Eventually one year passed and we were still in business:

 

and not in the worst shape (even if I was gaining quite som weight, eventually passing 100Kg :-) ):

In the years that followed (initially mainly on behalf of the University) we taught at several different courses and master courses, gave lessons at the university and to professionals, participated at many Conferences, EGUs and FOSS4G's, went to code sprints, developed GIS, made Engineering work, entered the OpenMI Steering Committee, the uDig Steering Committee, developed and coordinated JGrass, BeeGIS, the Nettools, the JGrasstools, Geopaparazzi and eventually won different innovation competitions.

Silvia winning the first price for innovative women entrepreneur.

GRASS code sprint in Prague.

JGrass went through many different periods. Being rejected from the GRASS community we had tried to develop it on our own, but it had overwhelmed us. we were not a pure software company.

A short history of JGrass until 2010, as presented at FOSS4G Sydney.

So in 2007 one big move had been done, the migration in what I was convinced was the best java open source desktop GIS (I still am convinced it has that potential): uDig

The first splashscreen of JGrass as uDig extension.

HydroloGIS, beyond others, teaching to high school teachers in Cape Town after the FOSS4G.

Talking about JGrass at Foss4G Sydney.

and having great fun at the same conference, always wearing the colors :-)

always ready to attend to important meetings to shout out our thoughts.

With the begin of my PhD at the University of Urbino a new open source door opened up. The mobile field mapping.

The BeeGIS extensions for uDig were developed in that context, which gained quite some interest. Being uDig based it worked only on full size pcs, or better tablets. Back then the big deal where Ultralight tablets, that had some complete-yet-downscaled operating system and were able to give enough juice to make uDig run on them. 

The splashscreen of the BeeGIS release for which ARPA Piemonte sponsored a nice part of development both for BeeGIS and uDig.

Digital field mapping as PhD student in Urbino.

Today I still have to laugh about that and I know some of you don't even remember. But tablets were heavy back then:

but everything is possible if you only want it:

In 2007 the first Geopaparazzi was born. And nothing has been as it was before :-)

We were finally able to have a tool that we would always have with us and with that we would be able to map in extreme situations:

Android made the BeeGIS project die out, because we simple stopped using it to develop the Geopaparazzi project, which, funny enough, turned out to be our most supported in the GFOSS world. There is even a facebook group for it now :-)

The years passed and many interesting things happened, as well as quite difficult things that hit hard on us. We tried to work tightly with other companies, which sometimes didn't work out well. We also tried to have employees, which did really work badly and we figured that would be something for when we are old :-). 

As I am writing this up now, overwhelmed by happiness and proud of what we achieved, all the bad things just vanish and I could go on telling you stories about our life, but I think it is really enough now. :-) It is really more material for a pub than a technical blog. But you got the point: I love the way HydroloGIS turned out, with its ups and downs.

The sole fact that few years ago I have been able to go back again to do music actively with my Alpentraum Orchestra, is a great indicator of having achieved what I wanted to: a job I love to work on every minute of the day and (some degree of) complete freedom in the organisation of time, which makes family and music possible.

Over time HydroloGIS made sense, even if they told us that it would not make sense to sell things for free and that we were crazy to do that in our niche of work... well, we were never able to properly explain it around here, we simply knew it was the right way. Eventually we figured that it was the somehow old Italian method that was wrong, not us. 

Our open source products and community involvement started to bring great jobs outside Italy and even overseas. While we still were not able to get work within a 100Km radius around our office (not one single job), we started to work in Germany, Finland, England, the United Arab Emirates, New York.

And obviously there were the projects in development countries, so important to Silvia :-). We were able to bring training sessions and our tools to Rwanda, Ethiopia and Kongo and work on water management systems. The sparkling new agreement with the GISMAP will help us to spread Geopaparazzi in the eastern side of the globe.

Silvia teaching Geopaparazzi in Arba Minch.

Teaching uDig and GIS at the University of Arba Minch.

Alright, I think I have kept you here for enough time now and my story is getting very confused. I know I missed many important things and people. Don't feel bad about it, this is a simple writedown, in a couple of hours, while browsing through old pictures and sensations.

One last thing I want to do is to thank those that believed in us even when there was no money and no future (well, that would be for about the first 6 years :-) ). Thanks to our families and partners, that supported us by any possible means. Thanks for being there, thanks for supporting without asking questions. Just thank you!

(In this picture, taken on HydroloGIS' 8th birthday, my mother and my sister Michela are missing. My mother was taking the picture and Michela lives too far away to be able to attend to every party we throw :-). I want them to know that they are part of it.)

Thanks also to Silvia, with who I had the luck to share these last 10 years. It has been sometimes difficult, she is soooooo hard-headed, but then I know I am too. :-) Thanks for letting me try all those things, even if no evident money would come out of it and we were starving :-) Thanks for being the other half of HydroloGIS.

HydroloGIS is Tony and Silli.

Last but not least, thanks to all of you that have sympathized with our concept of leading such a small company the meritocratic and open source way. We know you are out there and we have always been honoured when you told us how much you respect and like us.

Happy 10th birthday HydroloGIS, while my eyes are getting slightly wet...

Geopaparazzi at FOSS4G 2014 Osaka/Tokyo

This year I have the great honor to be invided to attend and present a the FOSS4G in Osaka and Tokyo and do some research with the team of professor Venkatesh Raghavan.

There will be to mainstreams we will contribute to:

Geopaparazzi

This is quite natural, since the Japanese is one of the most supportive communities to the project.

Well, we do not know all the details about the program yet, but we know for sure that apart of the talks there will be a:

Hands-on workshop:  27 Oct 2014: FOSS4G-Osaka

Code Sprint: 25 Oct 2014: FOSS4G-Osaka

I have to admit that for me as author of Geopaparazzi it is amazing to attend the first geopaparazzi code sprint in Osaka. I do love code sprints!

I know for many of you it is far, but maybe some nearby community members can come? It would be great to meet you in person and maybe discuss some future geopaparazzi features.


uDig, the Spatial Toolbox and LESTO

We will give some presentation about uDig and its Spatial Toolbox, both from a technical point of view as well as a user pooint of view.

We will also introduce the LESTO toolbox, which enables LiDAR data processing in the Spatial Toolbox.To get an idea about LESTO, have a look here.



That is all for now. But we'll keep you posted as soon as we have news.

uDig 1.4.0 on Osgeo4W + BeeGIS and the Nettools (and java 7) + 32/64bit

I have been made aware of the fact that java is outdated on Osgeo4W and that I am the maintainer. So I checked into it and noticed that I never upgraded uDig to 1.4.0 (and of which I know I am the maintainer).

Also I was told that the Nettools didn't work very well and even BeeGIS!!!

So I took the time to do a huge upgrade of everything and and very important: also added the 64 bit versions for Osgeo4W. This is almost mandatory for those that do raster data processing with uDig.

So pick your software: 32bit installer or 64bit installer.

Enjoy!!! :-)








 

UDIG 1.4.0 RELEASED

I am really happy to announce that uDig 1.4.0 has been released.

I will just link you directly to the announcement post.

Course: Geographic scripting in uDig - halfway between user and developer

I recently gave a course at the University of Potsdam about scripting in uDig. Since I didn't want me to take again more than a year to get this to you all (see here), I posted them already to slideshare.

This will soon be converted to a tutorial for the uDig community and available from its documentation section.

It will also be the big version of what I am going to present as a workshop to this years FOSS4G. Lets see if it gets picked.

Part 1: Introduction to uDig

Part 2: Data in uDig

Part 3: The scripting console

Part 4: Geoscript

Part 5: JGrasstools & Geoscript

Enjoy and share if you like them!

Talking about INSPIRE: of Humboldts and Hales

I just wrote a blog post about the Humboldt Alignment Editor here. It is written in Italian and I don't think I will have the energy to translate it in English right now (sorry!), but for the tutorial part, I think that google translate might do the trick. :)
Obviously if you have questions, just post them here, I will be happy to answer.

Go to the article.

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:

1) Introduction and main tools

2) Introduction to the main Geo-objects

3) Vector data

4) Raster data

5) Integrating with uDig

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.

GIS clipping benchmark: jgrasstools & uDig (on JTS & geotools)

I hate this. I hate it when I see a callout for a benchmark and am not able to not give it a try. And I hate it even more when I have tons of work to do. But yeah, I love the thrill :)

So here it goes. This morning Markus called out for the GIS Clipping benchmark contest revisited. Well, I somehow felt invited as part of the "other FOSS GIS", so I had to run for it. :)

On thing I noticed at once, is that the reported processing times were quite high. I had no proof, but in the last years I worked (also on editing) withmany 1.5 giga shapefiles in uDig. And to be honest I aslo found it was the only software (FOSS and non) that was able to handle the thing properly without making one get mad.

I wanted to have a look how the geotools/jgrasstools/uDig Spatial Toolbox would perform. I am not a real benchmark guy, but well, I can run some modules to have an idea about more or less what it takes. So I grabbed the testdata and gave them a run.

I have also to say that I ceated a bit because we didn't have a clipping tool inside the spatial toolbox up to now, since in uDig this would be done with the Axios tools. So I quickly wrote one, the VectorClipper.

The machine I tested this on is a 2 years old windows 7 64bit machine with 8 gigs of RAM and java 1.6.
It has 4 cores.

The first run was really simple, reading in the features, create an index to quickly get the features that might be involved in the clipping and clip one by one.

Result using one core: ~201 seconds

Interesting. GRASS takes about 5 minutes, but that is ok (or better, great), since it also does topology. QGIS seems to take about 5 minute, which looks a bit like bad performance to me, considered that our worst case scenario takes a bit over 3 minutes.

Anyways, let's focus on making things better.

The VectorClipper can run in multithreading mode. So I enabled it for my 4 cores.

Result using 4 cores: ~152 seconds

Hey, hey. Nice!
But We can do better than that.

Since the creation of the spatial index was taking quite some time, I decided to drop that one, and use instead JTS prepared geometries, which would make the intersects query faster.

So without an index but with fast intersect query I got:

Result using 1 core: ~130 seconds

Result using 4 core: ~110 seconds

So I though: what if I was wrong about the index thing?
So I added the index back...

Result using 4 core: ~102 seconds

Then I noticed that in the multithreading part I had some lists that got copied instead of just passed as indexes. Once that was fixed I got a nice:

Result using 4 core: ~82 seconds

Which is where I was very satified and stopped my tests.

So the above could be called the geotools/JTS/jgrasstools benchmark, since I was running the module from my development environment.

Running this inside uDig has some more overhead, so it made sense to test that, since that is what the user would get.

Here the result I got:

as you can see from the console output, the processing took about 117 seconds, which is anyways a good performance, considered the available benchmarks.


I can't take much credit on this, all the work is done by JTS and geotools, so the credit goes there.

I loaded the used jgrasstools libs on the site, so they could be used in uDig. If you need help in getting started with uDig's spatial toolbox, have a look at this video.

-------------------------------
UPDATE
Just for the interest/fun of doing it, I ran this on amazon AWS on an cc2.8xlarge instance with 32 cores. It took about 25 seconds, 2 of which for reading the data, 7 of which for writing the result, and most f the rest of the time for creating the index.

The new uDig video tutorial series

The following comes from the udig-news blog, since I wrote it I will report it also here.

Today we activated a youtube channel for uDig: http://www.youtube.com/udiggis

Here we want to collect different video material about uDig.

Some members of the community have agreed on creating each week a new tutorial about any feature not yet described.

Need some examples?

Ever needed to change language of the gui?
Or maybe you are new to GIS and are wondering about how to load common gis data formats?
What about query data in uDig?

More advanced users might need to rasterize a shapefile or vectorize a raster?
Scientific users might want to get started with the Spatial toolbox to do some analyses, maybe start with the extraction of a watershed from a DEM?


Anyone can contribute to the channel and anyone can ask for a tutorial about a certain feature.
On this page information about ongoing tutorial production is kept.
If you need a tutorial about any uDig feature, check if it is not already listed there, and if it is not, join the mailinglist and ask kindly. :)

Geopaparazzi 3 is out - explained through wiki-links

I learned through the years that jumping up major versions too often is not good. And I applied what I learned. Well, this time I was forced to, I swear. This had to be geopaparazzi 3. No 2.6.2, no 2.7.0. Just 3.

And  to show that to you all, I also upgraded the whole documentation wiki. And since most of the people out there do not even know that there is such an effort, I will make this release based on its entry.

So, let's walk through the changes that this release contains. The first two changes are definitely the most important ones and depend on the fact that we dropped osmand as mapping engine to go with mapsforge. The decision mostly came from the need to work with vector maps, but resulted in some other big advantage.

CUSTOM MAP TILES

It is now possible to load TMS tilesets into geopaparazzi. One can create tilesets from GIS data layers (also with jgrasstools) and load them in geopaparazzi. Tilesets can be in TMS or GOOGLE mode, and both remote or local.

Professionals will be particularly happy with this feature, since one can create maps from the overlay of complex GIS layers, as our small showcase shows.

VECTOR MAPS

Mapsforge works with vector maps. And so does Gaopaparazzi now (obviously). Vector maps are great, because they take much less space than tiles and one is able to carry along the whole map of his nation on the sdcard at each zoom level. That is an amazing feature. Never more missing tiles during your surveys!

Mapsforge generates and maintains a set of standard vector maps. Those guys are really amazing!

Recently the osmandguys started generating vector maps rendering after the opencycle maps.Those maps are great, because they also contain isolines.

OSM TOOLS

The OSM tools god some enhancement, mainly related to the ability to update the osm tags once they are extended on the main website. A tutorial is now available.

BOOKMARKS AND PROXIMITY ALERT

The bookmarks list has finally been enhanced to look a bit nicer. Note that it now gives the possibility to enable certain bookmarks with a proximity alert, which will ring when one get's near the point of interest.

FORMS AND TAGS

The forms part has been enhanced with some new tag, which can be usefull for more complex forms.

IMPORT AND EXPORT

New import and export features have been added. It is now possible to import and export from GPX, export to KMZ, export to some cloudbased service. An utility to import and export bookmarks has been added, which makes it easy to move bookmarks around projects.

CLOUD PROJECTS

Geopaparazzi exposes also a very simple API to load projects into the web and download online projects definitions as well as download actual projects. Currently we have no server to make this public, so you will have to believe in what we wrote here.

TRANSLATIONS

We didn't want to wait any longer to release this version, so we are behind with the translations. We have instructions for potential translators. Please help translating geopaparazzi in your language!

CONNECTIONS TO OTHER SOFTWARE

Until this release only BeeGIS was able to seamlessly import data into a real GIS software to allow further analysis.

Since the GRASS community sprint in Prague there is one new amazing software that is able to import geopaparazzi data. There is no info page available yet, but the module is already usable through the GRASS extensions engine. The module works with GRASS 7.


And that's it for this release. Enjoy|!

uDig web map tiles enhancements

Many of you for sure know that uDig has the ability to show Web Map Tiles.

From the import dialog you select Web Map Tiles:

push the next button and find a long list of available web map tile servers (which we should probably check).

There is also the possibility to select a custom server. This is very handy, but had 2 problems:
- it could not load local folders of files
- it understood only the google tile schema numbering, which means no TMS

Well, this is the first enhancement. Those two problems were solved. Mind that you will have to check the right option:

The second enhancement will make uDig Spatial Toolbox users happy. With the next uDig release we will also release the module that creates TMS folders from a set of layers. I do not want to go into detail shere, but a new module will allow to export a set of styled layers as tiles folder. Those tiles come with the complete description of the zoom levels and so on.

In fact since that file is the only thing needed to load a folder of tiles, it made sense to add a small item to the list, the JGrasstools TMS folder:

And there we have it. Push the button, push, push the button and:

This will be extrememly helpful for those like us that use uDig with BeeGIS field extensions out in the field on netbooks. The base dataset gets extremely lightweight to load and rasters can be prepared to be fast and easy.