Posts Tagged ‘location tracking’

REST Service Implementation using HTTP – Cross Domain Request

Sunday, March 29th, 2009

By Phavanhna Douangboupha, 03/29/09

The three main basic ideas of a REST process are to process a client request, to response to the request, and return a result/data in XML format according to the request.

Two techniques that can be used are getting parameters from client through a URL query string and the use of HTTP methods. The first technique is easier to implement compared to the second technique. The main disadvantages of the first technique include the size of the URL string, the maximum length of the URL string consisting of query parameters, and a possible negative side effect. The first limitation, the size of URL string, can be overcome by using POST method instead of GET method for a client request. However, POST and GET methods should be applied according to a specific task (see the blog on Creating REST Web Service for more detail). Consequently, the HTTP methods are a better solution for REST service.

I have already talked about how to implement a REST client using a URL query string from my previous post, now I will talk about how I implement a REST service for the cross server client request using HTTP methods.

For this exercise, a database server, a web host server and a web client server are assigned in different machines and hosted by different domains. The database server is hosted at STREAMER. The web host server is hosted by CHW domain and finally the demonstrated web client request comes from GIBSON domain (Figure 1 shows system architect for the REST cross domain service). STREAMER is a house to MySQL database which is hosted in a different domain from the web server.

System architect for REST cross domain service
System architect for REST cross domain service

Figure 1: System architect for REST cross domain service

GIBSON is used as a demonstration client to request data from another domain (CHW). The four main files implemented here are a normal HTML file (index.html), a JavaScript file (client_local.js), and two php using cURL libraries files (getclient_chw.php and postclient_chw.php). The Javascript file is used to implement Ajax to send a request and to receive responded data sent back by a server asynchronously. The data is displayed on the HTML file. The JavaScript file uses HTTP request object to send a request to either getclient_chw.php (”How Many Users?” in the database) or postclient_chw.php (”Add New User” to the database). getclient_chw.php and postclient_chw.php use cURL libraries to set up a HTTP request where getclient_chw.php uses the GET method to request to get data from a server and postclient_chw.php uses the POST method to request to post data to a server (please see table 1 for the correspondent HTTP methods to the database query). Both of the files make a request to process data with the web server on CHW. The client side has no relation to the database server on STREAMER and it only sends a HTTP request which will later be checked by the web server.

Use Gibson to act as a client to make REST request​ (Figure 2) - http://people.rit.edu/~pxd8840/restclient/index.html . As you click one of the two buttons – “How Many Users?” (HTTP GET) and “Add New User” (HTTP POST), you will see that the displayed results are updated asynchronously. These are done via Ajax using REST service to perform a cross-domain request instead of the <script> tag hack solution as mentioned from my previous post.

index.html, client requests on GIBSON

index.html, client requests on GIBSON

Figure 2: index.html, client requests on GIBSON

On the web host server (CHW), there are two main files – rest_database.php and ConnectDB.php. ConnectDB.php is an Object Oriented PHP class that contains methods to connect to the database and the required methods to process or retrieve data from STREAMER database server. The rest_database.php file also contains all the logic check method that received from a client. The rest_database.php file is used to check what kind of request being made if it is a HTTP GET request or a HTTP POST request. According to the request, it retrieves data from the database. Then it creates XML responses to the client.

Table 1: HTTP method, REST action, and SQL command for a client request

HTTP Request Method REST Action SQL database command Description
GET GET SELECT Search/Request for
data (getdata)
POST POST INSERT Add/Insert new data
(postdata)

List of files

Client Side

  • index.html
  • client_local.js
  • postclient_chw.php
  • getclient_chw.php

Server Side

  • rest_database_php
  • ConnectDB.php class code on the server side contains database connection and database process methods

References:

Links to other blogs in this project

Tags: , , , , , ,
Posted in Best Practices, Design, Mobile Devices, Physical Design, Web Apps, development | No Comments »

Location Tracking Techniques

Saturday, January 31st, 2009

by Phavanhna Douangboupha

This blog contains information about some of the current practices in location tracking technologies. It mainly discusses the three common methodologies – GPS, Cell Towers, and Wi-Fi positioning service. The blog is a part of the ongoing investigation for the proposed capstone project on Web-based resource tracking during a disaster or crisis situation.

