ORIGINAL PAPER

Enhanced satellite positioning as a web service with goGPSopen source software

Eugenio Realini & Daisuke Yoshida & Mirko Reguzzoni &Venkatesh Raghavan

Received: 15 November 2010 /Accepted: 20 February 2012 /Published online: 8 March 2012# Società Italiana di Fotogrammetria e Topografia (SIFET) 2012

Abstract Providing enhanced satellite positioning as a webservice can be an effective way to enable low-level GPSreceivers to perform surveys with a good accuracy and toreduce hardware cost, by removing computation capabilityand embedded proprietary software. goGPS is an opensource application for achieving sub-meter accuracy withlow-cost GPS receivers by exploiting real-time kinematicpositioning, Kalman filtering, aid from a digital terrainmodel, and in general by integrating GPS data with othersources of information. Since goGPS directly processes rawGPS observations, it provides a means to substitute black-box processing components (e.g., GPS chipsets) with opensource positioning software. goGPS can work either in real-time or post-processing, by acquiring raw GPS data in inputand providing positioning (i.e., coordinates) in output.Though originally developed in MATLAB, goGPS wasrecently ported to Java in order to have the possibility to

provide it as a web service, thus allowing a wider user baseto develop and use it. Since real-time GPS positioningheavily relies on fast matrix computation, a careful selectionof Java matrix libraries was carried out in order to obtainoptimal performances. An Open Geospatial Consortiumstandard Web Processing Service (WPS) implementationof goGPS by means of ZOO WPS framework was devel-oped and tested in order to let lightweight clients just ac-quire raw GPS data, send them to a server for processing,and receive back the accurate positioning.

Keywords GPS positioning . Low-cost receivers .

MATLAB . Java .Web processing services

Introduction

Recently, as the word “ubiquitous society” describes, thetechnologies related to the Internet and to location informa-tion are developing remarkably. Handheld devices withbuilt-in GPS capabilities, such as smart phones, have spreadconspicuously; many location-based applications for mobiledevices are being developed, and the increasing use oflocation information draws attention for business. However,built-in GPS receivers in mobile phones and portable navi-gation devices offer low-quality positioning with an accura-cy of around 3–5 m. Moreover, in urban areas (e.g., inlocations enclosed by skyscrapers), the accuracy degradesfurther. Nevertheless, business with highly accurate locationinformation has not been spread at consumer level yet, sincegetting high positioning accuracy is still costly.

There are various grades in GPS devices: professionaldouble-frequency receivers can get positioning with an ac-curacy of some centimeters by real-time kinematic (RTK);professional single-frequency receivers can improve the

