Content uploaded by Eugenio Realini
Author content
All content in this area was uploaded by Eugenio Realini on Jan 30, 2015
Content may be subject to copyright.
1
Enhanced satellite positioning as a web
service with goGPS open source software
Eugenio Realini1*, Daisuke Yoshida2, Mirko Reguzzoni3, Venkatesh Raghavan4
1Research Institute for Sustainable Humanosphere, Kyoto University, Gokasho,
Uji City, 611-0011 Kyoto, Japan
* e-mail: eugenio_realini@rish.kyoto-u.ac.jp; phone: +81-774-38-3861
2Faculty of Liberal Arts, Tezukayama Gakuin University, 2-1823 Imakuma,
Osakasayama City, 589-8585 Osaka, Japan
3DIIAR, Politecnico di Milano, P.zza Leonardo da Vinci 32, 20133 Milano, Italy
4Graduate School for Creative Cities, Osaka City University, 3-3-138 Sugimoto,
Sumiyoshi-ku, 558-8585 Osaka, Japan
Abstract
Providing enhanced satellite positioning as a web service can be an effective way to enable low-
level GPS receivers to perform surveys with a good accuracy and to reduce hardware cost, by
removing computation capability and embedded proprietary software. goGPS is an open source
application for achieving sub-meter accuracy with low-cost GPS receivers by exploiting RTK
(Real Time Kinematic) positioning, Kalman filtering, aid from a digital terrain model and in
general by integrating GPS data with other sources of information. Since goGPS directly processes
raw GPS observations, it provides a means to substitute black-box processing components (e.g.
GPS chipsets) with open source positioning software. goGPS can work either in real-time or post-
processing, by acquiring raw GPS data in input and providing positioning (i.e. coordinates) in
output. Though originally developed in MATLAB, goGPS was recently ported to Java in order to
have the possibility to provide it as a web service, thus allowing a wider user base to develop and
use it. Since real-time GPS positioning heavily relies on fast matrix computation, a careful
selection of Java matrix libraries was carried out in order to obtain optimal performances. An OGC
(Open Geospatial Consortium) standard WPS (Web Processing Service) implementation of goGPS
by means of ZOO WPS framework was developed and tested in order to let lightweight clients just
acquire 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, the technologies related to the Internet and to
location information are developing remarkably. Handheld devices with built-in GPS capabilities,
such as smart-phones, have spread conspicuously, many location-based applications for mobile
devices are being developed and the increasing use of location information draws attention for
business. However, built-in GPS receivers in mobile phones and PNDs (Portable Navigation
Devices) offer low-quality positioning with an accuracy of around 3 - 5 m. Moreover, in urban
areas (e.g. in locations enclosed by skyscrapers) the accuracy degrades further. Nevertheless,
business with highly accurate location information has not been spread at consumer level yet,
since getting high positioning accuracy is still costly.
There are various grades in GPS devices: professional double-frequency receivers can get
positioning with an accuracy of some centimeters by Real-Time Kinematic (RTK), professional
2
single-frequency receivers can improve the accuracy to less than 1 meter using Differential GPS
(DGPS) correction data or single-frequency RTK, while low-cost receivers, which are mainly used
for mobile phones and car navigation devices, have accuracies of some meters. These different
devices cost according to their hardware quality and therefore their accuracy: professional double-
frequency ones cost US $ 20,000 ~ 30,000, professional single-frequency ones US $ 1,000 ~ 3,000
and low-cost ones less than US $ 100. Moreover, software in these GPS devices is proprietary,
thus source code is not opened to the public. This means that positioning algorithms cannot be
modified or tuned to improve the accuracy for specific applications.
goGPS (http://www.gogps-project.org) is an open source software package that can achieve
accuracies of less than 1 m, depending on sky visibility conditions, using low-cost GPS
instrumentation (specifically, u-blox Evaluation Kits AEK-4T and EVK-5T are usually employed
for tests). goGPS has the potential to reduce costs greatly since there are no limitation in
development and distribution, in contrast to proprietary software. goGPS has been developed since
2007 in MATLAB numerical computation language (MathWorks, Inc. -
http://www.mathworks.co.jp/products/matlab/). MATLAB already implements a great number of
mathematical functions, it excels in matrix manipulation and computation and it makes data
visualization easy and straightforward. However MATLAB code is not compiled and so its
processing speed is relatively slow, especially for parsing big text files, like in the case of GPS
data files in RINEX format, and for displaying data: therefore it is not of practical use to post-
process big amounts of GPS data. Moreover, MATLAB is a commercial software platform that
severely limits users to participate in the development or even just in the use of goGPS. Therefore,
it bounds goGPS development within universities and research institutions even though it is an
open source project. In this work, the core processing functions of goGPS have been ported to Java
code in order to help the software spread at both user and developer level, to improve the
processing and visualization speed, and to obtain a way to provide goGPS processing as a web
service, which is one of the main future goals in the goGPS project.
goGPS L1 low-cost RTK positioning
Low-cost GPS devices typically implement small patch or helix antennas and single frequency
(L1) receivers functioning in stand-alone mode; moreover, they are often highly sensitive to GPS
signal (even if degraded) in order to assure positioning with bad sky visibility conditions, like in
dense urban environments or under forest canopy. Nevertheless, the positioning accuracy with this
kind of devices is generally low, not only because of the classical errors induced by atmospheric
and clock delays, but also because of the low quality of involved hardware and the multipath
resulting from high sensitivity.
goGPS (http://www.gogps-project.org) is an open source software package (Realini, 2009)
designed to perform relative positioning with code and phase (RTK) using low-cost GPS
instrumentation, if this gives raw data (GPS observations) in output: in this way atmospheric and
clock errors are removed or made negligible (Hofmann-Wellenhof et al., 2003). Moreover, goGPS
includes a Kalman filter (Kalman, 1960) applied to GPS observations which reduces the
estimation error by modeling the receiver dynamics, by weighting observations on the basis of
their quality (i.e. signal-to-noise ratio and satellite elevation), by integrating additional information
like digital terrain models or road networks and by exploiting at best the information provided by
the L1 phase, managing its ambiguities when changes of satellite configuration or cycle slips
happen. It is important to note that phase ambiguities in goGPS are estimated by the Kalman filter
as float values, without trying to fix them to integers; fixing ambiguities would certainly increase
the positioning accuracy, also when working with low-cost receives. However the higher noise of
this type of receivers and the fact that many obstacles reducing sky visibility and producing cycle
slips are often met when navigating, especially in urban environments, make the fixing of
ambiguities very difficult to be achieved, at least with a sufficient level of certainty. goGPS can
work either in RTK or stand-alone mode and it can be used either for real-time or post-processing
tasks. Observations coming from a reference GPS permanent station or from a virtual reference
station (VRS) are needed for the RTK mode, thus a mobile Internet connection has to be available
when using goGPS in real-time. goGPS can act as an NTRIP (Networked Transport of RTCM via
Internet Protocol) client for receiving observations from a base station in RTCM 3.1
(http://www.rtcm.org/) format in real-time. On the other hand, for post-processing tasks, reference
station data in RINEX format can be used. goGPS MATLAB is currently capable to decode three
receiver-specific binary formats for retrieving their observations (u-blox UBX, SkyTraq binary
3
and Fastrax iTalk). Specific tools are provided for creating RINEX files from each source of raw
data. By using low-cost GPS receivers and antennas with good sky visibility conditions, accuracies
ranging from 40 to 80 cm with a moving receiver and around 20 cm with a stationary receiver
were obtained in several tests using goGPS in RTK post-processing mode. Recently, tests have
been carried out also by applying goGPS positioning to geodetic receivers and antennas using only
one of their frequencies (L1), comparing its result with a standard double frequency RTK solution
and obtaining accuracies ranging from 20 to 40 cm with a moving receiver. Preliminary tests
involving a better modeling of the receiver dynamics (e.g. by providing information about when it
was kept stationary and when it was moving) show an accuracy of about 10 cm with geodetic
receivers. Since no algorithms tailored for post-processing are currently implemented into goGPS,
the expected accuracy when working in real-time are essentially the same as post-processing.
Porting goGPS to Java
When it was decided that goGPS needed to be ported from MATLAB to a more widely used
language, the main candidates were C/C++ and Java. Despite favoring at first the C/C++ option,
mainly for concerns related to processing speed, when the group at Politecnico di Milano (Italy)
and the IT company CRYMS Sagl (http://www.cryms.com/) started a collaboration on goGPS
development, the Java option was reconsidered and finally chosen. This section briefly illustrates
why goGPS was initially developed in MATLAB, then, while introducing Java, it explains the
reasons that lead goGPS to be ported to this language. Considerations about choosing a proper
library for fast matrix computation are then made, followed by a performance benchmarking
comparing goGPS MATLAB and Java versions.
goGPS MATLAB version
goGPS was initially developed in 2007 at the Geomatics Laboratory of Politecnico di Milano as a
tool for teaching students about GPS positioning and Kalman filtering. When goGPS development
effectively started with the aim of obtaining a complete application, Prof. Kai Borre's EASY
(Borre, 2003; Borre, 2010) open source software package for code-only standalone GPS
positioning (written in MATLAB) was used as a basis for developing the basic algorithms and as a
reference to check goGPS initial results and performance.
Nevertheless, MATLAB poses some drawbacks. For example, the text file parsing functions are
very inefficient if text files are not already formatted in a simple delimited structure, and since the
main format for storing and exchanging GPS raw data is RINEX
(http://igscb.jpl.nasa.gov/igscb/data/format/rinex211.txt), which employs quite complex data
structures as ASCII text, parsing large datasets spanning several hours (tens of megabytes)
becomes quite slow. Moreover, MATLAB display functions, although easy to use and
straightforward, are very inefficient too, especially in real-time functioning, when timing and
synchronization between rover and master data streams become crucial issues. Last but not least,
MATLAB is neither free nor open source software, and because of this goGPS usage and
development was in fact limited to researchers and professionals who can afford to buy a
MATLAB license. Although free MATLAB clones such as FreeMat, Scilab or Octave may be able
to run goGPS basic processing functions, incompatibilities are often introduced by missing
specific tools, such as serial communication interfaces or GUI functions. Therefore, instead of
trying to keep goGPS compatible with free MATLAB clones, it was decided to develop a
MATLAB-independent version of goGPS by porting it to Java language, which is also better
suited for providing goGPS processing in a service-oriented architecture.
goGPS Java version
A typical argument against the adoption of Java is that it is slower than C/C++ because it is a pre-
compiled language (i.e. it is not compiled with the native language of the machine were it is
executed), interpreted by the Java Virtual Machine (JVM) which has to be installed on the host
system. Nevertheless, performance benchmarks with C/C++ often show that modern Java
4
implementations are getting nearer and nearer to C/C++ performance (sometimes they are even
better), since Just In Time (JIT) compilation was introduced.
On the other hand, adopting Java brings benefits like being able to release platform independent
executables, simplifying the source code and having the possibility to rely on numerous third-party
libraries for the most diverse tasks. In the specific case of goGPS, switching from MATLAB to
Java allows users to run the software without owning a MATLAB license (on any operating
system that can install a JVM), besides providing the possibility to easily enable multiple threads
to parallelize tasks.
Up to now the core algorithms of goGPS have already been ported to Java, which means that
goGPS Java can read input data from RINEX files and perform positioning as code-only stand-
alone epoch-by-epoch least squared adjustment (LSA), code double-differenced epoch-by-epoch
LSA, and Kalman filtered solution using both code and phase. In every case observations can be
weighted according to satellite elevation, signal-to-noise ratio or both. When using the Kalman
filtered solution, changes in satellite configuration like satellite addition and loss, pivot change and
cycle slips are handled consistently with the estimation of phase ambiguities.
The differences in the final positioning between MATLAB and Java implementations are always
significantly below the accuracy achievable with the test instrumentation (goGPS with u-blox
receiver). In any case these differences are never higher than 1 mm.
goGPS Java performance
A crucial issue to obtain good computation performance with goGPS is matrix computation: at
every epoch Kalman filter equations are applied on matrices that, depending on the number of
available satellites, dynamical model complexity and whether one frequency or two frequencies
are used, can have sizes ranging from ~30 to ~80 elements per line and/or column. Moreover, at
every epoch several roto-translations are applied for getting satellite and receiver positions in
different coordinate and reference systems (thus typically on 3x3 matrices).
Several open source Java matrix libraries exist: in some cases they focus specifically on handling
matrices and linear algebra, while in other cases the matrix-related classes are part of a wider
toolset for scientific computation (Table 1 includes the most complete libraries with regards to
matrix manipulation and linear algebra). In order to choose one of them, particular care was
adopted to get the best performance for the matrix size used in goGPS.
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
Moreover, since goGPS could be run either locally on low-level devices (even as embedded
solutions) or in client-server architectures, specifically server-side, on multi-core machines with
high computational capabilities, libraries performing well also on lower grade CPUs (thus possibly
in single-threaded mode) were preferred. Finally, ease of use, good documentation, correctness of
results and activity of the project were obviously taken into account. A useful open source tool for
benchmarking different Java matrix libraries, called JMatBench (Abeles, 2010a) was used to check
the libraries performance according to matrix size on different grades of CPU. Finally EJML
(Abeles, 2010b) was chosen according to the requirements described above.
5
The performance of goGPS Java version were compared to those of goGPS MATLAB version on
different machines with different operating systems. A server-grade PC and a client-grade laptop
were used for the tests (specifications are reported in Table 2).
Table 2. Specifications of test machines
Server-grade PC Client-grade laptop
CPU Intel Core i7-860 2.80 GHz (64 Bit) Intel Pentium M 1.30 GHz (32 Bit)
RAM 8 GB 1 GB
Operating System Linux Slackware64 13.0
(Kernel 2.6.29.6)
Dual boot with:
Windows XP Professional SP3
Linux Slackware 12.2
(Kernel 2.6.27.7)
The Java Runtime Environment version was homogenized on all test machines: build 1.6.0_16-
b01 was used. As for the Virtual Machine (VM), Java HotSpot(TM) 64-Bit Server VM (build
14.2-b01, mixed mode) was used on the server-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, that is R2009b.
The time needed to parse RINEX files and the actual computation time employed by the core
algorithms were checked separately. The core algorithms roughly include:
- 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 equations and observation weighting) (at each epoch)
- Ambiguity estimation and cycle slip check (at each epoch)
- Kalman filter computation (at each epoch)
For the moment goGPS Java does not employ any multi-threaded process, so everything is
computed consecutively both in MATLAB and Java.
The test dataset was a ~5 hour survey (17205 epochs) with a number of satellites ranging from 6 to
7 (satellites effectively used in the computation after applying a cutoff of 15 degrees on their
elevation). Table 3 reports the average time for processing a single epoch.
Table 3. Results of computation speed
Core i7 Linux
[msec]
Pentium M Linux
[msec]
Pentium M Windows
[msec]
RINEX
parsing
MATLAB 30.2 270.7 236.6
Java 0.2 0.6 1.0
Core
algorithms
processing
MATLAB 15.3 33.5 20.6
Java 0.5 3.3 3.1
It is clear that porting goGPS MATLAB code to Java made a significant improvement in
performance (as it was expected), especially for parsing RINEX files (i.e. text files). As for the
core processing, the main difference is that goGPS MATLAB code is not object-oriented,
differently from the Java code.
An additional remark has to be made about the use of EJML in goGPS. EJML provides two basic
approaches to define and work with matrices: the DenseMatrix64F class, which is oriented to
speed and memory optimization, and the SimpleMatrix class, which is a wrapper around
DenseMatrix64F that provides an easier but more limited and slow way to perform matrix
operations (Abeles, 2010c). When goGPS Java was started, the SimpleMatrix class was used
because it was easy and straightforward, besides providing more readable code. All the tests above
were run with this class, but an additional test was done by switching to DenseMatrix64F class the
most processing intense operations (Kalman filter and roto-translations of coordinates). An overall
improvement of about 10 percent in speed was noticed. Future developments will include more in-
depth optimizations.
6
goGPS processing as an OGC-compliant web
service
In recent information technology developments, there are remarkable trends that shift software
processing from local computation units to remote ones in order to provide web services such as
Software as a Service (SaaS) and Platform as a Service (PaaS). Cloud computing is the latest effort
in delivering computing resources as a service: it represents a shift away from computing as a
product that is purchased, to computing as a service that is delivered to consumers over the
Internet from large-scale data centers – or “clouds” (Sriram and Khajeh-Hosseini, 2010). Web
services are based on standard HTTP communication, so that the user does not need to install any
special software; service requests can be done directly through a browser, making web services
straightforward and easy to use. Moreover, multiple services can be connected or merged in what
is called "mashup" or “chain”. For example, Yoshida et al., 2009 and 2010 developed a web-based
POI (Points of Interest) management system which can import, handle and display GPS track logs
together with POIs such as geo-referenced photos and videos. The system connects Flickr's photo
album with a GPS track log by implementing Flickr's web Application Programming Interface
(API) (http://www.flickr.com/services/api/). And it also provides its functionality as a web service.
These open web APIs help reducing redundant work and development costs as the low-cost model
of high availability in the information system field becomes mainstream. Obviously, these
implementations require interoperability, which is pursued by the definition and application of
standards. In the geospatial information field, ISO and Open Geospatial Consortium (OGC)
promote standardization of data formats and services at international level. By complying with
these standards, various applications can handle common data and processes and therefore reduce
data and software development costs, thus contributing to the distributed processing network.
These specifications do not need royalties and are widely used especially in public sectors around
the world. The main database engines and GIS software packages already comply with open
standards and this enables easy data connection and sharing without the need of generating new
data, which reduces significantly costs and efforts. This leads also to a high level of
interconnectivity, reduction of time of computation and it can guarantee the perpetuity of data and
services.
goGPS processing will be provided as a standard Web Processing Service (WPS) by subsequent
development steps, some of which have already been implemented. This section describes how
goGPS Java code was run as a standard web service using one of the available open source WPS
platforms, specifically the ZOO WPS framework (http://www.zoo-project.org).
OGC Web Processing Services
The OGC WPS protocol defines a standardized interface that facilitates the publishing of
geospatial processes, and the discovery of and the binding to those processes by clients.
“Processes” include any algorithm, calculation or model that operates on spatially referenced data.
“Publishing” means making available machine-readable binding information as well as human-
readable metadata that allows service discovery and use (The OGC Web Processing Service,
2007). Thus, WPS can standardize all GIS processes and calculations and provide them as web
services via HTTP.
WPS implementation using the ZOO framework
The ZOO project is an open source project that provides an open WPS platform. The ZOO Kernel
is the core of the ZOO Project: it is a server-side C kernel which makes it possible to create,
manage and chain WPS 1.0.0 compliant web services, by loading required dynamic libraries and
handling them on-demand. Thus, it can be easily connected to geospatial libraries and scientific
models, but also to the common cartographic engines and spatial databases (Fenoy et al., 2009 and
2010).
The ZOO Kernel supports various programming languages (C, Python, Java, JavaScript,
FORTRAN, PHP and Perl). This multi-language support is convenient for developers and allows,
above all, to use existing code to create new web services. Open source GIS libraries or specific
code (spatial based or not) can thus be ported server-side with very little modifications and also
7
make them available as open processing services for various applications over the network. ZOO
is one of the latest open source software projects which has attracted attention as an engine for
WPS in the geospatial community.
In this research, a basic process of goGPS Java was implemented as WPS using the ZOO Kernel.
The implemented process works for reading RINEX files, performing positioning by Kalman filter
on code and phase observations and exporting results into KML.
The input parameters are provided via an URL as below:
http://localhost/cgi-bin/zoo_loader.cgi?metapath=&
ServiceProvider=goGPS&Service=WPS&Request=Execute&Version=1.0.0&Identifier=goGPS&
DataInputs=Obs=perim2.08o;Nav=COMO1190.08n;mObs=COMO1190.08o;date=2010-11-
11_18:49:29
In this example, three RINEX files are used as input datasets: an observation file containing raw
data for the GPS rover (perim2.08o), a navigation file containing satellite ephemerides and
ionosphere parameters (COMO1190.08n) and an observation file containing raw data for the
master station (COMO1190.08o).
Figure 1 illustrates on overview of ZOO WPS server and client communication. The client can be
a web browser or a WPS-enabled GIS application such as uDig (http://udig.refractions.net) and it
must send the WPS request parameters (as the URL above) through standard HTTP protocol. The
ZOO WPS server receives the request, it carries out the goGPS processing and finally returns the
WPS response as the XML document shown in Figure 2.
Figure 3 shows a web interface for goGPS positioning using OpenLayers
(http://www.openlayers.org) that can select and upload GPS datasets as RINEX files and send a
WPS request to the ZOO Kernel. The web client shows the result that is returned from the server
as a KML file (represented by 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 package which enables the web interface to provide uploading function dynamically.
Figure 1. ZOO WPS server and client communication
Figure 2. goGPS WPS result
8
Figure 3. goGPS web interface
For further research and development, several processes of goGPS Java are planned to be
implemented as WPS in order to provide various web services for GPS positioning, for example:
- RTK processing by goGPS Kalman filter (as in the example 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 use goGPS precise positioning in their web
browser or their own applications since the goGPS web services are going to be open services
compliant with WPS open standard.
Conclusions
goGPS open source positioning software was ported from MATLAB 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 tests comparing goGPS Java and MATLAB
versions were described. The results clearly show the differences in speed between the two and
indicate that the Java version of goGPS can work much faster than the MATLAB version,
especially for handling data input in the form of complex structured text files (e.g. RINEX files).
The performance tests also included the evaluation of different Java matrix libraries for efficient
matrix computation.
In the second part, the adoption of the open WPS platform ZOO as WPS server and the
implementation of goGPS positioning process using the ZOO framework were described. The
ZOO server successfully provided goGPS processing as an OGC-compliant web service.
Further developments for goGPS Java code include: enabling multi-threaded processing;
optimizing the processing speed, with particular attention to matrix computation; developing a
graphical user interface. Concerning goGPS WPS implementation, further goGPS processes are
going to be implemented as WPS in order to provide a fully-featured web platform for GPS
positioning. The web interface for goGPS WPS is also going to be further developed.
Last but not least, a low-cost hardware prototype that just logs raw GPS data in order to process
them through goGPS WPS is currently being developed.
Acknowledgments
The authors acknowledge the positioning services IREALP GPSLombardia (Italy) and JENOBA
(Japan) for their support in the test activities. The first author acknowledges the Japan Society for
the Promotion of Science (JSPS) for the post-doctoral fellowship under which this work was
9
carried out. The authors would also like to thank the developer of EJML library, Peter Abeles, for
his help during the matrix computation performance study, Gérald Fenoy for his helpful support in
integrating goGPS into the ZOO Kernel and CRYMS Sagl for contributing to goGPS Java
development. This research 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, viewed 11 February 2012,
<http://code.google.com/p/java-matrix-benchmark/>.
Abeles, P (2010b) efficient-java-matrix-library, viewed 11 February 2012,
<http://code.google.com/p/efficient-java-matrix-library/>.
Abeles, P (2010c) SpeedSimpleMatrix – SimpleMatrix runtime performance study, viewed 11
February 2012, <http://code.google.com/p/efficient-java-matrix-library/wiki/SpeedSimpleMatrix>.
Borre, K (2003) 'The Easy Suite - MATLAB code for the GPS newcomer'. GPS Solutions, 7(1),
pp 47-51.
Borre, K (2010) The EASY Suite, viewed 11 February 2012, <http://kom.aau.dk/~borre/easy/>.
Fenoy, G (2009) ZOO project : an open WPS Platform, International Conference FOSS4G2009,
Sydney, Australia, viewed 11 February 2012, <http://2009.foss4g.org/presentations/>.
Fenoy, G, Bozon, N, Raghavan, V (2010) 'ZOO project: The Open WPS Platform', submitted to
WebMGS 2010, Como, Italy.
Hofmann-Wellenhof, B, Legat, K, Wieser, M (2003) Navigation – Principles of Positioning and
Guidance, Springer Wien New York.
Kalman, RE (1960) ' A New Approach to Linear Filtering and Prediction Problems'. Transaction
of the ASME - Journal of Basic Engineering, pp. 35-45.
Realini, E (2009) goGPS - free and constrained relative kinematic positioning with low cost
receivers, Ph.D. Thesis, viewed 11 February 2012
<http://geomatica.como.polimi.it/tesi/E_Realini.tar>.
Sriram, I, Khajeh-Hosseini, A (2010) Research Agenda in Cloud Technologies, 1st ACM
Symposium on Cloud Computing (SOCC 2010), viewed 11 February 2012,
<http://arxiv.org/pdf/1001.3259>.
The OGC Web Processing Service (2007) Open Geospatial Consortium, viewed 11 February
2012, <http://www.opengeospatial.org/standards/wps>.
Yoshida, D, Song, X, Raghavan, V (2009) Development of Track Log POI Management System
using Free and Open Source Software, International Conference FOSS4G2009, Sydney, Australia,
viewed 11 February 2012, <http://2009.foss4g.org/researchpapers/>.
Yoshida, D, Song, X, Raghavan, V (2010) 'Development of Track Log POI Management System
using Free and Open Source Software', Applied Geomatics, vol. 2, no. 3, pp. 123-135.