In general, there are four geo-location methods including triangulate, associate, geo term extraction, and data entry or geo-coding. The Global Positioning System (GPS), Cell Towers, and Wi-Fi positioning service (WPS) are the three well known triangulation techniques to identify a mobile device geo-location. GPS and Cell Towers are based on triangulation to identify an object position by using the location of known objects.

To put a location on a map, the geo-coding position technology relies on getting a location of an object via a meaningful X, Y coordinate or a latitude and longitude coordinate. In fact any available mapping tool such as Microsoft live search maps, Google maps, and Yahoo maps use the coordinate system to identify a requested location.

GPS relies on satellites that send microwave signals information back to the earth. The information is a navigation message of each satellite’s position and time. An object location is calculated by GPS receivers by the use of triangulation and the signal information provided by at least three satellites in order to determine an object’s location and four satellites for greater accuracy. The use of fourth satellite enhances the accuracy in the order of nanoseconds. GPS receivers compare the time difference between the arrival of satellite signals to tell the position. At least three satellites are needed in the calculation for an accuracy result. The first satellite provides a possible location of an object narrowed down to the surface of a sphere. The position is recorded as a radius equal to range 1. On the same token, satellite number two provides confirmation that the object is located within the first sphere (as located by the first satellite). Satellite number two provides an additional position circle of a radius range 2. The first and second satellite indicate that the object is positioned between the intersection between their two spheres – sphere one and sphere two. Finally, the third satellite shows a third sphere of radius range 3 for the positions. The object position is the intersect location of the three spheres. Finally, the fourth satellite is used to confirm the location and hence provides the time reference.

A GPS-enabled device provides geo-code location accuracy about 1 to 5 meters. Despite the fact that GPS system is widely used with many position tracking systems, it does come with some drawbacks. GPS does not work within indoor environment positioning and it requires costly power-consumption on mobile devices. In addition, not all mobile devices are GPS-enabled.

Another solution for location finding is the Cell Tower technique. Similar to GPS system, it requires at least three different cell towers within range of the device to calculate an object location for a high accuracy result. Otherwise, at least two cell towers are required. Each cell tower ,with a unique cell identifier, returns a positioning data to a requested mobile phone. Each mobile phone constantly pings a signal to nearby cell towers to get the cellular radio signal and hence some mobile phones also require costly power-consumption just like in the GPS  positioning techniuqe. Having data from all the cell towers, an algorithm can be used to calculate a final location of the mobile phone which lies in the middle. The advantage of cell tower triangulation technique is that is available for all mobile phones that have registered service providers . In addition, cell towers can be set up to send signal to mobile devices. Unlike GPS, cell towers will work in both indoor and outdoor environment. The accuracy of a position allocation depends on the density of cell towers in the area.

Wi-Fi Positioning Service (WPS) is the least accurate technique for location finding among the three techniques (GPS, Cell Towers, and WPS). IP address from a mobile device Wi-Fi connection is used to get a guessed location back from a service provider database such as Google map using API. Some of the available and well known mobile device location locator technologies are Google gear (Google map version for a mobile device), iPhone Core Location, and Navizon. Google mobile map and Navizon peer-to-peer wireless positioning tools  make the use of their massive data collection to provide a best guessed location for a device without GPS-enabled and for thoser devices that can not communicate with cell towers.

Google gear uses all three triangulation technologies to get the best accurate result. Google gear is compatible with many mobile devices including Windows Mobile, and Android. On the other hand, Core Location is another tool specifically programmed for iPhone. Apart from Google gear and iPhone Core Location, Navizon is another map locator tool. Navizon is free for a cellular enabled device, with some limitations, using cell ID positioning. However,  it is not free for a Wi-Fi or cellular enable device using cellular and Wi-Fi triangulation. Navizon database collects geo-coding data from registered users or devices with GPS-enabled. These data is collected and used as a virtual GPS. The tool uses the bank of data as a reference positioning point to locate a mobile device geo-location.

Another alternative technology is a tool so called PhoneGap that utilizes web application technology and Objective-C core features available on three mobile devices – iPhone, Android, and Blackberry.

