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:









Saturday, November 10, 2012

Geopaparazzi 3.3.0 is out: free you painting artist heart!

We just released Geopaparazzi 3.3.0 in the market.

There are a couple of enhancements and a feature I think most people will like.
The is version's changelog is the following:
  • added sketch pad for forms(the feature I think most people will like)
  • added textarea for forms
  • move export folder outside of geopap folder
  • fixed OSM notes info
  • sms are now sent through the system app
  • better geocoding
  • better about window 
Let's give some more info about those that need...

1) the sketch pad

If you browse through the menus, you will note that you are now able to add a new type of note:





and also when you add notes without gps:


Well, you now can add finger drawn sketches as notes to your map. For now the sketch pad is quite simple, it allows for some colors and some line widths. But it also has.... UNDO/REDO capabilities!! I really want to thank Almond Mendoza for his tutorials on creating a nice sketch pad.
An example? Assume you are an engineer that needs to create a quick schema of what he sees inside a manhole:


Just draw it, save it and it is on your map!



2) geocoding 

In the geocoding part, the routing gui has been cleaned up to have a better user experience. Remeber that narrow gui, where on small screens you were not even able to read the results? Yeah, that one.





3) sms sending

A user reported that the sms were sent without considering special offers they have with their carriers. So if seems that direct sending of sms goes through an extra channel.

Therefore for all geo-sms message sending we now popup the system's sms application, so the user can decide to add some text and decide the destination.

For the panic button, since when we use it we are happy to pay those few cents if it happens, we left the automatic, one tab sms sending.


Well, that is more or less it.
Enjoy!


one sad PS: this was the last version supporting android 2.2. With the next release NFC will get into the library, which will require android 2.3+. I am sorry about that, but we need to keep moving with the innovating parts.




Thursday, November 8, 2012

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.