A simple project status report has now been posted on the Project documents page. The report is to be presented on Monday, March 27, 2006.

(…and it’s easy to see that I’m not late at all with the status report – this text was posted at 08:59, with deadline at 09:00 )

Update 2006-03-27: Fixed link to status report; it was referring to wrong file..

Been doing some programming these last days (finally!), which means that I am on schedule with the project. Added functions to select a track and view detailed information, and also to type in a comment and send it back to the server using HTTP POST. Created simple status indicators showing track load status and map load status (none, currently loading or error).

Used to have the IP address of the server (my laptop) hard-coded in the client, but this didn’t work well as my laptop changes its IP adress frequently. Added user-interface to type in URL of server manually. This user interface appears as the application is started, to avoid lagging problems (described below). The URL is stored in persistent storage, so that as long as the server keeps the same IP adress, the user only has to press OK on this dialog.

Frustrating issues
- The J2ME user interface components (javax.microedition.lcdui.*), especially some Command items, are handled strangely on Nokia phones. It creates a menu “options”, even if it is only one item to put there..
- Seems that if a HTTP server is not available, all threads are frozen in a time-out. However, as far as I can tell, this only happens on the simulators, and not the real phone.
- In HTTP POST requests, NetBeans mobility pack DefaultColorPhone simulator uses “Transfer-Encoding: chunked”, whereas Nokia uses normal encoding. My server now handles both, but who knows what will appear in other mobile devices, “Transfer-Encoding: gzip”?
- Decided to not rely on the time on the client. Using System.currentTimeMillis() gives a different results than expected on the Nokia phones. After looking into the problem, it seems to me that the phone uses a “GMT-13″ timezone..
- Unable to draw using transparency. Had to use a png to create a simple cursor ..

Joyful moments
- Run multiple clients, and see that a comment written on one client appears on the other
- Found the reason why no tracks were visible on the Nokia client (time problems..)
- Start up the client, and see for the first time that information has been sucessfully recovered from persistent storage.
- See my .png picture appear on screen!

Below are a couple of screendumps from a simulator:

Screen showing map and simulated tracks. Notice the “T” in the upper right corner. This indicates that the application is currently loading tracks. The red brackets are the track selector.

Screen showing track details. The user can type in comment and send back to server.

Added a new page to the website, with links to the project documents. Started writing on the main project report, which can also be found on the “project documents” page. Writing in MS Word for now, but we’ll se if I switch to LaTeX later..

Completed a more thorough project description. The file is available here.

Some tips for my co-students struggling with IEEE references and Latex: Download the IEEE bst file from IEEE author tools. If you use Miktek, then copy IEEEtran.bst to [texmf]/bibtex/bib. Run “initexmf -u” to refresh the configuration (or something..!). In the .tex document, use “\bibliographystyle{IEEEtran}”. In the .bib file, add the entry “url={My url}” for webpages. Who said Latex is easy!?

I tried to use RefWorks, but found it cumbersome to export the references each time I modified them, in order to use them from Latex. Also, the names of the exported references are not logical. This makes the references in the .tex document more difficult to read. So I ended up with editing the .bib file manually.

I’ve been working on the client-side of the system. Current functions:
– Map with pan and zoom (See earlier post!)
– Tracks received from server through HTTP – update every 30 seconds or so
– Tracks presented on map
– Tracks are predicted according to speed and course, screen update every 5 seconds

A word on internal representation on data: uses two ‘double’ values to represent a position (latitude and longitude). Represented as “degrees, decimal degrees”. A map view is defined by the center position (latitude/longitude) and the range per pixel (meters per pixel). This was chosen over the “bounding box” representation, as I believe the “center/range per pixel” representation makes it easier to calculate positions anywhere on the screen.

My calculations makes the following assumptions:
For latitude values: one degree = 60 minutes = 60 nautical miles = 60*1852 meters.
For longitude values, the calculations are slightly more complicated, as the width of each degree decreases further north/south: one degree = 60 minutes = 60 nautical miles * cos(latitude) = 60*1852*cos(latitude) meters