References

  1. Bellavista, P., & Corradi, A. (2007). Mobile Middleware for Location-Dependent Services. In The Handbook of Mobile Middleware. USA: Auerbach Publications
  2. Berka, J. (2008, January 22). PhoneGa tool provides JavaScript access to iPhone features. In PhoneGap tool provides JavaScript access to iPhone features - Ars Technica [Internet Article]. Retrieved January 31, 2009, from
    http://arstechnica.com/apple/news/2008/10/
    PhoneGap-tool-provides-javascript-access-to-iphone-features.
  3. B’Far, R. (2005). Mobile Computing Principles: Designing and Developing Mobile Applications with UML and XML. United Kingdom: Cambridge University Press.
  4. Google. (2008). Services – Google Maps API – Google Code. In Google Maps API [Google Maps API Reference]. Retrieved November 9, 2008, from Google Web site: http://code.google.com/apis/maps/documentation/
    services.html#XML_Requests
  5. Google. (2009). Geolocation API. In Geolocation API – Gears API – Google Code [documentation]. Retrieved January 31, 2009, from Google Web site: http://code.google.com/apis/gears/api_geolocation.html#getCurrent
  6. Katsaros, D., Nanopoulos, A., & Manolopoulos (eds), Y. (2005). Location-Based Services. In Wireless Information Highways (section iv – location-based
    services). United States of America: Idea Group Publishing . Retrieved
    November 6, 2008
  7. Mallick, M. (2003). Mobile and Wireless Design Essentials. Indianapolis,
    Indiana, USA: Wiley Publishing. Retrieved November 8, 2008
  8. Mark, D., & LaMarche, J. (2009). Where Am I? Finding Your Way with Core
    Location. In Beginning iPhone Development: Exploring the iPhone SDK (pp. 429-439). USA: Apress
  9. Mexens. (2005-2008). How it works. In Peer-to-peer wireless positionin [product description]. Retrieved January 31, 2009, from http://www.navizon.com
  10. Olla, P. (2008). Global Navigation and Satellite Systems and Services. In
    Commerce in Space: Infrastructures, Technologies, and Applications
    (chapter v). USA: IGI Publishing. Retrieved November 8, 2008
  11. Wu, S.-L., & Tseng, Y.-C. (2007). Wireless Ad Hoc Networking-Personal-Area, Local-Area, and the Sensory-Area Networks (S.-L. Wu & Y.-C. Tseng, Eds.). USA: Auerbach Publications. Retrieved January 30, 2009

Links to other blogs in this project

Tags: , , , ,
Posted in Mobile Devices, Sahana, development | No Comments »

Creating REST Web Service

Tuesday, December 9th, 2008

by Phavanhna Douangboupha

Representational State Transfer (REST) is a web service that offers many advantages compared to Simple Object Access Protocol (SOAP) web service. REST can be a solution to mobile device web limitations. Amazon, EBay, and Yahoo are the examples of REST web services. REST service architect includes XML, HTTP, URI, and MIME type.

The first thing to consider when creating a REST is URI. Unlike URL, URI is suitable for REST since it points to a resource of a web service and hence does not change over time. Richards (2006) suggests a structure of URI for a web service.

A web service returns data in the form of XML format as defined by the service implementer (Richards, 2006). Therefore, different REST web services can have different XML format and there is no particular standard. MIME must be in the type of text/xml for XML (Content-type: text/xml).

HTTP methods that are commonly used for REST are GET, HEAD, POST, PUT, and DELETE (Create, Retrieve, Update, and Delete). Richards (2006) suggests to use GET and POST methods differently according to each functionality. He states that GET should only be used for retrieving a resource representation. In contrast, POST can be used for other operations rather than the resource retrieval including resource creation, medication, addition, and deletion. For security purposes, as a result of performing GET request, according to Gregorio (2004) and Richards (2006), there should not be any side-effects that users unaware of and therefore the implementation of GET method should be safe and idempotent. The idempotent method is the method that provides the same result every time a service is requested.

Apart from URI, data format and methods, we also have to consider the other types of web service status codes (Gregorio, 2004) – 2xx for success, 3xx for redirection, and 4xx for errors.

The next blog is going to address how REST will be used in the resource pooling and prediction project using handheld devices.

References

Gregorio, J. (2004, December 1). How to create a REST protocol. Retrieved December 8, 2008

Richards, R. (2006). Pro PHP XML and Web Services. New York, USA: Apress . Retrieved December 8, 2008, from Books24×7 database: http://library.books24×7.com.ezproxy.rit.edu/

