ArticlePDF Available

Smartphones in the field: preliminary study comparing GPS capabilities between a smartphone and dedicated GPS device

Authors:
Papers of the Applied Geography Conferences (2010) 33: 270-279
SMARTPHONES IN THE FIELD: PRELIMINARY STUDY COMPARING GPS
CAPABILITIES BETWEEN A SMARTPHONE AND DEDICATED GPS DEVICE
Anna Klimaszewski-Patterson (eradani@gmail.com)
Department of Geography
New Mexico State University
Las Cruces, NM 88004
1. INTRODUCTION
Purchasing dedicated global positioning system (GPS) devices is typically cost
prohibitive for small-scale research and educational applications. There is a need for a cost-
effective, reliable alternative to allow researchers and educators to perform geographic
fieldwork where financial resources are limited. Such an alternative exists today in the form of
smartphones and mobile multimedia devices. Given that smartphones are possibly the most
ubiquitous devices in our lives, researchers, educators, and students most likely have a GPS-
capable device that can be used without any additional expenditure. As more smartphones are
produced and marketed as GPS-enabled, and more applications are written for their use, the
smartphone’s usefulness as a GPS device expands. Smartphones are already used in the field
for a multitude of studies (Chu et al., 2006; Lester et al., 2008; Mohan et al., 2008;
Yu et al., 2008; Whipple et al., 2009), yet the accuracy of their GPS readings has been
unexplored. This preliminary study examines whether a GPS-enabled smartphone has
comparable GPS capabilities to a dedicated GPS unit for coarse geographic fieldwork. To
examine a smartphone’s potential GPS capabilities, I compared the HTC G1 Dream (G1)
smartphone to a Trimble Juno SB (Juno), a dedicated GPS device, with regard to intuitive use
and accuracy of GPS readings.
Though less expensive stand-alone GPS devices exist, G1 and Juno share the most
hardware similarities (Figure 1). G1, released October 22, 2008 in the United States, is the first
smartphone to run on the Android operating system, a fully customizable open source mobile
platform (Android, 2008). Various applications, both free and available for purchase, can be
downloaded via the Android Market. Juno, released in December 2008, is a dedicated GPS unit
that runs on Windows Mobile 6.1 and is marketed as having a “high-sensitivity receiver” with
positional accuracy of two to five meters (one to three meters after post-processing;
Trimble, 2009). Juno applications are purchased as standard software. As of February 2010, the
retail price of Juno, with ArcPad 8 and GPSCorrect is $1,750 (ESRI, 2010); the retail price of
an unlocked, no-contract G1 is $369 (T-Mobile, 2010).
The G1 was additionally selected for this preliminary study because of:
1) Having a standalone-enabled GPS chip (Qualcomm MSM7201A gpsOne) so that
GPS applications can work even in places where no cellular or data coverage is
available (QCTConnect, 2009; PDAdb.net, 2010a);
2) Using the same NMEA 0183 GPS protocol as Juno (PDAdb.net, 2010a;
PDAdb.net, 2010b);
3) Having a comparable tracking sensitivity of 160 dBm (QCTConnect, 2009)
4) Having a reported positional accuracy similar to that of Juno (3-6 meters vs. 2-5
meters);
5) Having a 528 MHz processor (HTC, 2008; PDAdb.net, 2010a), similar to Juno’s
533 MHz processor (Trimble, 2009; PDAdb.net, 2010b);
271
6) Both devices have nearly identical graphical subsystems, screen size, touchscreen
input, and menu control buttons.
7) Android’s open source philosophy;
8) Android’s growing market share (Carton and Crumrine, 2010);
9) Android’s ability to multi-task applications; and
10) Having free applications available on the Android Market, which are usable for
basic fieldwork and geographic education.
Because G1’s strength lies in the variety of mobile applications (apps) available, two
free GPS mapping apps were used to ensure that the device was tested to its best ability. These
apps were Maverick (version 1.1.7) and OruxMaps (version 2.0.0). Juno’s strength lies in being
a dedicated GPS unit and its ability to use ESRI’s ArcGIS files natively via ArcPad. For Juno,
ArcPad (version 8.0.0.88) and TerraSync (version 4.00) were used in each test.
2. METHODS
In order to compare the GPS capabilities between G1 and Juno in a field setting, the
following was assessed for each device/application (Dev/App):
1) Ability to navigate/record/load specific geographic coordinates
2) Ability to record/read/load a track (polyline)
3) Ability to record/read/load a polygon
4) Error between reported and actual accuracy
All tests compared ease-of-use, reliability, and overall experience for each
device/application (Dev/App). Settings were standardized as much as possible for each
Dev/App (Table 1). In addition, G1’s stand-alone GPS mode was enabled and each Dev/App
HTC G1 Dream
Trimble Juno SB
FIGURE 1
PHYSICAL COMPARISON OF HTC G1 DREAM AND TRIMBLE JUNO SB
Images courtesy of Anna Klimaszewski-Patterson and ESRI Store, respectively
272
was set to record and display in geographic coordinates in decimal degrees using GCS WSG-
84.
TABLE 1
SETTINGS FOR DEV/APPS
Device
Application
Time
Interval
Distance
Threshold
Threshold
Trimble Juno SB
ArcPad 8.0.0.88
1 second
1 meter
Trimble Juno SB
TerraSync 4.00
1 second
Any
HTC G1 Dream
Maverick 1.1.7
1 second
5 meters
HTC G1 Dream OruxMaps 2.0.0 1 second Any 20 meters
ArcGIS (version 9.3 build 1770, ArcView license) and Google Earth (version
5.1.3533.1731) were used in the analysis of each device test to ensure that both enterprise-level
and freeware desktop applications could be used by researchers, educators, students, and field
technicians. For G1 applications, data were loaded/exported as Keyhole Markup Language
(KML; OruxMaps) or GPS Exchange Format (GPX; Maverick) files. For Juno applications,
data were loaded/exported as ArcGIS shapefiles (SHP).
With the researcher as the control, two Geography students were recruited in order to
perform ease-of-use tests (sections 3.1-3.3). The participants, one female undergraduate student
and one male graduate student, were selected due to their innate technical aptitude, advanced
knowledge with ESRI® ArcGIS Desktop applications (ArcGIS), and basic familiarity with
smartphones. The limited participant size was due to availability of 1) devices, 2) technically-
inclined individuals with no formal GPS training, and 3) time. Participants performed each test
before completing a survey that ranked ease-of-use, creating meaningful labels,
exporting/loading data, and overall experience for each Dev/App. Written and verbal feedback
regarding user experience, advantages/disadvantages for each Dev/App, recommendations, and
additional thoughts were also recorded.
2.1 SPECIFIC GEOGRAPHIC COORDINATES
Testing specific geographic coordinates (waypoints) was conducted by each
participant in four parts per Dev/App: 1) navigating to a given waypoint, 2) recording a
waypoint, 3) loading a waypoint into the application on-the-fly, and 4) pre-loading waypoints.
These tests examined the ability of each application to perform fundamental waypoint
operations in the field. Of all tasks performed on a GPS unit, handling waypoints is likely the
most common.
2.2 TRACKS/POLYLINES
Continuous vertices polylines (tracks) may represent the path traveled by a GPS
device. In both educational and fieldwork settings, tracks can be used to (1) physically digitize
features and (2) record/follow paths traveled, and (3) act as a digital breadcrumb. Testing tracks
was conducted in three parts for each Dev/App: 1) loading a track, 2) following a track, and 3)
recording a track. Tracks were created in ArcGIS and Google Earth. Google Earth tracks were
exported as KML and converted to shapefiles in ArcGIS. ArcGIS tracks were saved as
shapefiles and also exported as KML. Both methods were done to ensure usability regardless of
the application with which the tracks were created.
273
2.3 POLYGONS
Polygons are often used to create management boundaries in GIS. In the field, these
management boundaries may not be self-evident; therefore, having a device that can demarcate
boundaries can be invaluable. Polygons are similar to polylines except that the line is closed,
which may cause difficulties for some applications. Tests for polygons were identical to tests
for tracks, except for the additional use of OruxMapsDesktop, a desktop companion to
OruxMaps.
2.4 ERROR BETWEEN ESTIMATED POSTIONAL ERROR AND ACTUAL ACCURACY
A report of 260 control points (Control Points), surveyed to within several
centimeters accuracy by Bohannan-Huston in 1992 (Wurm, 2010), was used to determine
Dev/App accuracy. Five percent of Control Points (13 total) were randomly selected (Figure 2)
and repeatedly visited between February and May 2010 by the researcher. Tests were
performed on days ranging from cloud-free to a light drizzle. Values of position dilution of
precision (PDOP) were always below 3.0, with no less than nine satellites signal locked. Each
Dev/App was given 15-20 seconds for satellite acquisition before a waypoint, estimated
positional error (EPE), and the number of signal locked satellites was recorded. Fifteen to 20
seconds was used for acquisition time because G1, the non-dedicated GPS device, stabilized
geographic coordinate readings within that timeframe. All data were also recorded manually as
backup in case of software failure. Recorded geographic coordinates were then used in
calculating residual error between actual and EPE. The distance between each recorded point
and actual Control Point location was calculated using the spherical law of cosines formula
(Movable, 2010). The spherical law of cosines was used due to its simple integration into SQL
queries, as data were stored in a database. Additionally, a comparison between results using
Haversine formula (Movable, 2010), a great circle distance accurate for short distances, and the
spherical law of cosines was negligible (e.g., 2.030177964 m. vs. 2.031704099 m.), and non-
existent when rounding the distance to the nearest tenth of a meter.
ACOS(SIN(lat1)*SIN(lat2)+COS(lat1)*COS(lat2)*COS(lon2-lon1))*6371
SPHERICAL LAW OF COSINES
3. RESULTS
Based on tabulation of survey data, G1 applications were favored for waypoint and
track handling. Juno’s ArcMap was preferred for polygon data. Regarding Dev/App accuracy
during Control Point testing, both devices had comparable EPE accuracy and root mean square
error (RMSE). All G1 apps had a lower residual error between actual accuracy and EPE (an
average of -1.04 meters vs. -3 meters for Juno), making their reported EPE more precise than
any Juno applications.
3.1 SPECIFIC GEOGRAPHIC COORDINATES
G1 applications were preferred when using specific geographic coordinates. When
navigating to a pre-loaded set of waypoints, Maverick and OruxMaps were favored, followed
by ArcPad and TerraSync. For on-the-fly waypoint navigation, G1’s Maverick was the
application of choice, followed by TerraSync, ArcPad, and OruxMaps. For recording
meaningful waypoints, Maverick and OruxMaps again ranked highest. When loading
waypoints into the application, ArcPad was preferred when the point shapefile already existed.
Once KML files were edited, Maverick and OruxMaps were equally liked. The KML method
274
was favored for loading specific geographic coordinates where a point shapefile did not exist,
opposed to creating a new point shapefile. TerraSync was least liked overall due its need for
additional software when loading data. When exporting data and loading into a visualization
program (i.e., ArcGIS and Google Earth), Maverick and OruxMaps were preferred in relation
to Google Earth, and ArcPad in relation to ArcGIS (Table 6). Participants found the conversion
process equivalent for data loading to/exporting from ArcGIS to Google Earth.
FIGURE 2
SAMPLE CONTROL POINTS LOCATIONS AND STATION IDS
3.2 TRACKS/POLYLINES
G1 apps were again preferred overall for all tests regarding tracks. Participants’
experience was consistent in creating/visualizing tracks between ArcGIS and Google Earth.
Loading a track was considered equal in Maverick, OruxMaps, and ArcPad. TerraSync was
least liked due to additional conversions needed with GPS Pathfinder Office software.
Following a track was more easily done with both G1 apps, given that G1 experienced less
positional lag than Juno. Recording a track was again preferred in both G1 apps, followed by
TerraSync. No participants were able to successfully record and export a track in ArcPad.
Slight variations in recorded tracks were noticeable, even among apps running simultaneously
on the same device. This variation may result from how each app handles the GPS signal
received, as well as the app’s settings (Table 1). Because TerraSync and ArcPad were unable to
run simultaneously on the same device, their testing was done individually.
3.3 POLYGONS
ArcPad was favored for loading and displaying polygons. Maverick was unable to
load polygons natively, whereas OruxMaps could display polygons as long as a georeferenced
image was first created in OruxMapsDesktop and uploaded to G1. G1 apps were unable to
inherently create polygons, since the applications only have the ability to create/read polylines;
275
however, the created polylines could be converted to polygons through post-processing in
ArcGIS. Conversely, if polygons were converted to individual polylines prior to uploading to
G1, both Maverick and OruxMaps could load the polyline data, treating them as tracks.
Participants initially had difficulty creating a properly georeferenced image in
OruxMapsDesktop, though after several attempts, all participants were successful. Traversing a
boundary was accomplished with all Dev/Apps; however, recording how well the boundary
was traversed depended on participants' prior experience recording tracks with the Dev/App
(section 3.2). Even though traversed boundaries were imprecise, they were within the EPE of
the Dev/App.
When exporting data, participants found that conversion between SHP and KML files
for analysis was straightforward when using the GPSFiles to SHP toolbox (Klimaszewski-
Patterson, 2010) and Map to KML tool in ArcGIS’s Conversion and 3D Analyst toolboxes. In
the office, though OruxMapsDesktop georeferenced maps were more accurately created,
participants preferred working with polygon SHP data. However, for use in the field,
OruxMaps was preferred due to quick positional updates. ArcPad routinely experienced
positional lag, exhibited positional drift, and displayed movement along the initial trajectory
over 20 meters after a turn or stopping.
3.4 RESIDUAL ERROR BETWEEN EPE AND ACTUAL ACCURACY
G1 applications demonstrated the smallest residual error and RMSE. Readings for
sampled Control Points (section 3.1) were repeatedly taken between March and May 2010 to
capture both weather and satellite positional variability over time. All G1 apps had more
precise EPE values than any Juno applications (Table 2). Readings for each Dev/App were
taken and distance from the actual location calculated using the spherical law of cosines
formula. Distance differences were rounded to the nearest tenth of a meter. Of the 37
cumulative samples taken thus far, 87% of G1’s points were within the EPE for OruxMaps and
Maverick. Juno’s points within EPE were 95% for ArcPad and 90% for TerraSync (Table 3).
When one meter was added to the EPE to account for any potential projection error, all but
Juno’s TerraSync (92%) had 100% of recorded coordinates within the EPE. A scale of 1:1,000
was required to accurately visualize positional differences (Figure 3).
TABLE 2
DEV/APP EPE AND PDOP VALUES
Dev/App Min EPE Max EPE Avg. EPE Avg. PDOP Mode PDOP
G1/OruxMaps
2 meters
6 meters
3.3 meters
N/A
N/A
G1/Maverick
2 meters
6 meters
3.3 meters
N/A
N/A
Juno/ArcPad
5 meters
9 meters
6.0 meters
1.52
1.4
Juno/TerraSync
5 meters
8.3 meters
5.8 meters
5.61
1.44
TABLE 3
DEV/APP WITHIN EPE
Dev/App Within EPE Within EPE + 1 m. Avg. Residual Error RMSE
G1/OruxMaps
87%
100%
-0.98 meters
2.29 meters
G1/Maverick 87% 100% -1.1 meters 2.17 meters
Juno/ArcPad
95%
100%
-3.3 meters
2.68 meters
Juno/TerraSync
90%
92%
-2.7 meters
3.14 meters
276
4. CONCLUSIONS
To test the fundamental GPS capabilities of a smartphone, such as G1, ease-of-use
and accuracy tests were performed. These fundamental tasks included the ability to
navigate/record/load specific geographic coordinates, the ability to record/read/load polylines
and polygons, and the error between EPE and actual accuracy. G1’s applications were most
preferred in ease-of-use tests for waypoints and polylines, while results were mixed for
polygons. ArcPad was preferred for loading and visualizing polygons, while the combination of
OruxMaps and OruxMapsDesktop was preferred for navigating along/within polygons due to
less positional lag than ArcPad.
FIGURE 3
GEOGRAPHIC COORDINATES COLLECTED AT SAMPLED CONTROL POINTS
Overall, participants felt that G1 apps had more intuitive and thoughtful user
interfaces over the Juno applications. G1 apps were far less difficult for participants to learn
informally compared to Juno applications. Juno’s core strength lies in its applications’
integration with ArcGIS, post-processing capabilities to improve the accuracy of recorded data,
multifunctional applications, and corporate sponsorship; however, extensive and expensive
training is required to use the device and its applications to their full potential. G1 applications,
277
on the other hand, demonstrated an ability to match, or exceed, the expectations of a GPS
device for fundamental operations. While the G1 apps tested were unable to create/use polygon
data natively, workarounds for this limitation are available. For instance, OruxMapsDesktop
can be used to georeference a map image containing polygon data, which can then be loaded
via OruxMaps. G1’s strength lies in the open-source nature of its applications, the
responsiveness of application authors to requested changes/updates, and the growing variety of
applications to suit any particular need; however, GPS apps currently available on the Android
Market are geared towards outdoor enthusiasts and not personnel involved in fieldwork.
Participants especially found the ability for G1’s apps to integrate easily with Google Earth
useful, allowing GPS visualization on computers with Linux, Macintosh, and Windows
operating systems (Google, 2010). The ability to use the freely available Google Earth for
visualization and creation of data further reduces possible costs associated with GPS data
collection and use.
Simple to use applications are worthless unless the data collected is reasonably
accurate. For this reason, G1’s GPS accuracy was compared against Juno’s. G1 apps
demonstrated a smaller residual error, indicating their EPE values were more precise than
Juno’s applications. Given that projecting coordinates from GCS WSG84 can incur a one meter
positional error, geographic coordinates collected by Maverick, Juno, and ArcPad were 100%
within their reported EPE. Only TerraSync reported geographic coordinates that were over
twice the reported EPE. This inconsistency may demonstrate the difference in positional
interpretation by applications, given that TerraSync and Juno were both used on the same
device.
Considering device accuracy and user experience, this preliminary study found that a
GPS-enabled smartphone, such as G1, could be a capable GPS device. This is especially true
when using OruxMaps, given its ability to handle polygon data with additional processing via
OruxMapsDesktop. G1 compared favorably against a dedicated GPS device, and was found to
be just as accurate as Juno, if not more so, regarding GPS positioning. Therefore, a smartphone
may be a viable alternative to an expensive dedicated GPS device for small-scale research and
educational applications where the functionality of enterprise-level GIS integration is
unnecessary.
5. DISCUSSION
While this preliminary study determined that G1 has the potential to be used as a
geographic tool, the study did not use a statistically significant sampling size regarding user
experience. In the future, similar research should be expanded to include a wider variety of test
subjects, both in technical abilities, age, and GPS experience. Additionally, further research
should be conducted to determine:
1) How successfully G1 applications could be used in a classroom setting;
2) The capabilities of other, non-Android smartphones for geographic research;
3) How well G1 compares to other comparable, inexpensive stand-alone GPS devices,
such as Garmin Dakota 20 or Garmin GPSMAP 60CSx;
4) The advancement of standalone GPS chipsets in more recent smartphones;
5) How much, and what kind of, training would be required for educators to include a
geographic curriculum using GPS-enabled smartphones such as G1; and
6) If there is a gender/age bias towards particular Dev/Apps.
In observing participants interactions with each Dev/App, I noticed that opinions on
application intuitiveness appeared to be made quickly, depending on how easily accessible the
application’s menu structure was. If the application’s menu was simple to navigate, participants
278
were more likely to forgive any difficulties later encountered with the Dev/App. I also noticed
that participants quickly became confused when constantly switching between Dev/Apps, and
often tried to access menu items incorrectly for the application they were currently in. First
impressions towards a Dev/App may also have caused some bias in which applications were
preferred.
The training that participants received in this study was minimal and intended to
cover the fundamental needs a user could encounter in the field; it was by no means exhaustive.
The possibility exists that with authorized training, participants’ opinions towards Juno
applications could change. However, as one goal of this study was testing an application’s
intuitive ease-of-use, thorough training on Juno applications was deemed excessive and
disproportionate to the amount of training needed to use G1 applications.
A more recent set of Control Points could also be beneficial, as the Bohannan-Huston
survey marker data was released in 1992. Since then, the city of Las Cruces has grown
considerably, destroying over half of the original survey markers. For this reason, only 5% of
Control Points were used for GPS accuracy testing. Time and budget limitations resulted in a
small sampling size but it was still allowing some spatial distribution of sampling points.
Finally, the Juno device itself may not have been the most appropriate stand-alone
GPS device to test the G1 against. Juno is an expensive, enterprise-level GPS device, and using
ArcPad to its full potential requires upfront data preparation before performing field data
collection. However, G1’s apps could perform more complex and robust GPS mapping than
very inexpensive GPS devices, such as Garmin eTrex. Also, the user interface and hardware of
G1 was more robust than very inexpensive GPS devices available at the time. Therefore, I
wanted to test a smartphone’s GPS mapping capability and usability against a more capable and
comparable device. Given the resources available, the Juno was the most appropriate device,
functionality and hardware-wise, to use in this preliminary comparative study.
6. REFERENCES
Android. 2008. Welcome. Android Open Source Project. http://source.android.com. Last
accessed 15 September 2009.
Carton, P., & J. Crumrine. 2010. Smartphone users take a shine to Android. Marketing Charts:
ChangeWave Research. http://www.changewave.com/freecontent/
viewalliance.html?source=/ freecontent/2010/01/android-roils-smart-phone-market-
01-04-10.html. Last accessed 15 February 15 2010.
Chu, H-T., C-C Huang, Z-H Lian, J.J.P. Tsai. 2006. A ubiquitous warning system for asthma-
inducement. IEEE International Conference on Sensor Networks, Ubiquitous, and
Trustworthy Computing 2: 186-191.
Lester, J., P. Hurvitz, R. Chaudhru, C. Hartung, and G. Borriello. 2008. MobileSense Sensing
modes of transportation in studies of the built environment. Proceedings of
International Workshop on Urban, Community, and Social Applications of
Networked Sensing Systems: 46-50.
Developer Connection. 2010. iPhone developer program. Apple. http://developer.apple.com/
iphone/program/. Last accessed 10 February 2010.
ESRI Store. 2010. Trimble Juno SB and SC. ESRI: http://store.esri.com/esri/
showprod.cfm?sid=2&category_id=153. Last accessed 12 February 2010.
Google Earth. 2010. Operating system requirements: Requirements for Google Earth. Google.
http://earth.google.com/support/bin/answer.py?hl=en&answer=20701. Last accessed
20 February 2010.
GPS Visualizer. 2010. Geographic calculators. http://www.gpsvisualizer.com/calculators. Last
accessed 25 February 2010.
279
HTC. 2008. T-Mobile G1 Specification. http://www.htc.com/www/product/g1/
specification.html. Last accessed 12 September 2009.
Klimaszewski-Patterson, A. 2010. Convert GPS files (KML, GPX) to shapefiles (GPSFiles to
SHP toolbox). ArcScripts: ESRI Support Center. http://arcscripts.esri.com/
details.asp?dbid=16797. Last accessed 12 February 2010.
Movable Type Ltd. 2010. Calculate distance, bearing and more between Latitude/Longitude
points. Movable Type Scripts. http://www.movable-type.co.uk/scripts/latlong.html.
Last accessed 16 March 2010.
Mohan, P., V.N. Padmanabhan, and R. Ramjee. 2008. Nericell: rich monitoring of road and
traffic conditions using mobile smartphones. Proceedings of the 6th ACM Conference
On Embedded Networked Sensor Systems 33: 323-336.
PDAdb.net. 2010a. Detailed technical specifications of T-Mobile G1 (HTC Dream 100).
http://pdadb.net/index.php?m=specs&id=1495&view=1&c=t-
mobile_g1_htc_dream_100. Last accessed 10 January 2010.
___. 2010b. Detailed technical specifications of Trimble Juno SB.
http://pdadb.net/index.php?m=specs&id=1623&view=1&c=trimble_juno_sb. Last
accessed 10 January 2010.
QCTConnect. 2009. gpsOne. Qualcomm. http://www.qctconnect.com/products/gpsone.html.
Last accessed 12 October 2009.
T-Mobile. 2010. T-Mobile G1 with Google. (2010). http://www.t-mobile.com/shop/phones/
cell-phone-detail.aspx?cell-phone=t-mobile-g1-with-google-black. Last accessed
15 February 2010.
Trimble. 2009. Juno SB Handheld. http://www.trimble.com/junosb.shtml. Last accessed
15 September 2009.
Whipple, J., W. Arensman, and M.S. Boler. 2009. A public safety application of GPS-enabled
smartphones and the Android operating system. Proceedings of the 2009 IEEE
International Conference on Systems, Man and Cybenetics: 2059-2061.
Wurm, K. (Associate Professor, Department of Surveying Engineering, New Mexico State
University) 2010. Personal communication. 26 February 2010.
Yu, A., A. Bamis, D. Lymberopoulos, T. Teixeira, and A. Savvides. 2008. Personalized
awareness and safety with mobile phones as sources and sinks. Proceedings of
International Workshop on Urban, Community, and Social Applications of
Networked Sensing Systems 26-30.
... Modsching et al. [26] also noted that the presence of multi-story buildings can decrease the accuracy of horizontal determined positions, due to use of degraded signals in order to generate position fixes within urban canyons. Using a HTC G1 Dream and a Trimble Juno SB, Klimaszewski-Patterson [27] also assessed differences in accuracy between a smartphone and traditional GPS receiver. Using two different apps for GPS data collection, the residual error was lower when using the smartphone. ...
Article
Full-text available
An iPhone 6 using the Avenza software for capturing horizontal positions was employed to understand relative positional accuracy in an urban environment, during two seasons of the year, two times of day, and two perceived WiFi usage periods. On average, time of year did not seem to influence the average error observed in horizontal positions when GPS-only (no WiFi) capability was enabled, nor when WiFi was enabled. Observations of average horizontal position error only seemed to improve with time of day (afternoon) during the leaf-off season. During each season and during each time of day, horizontal position error seemed to improve in general during perceived high WiFi usage periods (when more people were present). Overall average horizontal position accuracy of the iPhone 6 (7-13 m) is consistent with the general accuracy levels observed of recreation-grade GPS receivers in potential high multi-path environments.
... A-GPS sensor capability implemented in mobile handheld devices has changed much in the last decade and can provide today an absolute planar accuracy in outdoor environments of 5-8.5 m horizontally, and 6-12.5 m vertically (e.g., [3,11,12]). This is achieved thanks to the hybrid locational system procedure that is nowadays known as "the seven technology enablers": A-GPS, massively parallel correlation, high sensitivity, coarse-time navigation, low time-of-week, host-based GPS, and RF-CMOS. ...
Article
Full-text available
Digital Terrain Models (DTMs) used for the representation of the bare earth are produced from elevation data obtained using high-end mapping platforms and technologies. These require the handling of complex post-processing performed by authoritative and commercial mapping agencies. In this research, we aim to exploit user-generated data to produce DTMs by handling massive volumes of position and elevation data collected using ubiquitous smartphone devices equipped with Assisted-GPS sensors. As massive position and elevation data are collected passively and straightforwardly by pedestrians, cyclists, and drivers, it can be transformed into valuable topographic information. Specifically, in dense and concealed built and vegetated areas, where other technologies fail, handheld devices have an advantage. Still, Assisted-GPS measurements are not as accurate as high-end technologies, requiring pre- and post-processing of observations. We propose the development and implementation of a 2D Kalman filter and smoothing on the acquired crowdsourced observations for topographic representation production. When compared to an authoritative DTM, results obtained are very promising in producing good elevation values. Today, open-source mapping infrastructures, such as OpenStreetMap, rely primarily on the global authoritative SRTM (Shuttle Radar Topography Mission), which shows similar accuracy but inferior resolution when compared to the results obtained in this research. Accordingly, our crowdsourced methodology has the capacity for reliable topographic representation production that is based on ubiquitous volunteered user-generated data.
... The GPS systems and maps built into mobile devices make them an excellent means of navigation (Johnson, Levine, Smith, Smythe, & Stone, 2009;Klimaszewski-Patterson, 2010). Like printed maps, these devices enable students to experiment with navigating in the field and reading maps (Rosenberg, 2011) . ...
Article
Full-text available
In recent years, cellular phones and tablets have become increasingly more prevalent and popular. Due to their great mobility, light weight and ability to serve as a platform for various applications, these devices are ideal candidates for supporting out-of-classroom learning. Geography teachers in the twenty-first century must become familiar with these tools and must learn how to integrate them into their teaching, both in the classroom and in the field. Intelligent use of these tools can make classroom learning interesting and interactive and can transform the field trip into a stimulating and probing learning experience.
Article
Full-text available
Location-related mobile device evidence is increasingly used to address forensic questions in criminal investigations. Evaluating this form of evidence, and expressing evaluative conclusions in this forensic discipline, are challenging because of the broad range of technological subtleties that can interact with circumstantial features of cases in complex ways. These challenges make this type of digital evidence prone to misinterpretations by both forensic practitioners and legal decision-makers. To mitigate the risk of misleading digital forensic findings, it is crucial to follow a structured approach to evaluation of location-related mobile device evidence. This work presents an evaluation framework widely used in forensic science that employs scientific reasoning within a logical Bayesian framework to clearly distinguish between, on the one hand, what has been observed (i.e., what data are available) and, on the other hand, how those data shed light on uncertain target propositions. This paper provides case examples to illustrate the advantages and difficulties of applying this approach to location-based mobile device evidence. This work helps digital forensic practitioners follow the principles of balanced evaluation and convey location-related mobile device evidence in a way that allows decision-makers to properly understand the relative strength of, and limitations in, digital forensic results.
Research
Full-text available
This represents one of several sections of "A Bibliography Related to Crime Scene Interpretation with Emphases in Geotaphonomic and Forensic Archaeological Field Techniques, Nineteenth Edition" (The complete bibliography is also included at ResearchGate.net.). This is the most recent edition of a bibliography containing resources for multiple areas of crime scene, and particularly outdoor crime scene, investigations. It replaces the prior edition and contains approximately 10,000 additional citations. As an ongoing project, additional references, as encountered, will be added to future editions. After it is secured, the first step toward processing a crime scene is assessing and recording its position in situ as well as its relationship to other sites affected by subject(s) and victim(s). This follows tenets shared by archaeology, geotaphonomy, and general criminalistics: Crime scenes do not occur in vacuums. They entail points of access, egress, and are influenced by immediate and neighboring environmental activities. Consider cases in which lone skulls are found by pedestrians. More often than not, those skulls were once attached to remains which lie nearby. By recording the environment or context from which the skull was recovered, (beyond its mere two dimensional position within a small grid), its peri- and postmortem history may become more clear. The routine recording of elevations and topographic features such as streams, flood plains, slopes, et cetera, near remains could provide the investigator, laboratory analyst, and ultimately a jury, with information related to taphonomic processes affecting those remains and explanations for their ultimate dispositions. Too often investigators take a myopic view toward crime scenes and concentrate only on the area around the primary piece of evidence. The experienced, well-trained, and practiced crime scene investigator or archaeologist realizes three integrated and expanding spheres of any investigation: the evidence or artifact, the incident, and the event. Toward expanding perspective into the incident and event spheres of investigation, this category contains resources which generally entail topics of search or survey techniques as well as mapping methodologies and equipment. Several of the articles also apply to logistics and preparation; however, the reader is also directed to the categories of “General Crime Scene and Death Scene Investigation” and "Excavation and Recovery Strategies" for additional references which contain discussions about logistics and planning. The most important component of planning for a forensic search or recovery is consideration of personal and team safety. Many sites suitable for the disposal of homicide victims pose significant risks to living individuals. Sites such as landfills and cesspools demonstrate one type of obvious hazard, while confined spaces such as wells, cisterns, or mine shafts represent another with less visible dangers such as carbon monoxide or structural collapse. Attention to safety extends beyond the field to laboratory and storage settings. Inadequate facilities, personal protection, or inappropriate handling of hazardous evidence or chemicals used to process evidence can put technicians and scientists at significant risk. For these reasons, this section of the bibliography begins with the topic of safety.
Article
Full-text available
Geospatial technology is a term used to describe the range of modern tools contributing to the geographic mapping and analyses which typically involve Global Navigation Satellite Systems (GNSS), Remote Sensing (RS), and Geographic Information Systems (GIS). By manipulating these tools, users can easily plan ahead, scrutinize each data, improve service delivery, and optimize operation management. Field/on-site workers is defined as those who work most of their time away from their main office and get connected via mobile and wireless devices. This paper will demonstrate a methodology to integrate geospatial technology with selected sensors to increase the on-site operations and management using mobile platform and optimize the workflows allowing real-time tracking and monitoring.
Article
Smartphones have become ever-present in our lives since the launch of the Apple iPhone in 2007. Since then, the number of smartphones in use has climbed to over 1 billion worldwide. Many users are attracted to the myriad of apps that these devices offer, including location-based services (LBS) that allow users to track their current location. In this study we seek to establish some preliminary results concerning the horizontal accuracy of several common smartphones. Many of the devices used in this study represent several generations of the same device with developmental and technological upgrades differentiating them from one another. Location coordinate data were collected using volunteer students and their smartphones in the study and compared to RTK corrected benchmarks to assess horizontal accuracy. Each benchmark represented different types of local obstruction that have plagued traditional Global Positioning System (GPS) receivers for years. The objective is to create some preliminary results of smartphone LBS accuracies that can be used as a baseline in future studies.
Article
Limited research addresses the development of emerging adults who are homeless, and studies rarely explore their immediate and intertwined experiences of geography, social networks, and daily paths. These dynamic contexts may play significant roles in emerging adults' homeless experiences, continued chronic homelessness, and/or successful transitions to self-sufficient adulthood. Applying geographic theory to emerging adult development among marginalized youth offers new linguistic and methodological tools to further our understanding of what emerging adulthood looks like and how it functions among youth “on the street,” those “of the street,” and those who have been completely abandoned. An integrated theoretical model is offered for innovative interdisciplinary research on the lived experiences of homeless youth, particularly related to developmental themes of exploration, stability, and connectedness.
Article
An Android application, HyDroid, was developed to help hydrogeologists conduct field investigations. By employing the powerful hardware and operation systems in the Android smartphone, HyDroid not only facilitates geospatial data collection and management, but also helps to conduct some essential hydrogeologic field tests, and to visualize field data instantly.
Article
Full-text available
We discuss a study we conducted using the Mobile Sensing Platform and GPS information to record the activities and locations of 53 subjects, each of whom collected data for one week. Using this data we are developing methods for combining activity inference from sensors to infer the mode of transportation, label significant locations, and extract trips. Although our data collection was conducted using a non-consumer sensor platform, we discuss how our methods can translate onto existing mobile platforms such as the iPhone and Nokia N95, and how these platforms will enable us to study larger populations to draw more concrete conclusions about the relationship between the urban environment and people's activities.
Article
Full-text available
Today's mobile phones are equipped with an increasing set of sensors including GPS, accelerometers, cameras, and more that makes them ideal source nodes in urban sensing applications. The growing displays and internet connectivity also makes these phones excellent sinks of just-in-time information, including information from other sensors deployed in the infrastructure. Exploiting these features, our personalized safety and awareness system tries to enhance personal safety of users around the clock through a collection of services that process personal and aggregate community data to track, escort, flag, supervise behaviors and help users coordinate to enhance the collective safety of the group. Designed for individuals and groups that operate on campuses and beyond, it intends to make campuses safer, by going beyond the processing of individual location data and by providing services based on the application of intelligent behavior sensing algorithms and collaborative models to aggregate sensor data. I. INTRODUCTION M ost campus security plans consist of scattered emergency phones, scheduled shuttles, and foot or vehicle escorts, but such plans are not always very effective with rising student population numbers and sudden spikes in localized security demand. Moreover, many campus security implementations are unreliable and unable to meet the needs of busy individuals. Confusing timetables, unclear pick-up locations, and limited hours of service discourage many people from actually using campus security services. To compound this problem, many people hesitate to call for a security escort out of embarrassment, or false beliefs that they are immune to danger. To address some of these c hallenges, our system takes a broader view to personal safety, leveraging GPS mobile phones and social networking to introduce dynamic safety practices. Our system provides user customizable activity monitoring that begins to form the basic virtual escort tracking for small trips on foot, longer term tracking during travels, and escalates up to model-driven activity monitoring and community based coordination for safety. Instead of focusing on security and privacy issues our research is directed towards the creation of semantic meaning from the sensor data, particularly reasoning with user locations in time and space, also using context information extracted form maps. Privacy issues are implicitly handled by exploiting the phones' local processing capabilities, provisioning for the use of security and privacy from other researchers (8) and by operating in community mode where users are willing to share some level of private information in aggregate form with other members of the community to enhance community-wide safety. In this position paper we describe a personal safety and awareness framework that is currently being developed as p art of the Behavior-Scope (BScope) project at Yale (1). This is centered on the use of smartphones as sources and sinks of information and involves coordination among multiple phones as well as other sensors deployed in the environment. The mobile phones coordinate with a central server to provide a set of services to the users. For instance, when walking across campus, users can put their mobile phone client application in a virtual escort mode. This service provides a panic button option and tracks the travel progress of the user to ensure that the user safely reached the intended destination. During longer trips, a travel service sends automatic emails and text messages to family and friends providing updates about the trip. For more general personal safety, the phone also learns the daily routines of the user and notifies a set of registered recipients at different levels of behavior deviations. Finally, a set of aggregate location information and inputs from campus security are used to coordinate the movements of users
Conference Paper
Full-text available
We consider the problem of monitoring road and traffic conditions in a city. Prior work in this area has required the deployment of dedicated sensors on vehicles and/or on the roadside, or the tracking of mobile phones by service providers. Furthermore, prior work has largely focused on the developed world, with its relatively simple traffic flow patterns. In fact, traffic flow in cities of the developing regions, which comprise much of the world, tends to be much more complex owing to varied road conditions (e.g., potholed roads), chaotic traffic (e.g., a lot of braking and honking), and a heterogeneous mix of vehicles (2-wheelers, 3-wheelers, cars, buses, etc.). To monitor road and traffic conditions in such a setting, we present Nericell, a system that performs rich sensing by piggybacking on smartphones that users carry with them in normal course. In this paper, we focus specifically on the sensing component, which uses the accelerometer, microphone, GSM radio, and/or GPS sensors in these phones to detect potholes, bumps, braking, and honking. Nericell addresses several challenges including virtually reorienting the accelerometer on a phone that is at an arbitrary orientation, and performing honk detection and localization in an energy efficient manner. We also touch upon the idea of triggered sensing, where dissimilar sensors are used in tandem to conserve energy. We evaluate the effectiveness of the sensing functions in Nericell based on experiments conducted on the roads of Bangalore, with promising results.
Conference Paper
Full-text available
In this paper, we introduce a medical application of the Global Positioning System (GPS). For an asthmatic patient, he or she can carry a portable GPS device to prevent possible morbidity of asthma during his or her outdoor activities of daily livings. To reduce possible allergy asthma, the GPS-enable device continuously consults a remote server with sending user's position to decide whether current ambient air quality will threaten user's health. The server of the detecting system collects real-time data from the network of national air quality monitoring stations. For the response to a remote query, the server makes decision of warning messages according to a proposed asthma neural network model. The proposed system is hopeful for asthmatic patients
Conference Paper
While the Apple iPhone single handedly redefined the term ¿smartphone¿ during its first two years of release, Google's Android platform for mobile devices has quickly developed into a serious open source alternative. We explored the android operating system (OS) and software development environment and evaluated several of its capabilities by constructing a working application. This application collected speed and location information from the Global Positioning System (GPS) receiver, used the Google Maps Application Programming Interface (API) to determine the location of nearby schools, and sounded an alarm if a person drove over the speed limit in a school zone. The platform proved capable of supporting a melding of different services, and we believe such smartphones have broad applicability to public safety problems.
Welcome. Android Open Source Project
  • Android
