Archive for Links

sdfjsdlkfjlsd

dslfklsdjfsdkfjsldfksdfkljsdf sdf sd fsdf sdf

Leave a Comment

Progress report week 19 and 20

The last two weeks has been used to do the following:

  • Add synchronization support to the mobile client which means that it is possible to send routes and results from the mobile client to the repository
  • Add a light weight implementation of the repository and the web client
  • Perform a usability test on the mobile client

In addition, the living document has been evolved to include this information. Currently, the living document is missing abstract, conclusion and description of the technologies used and how the fetching of location information is performed. This will be added this week.

Leave a Comment

Progress report 18

The last week has been used to update the report. I have made some small changes to the introduction and the design chapters and started writing about the implementation.

Leave a Comment

Progress report week 17

Not much work has been done in the previous week to the client and the report. In the client, I have changed the way the LocationProvider class handles threading, and in the report, I have added some information about the implementation, but it is still incomplete. Therefore, the changes have not been made accessible to others.

Leave a Comment

Progress report week 16

It has been a couple of weeks since last progress report due to easter vacation. However, the client has evolved and I have partly succeeded with the goal of finishing the implementation of the client.

The following functionality has been added in the easter:

  • Browsable and zoomable map component which in addition supports moving in the same direction as the jogger moves.
  • Saving and loading results.
  • Draw the jogger and the opponent on top of the map as well as their tracks
  • Calculating the distance of results and routes.

In addition, the off-course algorithm, notification of the user about the results, and the calculation of the difference in time between the jogger and the opponent have been implemented. However, these parts have not been tested, so there may be faults in the implementation; The following week will be used to test these parts.

Most of the implementation of joggerlogger is done, but the report have not progressed in the same pace. Therefore, this will be the main focus for next weeks.

Leave a Comment

Progress report week 13

Last week, I wrote that I had problems with getting the SRS=EPSG:4326 to work with the WMS I used. These problems were quickly resolved after a talk with Gunnar Misund, the lecturer for the course LAS (Location aware systems). It turned out that I had bugs in both places where I tried the map service. In the first, I managed to switch some of the arguments for the bounding box so that the min and max long/lat were in the wrong order. In the second, which where in joggerlogger, I had a bug with how I handled the long/lat-values, so I ended up switching them which again resulted in an invalid bounding box.

Now joggerlogger can download images from a WMS and display them on the mobile. In addition, it supports drawing the outline of the route on top of the map. However, the application can only display the whole route at once on a screen and does not have the ability to zoom or move in direction the jogger moves in. These tasks will be the focus for the next week.

Leave a Comment

Evaluation of the project Where R U

I have evaluated the progress of the project Where R U. The evaluation is written in Norwegian and can be found here.

Leave a Comment

Progress report week 12

Not much progress have been made in the project since last week’s status report. I have started exploring WMS and I have managed to download maps from a WMS to the mobile emulator. However, I have had difficulties with downloading maps for the bounds I specify. Apparently, the WMS I use supports only the Spatial Reference System(SRS) EPSG:32633 and not EPSG:4326, which means that the bounding box must be specified in UTM format and not lat/long. The problem with this is that I currently use lat/long as the format for the coordinates on the mobile phone so some form of conversion must be done.

Leave a Comment

Status report

The progress of the project is described below where the implemented and the planned functionality is described. The living report for the project can be found here and the power point (in Norwegian) for the status report presentation, which will be held on Monday, can be found here.

Work done

The main focus will be on the mobile client and thus I have started working on this part of joggerlogger. The following parts have been implemented.

  • Save settings in RMS
  • Connect to the GPS and create a route from the coordinates fetched from it
  • Save routes locally on the mobile phone
  • Display a simple presentation of a route (must be improved)

Future work

There is still a lot work that has to be done and the planned functionality of each part of joggerlogger is presented below. The functionality is numbered according to order which the different functionality will be implemented.

Mobile client

  1. Display details about a route like average speed, length and time used
  2. Improve the visual representation of the routes
  3. Receive and fetch routes and results from the server
  4. Notify about virtual competitors
  5. Notify about off-course movement

Web Server

  1. Save routes and results. (Probably a simple solution using only text-files

Web client

  1. Find routes and results and add those to the account of the user

Leave a Comment

Progress report 11

Last week have been used to implement some of the proposed functionality of the mobile client. I have added the ability to store settings so that the address for the gps receiver do not have to be entered every time. In addition, the mobile client can now record a route and store it to the file system of the mobile using jsr-75 (file and pim api). However, this part is not finished since a better GUI must be built.

The recording of the route have been tested two times and it seems to work. The recorded routes were displayed using a simple canvas class that draws the outline of the route. Currently, the route which is drawn is scaled to fit the screen of the mobile, but a smarter solution will be added.

Leave a Comment

Older Posts »