Singh, M. P., & Huhns, M. N. (2005). Service-Oriented Computing: Semantics, Processes, Agents. England: John Wiley & Sons. Retrieved December 8, 2008, from Books24×7 database: http://library.books24×7.com.ezproxy.rit.edu/

Links to other blogs in this project

Tags: , , , , , ,
Posted in Best Practices, Mobile Devices, development, webs | 1 Comment »

Web-based resource tracking system implemented on a mobile device

Wednesday, October 29th, 2008

by Phavanhna Douangboupha

The objective of this project is to develop a prototype for an easy to use web-based resource tracking system implemented on a mobile device. It provides real time data to a decision maker so that he/she can effectively and efficiently monitor resources and access the situation accordingly. By the same token, emergency personnel (e.g. a doctor or a police man) has the advantage of system auto login without manual report upon their arrival to an affected location. The system architecture of the web-based resource tracking during a disaster or crisis situation can be seen below in Figure 1.

System architecture of Web-based resource tracking during a disaster or crisis situation
System architecture of Web-based resource tracking during a disaster or crisis situation

Figure 1: System Architecture of Web-based resource tracking during a disaster or crisis situation

Resources are, a human resource (e.g. a doctor, a policeman), a moving resource (an ambulance, a police car), and a building resource (e.g. a hospital).

The prototype includes three main applications – position tracking, resource management, and identity manager modules.

The resource management system consists of emergency classification, search, and alert systems. The project aims to design an easy to use user interface for the system so that users and decision makers can get to important information as quickly as possible. One of the solutions to such an objective is to have a classification of emergency combined with a recommendation system. The application utilizes the pre-existing data to recommend resources (what are required resources and their locations) for a certain situation such as flooding. Apart from the recommendation system, the system offers another search option, nearest search option, for users to search for required resources for the crisis that they have to manage.

The identified needed resource shall be alerted by the system. For a moving resource such as a doctor or an ambulance, the system should automatically provide routing or direction information to his/her GPS-enabled device. This functionality links to the position tracking application.

The second application is the position tracking application that consists of real time location update, routing, and the time statistic module. As a doctor responds to the system alert, his/her GPS enabled device will automatically send his current geographic X, Y coordinate location in thee form of an XML file. The XML file also includes the login id which is the unique device id. Before being passed through the network, the XML file is encrypted and only the system can decrypt the information (the identify manager module). As each resource travels toward the site, the decision maker will have a virtual map showing real time information about the resources. In addition, the system shall be able to provide a report on number of resources at each near by location. The routing information and the estimate time statistic prediction on when each resource will reach the site will also be an option on the decision maker’s screen. Using API technology, a virtual map is requested from a map server.

The system will make the use of the REST web-service to bridge the connection between the server and clients. The REST web-service and the WWW solution for the prototype are selected to avoid certain mobile specific standards. REST provides a solution for the mobile device system to interface with the system in manageable lightweight implementation. Since, REST utilizes URI namespace technology, it makes the application scalable and the data can be easily shared with different servers. In addition, REST uses HTTP and XML solutions and hence it is well understood by firewalls and security administrators.

Links to other blogs in this project

Tags: , , ,
Posted in Design, Logical Design, Mobile Devices, Physical Design, paradigms, webs | 4 Comments »

Resource pooling and scheduling systems during a disaster and/or crisis situation using a handheld device and the World Wide Web (WWW) technologies

Thursday, October 2nd, 2008

by Phavanhna Douangboupha

This is a brief and initial description of a proposal for resource pooling and scheduling systems during a disaster and/or crisis situation using a handheld device and the WWW technologies. The ideas are formed as a result of discussions with Prof. Jeff Sonstein (the Center for the Handheld Web, Department of Information Technology, Rochester Institute of Technology). The proposal is still at an early stage; hence all feedback and suggestions will be highly appreciated and are more than welcome. This proposal covers a lot of areas and will be narrowed down further after receiving feedback. If you are interested, please come back and read my next blog to see which direction (if I can decide) I will pursue.

The two main target user groups are emergency respond teams and general public. The following are possible scenarios of when the systems could be useful.