Android. 2008. Welcome. Android Open Source Project. http://source.android.com. Last accessed 15 September 2009.
Operating system requirements: Requirements for Google Earth
  • Google Earth
Google Earth. 2010. Operating system requirements: Requirements for Google Earth. Google. http://earth.google.com/support/bin/answer.py?hl=en&answer=20701. Last accessed 20 February 2010.
Geographic calculators
  • Gps Visualizer
GPS Visualizer. 2010. Geographic calculators. http://www.gpsvisualizer.com/calculators. Last accessed 25 February 2010.
Convert GPS files (KML, GPX) to shapefiles (GPSFiles to SHP toolbox) ArcScripts: ESRI Support Center
  • A Klimaszewski-Patterson
Klimaszewski-Patterson, A. 2010. Convert GPS files (KML, GPX) to shapefiles (GPSFiles to SHP toolbox). ArcScripts: ESRI Support Center. http://arcscripts.esri.com/ details.asp?dbid=16797. Last accessed 12 February 2010.
Calculate distance, bearing and more between Latitude/Longitude points. Movable Type Scripts
  • Type Movable
  • Ltd
Movable Type Ltd. 2010. Calculate distance, bearing and more between Latitude/Longitude points. Movable Type Scripts. http://www.movable-type.co.uk/scripts/latlong.html. Last accessed 16 March 2010.