Verto is a proprietary software package (available from the Italian IGM e-shop) to perform coordinate transformations among the various CRS used in Italy. Results provided by Verto are considered official so this software is used as a reference to estimate the accuracy of other tools.

Traspunto is a more accessible and less accurate alternative to Verto. It was developed by the Ministry for the Environment of Italy. It’s not open-source as far as I know, and is usually downloaded for free by end users like me :) According to Davide Travaglini and V. Baiocchi, M. Crespi and C. De Lorenzo, Traspunto provides submetric accuracy.

gvSIG Mobile uses three different sets of parameters (for Italy’s mainland, Sardinia and Sicily) to perform the transformation between WGS84 and the Monte Mario datum (for EPSG:3003 and EPSG:3004). The application decides which parameters must be used, depending on the input latitude and longitude:

These maps show the offset between the coordinates provided by gvSIG Mobile and the ones provided by Traspunto. The vector represented is:

[gvSIG Mobile value] minus [Traspunto value]

• Since Traspunto is much more accurate than gvSIG Mobile, those maps are showing a good approximation of gvSIG Mobile’s true accuracy.
• Each one of those maps is actually a composition of two different parts: for longitude < 12, it compares gvSIG Mobile and Traspunto in the transformation: EPSG:4326 to EPSG:3003, while for longitude > 12, it compares gvSIG Mobile and Traspunto in the transformation: EPSG:4326 to EPSG:3004.
• We can see a sudden change in the argument’s variation pattern for longitude > 15. gvSIG Mobile is using the same transformation parameters for the whole peninsula, so that discontinuity has to be caused by a change in the grid nodes used by Traspunto (it probably uses nodes from a different source when longitude is larger than 15.)
• Congratulations to Tuscany, Liguria and Sardinia (regions with highest accuracy). Pity about Apulia though (large orange area).

The modulus heatmap for Britain shown in a previous post looks like this when using the same color function I used for Italy. We can see that gvSIG Mobile provides about the same accuracy when using the traditional datums of these countries (Monte Mario and OSGB36).

Ernesto Sferlazza (from Agrigento, Sicily) has derived several interpolation grids from Traspunto in the NTv2 format (the de facto standard) which can be used in many applications like gvSIG. Downloads and details here. I actually used his grids to check that I was using Traspunto correctly.

The synchro server that survives among my room’s dust will be off-line between 25 December 2009 and 10 January 2010. If you try to use the synchronization service in that period, you’ll get a message similar to:

As I have been very nice for the last twelve months, I’m sure Saint Nicholas will bring me some cool new feature ;)

The Tellus project has been briefly presented in the 5th international gvSIG conference as scheduled on Thursday 3 December 2009 at 4 pm at the Convention Center in Feria Valencia (Spain). More details here. As an example, this video shows how a remote PostGIS database can be effectively updated from a Linux-based mobile device:

Olympic swimming pool in Barcelona on Google Maps. Latitude is 41.36573:

As served by the Cadastre WMS in EPSG:3857:

True length:

L = 66.57 * cos(41.36573) = 49.96 m

As far as I know, the Spanish Cadastre WMS server (run by the Ministry of Economy of Spain) is one of the first to provide its data in the Spherical Mercator projection EPSG:3857 (aka EPSG:3785 and EPSG:900913), so now we can switch between the great cadastre layer and the OSM layers for example. This is the Montjuic Palace in Barcelona:

As we know, the Spherical Mercator projection is conformal (keeps angles and shapes locally) and all parallels have the same length E:

R = 6378137 m
E = 2 * pi * R = 40075016.686 m

But we know that the true length of each parallel is approximately P = E * cos(lat), so if one wishes to measure distances, perimeters or paths directly on a map in EPSG:3857, it’s necessary to multiply the result by a factor f = cos(lat). For areas, f = [cos(lat)]^2. For Barcelona, for example, we have:

lat = 41.402634
f = 0.75008067 (distance)
f = 0.56262101 (area)

According to these results obtained with gvSIG, the perimeter p and area a of that block of buildings should be: p = 0.75008067 * 571.444 = 428.6 m a = 0.56262101 * 22935.684 = 12904.1 sq m The expected values (from the official size of the block shown here) are: p = 418 m a = 12387 sq m Oops, I think I didn’t choose a very standard block.