1. A medical doctor receives an alert that contains information about a disaster in the area on a handheld device. The doctor will then browse through the information provided on the device. The systems will provide information to the doctor as to the distance and time it would take to get to the location. The information will be updated in real time to alert users about any possible traffic issues and unexpected conditions, for instance, when roads are closed or cut off unexpectedly during the disaster. The systems will also display the current situation: an authorized user would be able to see the latest on-site resource information (e.g. how many doctors are already on-site). Upon the doctor’s arrival, the device will report his/her location directly to the central system, therefore eliminating the need for personal reporting. The information will be shared among disaster command centers. The tracking system will automatically be seen by authorized people such as the mayor or emergency personnel in charge. They would use the information to come up with an appropriate plan.

2. A crisis manager on- or off-site requires a resource management system to provide him/her with information needed to effectively assess the situation. Tiesyte, D., & Jensen, C. S. (2008, April) presents a technique for efficient cost-based tracking of scheduled vehicle journeys. They believe that geographical positioning and wireless communication technologies are useful to the managers and users of the fleets on vehicle status tracking. By the same token, data from existing centralized systems of resource pooling and scheduling systems will be highly critical during a crisis. It will support a specific subset of management decisions. For instance, how many medical doctors have already arrived on-site, how many more are required, how many more are on their way, and how much time it would take to get to the site?

3. A victim or a citizen who needs help, which could be as simple as needing evacuation from an affected area. During disasters, it is expected that wired communication, such as a landline, would be cut. Consequently, mobile communication is known to be a solution for such situations. Therefore, the technology should be easy to use; it should enable fast interaction between users and the systems during an emergency.

4. A citizen who responds to the crisis by sharing information and resources with other users. For instance, someone who happens to be in the same area and is willing to pick up neighbors who need to be evacuated. This would be particularly crucial in remote areas where help from emergency personnel may take more time to arrive. During high demand resource situations, sharing of resources among citizens (wherever possible and reasonable) will not only reduce the requirement for government/agency resources, but more importantly, it will assure the faster delivery of assistance. Having said that, there might be issues relating to trust and security which could be further investigated.

5. A father or a family member who uses the handheld device to locate or track their loved one’s current location. As suggested by Prof. Jeff Sonstein, during a disaster, it is possible for family members to get separated due to various reasons. The ability to track and communicate with members of their family could ease their anxieties somewhat.

6. Citizens who are interested in the current status of the crisis.

The idea of the project is to utilize handheld devices and WWW technologies combined with user generated content during a disaster or a crisis situation. The technology is a tool to support resource pooling and scheduling. To implement this system, it is required to have a web application to interact with users and accept or grab data from various sources. The data will then be analyzed to feed into the central data source. Consequently, suggestions (predictions) and plans for the resource sharing and pooling will be generated. For example, the system shall have an algorithm to predict, based on data, a near-future resource requirement such as how many medical doctors will be needed or how many rescue vehicles will be required. The number of vehicles to send to suburb A might be less compared to suburb B, if people in suburb A have already been evacuated, or already have enough shared resources (cars) among them. Additionally, information about which cities can pool resources and the estimated travel times to deliver the resources will help a mayor or a chief of police address the situation more effectively. The project will make use of existing technologies such as GPS systems, Google map, Ushahidi resource, and the location-aware routing prediction method such as in Zhang, Q., Mayes, K., & Markantonakis, K. (2005) and Tiesyte, D., & Jensen, C. S. (2008). The system will provide information regarding possible traveling routes from point A to point B on a handheld device and give notification on any problematic traveling routes for users, especially when urgency and timing are highly critical. The sensitive information will only be shared among authorized users such as policemen, medical personnel, firemen, rescuers, emergency teams, etc. This information will be pulled from all existing databases. Examples of such information include personnel information and city resource information. Other kinds of data required include scraping from other online existing sources that will not be stored on a database. Nevertheless, a derived report or the result analysis data could be stored on the database for further situational analyses. Lastly, the handheld device should have a simple user interface not only to provide information to users but also to allow users to share their information. These are the three possible sources of data – private or government data, data that are already existing online (e.g. Ushahidi), and user-generated contents.

Possible Users:

  • A medical doctor, a policeman, a fireman, emergency personnel, etc.
  • A mayor or a police chief on location or off-site
  • A citizen in the area who needs/requests help
  • A citizen in the area who is available to help/has resources to share
  • A citizen who is interested in the situation or needs information about crisis for various reasons.