E. Realini (*)Research Institute for Sustainable Humanosphere,Kyoto University,Gokasho,Uji City 611-0011( Kyoto, Japane-mail: eugenio_realini@rish.kyoto-u.ac.jp

D. YoshidaFaculty of Liberal Arts, Tezukayama Gakuin University,2-1823 Imakuma,Osakasayama City 589-8585( Osaka, Japan

M. ReguzzoniDIIAR, Politecnico di Milano,P.zza Leonardo da Vinci 32,20133 Milano, Italy

V. RaghavanGraduate School for Creative Cities, Osaka City University,3-3-138 Sugimoto, Sumiyoshi-ku,558-8585 Osaka, Japan

Appl Geomat (2012) 4:135–142DOI 10.1007/s12518-012-0081-5

accuracy to less than 1 m using differential GPS correctiondata or single-frequency RTK, while low-cost receivers,which are mainly used for mobile phones and car navigationdevices, have accuracies of some meters. These differentdevices cost according to their hardware quality and there-fore their accuracy: professional double-frequency ones costUS $20,000–30,000, professional single-frequency ones US$1,000–3,000, and low-cost ones less than US $100. More-over, software in these GPS devices is proprietary; thus,source code is not opened to the public. This means thatpositioning algorithms cannot be modified or tuned to im-prove the accuracy for specific applications.

goGPS (http://www.gogps-project.org) is an open sourcesoftware package that can achieve accuracies of less than1 m, depending on sky visibility conditions, using low-costGPS instrumentation (specifically, u-blox Evaluation KitsAEK-4T and EVK-5T are usually employed for tests).goGPS has the potential to reduce costs greatly since thereis no limitation in development and distribution, in contrastto proprietary software. goGPS has been developed since2007 in MATLAB numerical computation language (Math-Works, Inc.—http://www.mathworks.co.jp/products/matlab/).MATLAB already implements a great number of mathe-matical functions, it excels in matrix manipulation andcomputation and it makes data visualization easy andstraightforward. However, MATLAB code is not compiled,and so, its processing speed is relatively slow, especiallyfor parsing big text files, like in the case of GPS data filesin RINEX format, and for displaying data: therefore, it isnot of practical use to post-process big amounts of GPSdata. Moreover, MATLAB is a commercial software plat-form that severely limits users to participate in the devel-opment or even just in the use of goGPS. Therefore, itbounds goGPS development within universities and re-search institutions even though it is an open source project.In this work, the core processing functions of goGPS havebeen ported to Java code in order to help the softwarespread at both user and developer level, to improve theprocessing and visualization speed, and to obtain a way toprovide goGPS processing as a web service, which is oneof the main future goals in the goGPS project.

goGPS L1 low-cost RTK positioning

Low-cost GPS devices typically implement small patch orhelix antennas and single frequency (L1) receivers function-ing in stand-alone mode; moreover, they are often highlysensitive to GPS signal (even if degraded) in order to assurepositioning with bad sky visibility conditions, like in denseurban environments or under forest canopy. Nevertheless,the positioning accuracy with this kind of devices is gener-ally low, not only because of the classical errors induced byatmospheric and clock delays but also because of the low

quality of involved hardware and the multipath resultingfrom high sensitivity.

goGPS (http://www.gogps-project.org) is an open sourcesoftware package (Realini 2009) designed to perform rela-tive positioning with code and phase (RTK) using low-costGPS instrumentation, if this gives raw data (GPS observa-tions) in output: in this way, atmospheric and clock errorsare removed or made negligible (Hofmann-Wellenhof et al.2003). Moreover, goGPS includes a Kalman filter (Kalman1960) applied to GPS observations, which reduces the esti-mation error by modeling the receiver dynamics, by weight-ing observations on the basis of their quality (i.e., signal-to-noise ratio and satellite elevation), by integrating additionalinformation like digital terrain models or road networks, andby exploiting at best the information provided by the L1phase, managing its ambiguities when changes of satelliteconfiguration or cycle slips happen. It is important to notethat phase ambiguities in goGPS are estimated by the Kal-man filter as float values, without trying to fix them tointegers; fixing ambiguities would certainly increase thepositioning accuracy, also when working with low-costreceives. However, the higher noise of this type of receiversand the fact that many obstacles reducing sky visibility andproducing cycle slips are often met when navigating, espe-cially in urban environments, make the fixing of ambiguitiesvery difficult to be achieved, at least with a sufficient levelof certainty. goGPS can work either in RTK or stand-alonemode, and it can be used either for real-time or post-processing tasks. Observations coming from a referenceGPS permanent station or from a virtual reference stationare needed for the RTK mode; thus, a mobile Internetconnection has to be available when using goGPS in realtime. goGPS can act as a Networked Transport of RTCM viaInternet Protocol (NTRIP) client for receiving observationsfrom a base station in RTCM 3.1 (http://www.rtcm.org/)format in real-time. On the other hand, for post-processingtasks, reference station data in RINEX format can be used.goGPS MATLAB is currently capable to decode threereceiver-specific binary formats for retrieving their observa-tions (u-blox UBX, SkyTraq binary, and Fastrax iTalk).Specific tools are provided for creating RINEX files fromeach source of raw data. By using low-cost GPS receiversand antennas with good sky visibility conditions, accuraciesranging from 40 to 80 cm with a moving receiver and with astationary receiver around 20 cm were obtained in severaltests using goGPS in RTK post-processing mode. Recently,tests have been carried out also by applying goGPS posi-tioning to geodetic receivers and antennas using only one oftheir frequencies (L1), comparing its result with a standarddouble-frequency RTK solution, and obtaining accuraciesranging from 20 to 40 cm with a moving receiver. Prelim-inary tests involving a better modeling of the receiver dy-namics (e.g., by providing information about when it was

136 Appl Geomat (2012) 4:135–142

kept stationary and when it was moving) show an accuracyof about 10 cm with geodetic receivers. Since no algorithmstailored for post-processing are currently implemented intogoGPS, the expected accuracy when working in real-time isessentially the same as post-processing.

Porting goGPS to Java

When it was decided that goGPS needed to be ported fromMATLAB to a more widely used language, the main candi-dates were C/C++ and Java. Despite favoring at first the C/C++option, mainly for concerns related to processing speed, whenthe group at Politecnico di Milano (Italy) and the IT companyCRYMS Sagl (http://www.cryms.com/) started a collaborationon goGPS development, the Java option was reconsidered andfinally chosen. This section briefly illustrates why goGPS wasinitially developed in MATLAB; then, while introducing Java,it explains the reasons that lead goGPS to be ported to thislanguage. Considerations about choosing a proper library forfast matrix computation are then made, followed by a perfor-mance benchmarking comparing goGPS MATLAB and Javaversions.

goGPS MATLAB version

goGPS was initially developed in 2007 at the GeomaticsLaboratory of Politecnico di Milano as a tool for teachingstudents about GPS positioning and Kalman filtering.When goGPS development effectively started with theaim of obtaining a complete application, Prof. Kai Borre’sEASY (Borre 2003, 2010) open source software packagefor code-only stand-alone GPS positioning (written inMATLAB) was used as a basis for developing the basicalgorithms and as a reference to check goGPS initial resultsand performance.

Nevertheless, MATLAB poses some drawbacks. For ex-ample, the text file parsing functions are very inefficient iftext files are not already formatted in a simple delimitedstructure, and since the main format for storing and ex-changing GPS raw data is RINEX (http://igscb.jpl.nasa.gov/igscb/data/format/rinex211.txt), which employs quitecomplex data structures as ASCII text, parsing large datasetsspanning several hours (tens of megabytes) becomes quiteslow. Moreover, MATLAB display functions, although easyto use and straightforward, are very inefficient too, especial-ly in real-time functioning, when timing and synchroniza-tion between rover and master data streams become crucialissues. Last but not least, MATLAB is neither a free nor anopen source software, and because of this, goGPS usage anddevelopment was in fact limited to researchers and profes-sionals who can afford to buy a MATLAB license. Althoughfree MATLAB clones such as FreeMat, Scilab, or Octave

may be able to run goGPS basic processing functions,incompatibilities are often introduced by missing specifictools, such as serial communication interfaces or GUI func-tions. Therefore, instead of trying to keep goGPS compati-ble with free MATLAB clones, it was decided to develop aMATLAB-independent version of goGPS by porting it toJava language, which is also better suited for providinggoGPS processing in a service-oriented architecture.

goGPS Java version

A typical argument against the adoption of Java is that it isslower than C/C++ because it is a pre-compiled language (i.e.,it is not compiled with the native language of the machinewhere it is executed), interpreted by the Java virtual machine(JVM) which has to be installed on the host system. Never-theless, performance benchmarks with C/C++ often show thatmodern Java implementations are getting nearer and nearer toC/C++ performance (sometimes they are even better), sinceJust In Time (JIT) compilation was introduced.

On the other hand, adopting Java brings benefits likebeing able to release platform independent executables,simplifying the source code, and having the possibility torely on numerous third-party libraries for the most diversetasks. In the specific case of goGPS, switching from MAT-LAB to Java allows users to run the software without own-ing a MATLAB license (on any operating system that caninstall a JVM), besides providing the possibility to easilyenable multiple threads to parallelize tasks.

Up to now, the core algorithms of goGPS have alreadybeen ported to Java, which means that goGPS Java can readinput data from RINEX files and perform positioning ascode-only stand-alone epoch-by-epoch least squared adjust-ment (LSA), code double-differenced epoch-by-epoch LSA,and Kalman filtered solution using both code and phase. Inevery case, observations can be weighted according to sat-ellite elevation, signal-to-noise ratio, or both. When usingthe Kalman filtered solution, changes in satellite configura-tion like satellite addition and loss, pivot change and cycleslips are handled consistently with the estimation of phaseambiguities.

The differences in the final positioning between MAT-LAB and Java implementations are always significantlybelow the accuracy achievable with the test instrumentation(goGPS with u-blox receiver). In any case, these differencesare never higher than 1 mm.

goGPS Java performance

A crucial issue to obtain good computation performance withgoGPS is matrix computation: at every epoch, Kalman filterequations are applied on matrices that, depending on thenumber of available satellites, dynamical model complexity,

Appl Geomat (2012) 4:135–142 137

and whether one frequency or two frequencies are used, canhave sizes ranging from ~30 to ~80 elements per line and/orcolumn. Moreover, at every epoch, several roto-translationsare applied for getting satellite and receiver positions in dif-ferent coordinate and reference systems (thus typically on 3×3matrices).

Several open source Java matrix libraries exist: in somecases, they focus specifically on handling matrices andlinear algebra, while in other cases, the matrix-related clas-ses are part of a wider toolset for scientific computation(Table 1 includes the most complete libraries with regardsto matrix manipulation and linear algebra). In order tochoose one of them, particular care was adopted to get thebest performance for the matrix size used in goGPS.

Moreover, since goGPS could be run either locally onlow-level devices (even as embedded solutions) or in client–server architectures, specifically server-side, on multi-coremachines with high computational capabilities, librariesperforming well also on lower grade CPUs (thus possiblyin single-threaded mode) were preferred. Finally, ease ofuse, good documentation, correctness of results, and activityof the project were obviously taken into account. A usefulopen source tool for benchmarking different Java matrixlibraries, called JMatBench (Abeles 2010a), was used tocheck the libraries’ performance according to matrix sizeon different grades of CPU. Finally, EJML (Abeles 2010b)was chosen according to the requirements described above.

The performance of goGPS Java version was comparedto those of goGPS MATLAB version on different machineswith different operating systems. A server-grade PC and aclient-grade laptop were used for the tests (specifications arereported in Table 2).

The Java Runtime Environment version was homoge-nized on all test machines: build 1.6.0_16-b01 was used.As for the virtual machine (VM), Java HotSpot(TM) 64-BitServer VM (build 14.2-b01, mixed mode) was used on theserver-grade PC, while Java HotSpot(TM) Client VM (build

14.2-b01, mixed mode, sharing) was used on the client-grade laptop. The same MATLAB version was used, thatis R2009b.

The time needed to parse RINEX files and the actualcomputation time employed by the core algorithms werechecked separately. The core algorithms roughly includethe following:

– Bancroft positioning (executed once)– Code double difference positioning (executed twice)– Satellite position computation (with clock and Earth

rotation corrections) (at each epoch)– Satellite topocentric coordinates computation (at each

epoch)– Kalman filter matrices setup (with computation of

parameters obtained from linearized observation equa-tions and observation weighting) (at each epoch)

– Ambiguity estimation and cycle slip check (at eachepoch)

– Kalman filter computation (at each epoch)

For the moment, goGPS Java does not employ any multi-threaded process, so everything is computed consecutivelyboth in MATLAB and Java.

The test dataset was a ~5-h survey (17,205 epochs) with anumber of satellites ranging from six to seven (satelliteseffectively used in the computation after applying a cutoffof 15° on their elevation). Table 3 reports the average timefor processing a single epoch.

It is clear that porting goGPS MATLAB code to Javamade a significant improvement in performance (as it wasexpected), especially for parsing RINEX files (i.e., textfiles). As for the core processing, the main difference is that

Table 1 Java matrix libraries

Pure Java Multi-threaded

Apache Commons Math ✓

Colt ✓ ✓

EJML ✓

JAMA ✓

jblas

JScience ✓ ✓

MTJ ✓

ojAlgo ✓ ✓

Parallel Colt ✓ ✓

UJMP ✓a ✓

a UJMP may be optimized by including native code

Table 2 Specifications of test machines

Server-grade PC Client-grade laptop

CPU Intel Core i7-8602.80 GHz (64 b)

Intel Pentium M 1.30GHz (32 b)

RAM 8 GB 1 GB

Operatingsystem

Linux Slackware6413.0 (Kernel 2.6.29.6)

Dual boot with Windows XPProfessional SP3 and LinuxSlackware 12.2 (Kernel2.6.27.7)

Table 3 Results of computation speed

Core i7Linux (ms)

Pentium MLinux (ms)

Pentium MWindows (ms)

RINEX parsing MATLAB 30.2 270.7 236.6

Java 0.2 0.6 1.0

Core algorithmsprocessing

MATLAB 15.3 33.5 20.6

Java 0.5 3.3 3.1

138 Appl Geomat (2012) 4:135–142

goGPS MATLAB code is not object-oriented, unlike theJava code.

An additional remark has to be made about the use ofEJML in goGPS. EJML provides two basic approaches todefine and work with matrices: the DenseMatrix64F class,which is oriented to speed and memory optimization, andthe SimpleMatrix class, which is a wrapper around DenseMa-trix64F that provides an easier but more limited and slow wayto perform matrix operations (Abeles 2010c). When goGPSJava was started, the SimpleMatrix class was used because itwas easy and straightforward, besides providing more read-able code. All the tests above were run with this class, but anadditional test was done by switching the most processingintense operations (Kalman filter and roto-translations of coor-dinates) to DenseMatrix64F class. An overall improvement ofabout 10 % in speed was noticed. Future developments willinclude more in-depth optimizations.

goGPS processing as an OGC-compliant web service

In recent information technology developments, there areremarkable trends that shift software processing from localcomputation units to remote ones in order to provide webservices such as software as a service and platform as aservice. Cloud computing is the latest effort in deliveringcomputing resources as a service: it represents a shift awayfrom computing as a product that is purchased to computingas a service that is delivered to consumers over the Internetfrom large-scale data centers—or “clouds” (Sriram andKhajeh-Hosseini 2010). Web services are based on standardHTTP communication, so that the user does not need toinstall any special software; service requests can be donedirectly through a browser, making web services straight-forward and easy to use. Moreover, multiple services can beconnected or merged in what is called “mashup” or “chain.”For example, Yoshida et al. (2009, 2010) developed a web-based points of interest (POI) management system whichcan import, handle, and display GPS track logs togetherwith POIs such as geo-referenced photos and videos. Thesystem connects Flickr’s photo album with a GPS track logby implementing Flickr’s web application programminginterface (API) (http://www.flickr.com/services/api/), and italso provides its functionality as a web service. These openweb APIs help in reducing redundant work and developmentcosts as the low-cost model of high availability in the informa-tion system field becomes mainstream. Obviously, theseimplementations require inter-operability, which is pursuedby the definition and application of standards. In the geospatialinformation field, ISO and Open Geospatial Consortium(OGC) promote standardization of data formats and servicesat international level. By complying with these standards,various applications can handle common data and processes

and therefore reduce data and software development costs, thuscontributing to the distributed processing network. These spec-ifications do not need royalties and are widely used especiallyin public sectors around the world. The main database enginesand GIS software packages already comply with open stand-ards, and this enables easy data connection and sharing withoutthe need of generating new data, which reduces significantlycosts and efforts. This leads also to a high level of inter-connectivity and a reduction of time of computation, and itcan guarantee the perpetuity of data and services.

goGPS processing will be provided as a standard WebProcessing Service (WPS) by subsequent developmentsteps, some of which have already been implemented. Thissection describes how goGPS Java code was run as a stan-dard web service using one of the available open sourceWPS platforms, specifically the ZOO WPS framework(http://www.zoo-project.org).

OGC Web Processing Services

The OGC WPS protocol defines a standardized interfacethat facilitates the publishing of geospatial processes and thediscovery of and the binding to those processes by clients.“Processes” include any algorithm, calculation, or modelthat operates on spatially referenced data. “Publishing”means making available machine-readable binding informa-tion as well as human-readable meta-data that allows servicediscovery and use (The OGC Web Processing Service2007). Thus, WPS can standardize all GIS processes andcalculations, and provide them as web services via HTTP.

WPS implementation using the ZOO framework

The ZOO Project is an open source project that provides anopen WPS platform. The ZOO Kernel is the core of theZOO Project: it is a server-side C kernel which makes itpossible to create, manage, and chain WPS 1.0.0 compliantweb services, by loading required dynamic libraries andhandling them on-demand. Thus, it can be easily connectednot only to geospatial libraries and scientific models but alsoto the common cartographic engines and spatial databases(Fenoy 2009; Fenoy et al. 2012).

The ZOO Kernel supports various programming lan-guages (C, Python, Java, JavaScript, FORTRAN, PHP, andPerl). This multi-language support is convenient for devel-opers and allows, above all, to use existing code to createnew web services. Open source GIS libraries or specificcode (spatial based or not) can thus be ported server-sidewith very little modifications and also make them availableas open processing services for various applications over thenetwork. ZOO is one of the latest open source softwareprojects, which has attracted attention as an engine forWPS in the geospatial community.

Appl Geomat (2012) 4:135–142 139

In this research, a basic process of goGPS Java wasimplemented as WPS using the ZOO Kernel. The imple-mented process works for reading RINEX files, performingpositioning by Kalman filter on code and phase observa-tions, and exporting results into KML.

The input parameters are provided via a URL as below:http://localhost/cgi-bin/zoo_loader.cgi?metapath0

&ServiceProvider0goGPS&Service0WPS&Request0Execute&Version01.0.0&Identifier0goGPS&DataInputs0Obs0pe r im2 . 08o ;Nav0COMO1190 . 0 8n ;mObs0COMO1190.08o;date02010-11-11_18:49:29

In this example, three RINEX files are used as input data-sets: an observation file containing raw data for the GPS rover(perim2.08o), a navigation file containing satellite ephemeri-des and ionosphere parameters (COMO1190.08n), and an

observation file containing raw data for the master station(COMO1190.08o).

Figure 1 illustrates an overview of the ZOO WPS serverand client communication. The client can be a web browseror a WPS-enabled GIS application such as uDig (http://udig.refractions.net), and it must send the WPS request parame-ters (as the URL above) through standard HTTP protocol.The ZOO WPS server receives the request, it carries out thegoGPS processing, and finally returns the WPS response asthe XML document shown in Fig. 2.

Figure 3 shows a web interface for goGPS positioningusing OpenLayers (http://www.openlayers.org) that can se-lect and upload GPS datasets as RINEX files and send a WPSrequest to the ZOO Kernel. The web client shows the resultthat is returned from the server as a KML file (represented by

Fig. 1 ZOO WPS server andclient communication

Fig. 2 goGPS WPS result

140 Appl Geomat (2012) 4:135–142

the purple line in the figure) overlaid on Google Maps’background. The web interface uses Uploadify (http://www.uploadify.com), a jQuery (http://jquery.com) uploading pack-age which enables the web interface to provide uploadingfunction dynamically. For further research and development,several processes of goGPS Java are planned to be imple-mented as WPS in order to provide various web services forGPS positioning; the examples are as follows:

– RTK processing by goGPS Kalman filter (as in theexample above)

– Epoch-by-epoch least squares processing– Kalman filter (on previously computed coordinates)– Line simplification (e.g., Douglas–Peucker algorithm)– RINEX file generation from binary data (RTCM, UBX,

etc.)– GPS-related data format conversion (KML, NMEA,

GPX, etc.)

These implementations will allow general users to usegoGPS precise positioning in their web browser or in theirown applications since the goGPS web services are going tobe open services compliant with WPS open standard.

Conclusions

goGPS open source positioning software was ported fromMATLAB code to Java code in order to improve its

performance and to enable it to be provided as an OGC-compliant WPS.

In the first part of this paper, several performance testscomparing goGPS Java and MATLAB versions were de-scribed. The results clearly show the differences in speedbetween the two and indicate that the Java version of goGPScan work much faster than the MATLAB version, especiallyfor handling data input in the form of complex structuredtext files (e.g., RINEX files). The performance tests alsoincluded the evaluation of different Java matrix libraries forefficient matrix computation.

In the second part, the adoption of the open WPS plat-form ZOO as a WPS server and the implementation ofgoGPS positioning process using the ZOO framework weredescribed. The ZOO server successfully provided goGPSprocessing as an OGC-compliant web service.

Further developments for goGPS Java code includeenabling multi-threaded processing; optimizing the pro-cessing speed, with particular attention to matrix com-putation; and developing a graphical user interface.Concerning goGPS WPS implementation, further goGPSprocesses are going to be implemented as WPS in orderto provide a fully featured web platform for GPS posi-tioning. The web interface for goGPS WPS is alsogoing to be further developed. Last but not least, alow-cost hardware prototype that just logs raw GPS datain order to process them through goGPS WPS is cur-rently being developed.

Fig. 3 goGPS web interface

Appl Geomat (2012) 4:135–142 141

Acknowledgments The authors acknowledge the positioning serv-ices IREALP GPSLombardia (Italy) and JENOBA (Japan) for theirsupport in the test activities. The first author acknowledges the JapanSociety for the Promotion of Science (JSPS) for the post-doctoralfellowship under which this work was carried out. The authors wouldalso like to thank Peter Abeles, developer of EJML library, for his helpduring the matrix computation performance study; Gérald Fenoy forhis helpful support in integrating goGPS into the ZOO Kernel; andCRYMS Sagl for contributing to goGPS Java development. Thisresearch is supported by JSPS Grant-in-Aid for Scientific Research(issue no. 2109737) entitled “Development of Ubiquitous LBS Web-Service using Free and Open Source Software.”

References

Abeles P (2010a) Java-matrix-benchmark. <http://code.google.com/p/java-matrix-benchmark/>. Viewed 11 Feb 2012

Abeles P (2010b) Efficient-java-matrix-library. <http://code.google.com/p/efficient-java-matrix-library/>. Viewed 11 Feb 2012

Abeles P (2010c) SpeedSimpleMatrix—SimpleMatrix runtime perfor-mance study. <http://code.google.com/p/efficient-java-matrix-library/wiki/SpeedSimpleMatrix>. Viewed 11 Febr 2012

Borre K (2003) The Easy Suite—MATLAB code for the GPS newcomer.GPS Solutions 7(1):47–51

Borre K (2010) The EASY Suite. <http://kom.aau.dk/~borre/easy/>.Viewed 11 Feb 2012

Fenoy G (2009) ZOO project: an open WPS platform. Internationalconference FOSS4G2009, Sydney, Australia. <http://2009.foss4g.org/presentations/>. Viewed 11 Feb 2012

Fenoy G, Bozon N, Raghavan V (2012) ZOO project: the open WPSplatform. Applied Geomatics 4(1):1–6

Hofmann-Wellenhof B, Legat K,WieserM (2003) Navigation—principlesof positioning and guidance. Springer Wien, New York

Kalman RE (1960) A new approach to linear filtering and predictionproblems. Trans ASME J Basic Eng 82(Series D):35–45

Realini E (2009) goGPS—free and constrained relative kinematicpositioning with low cost receivers, Ph.D. thesis. <http://geomatica.como.polimi.it/tesi/E_Realini.tar>. Viewed 11 Feb 2012

Sriram I, Khajeh-Hosseini A (2010) Research agenda in cloud tech-nologies. 1st ACM symposium on cloud computing (SOCC2010). <http://arxiv.org/pdf/1001.3259>. Viewed 11 Feb 2012

The OGC Web Processing Service (2007) Open Geospatial Consor-tium. <http://www.opengeospatial.org/standards/wps>. Viewed11 Feb 2012

Yoshida D, Song X, Raghavan V (2009) Development of track log POImanagement system using free and open source software. Inter-national conference FOSS4G2009, Sydney, Australia. <http://2009.foss4g.org/researchpapers/>. Viewed 11 Feb 2012

Yoshida D, Song X, Raghavan V (2010) Development of track log POImanagement system using free and open source software. ApplGeomatics 2(3):123–135

142 Appl Geomat (2012) 4:135–142