You can now test the new synchronization feature also in your Ubuntu or Windows desktop PC/laptop/netbook – and of course on your Freerunner (Linux/Openmoko) or Nokia N800/N810 (Linux/Maemo). Download your installer now!

		Linux/Ubuntu (tested on 8.04 and 9.04, also for netbooks)
		Linux/Openmoko for Freerunner (tested on SHR)
		Linux/Maemo for Nokia N770/N800/N810
		Windows XP/Vista and Windows 7

• Full install instructions here
• User manual here
• Installers are hosted in the project’s Garage page

This is what you will be able to do:

I have done a synchronization test to effectively edit a remote PostGIS table. This diagram describes the situation:

All three devices are using a wireless connection and are updating the same remote table which in turn is used by the server to render a point layer in raster mode (the server is both a synchro server and a map server). You can see a short video here. The remote synchro/map server is not shown:

You can also visit these websites (click on the logo):

	Tellus project blog
	Open mobile IS website

Open mobile IS (aka Openmis) is a Java open source project (GNU LGPL license) that aims to provide all the necessary tools, API and documents effectively enabling the development of mobile applications – not intended especially for GIS applications. It was created by Philippe Delrieu (Ubikis technical leader, based in Lyon, France) and has been used successfully for almost ten years in CDC and CLDC platforms. It’s listed as a mature project in the OW2 (ObjectWeb) consortium forge.

Manuel Gomez (Ubikis R&D officer) kindly invited me to join the Tellus project (visit its blog here) where he is exploring the integration of Openmis and gvSIG Mobile. There are several ways to integrate these two projects. I propose to add the Openmis client module as part of gvSIG Mobile (ideally as an extension). This diagram gives an idea of how Openmis fits our needs. Click to see larger image:

Openmis provides the synchronization engine, user authentication and encryption (this is only a part of all the components available in the Openmis framework). Synchronization happens at client request. The client side FODB (fast object database) lets the user work in disconnected mode, while the conflict resolver in the server side will decide who ‘wins’ if both sides have updated the same feature since the previous synchronization.

You can see a first test on a PC here.

In answer to Lanzo’s message in the Openmoko community mailing list, here is a demo where gvSIG Mobile for Openmoko v. 0.1.4 permanently shows the distance between the user and the shoreline. You only need to provide a line-type shapefile in EPSG:4326 with exactly one feature (the shoreline of your area). In this case, I recommend a vertex every 100 meters or so.

As you can see at the end of this 45-second video, the estimated distance between Plaza San Agustín (Valencia) and the Mediterranean sea is 4790 meters:

Some countries have an interpolation grid to accurately perform the conversion between EPSG:4326 and their traditional national coordinate system. gvSIG Mobile does not use so far any of these grids. Instead, it simply uses 7-parameter transformations and the standard formulae for projections, which causes a small error when the user watches the GPS arrow on his vector files or remote raster layers (when using a datum other than WGS84).

In the case of the United Kingdom and their national grid (EPSG:27700), an online free conversion service is available via the Ordnance Survey website:

http://gps.ordnancesurvey.co.uk/etrs89geo_natgrid.asp

This conversion claims to have an error of only a few cm, so we can accept it as the ‘official truth’ and compare our results with theirs. With a simple loop one can create a heatmap of Britain showing the divergence between the result given by gvSIG Mobile and the one obtained from the OS service, and here is the resulting heatmap in polar coordinates:

The vector represented is [gvSIG Mobile value] minus [OS value].

For example, the argument color for London is something between blue and cyan. Since blue = 0º and green = 120º, then cyan = 60º and the argument for London is about 45º. In the modulus heatmap, London is in a middle gray, so m = 5.05 / 2 ~= 2.5 m. All this means that, for London, the X (easting) in EPSG:27700 estimated by gvSIG Mobile is about 1.5 meters bigger than the X provided by the OS service and the Y (northing) in EPSG:27700 estimated by gvSIG Mobile is also about 1.5 meters bigger than the Y provided by the OS service.

Areas in black (Dorset & Ross-shire) are the lucky counties: gvSIG Mobile’s result is very accurate. Unlucky (white) counties include Norfolk & Lincolnshire.