Some Advantages:

  • Accessibility – mobile
  • Sharing data and information anytime and anywhere; data sharing among citizens – user-generated content. For instance, an accident might block traffic on a small road where it is less likely to be reported. This real-time information could be shared among users.
  • Scheduling and sharing resources
  • GPS location
  • Prediction systems to identify the best resource sharing and pooling to report to a decision maker
  • Prediction systems to provide several directions to users according to their GPS’s location

Possible Connection Structures:

  • Client to Client
  • Client to Server
  • Server to Client
  • Server to Server.

Some Issues/Concerns:

  • How to integrate data from different sources?
  • How to check/confirm data integrity from user-generated content?
  • What algorithm to use for the prediction systems?
  • System Security Issues
  • Is the scope of the project too broad/big? Basically, this idea can be seen from the perspective of resource management. But it also includes the general user’s functionalities during a crisis.

Some Current Technologies:

  • An intelligent and situation-aware pervasive system to support debris-flow disaster prediction and alerting in Taiwan2.
  • A wireless First Responder Handheld Device for Rapid Triage, Patient Assessment and Documentation during Mass Casualty Incidents1.
  • Cost-based tracking of scheduled vehicle journeys3.
  • Ushahidi [An opensource project for handheld device where people can submit crisis information to the website]4.

References (Annotated Bibliography)

1. Killeen, J. P., Chan, T. C., Buono, C., Griswold, W. G., & Lenert, L. A. (2006).

A Wireless First Responder Handheld Device for Rapid Triage, Patient

Assessment and Documentation during Mass Casualty Incidents. AMIA Annu Symp

Proc, 429-433. Retrieved September/October 30, 2008, from American

Medical Informatics Association Web site: http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=1839472

This article describes systems that provide wireless handheld device solutions with an electronic medical record in a mass casualty incident or a disaster. This paper shows how important accessible and timely information is during a critical situation where essential communications are highly important. Consequently, the technology is shown to be a valuable tool in particular where there are limited resources.

2. Kung, H.-Y., Ku, H.-H., Wu, C.-I., & Lin, C.-Y. (2008, January). Intelligent and situation-aware pervasive system to support debris-flow disaster prediction and alerting in Taiwan. Journal of Network and Computer Applications, 31(1), 1-18 . Retrieved September 12, 2008, from The ACM Portal 2008 Web site: http://portal.acm.org/‌citation.cfm?id=1321783.1321931&coll=&dl=ACM

This is one of the most current academic papers in the field of disaster prediction and alerting mobile Internet communication. The article contains figures of the network and system architecture that provide a broad perspective on how the systems can be implemented using mobile appliances and the Internet. Consequently, this shows a solution of how mobile appliances and Internet technologies can be applied to solve a real life problem.

3. Tiesyte, D., & Jensen, C. S. (2008, April). Efficient Cost-Based Tracking of Scheduled Vehicle Journeys. IEEExplore, 9-16. Retrieved September 12, 2008, from The Ninth International Conference on Mobile Data Management Web site: http://ieeexplore.ieee.org/‌iel5/‌4511414/‌4511415/‌04511429.pdf?…[more]

This paper provides an example of how a mobile device solution can be used in developed countries. This provides a different point of view on the topic. It is also a technical paper that contains a general algorithm for the vehicle journeys system and its experimental results. This paper also states several future research directions on the topic.

4. Ushahidi [An opensource project for handheld device where people can submit crisis information to the website.]. (n.d.). Retrieved September 11, 2008, from Ushahidi.com Web site: http://www.ushahidi.com/

This site has links to articles and current solutions for mobile disaster warning systems. The website is also a forum where the technology discussions can be viewed.

5. Zhang, Q., Mayes, K., & Markantonakis, K. (2005, November). A user-centric m-payment solution. IEEE Mobility Conference 2005. Retrieved September 10, 2008, from IEEE Xplore Web site: http://ieeexplore.ieee.org/‌iel5/‌11013/‌34698/‌01656674.pdf?…[more]

The article proposes a user-centric design approach for mobile payment technology. From the solution, several technologies can be identified. It provides a technical solution which can be used to investigate how to develop the technology.

Links to other blogs in this project

Tags: ,
Posted in Mobile Devices, webs | 14 Comments »