The test and development environment is getting ready. Have decided to develop the client as a MIDP 2.0 midlet, which enables it to run on my Nokia 6230, which is a Nokia series 40 cell phone.

The server will be developed using the .NET framework, and run on a Microsoft Windows computer. This is to match the environment of the VTS system, and ease the integration.

For developing the client side, NetBeans 4.1 with the Mobility Pack provides a good IDE for Midlet development. For testing, Nokia 6230 simulator is used, as well as the real phone. A Nokia datacable is used for fast transfer of the Midlet to the phone.

Microsoft Visual Studio and C# will be used for the server-side. Since HTTP probably will be used for client-server communication, web browsers as well as the client itself can be used for testing. In order to give an impression of the Mobile VTS system without running an entire VTS system in the background, the server will be able to simulate ships.

I am thinking about not using a position input (GPS) on the client, which makes the development and (most of all) the testing easier..
All in all, the test and development environment is in place, and I have started to experiment with the (to me) unfamiliar parts of the project (see previous post!)

I’ve started experimenting a bit on the mobile client, a MIDP 2.0 midlet (more on this later!). The first function is to retrieve and display maps.. It turned out to be quite easy! Using the Web Map Service on onemap.org, maps can be downloaded as images. A Image object can easily be constructed from the HTTP data stream.. try the following code snippet:

HttpConnection con = (HttpConnection)Connector.open("http://globus.hiof.no/geoserver/wms?request=GetMap&layers=gshhs_f_1&styles=green&Format=image/png&width=500&height=600&bbox=10,59,11,60.5");
if(con.getResponseCode()==200) {
InputStream ins = con.openInputStream();
Image image = Image.createImage(ins);
}

“bbox” is the bounding box of the map area, given in degrees. “width” and “height” is the size of the map, in pixels. Format can be at least image/jpeg or image/png (I prefer png – smaller files without loss of data..) Similar approach can be used to retrieve maps from a number of different Web Map Services

For some reason, it seems that the map service sometimes fills the land area with green and the water with white, and other times the water is green and land is white. Perhaps the drawing routine assumes that the upper left pixel is water, and fills according to that assumption?

Here is the current plan for the “Mobile Vessel Traffic Display” project. The plan consist of a project plan document and a Schedule.

Navtek utvikler og leverer produktet Navtims (se www.navtek.no, produkter, Navtims), som er et VTS-system til bruk for havne- eller kystovervåkning.

Som prosjekt ønsker jeg å lage en mobil applikasjon som kan presentere data fra dette VTS-systemet, dvs båter med posisjon, kurs, fart, navn etc. Tanken er at brukeren, med en mobil enhet og GPS, skal se et kart med sin egen posisjon i midten, og båtene som befinner seg i nærheten tegnet inn på kartet. Ved hjelp av GPS kan den mobile enheten automatisk spørre om data for området hvor brukeren befinner seg. Brukeren kan også til en viss grad manipulere på disse dataene, som for eksempel å legge inn identiteten til et ukjent fartøy.

Kart hentes fra en internettbasert tjeneste.

Figur som viser de viktigste elementene systemet

Har kikket på litt forskjellig saker rundt Google Earth, og har funnet frem følgende:

Mest brukbare
Google Maps doctor search
Kart over leger i USA, med mulighet for å søke utfra bosted, leges spesialitet osv

Mest imponerende
Kart over jordskjelvområde i Pakistan, med informasjon til hjelpearbeidere og pårørende..

Mest orginale
Oversikt over mord i Rochester New York

Størst kommersielt potensial
Informasjon om England, inkludert undergrunns-stasjoner, interessante steder, webkameraer osv. Nyttig for turister!

Minst nyttige
Noen steiner eller lignende som minner om en drage!

Dummeste
En person har observert noe helt spesielt: Varsellys som viser omkjøring/feltbytte grunnet veiarbeid.