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?